테스트 사례 정의 defining-your-test-cases
테스트 사례는 다음을 기반으로 해야 합니다.
사용 사례
- 이는 배우(특정 행동을 개시하는 역할)와 시스템 간의 상호 작용 측면에서 필요한 기능을 정의합니다.
- 사용 사례는 고객이 정의해야 합니다.
자세한 요구 사항 사양
- 모든 기능 및 성능 요구 사항을 테스트해야 합니다.
이 테스트는 다음을 명확히 정의해야 합니다.
- 사전 요구 사항: 특정 시스템, 구성 또는 테스터 경험이 여기에 포함될 수 있습니다.
- 적절한 수준의 세부 정보에서 따라야 할 단계입니다.
- 예상 결과.
- 합격 또는 불합격 기준을 지웁니다.
반복적인 작업을 없애기 때문에 테스트 사례를 자동화할 것이라는 전망은 매력적입니다.
수동 테스트와 자동화된 테스트 manual-versus-automated-tests
그러나 테스트 사례를 자동화하는 것은 상당한 투자이므로 다음과 같은 몇 가지 측면을 고려해야 합니다.
- 설정 및 구성하는 데 시간, 노력 및 경험이 필요합니다.
- 브라우저를 기반으로 하는 경우 브라우저 업데이트를 설치할 때 문제가 발생할 위험이 증가하므로 수정하는 데 시간이 더 걸립니다.
- 대형 프로젝트에서만 가능합니다.
- 테스트를 위해 또는 장기 릴리스 계획에서 여러 릴리스가 생성되는 경우에 유용합니다.
특정 측면 테스트 testing-specific-aspects
AEM을 테스트할 때 특히 중요한 몇 가지 특정 세부 사항이 있습니다.
작성자 및 Publish 환경
환경에서 다루지만 테스트와 관련하여 AEM의 결정 요소를 강조 표시할 필요가 있습니다.
AEM을 두 개의 애플리케이션으로 간주합니다.
-
작성자 환경
이 인스턴스를 통해 작성자는 컨텐츠를 입력하고 게시할 수 있습니다.
여기에는 예측 가능한 소규모 사용자 집합이 있으며, 이에 따라 특정 기능과 성능이 중요합니다. -
Publish 환경
이 인스턴스는 방문자가 액세스할 수 있도록 게시된 양식으로 웹 사이트를 제공합니다.
일반적으로 트래픽 볼륨이 항상 100% 예측 가능한 것은 아닌 더 큰 사용자 집합이 있습니다. 요청에 응답할 때 성능은 여전히 중요합니다. 캐싱 및 로드 밸런싱도 고려해 보십시오.
그와 동일한 소프트웨어이지만
- 다른 목적에 봉사하다
- 기능 및 성능에 대한 다양한 요구 사항
- 다르게 구성됨
- 별도로 조정됨
- 각 시험에는 나름의 합격 시험이 있다
다시 말해, 그들은 별도로 그리고 다른 검사 사례와 함께 검사되어야 합니다.
개인화
개인화를 테스트할 때 동작을 입증하기 위해 여러 사용자 계정을 사용하여 각 개별 사용 사례를 반복해야 합니다.
캐싱이 올바른지 확인하십시오.
Dispatcher
대부분의 프로젝트는 캐싱 및 로드 밸런싱을 위해 Dispatcher을 설치합니다.
테스트는 어려우며(캐싱은 다양한 수준 및 다양한 위치에서 발생) 블랙박스 기반으로 수행되어야 합니다. 을(를) 테스트하기 위한 주요 측면은 다음과 같습니다.
-
정확도
웹 사이트 방문자가 컨텐츠 업데이트를 볼 수 있도록 합니다. -
연속성
서버 하나가 종료된 후에도 웹 사이트를 계속 사용할 수 있는지 확인합니다. -
클러스터
다음을 제공하는 데 사용됩니다.-
장애 조치
한 서버가 실패하면 클러스터의 다른 서버가 처리를 대신합니다. -
성능
전체 장애 조치(failover)를 통한 로드 밸런싱은 클러스터의 성능을 향상시킵니다.
고객 프로젝트에 사용할 경우 구성을 올바르게 작동하는지 확인하기 위해 클러스터를 테스트해야 합니다.
-
타사 소프트웨어 테스트 testing-third-party-software
AEM에 인터페이스된 모든 타사 소프트웨어는 세부 요구 사항 사양에 참조됩니다.
필요한 모든 테스트(정의된 범위에 따라 다름)를 분석하고 클린 테스트를 획득해야 합니다.