테스트 사례 정의

테스트 케이스는

사용 사례

• 이러한 정의는 행위자(특정 작업을 시작하는 역할)와 시스템 간의 상호 작용에 대해 필수 기능을 정의합니다.
• 사용 사례는 고객이 정의해야 합니다.

세부 요구 사항 사양

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

테스트는 다음을 명확하게 정의해야 합니다.

• 사전 요구 사항;특정 시스템, 구성 또는 테스터 경험에 대해 다룹니다.
• 따를 단계;적절한 수준.
• 예상 결과.
• 합격 또는 불합격 기준을 지웁니다.

테스트 케이스를 자동화하는 것은 반복적인 작업을 없앨 수 있기 때문에 분명히 매력적입니다.

수동 테스트 및 자동화된 테스트

그러나 테스트 케이스를 자동화하는 것은 상당한 투자 사항이므로, 특정 측면을 고려해야 합니다.

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

특정 측면 테스트

AEM 테스트 시 특히 관심 있는 몇 가지 세부 사항이 있습니다.

작성 및 게시 환경

그러나 환경에서 다루면 테스트와 관련하여 AEM의 결정 요소를 강조할 가치가 있습니다.

AEM은 다음과 같은 두 가지 애플리케이션으로 간주해야 합니다.

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

소프트웨어와 동일하지만 다음과 같습니다.

• 다른 목적을 위해
• 기능 및 성능에 대해 서로 다른 요구 사항이 있음
• 다르게 구성됨
• 별도로 조정
• 각각 자체 수락 테스트 세트를 갖게 됩니다.

즉, 테스트 케이스를 별도로 테스트해야 합니다.

개인화

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

캐싱에 올바른 비헤이비어가 있는지 확인해야 합니다.

디스패처

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

테스트는 매우 어려우므로(캐싱은 다양한 레벨과 위치에서 수행) 블랙박스로 수행해야 합니다. 테스트의 주요 이점은 다음과 같습니다.

• 정확도;웹 사이트 방문자가 컨텐츠 업데이트를 볼 수 있는지 확인합니다.
• 연속성;하나의 서버가 종료되어도 웹 사이트를 계속 사용할 수 있는지 확인합니다.
• ​​ClustersClusters는 다음을 제공하는 데 사용됩니다.
  • 장애
    조치한 서버에서 장애가 발생하면 클러스터의 다른 서버가 처리를 담당하게 됩니다.
  • 전체
    장애 조치를 통한 PerformanceLoad 밸런싱은 클러스터의 성능을 향상시킵니다.

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

타사 소프트웨어 테스트

AEM에 연결된 제3자 소프트웨어는 세부 요구 사항 사양에 명시되어 있습니다.

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