테스트 사례 정의 defining-your-test-cases

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

사용 사례

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

자세한 요구 사항 사양

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

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

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

반복적인 작업을 없애기 때문에 테스트 사례를 자동화할 것이라는 전망은 매력적입니다.

수동 테스트와 자동화된 테스트 manual-versus-automated-tests

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

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

특정 측면 테스트 testing-specific-aspects

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

작성자 및 Publish 환경

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

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

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

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

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

  • 다른 목적에 봉사하다
  • 기능 및 성능에 대한 다양한 요구 사항
  • 다르게 구성됨
  • 별도로 조정됨
  • 각 시험에는 나름의 합격 시험이 있다

다시 말해, 그들은 별도로 그리고 다른 검사 사례와 함께 검사되어야 합니다.

개인화

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

캐싱이 올바른지 확인하십시오.

Dispatcher

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

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

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

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

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

    • 장애 조치
      한 서버가 실패하면 클러스터의 다른 서버가 처리를 대신합니다.

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

타사 소프트웨어 테스트 testing-third-party-software

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

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

recommendation-more-help
19ffd973-7af2-44d0-84b5-d547b0dffee2