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