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

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

Ramona Schwering

이전 게시물에서는 테스트 전략, 애플리케이션 테스트에 필요한 테스트 수, 리소스를 염두에 두고 결과의 확신을 얻기 위해 가장 적합한 테스트를 찾는 방법을 알아보았습니다. 그러나 이는 테스트해야 할 정도만 알 수 있습니다. 정확히 무엇을 테스트할지 결정해야 합니다. 다음 세 가지 기준은 테스트에서 예상되는 결과를 이해하고 가장 적합할 수 있는 테스트 유형과 세부정보 수준을 확인하는 데 도움이 될 수 있습니다.

1. 나의 행복한 삶을 돌보세요. 애플리케이션에서 가장 일반적이거나 주요한 사용자 스토리로, 사용자가 오류를 매우 빠르게 발견합니다.
2. 세부정보의 수준을 신중하게 결정합니다. 취약한 사용 사례나 오류로 인해 큰 피해를 야기할 수 있는 부분에 대해 자세히 설명합니다.
3. 가능하면 단위 테스트, 통합 테스트와 같은 하위 수준 테스트의 우선순위를 상위 수준 엔드 투 엔드 테스트보다 우선합니다.

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

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

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

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

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

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

테스트 경로: 일반적인 종류의 테스트 사례

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

첫 번째는 가장 잘 알려져 있으며 이미 사용 중일 수 있습니다. '행복한 하루 시나리오' 또는 '골든 패스'라고도 하는 만족스러운 경로입니다. 기능, 애플리케이션 또는 변경사항의 가장 일반적인 사용 사례(고객에게 맞는 방식)를 정의합니다.

테스트 사례에서 다루어야 할 두 번째로 중요한 테스트 경로는 이름이 암시하는 것처럼 불편하기 때문에 생략되는 경우가 많습니다. '무서운 길', 즉 네거티브 테스트입니다. 이 경로는 코드 오작동을 일으키거나 오류 상태로 전환되는 시나리오를 타겟팅합니다. 이해관계자 또는 사용자에게 높은 위험을 가하는 매우 취약한 사용 사례가 있는 경우 이러한 시나리오를 테스트하는 것이 특히 중요합니다.

알고 싶고 사용을 고려할 만한 다른 경로도 있지만 일반적으로 덜 사용됩니다. 다음 표에 이러한 내용이 요약되어 있습니다.

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

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

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

테스터가 작성한 클래식 테스트 사례에는 테스트의 내용을 파악하고 테스트를 실행하는 데 도움이 되는 특정 데이터가 포함됩니다. 일반적인 테스터는 자신의 테스트 활동을 표에 기록합니다. 이 단계에서는 두 가지 패턴을 사용하여 테스트 사례를 구성하고 나중에 테스트 자체를 구성할 수도 있습니다.

• 정렬, 동작, 어설션 패턴. '배치, 행동, 어설션'('AAA' 또는 '트리플 A'라고도 함) 테스트 패턴은 테스트를 세 가지 개별 단계로 구성하는 방법입니다. 즉, 테스트 배열, 테스트 수행, 마지막으로 결론을 도출하는 것입니다.
• 주어진 시간, 그 후에는 패턴으로 표현됩니다. 이 패턴은 AAA 패턴과 유사하지만 행동 중심 개발에 뿌리를 두고 있습니다.

향후 기사에서는 테스트 자체의 구조를 다루는 즉시 이러한 패턴에 대해 자세히 다루겠습니다. 이 단계에서 이러한 패턴에 대해 자세히 알아보려면 정렬-행-어설션: 좋은 테스트 작성을 위한 패턴 및 두 가지 도움말을 참고하세요.

이 문서에서 얻은 모든 내용에 따르면, 다음 표에는 전형적인 예시가 요약되어 있습니다.

자동 테스트에서는 의심의 여지 없이 도움이 되긴 하지만 테스터가 필요로 하는 방식으로 이러한 모든 테스트 사례를 문서화할 필요는 없습니다. 주의하면 테스트에서 이 모든 정보를 찾을 수 있습니다. 이제 이 전통적인 테스트 사례를 자동 테스트로 변환해 보겠습니다.