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