테스트 사례 정의

테스트 케이스는 다음을 기반으로 해야 합니다.

사용 사례

• 여기에서 작업자(특정 작업을 시작하는 역할)와 시스템 간의 상호 작용 측면에서 필요한 기능을 정의합니다.
• 사용 사례는 고객이 정의해야 합니다.

세부 요구 사항 사양

• 모든 기능 및 성능 요구 사항을 테스트해야 합니다.

테스트는 분명히 다음을 정의해야 합니다.

• 전제 조건;특정 시스템, 구성 또는 테스터 경험을 다룹니다.
• 따를 단계;적절한 수준의 세부 정보.
• 예상 결과.
• 통과 또는 실패 기준을 지웁니다.

반복 작업을 제거할 수 있으므로 테스트 케이스를 자동화할 가능성은 매우 매력적입니다.

수동 및 자동화된 테스트

그러나 테스트 사례 자동화는 중요한 투자이므로 특정 측면을 고려해야 합니다.

• 설정 및 구성하려면 시간, 노력 및 경험이 필요합니다.
• 브라우저를 기반으로 하면 브라우저 업데이트를 설치할 때 문제가 발생할 수 있습니다.수정하기 위해 추가 시간이 필요합니다.
• 큰 프로젝트에서만 가능해요
• 테스트용으로 또는 장기 릴리스 계획에서 여러 릴리스가 생성되면 좋습니다.

특정 측면 테스트

AEM을 테스트할 때 다음과 같은 몇 가지 특정 세부 사항이 특정 관심사에 해당합니다.

작성 및 게시 환경

그러나, 환경에서 다루더라도 테스트와 관련된 AEM의 결정 요소를 강조 표시할 필요가 있습니다.

AEM을 두 개의 애플리케이션으로 간주해야 합니다.

• 작성자 환경
  이 인스턴스를 사용하여 작성자가 컨텐츠를 입력하고 게시할 수 있습니다.
  여기에는 특정 기능과 성능에 중요한 소규모(er) 예측 가능한 사용자 세트가 있습니다.
• 게시 환경
  이 인스턴스는 방문자가 액세스할 수 있도록 게시된 형태로 웹 사이트를 제공합니다.
  이렇게 되면 일반적으로 더 많은 사용자 세트가 있으며, 트래픽의 양이 항상 100%는 예측할 수 없습니다. 요청에 응답할 때 여전히 성능이 중요합니다. 캐싱 및 로드 밸런싱도 고려해야 합니다.

이와 동일한 소프트웨어가 있지만,

• 다른 목적 제공
• 기능 및 성능에 대해 서로 다른 요구 사항이 있습니다
• 는 다르게 구성되어 있습니다
• 별도로 튜닝됩니다
• 각자 자기만의 수락시험을 보게 될 겁니다

즉, 테스트 케이스는 별도로 테스트해야 하며 테스트 케이스가 다릅니다.

개인화

개인화를 테스트할 때에는 여러 사용자 계정을 사용하여 각 개별 사용 사례를 반복하여 행동을 입증해야 합니다.

캐싱에 올바른 동작이 있는지 확인해야 합니다.

디스패처

대부분의 프로젝트는 캐싱 및 로드 밸런싱용 Dispatcher를 설치합니다.

테스트는 매우 어렵습니다(캐싱은 다양한 수준 및 여러 위치에서 발생함). 블랙박스를 기반으로 해야 합니다. 테스트해야 할 주요 사항은 다음과 같습니다.

• 정확성;웹 사이트 방문자가 컨텐츠 업데이트를 볼 수 있는지 확인합니다.
• 지속성;하나의 서버가 종료될 때 웹 사이트를 계속 사용할 수 있는지 확인하십시오.
• ​​ClustersClusters를 사용하여 다음을 제공합니다.
  • ​
    장애 조치(failover) 한 서버에 장애가 발생하면 클러스터의 다른 서버가 처리를 담당합니다.
  • ​
    전체 페일오버가 있는 PerformanceLoad Balancing은 클러스터 성능을 향상시킵니다.

고객 프로젝트에 사용할 경우 클러스터의 올바른 구성 작업을 확인하기 위해 테스트를 수행해야 합니다.

타사 소프트웨어 테스트

AEM에 연결된 타사 소프트웨어는 상세 요구 사항 사양에서 참조됩니다.

필요한 테스트(정의된 범위에 따라)는 분석 및 확보된 테스트를 정리해야 합니다.