답변.

자동 테스트 작업에서 올바른 구조는 그 효과성과 생명력의 기초입니다.

문제의 역사

이전에는 자동 테스트가 자주 단일화되고 밀접하게 연결된 스크립트로 작성되었습니다. 이는 유지 및 확장에 어려움을 초래했습니다. 테스트의 수 증가로 아키텍처의 중요성이 드러났습니다.

문제

명확한 구조가 없으면 다음과 같은 문제가 발생합니다:

해결책

테스트를 위해 명확한 추상화 수준을 사용하세요:

좋은 관행은 다음을 사용하는 것입니다:

# 구조의 예
/tests
  /features
    test_order_creation.py
  /steps
    order_steps.py
  /pages
    order_page.py

주요 기능:

함정 질문.

긴 엔드 투 엔드 테스트를 작성하는 것과 짧은 모듈 테스트를 작성하는 것 중 무엇이 더 나은가요?

종종 엔드 투 엔드만 선택하지만, 여러 종류의 테스트를 목표에 따라 조합하는 것이 중요합니다: 모든 수준(Unit, API, UI)은 품질 검증에 중요합니다.

테스트에서 텍스트 및 로케이터로 UI 검사를 동시에 사용할 수 있나요?

항상 올바른 것은 아닙니다: 두 방법을 동시에 사용할 수 있지만, UI의 변동성과 테스트의 논리가 이를 정당화할 때만 가능합니다. 자주 과도하며 유지 보수를 복잡하게 만듭니다.

자동 테스트를 작성할 때 테스트하는 소프트웨어 시스템의 구조를 완전히 복사해야 하나요?

아닙니다. 자동 테스트의 구조는 테스트 용이성에 중점을 두어야 하며, 응용 프로그램 구조를 정확히 복제하는 데 초점을 맞추어서 안 됩니다.

한 팀에서 자동 테스트를 한 사람이 작성했으며, 모든 테스트가 하나의 파일에 있었고, 각 테스트가 이전 단계들을 복사했습니다. 인터페이스가 업데이트될 때 모든 테스트에서 수동으로 버그를 수정했습니다.

장점:

단점:

다른 팀에서는 아키텍처 템플릿(단계, 페이지, 테스트 분리)을 도입했습니다. 새로운 직원들이 빠르게 이해하고 새로운 테스트를 신속하게 도입할 수 있었으며, 업데이트는 한 곳에서 이루어졌습니다.

장점:

단점: