테스트 사례 정의

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

사용 사례

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

자세한 요구 사항 사양

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

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

  • 사전 요구 사항: 특정 시스템, 구성 또는 테스터 경험이 포함될 수 있습니다.
  • 적절한 수준의 세부 정보에서 따라야 할 단계입니다.
  • 예상 결과.
  • 합격 또는 불합격 기준을 지웁니다.

반복적인 작업을 없앨 수 있기 때문에 테스트 사례를 자동화할 가능성은 분명 매력적입니다.

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

그러나 테스트 사례를 자동화하는 것은 상당한 투자이므로 다음과 같은 몇 가지 측면을 고려해야 합니다.

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

특정 측면 테스트

AEM을 테스트할 때 특히 중요한 몇 가지 특정 세부 사항이 있습니다.

작성 및 게시 환경

비록,에 다루어지지만 환경 테스트와 관련하여 AEM의 결정 요소를 강조 표시할 가치가 있습니다.

AEM을 두 개의 응용 프로그램으로 간주해야 합니다.

  • 다음 작성자 환경 이 인스턴스를 사용하여 작성자는 컨텐츠를 입력하고 게시할 수 있습니다.
    여기에는 예측 가능한 소규모 사용자 집합이 있으며, 이에 따라 특정 기능과 성능이 중요합니다.

  • 다음 게시 환경 이 인스턴스는 방문자가 액세스할 수 있도록 게시된 양식으로 웹 사이트를 제공합니다.
    일반적으로 트래픽 볼륨이 항상 100% 예측 가능한 것은 아닌 더 큰 사용자 집합이 있습니다. 요청에 응답할 때 성능은 여전히 중요합니다. 캐싱 및 로드 밸런싱도 고려해야 합니다.

그와 동일한 소프트웨어이지만

  • 다른 목적에 봉사하다
  • 기능 및 성능에 대한 다양한 요구 사항
  • 다르게 구성됨
  • 별도로 조정됨
  • 각자가 자기 자신의 합격 테스트 세트를 가질 것인가

다시 말해, 그들은 각각 다른 검사 사례와 함께 검사를 받아야 합니다.

개인화

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

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

디스패처

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

테스트는 어려우며(캐싱은 다양한 수준 및 다양한 위치에서 발생) 블랙박스 기반으로 수행되어야 합니다. 을(를) 테스트하기 위한 주요 측면은 다음과 같습니다.

  • 정확도
    웹 사이트 방문자가 컨텐츠 업데이트를 볼 수 있는지 확인합니다.

  • 연속성
    서버 하나가 종료된 후에도 웹 사이트를 계속 사용할 수 있는지 확인합니다.

  • 클러스터
    클러스터는 다음을 제공하는 데 사용됩니다.

    • 페일오버
      한 서버가 실패하면 클러스터의 다른 서버가 처리를 대신합니다.

    • 성능
      전체 장애 조치(failover)를 통한 로드 밸런싱은 클러스터의 성능을 향상시킵니다.
      고객 프로젝트에 사용할 경우 구성을 올바르게 작동하는지 확인하기 위해 클러스터를 테스트해야 합니다.

타사 소프트웨어 테스트

AEM에 인터페이스된 모든 타사 소프트웨어는 세부 요구 사항 사양에 참조됩니다.

필요한 모든 테스트(정의된 범위에 따라 다름)를 분석하고 클린 테스트를 획득해야 합니다.

이 페이지에서는