테스트 사례 및 우선순위 정의

테스트할 항목을 결정하고, 테스트 사례를 정의하고, 우선순위를 지정합니다.

Ramona Schwering

이전 게시물에서는 테스트 전략, 애플리케이션을 테스트하는 데 필요한 테스트 수, 리소스를 고려하면서 결과에 대한 신뢰도를 최대한 높이는 데 가장 적합한 방법을 찾는 방법을 알아봤습니다. 하지만 이 값은 테스트할 양에 대한 대략적인 개념만 제공합니다. 테스트할 항목을 정확하게 결정해야 합니다. 다음 세 가지 기준은 테스트에서 기대할 수 있는 결과를 파악하고 가장 적합한 테스트 유형과 세부정보 수준을 파악하는 데 도움이 될 수 있습니다.

1. 정상 경로를 관리하세요. 이는 애플리케이션의 가장 일반적인 또는 기본적인 사용자 스토리로, 사용자가 오류를 매우 빠르게 발견할 수 있습니다.
2. 세부정보의 수준을 신중하게 결정합니다. 사용 사례가 취약하거나 오류로 인해 큰 피해가 발생할 수 있는 경우 더 자세히 설명하세요.
3. 가능하면 상위 수준의 엔드 투 엔드 테스트보다 단위 테스트 및 통합 테스트와 같은 하위 수준 테스트를 우선시하세요.

이 도움말의 나머지 부분에서는 이러한 기준과 테스트 사례를 정의할 때 이러한 기준이 적용되는 방식을 살펴봅니다.

테스트 사례란 무엇인가요?

소프트웨어 개발에서 테스트 사례는 소프트웨어 프로그램 또는 애플리케이션의 효과를 확인하기 위해 고안된 일련의 작업 또는 상황입니다. 테스트 사례는 소프트웨어가 계획대로 작동하고 모든 기능이 올바르게 작동하는지 확인하는 것을 목표로 합니다. 소프트웨어 테스터 또는 개발자는 일반적으로 소프트웨어가 지정된 요구사항 및 사양을 충족하는지 확인하기 위해 이러한 테스트 사례를 만듭니다.

테스트 사례가 실행되면 소프트웨어는 일련의 검사를 실행하여 원하는 결과가 생성되는지 확인합니다. 테스트는 다음 작업을 실행합니다.

• 인증 소프트웨어가 오류 없이 작동하는지 철저히 확인하는 프로세스입니다. 생성된 제품이 필요한 모든 비기능적 요구사항을 충족하고 의도한 목적을 달성하는지 확인하는 것이 중요합니다. '제품을 올바르게 빌드하고 있나요?'라는 질문에 답변합니다.
• 유효성 검사 소프트웨어 제품이 필요한 표준 또는 상위 요구사항을 충족하는지 확인하는 프로세스입니다. 실제 제품이 예상 제품과 일치하는지 확인하는 작업이 포함됩니다. 기본적으로 '사용자 요구사항에 맞는 제품을 빌드하고 있나요?'라는 질문에 답하는 것입니다.

프로그램이 예상한 결과를 제공하지 못한다고 가정해 보겠습니다. 이 경우 테스트 사례가 메신저가 되어 실패 결과를 보고하고 개발자 또는 테스터가 문제를 조사하고 해결책을 찾아야 합니다. 검사 및 작업은 테스트 유형과 관계없이 컴퓨터가 따라가는 경로라고 생각하면 됩니다. 확인에 사용되는 입력 데이터 또는 조건 그룹을 '등가 클래스'라고 합니다. 테스트 대상 시스템에서 유사한 동작이나 결과를 가져와야 합니다. 테스트 내에서 실행되는 특정 경로는 다를 수 있지만 테스트에서 실행된 활동 및 어설션과 일치해야 합니다.

테스트 경로: 일반적인 테스트 사례 유형

소프트웨어 개발에서 테스트 사례는 특정 동작이 예상되고 테스트되는 코드 실행 시나리오입니다. 일반적으로 테스트 사례를 구성하는 시나리오는 세 가지가 있습니다.

첫 번째 방법은 가장 잘 알려져 있으며 이미 사용하고 계실 수도 있습니다. '해피 데이 시나리오' 또는 '골든 패스'라고도 하는 해피 패스입니다. 기능, 애플리케이션 또는 변경사항의 가장 일반적인 사용 사례, 즉 고객에게 적합한 작동 방식을 정의합니다.

테스트 사례에서 다루어야 하는 두 번째로 중요한 테스트 경로는 이름에서 알 수 있듯이 불편하여 종종 제외됩니다. '무서운 길', 즉 음성 테스트입니다. 이 경로는 코드가 오작동하거나 오류 상태로 전환되는 시나리오를 타겟팅합니다. 이러한 시나리오를 테스트하는 것은 이해관계자 또는 사용자에게 높은 위험을 부과하는 매우 취약한 사용 사례가 있는 경우 특히 중요합니다.

알아두고 사용을 고려해 볼 만한 다른 경로가 있지만 일반적으로 덜 사용됩니다. 다음 표에 요약되어 있습니다.

이러한 경로를 분류하는 방법에는 여러 가지가 있습니다. 일반적인 두 가지 접근 방식은 다음과 같습니다.

• 상응 파티션 나누기 테스트 사례를 그룹 또는 파티션으로 분류하여 등가 클래스를 만드는 데 도움이 되는 테스트 방법입니다. 이는 파티션의 한 테스트 사례에서 결함이 발견되면 동일한 파티션의 다른 테스트 사례에서도 유사한 결함이 발견될 가능성이 높다는 생각에 기반합니다. 특정 등가 클래스 내의 모든 입력은 동일한 동작을 나타내므로 테스트 사례 수를 줄일 수 있습니다. 등가 파티셔닝에 대해 자세히 알아보기
• 한계 분석. 경계 값 분석이라고도 하는 테스트 방법으로, 입력 값의 한도 또는 극단을 검사하여 시스템의 기능 또는 제약 조건 한도에서 발생할 수 있는 잠재적 문제나 오류를 찾습니다.

권장사항: 테스트 사례 작성

테스터가 작성한 기존 테스트 사례에는 수행하려는 테스트의 콘텐츠를 파악하고 테스트를 실행하는 데 도움이 되는 특정 데이터가 포함됩니다. 일반적인 테스터는 테스트 작업을 표에 문서화합니다. 이 단계에서 테스트 사례와 나중에 테스트 자체를 구성하는 데 도움이 되는 두 가지 패턴을 사용할 수 있습니다.

• 정렬, 실행, 어설션 패턴 '정렬, 실행, 어설션'('AAA' 또는 '트리플 A'라고도 함) 테스트 패턴은 테스트를 세 가지 고유한 단계(테스트 정렬, 테스트 실행, 마지막으로 결론 도출)로 구성하는 방법입니다.
• Given, when, then 패턴 이 패턴은 AAA 패턴과 유사하지만 동작 기반 개발에 뿌리를 두고 있습니다.

테스트 자체의 구조를 다루는 뒷부분에서 이러한 패턴을 자세히 다룰 예정입니다. 이 단계에서 이러한 패턴을 자세히 알아보려면 Arrange-Act-Assert: A pattern for writing good tests 및 Given-When-Then 도움말을 확인하세요.

이 도움말에서 얻은 모든 정보를 바탕으로 다음 표에 일반적인 예를 요약했습니다.

자동 테스트에서는 이러한 모든 테스트 사례를 테스터가 해야 하는 방식으로 문서화할 필요가 없습니다. 물론 그렇게 하는 것이 도움이 되기는 하지만, 테스트에 주의를 기울이면 이러한 모든 정보를 찾을 수 있습니다. 이제 이 기존 테스트 사례를 자동 테스트로 변환해 보겠습니다.