가이드라인: 테스트 케이스
이 가이드라인은 테스트 소프트웨어의 식별 및 디자인 방법을 설명합니다.
관계
기본 설명

설명

이해 당사자(stakeholder)가 소프트웨어에 대해 확실히 만족할 수 있게 하는 능력에 가장 큰 영향을 미치는 것은 프로젝트 팀이 이해 당사자의 기대에 대한 명확한 스펙을 가지고 있는지 여부입니다. 충분한 요구사항 스펙 세트가 있건 없건, 테스트 케이스는 이해 당사자의 기대를 검증하고 유효성을 검증할 수 있게 함으로써 이런 기대를 반영하게 하는 아티팩트 중 하나입니다.

유용한 요구사항 세트가 있는 경우 테스트 팀은 요구사항의 유효성을 적절하게 검증할 테스트를 계획할 필요가 있습니다. 요구사항에 대한 소프트웨어의 유효성 검증은 요구사항의 유형에 따라 다르게 수행될 수 있음에 유의하십시오. 예를 들어, 기능 및 성능 요구사항의 유효성을 검증하기 위한 소프트웨어 실행은 테스터가 자동화된 테스트 기법을 사용하여 수행하는 반면, 호스트 컴퓨터 시스템의 종료와 같은 구성 요구사항의 유효성 검증은 수동 테스트 기법을 사용하여 수행해야 할 수 있습니다.

모든 요구사항을 확인하지 못할 수 있으므로(또는 확인해야 할 책임이 없으므로) 현재 작업 노력의 범위에 대해 가장 적합하거나 중요한 요구사항에 초점을 맞춰야 합니다. 확인하려고 선택한 요구사항은 요구사항을 확인할 필요성, 위험성 및 비용 간의 밸런스가 되며 일반적으로 현재 반복의 범위로 제한됩니다.

요구사항은 테스트를 도출할 수 있는 중요한 소스이지만 유일한 정보 소스는 아닙니다. 사실, 많은 경우에 요구사항은 테스트가 개발되는 완전한 기반을 제공하기에 불충분합니다. 위험성, 제한조건, 기술, 변경 요청(결함) 및 장애 등과 같은 정보 소스에 기반한 테스트 케이스도 고려해야 합니다.
테스트를 도출할 수 있는 아이디어를 제안하는 방법에 대한 자세한 정보는 개념: 테스트 아이디어를 참조하십시오.

테스트 케이스 식별은 여러 이유로 유용합니다.

  • 테스트 케이스는 실제 테스트를 디자인하고 구현하기 위한 기반으로 사용될 수 있습니다. 시간을 들여 테스트 케이스를 고려하면 디자인 및 구현 요구사항을 보다 잘 이해하는 데 도움이 되며 디자인 및 구현 타스크에 소모되는 시간을 절약할 수도 있습니다.
  • 일부 테스트는 매우 복잡하거나 상세합니다. 이런 특성을 가지는 테스트는 테스트 구현을 시작하기 전에 미리 주의깊게 고려하는 것이 좋으며, 테스트 케이스와 테스트 디자인 아티팩트는 이러한 고려사항을 탐색하기에 좋은 도구입니다.
  • 테스트의 "깊이"는 일반적으로 테스트 수에 비례하는 것으로 간주됩니다. 식별된 테스트 케이스의 수에 기반하여 테스트의 잠재적 "깊이"를 추론할 수 있을 경우 테스트 프로세스 자체에 대해 보다 확신할 수 있게 됩니다.
  • 테스트 노력의 완전성을 측정하는 방법 중 하나는 일부 동기 부여 요소 세트에 대한 모니터링 적용 범위를 기반으로 합니다. 적용 범위 보고는 식별된 테스트 케이스 수와 각 테스트 케이스에 대해 구현 및/또는 실행된 테스트 수 또는 각 테스트 케이스에 소비한 노력의 정도와 같은 척도를 기반으로 할 수 있습니다.
  • 테스트 노력의 규모 및 복잡도는 테스트 케이스의 수에 어느 정도 비례합니다. 테스트 케이스를 작업분류하여 세부 레벨로 테스트 노력을 추론할 수 있습니다.
  • 테스트 디자인 및 개발의 종류과 필요한 자원은 부분적으로 테스트 케이스의 수 및 복잡도의 영향을 받습니다.

그러나 테스트 케이스에 대해 다음 사항을 고려해야 합니다.

  • 모든 테스트가 테스트 케이스 아티팩트 작성 시 오버헤드가 생겨 검토 및 유지보수할 필요가 있을 정도로 복잡하지는 않습니다. 짧은 텍스트 설명으로 충분히 필요한 내용을 제공할 수 있는 간단한 테스트도 있습니다. 사실, 대다수의 테스트 케이스가 이 카테고리에 들어갑니다. 너무 많은 수의 간단한 테스트 케이스를 문서화하는 데 시간을 소모하면 결국 보다 중요한 테스트 타스크에 필요한 시간을 빼앗길 수 있습니다.
  • 테스트에 대한 초기 아이디어 중 일부는 이후에 문제가 있는 것으로 밝혀집니다. 즉, 초기에 이런 아이디어에 기반해서 식별한 일부 테스트 케이스를 포기하게 됨을 의미합니다. 이 사실은 테스트 케이스를 자세히 문서화하면서 수행한 모든 작업을 이후에 포기할 수 있으며, 테스트 케이스에 기반한 적용 범위의 모든 보고에서 이런 상황을 고려할 필요가 있음을 의미합니다. 따라서 테스트 케이스보다 상위 레벨의 관심사항을 기반으로 테스트 적용 범위 보고를 수행하고, 테스트 케이스를 필요에 따라 사용되는 내부 테스트 팀 아티팩트로 간주하는 것이 보다 바람직합니다.

테스트 케이스는 종종 테스트의 유형 또는 연관된 테스트의 요구사항에 따라 분류됩니다. 테스트 케이스를 식별하는 방법 중 하나는 다음과 같이 시작됩니다.

  • 요구사항이 달성되었음을 증명(긍정적 테스트 케이스)
  • 요구사항이 원하는 조건 하에서 달성됨을 증명(부정적 테스트). 이 테스트 케이스는 소프트웨어에서 논리적으로 가질 수 있는 허용 불가능, 비정상 또는 예기치 않은 조건 또는 데이터를 반영합니다.

유스 케이스에서 테스트 케이스 도출

기능 테스트를 위한 테스트 케이스는 테스트 대상의 유스 케이스에서 도출됩니다(중간 산출물: 유스 케이스 참조). 각 유스 케이스 시나리오에 대해 테스트 케이스를 개발해야 합니다. 유스 케이스 시나리오는 유스 케이스를 통해 시작하여 종료되는 기본 플로우와 대체 플로우를 순회하는 유스 케이스 경로를 설명함으로써 식별됩니다.

예를 들어, 아래의 다이어그램에서는 기본 및 대체 플로우를 반영하며 유스 케이스를 통하는 다른 경로가 각각 화살표로 표현됩니다. 검은색 직선으로 표현되는 기본 플로우는 유스 케이스를 통하는 가장 간단한 경로입니다. 각 대체 플로우는 기본 플로우로 시작한 다음 특정 조건에 따라 대체 플로우가 실행됩니다. 대체 플로우는 기본 플로우와 다시 결합하거나(대체 플로우 1 및 3), 다른 대체 플로우에서 시작하거나(대체 플로우 2), 플로우와 재결합하지 않고 유스 케이스를 종료할 수 있습니다(대체 플로우 2 및 4).

함께 표시된 텍스트에서 설명되는 다이어그램

유스 케이스의 샘플 이벤트 플로우

위의 다이어그램에서 유스 케이스를 통하며 가능한 각 경로를 따라가면 다른 유스 케이스 시나리오를 식별할 수 있습니다. 기본 플로우로 시작한 다음 기본 플로우를 대체 플로우와 결합하면 다음 유스 케이스 시나리오를 식별할 수 있습니다. 

시나리오 1 기본 플로우      
시나리오 2 기본 플로우 대체 플로우 1    
시나리오 3 기본 플로우 대체 플로우 1 대체 플로우 2  
시나리오 4 기본 플로우 대체 플로우 3    
시나리오 5 기본 플로우 대체 플로우 3 대체 플로우 1  
시나리오 6 기본 플로우 대체 플로우 3 대체 플로우 1 대체 플로우 2
시나리오 7 기본 플로우 대체 플로우 4    
시나리오 8 기본 플로우 대체 플로우 3 대체 플로우 4  

참고: 간단하게 표시하기 위해 시나리오 5, 6 및 8은 대체 플로우 3으로 표시된 루프의 단일 실행만을 표시합니다.    

특정 유스 케이스 시나리오를 실행시키는 특정 조건을 식별함으로써 각 시나리오에 대한 테스트 케이스가 파생됩니다.

예를 들어, 위의 다이어그램에 표시된 유스 케이스에서 대체 플로우 3에 대해 아래와 같이 설명한다고 가정해 보십시오.

"이 이벤트 플로우는 위의 2단계, "인출 금액 입력"에서 입력한 달러 금액이 현재 계정 잔액을 초과하는 경우에 발생합니다. 시스템은 경고 메시지를 표시한 다음 위의 2단계, "인출 금액 입력"에서 기본 플로우와 재결합합니다(여기에 은행 고객이 새 인출 금액을 입력할 수 있음).

이 정보를 통해 대체 플로우 3을 실행하는 데 필요한 테스트 케이스 식별을 시작할 수 있습니다.

테스트 케이스 ID 시나리오 조건 예상 결과
TC x 시나리오 4 2단계 - 인출 금액 > 계정 잔액 2단계에서 기본 플로우 재결합
TC y 시나리오 4 2단계 - 인출 금액 < 계정 잔액 대체 플로우 3을 실행하지 않고 기본 플로우 사용
TC z 시나리오 4 2단계 - 인출 금액 = 계정 잔액 대체 플로우 3을 실행하지 않고 기본 플로우 사용

참고: 위에 표시된 테스트 케이스는 기타 정보가 제공되지 않으므로 매우 간단합니다. 테스트 케이스가 이처럼 간단한 경우는 드뭅니다.

유스 케이스에서 테스트 케이스를 도출하는 보다 현실적인 예제가 다음에 제공됩니다.

예제:

함께 표시된 텍스트에서 설명되는 다이어그램

ATM 시스템의 액터와 유스 케이스.

다음 표는 위의 다이어그램의 현금 인출 유스 케이스에 대한 기본 플로우와 일부 대체 플로우를 포함합니다.

기본 플로우 이 유스 케이스는 ATM이 준비된 상태에서 시작합니다.
  1. 인출 시작 - 고객이 ATM 시스템의 카드 판독기에 은행 카드를 넣습니다.
  2. 은행 카드 확인 - ATM이 은행 카드의 자기 테이프에서 계정 코드를 읽고 허용 가능한 은행 카드인지 확인합니다.
  3. PIN 입력 - ATM이 고객의 PIN 코드(4자리)를 요청합니다.
  4. 계정 코드 및 PIN 확인 - 계정이 올바른지 여부와 입력한 PIN이 계정에 올바른 PIN인지 여부를 판별하기 위해 계정 코드와 PIN을 확인합니다. 이 플로우의 경우, 계정이 올바른 계정이고 PIN이 이 계정과 연관된 올바른 PIN입니다.
  5. ATM 옵션 - ATM이 이 ATM에서 수행할 수 있는 다른 사항을 표시합니다. 이 플로우에서는 은행 고객이 항상 "현금 인출"을 선택합니다.
  6. 금액 입력 - ATM이 인출할 금액을 묻습니다. 이 플로우에서는 고객이 사전 설정된 금액($10, $20, $50 또는 $100)을 선택합니다.
  7. 권한 부여 - ATM이 카드 ID, PIN, 금액 및 계정 정보를 트랜잭션으로 송신해서 은행 업무 시스템과의 검증 프로세스를 시작합니다. 이 플로우에서는 은행 업무 시스템이 온라인 상태이고 권한 부여로 응답하여 현금 인출을 완료하고 이에 따른 계정 잔액을 갱신합니다.
  8. 지급 - 현금이 지급됩니다.
  9. 카드 반환 - 은행 카드가 반환됩니다.
  10. 영수증 - 영수증이 인쇄되어 지급됩니다. ATM은 이에 따른 내부 로그도 갱신합니다. 

ATM이 준비된 상태로 유스 케이스가 종료됩니다.

대체 플로우 1 - 올바른 카드가 아님 기본 플로우 2단계 - 은행 카드 확인에서, 카드가 올바르지 않은 경우 해당 메시지가 표시되고 카드가 나옵니다.
대체 플로우 2 - ATM에 현금이 부족함  기본 플로우 5단계 - ATM 옵션에서, ATM에 현금이 부족한 경우 "현금 인출" 옵션을 사용할 수 없습니다.
대체 플로우 3 - ATM의 잔고가 충분하지 않음  기본 플로우 6단계 - 금액 입력에서, ATM이 요청된 금액을 지급할 잔고가 충분하지 않은 경우 해당 메시지가 표시되고 기본 플로우 6단계 - 금액 입력과 재결합합니다.
대체 플로우 4 - 올바르지 않은 PIN  기본 플로우 4단계 - 계정 및 PIN 확인에서, 고객은 올바른 PIN 입력을 세 번 시도할 수 있습니다.  

올바르지 않은 PIN이 입력되면 ATM은 해당 메시지를 표시하며, 추가 시도 횟수가 남은 경우 이 플로우는 기본 플로우 3단계 - PIN 입력과 재결합합니다. 

최종 시도에서 입력된 PIN 번호가 올바르지 않은 경우에는 카드가 보유되고 ATM이 준비 상태로 되돌아오며 이 유스 케이스는 종료됩니다.
대체 플로우 5 - 계정 없음  기본 플로우 4단계 - 계정 및 PIN 확인에서, 은행 업무 시스템이 계정을 찾을 수 없거나 인출을 허용하는 계정이 아님을 표시하는 코드를 리턴하는 경우 ATM은 해당 메시지를 표시하고 기본 플로우 9단계 - 카드 반환과 재결합합니다.
대체 플로우 6 - 계정의 잔액이 충분하지 않음 기본 플로우 7단계 - 권한 부여에서, 은행 업무 시스템에서 계정 잔액이 기본 플로우 6단계 - 금액 입력에서 입력한 금액 미만임을 나타내는 코드를 리턴하는 경우 ATM은 해당 메시지를 표시하고 기본 플로우 6단계 - 금액 입력과 재결합합니다.
대체 플로우 7 - 일일 최대 인출 금액에 도달함  기본 플로우 6단계 - 권한 부여에서, 은행 업무 시스템에서 고객이 이 인출 요청을 포함하여 24시간 내에 허용된 최대 금액을 초과했거나 초과하게 됨을 나타내는 코드를 리턴하면 ATM은 해당 메시지를 표시하고 기본 플로우 6단계 - 금액 입력과 재결합합니다.
대체 플로우 x - 로그 오류 기본 플로우 10단계 - 영수증에서 로그를 갱신할 수 없는 경우 ATM은 모든 기능이 일시중단되는 "보안 모드"로 들어갑니다. ATM의 작동이 일시중단되었음을 나타내는 알람이 은행 업무 시스템에 전송됩니다.
대체 플로우 y - 종료 고객은 언제든지 트랜잭션 종료를 결정할 수 있습니다. 트랜잭션이 중지되고 카드가 나옵니다.
대체 플로우 z - "틸트(tilt)" ATM에는 전원, 여러 문과 게이트에 가해지는 압력 및 동작 감지기와 같은 다른 기능을 모니터하는 수많은 센서가 포함됩니다. 언제든지 센서가 활성화되면 경찰서에 알람 신호가 전송되고 ATM은 적절한 다시 시작/다시 초기화 조치가 취해질 때까지 모든 기능을 일시중단하는 "보안 모드"로 들어갑니다.


첫 번째 반복에서는 반복 계획에 따라 현금 인출 유스 케이스가 올바르게 구현되었는지 확인할 필요가 있습니다. 전체 유스 케이스는 아직 구현되지 않았으며 다음 플로우만이 구현되었습니다.

  • 기본 플로우 - 사전 설정된 금액($10, $20, $50, $100) 인출
  • 대체 플로우 2 - ATM에 현금이 부족함
  • 대체 플로우 3 - ATM의 잔고가 충분하지 않음
  • 대체 플로우 4 - 올바르지 않은 PIN
  • 대체 플로우 5 - 계정 없음/올바르지 않은 계정 유형
  • 대체 플로우 6 - 계정의 잔고가 충분하지 않음

이 유스 케이스에서 다음 시나리오가 도출될 수 있습니다.

시나리오 1 - 현금 인출에 성공함 기본 플로우   
시나리오 2 - ATM에 현금이 부족함 기본 플로우 대체 플로우 2
시나리오 3 - ATM의 잔고가 충분하지 않음 기본 플로우 대체 플로우 3
시나리오 4 - 올바르지 않은 PIN(남은 시도 횟수가 있음) 기본 플로우 대체 플로우 4 
시나리오 5 - 올바르지 않은 PIN(남은 시도 횟수가 없음) 기본 플로우 대체 플로우 4 
시나리오 6 - 계정 없음/올바르지 않은 계정 유형 기본 플로우 대체 플로우 5
시나리오 7 - 계정 잔액이 충분하지 않음  기본 플로우 대체 플로우 6

참고: 간단하게 표현하기 위해 대체 플로우 3 및 6(시나리오 3 및 7)의 루프와 루프의 결합은 위의 표에 포함되지 않았습니다.

이들 일곱 가지 시나리오 각각에 대해 테스트 케이스를 식별할 필요가 있습니다. 테스트 케이스는 매트릭스나 결정 표를 사용하여 식별하고 관리할 수 있습니다. 공통 형식은 아래에 표시되며 여기서 각 행은 개별 테스트 케이스를 나타내고 열은 테스트 케이스 정보를 식별합니다. 이 예제에서는 각 테스트 케이스에 대해 테스트 케이스 ID, 조건(또는 설명) 및 테스트 케이스에 관련된 모든 데이터 요소(입력으로 또는 이미 데이터베이스에 있는)와 예상 결과가 있습니다.

매트릭스 개발을 시작하려면 유스 케이스 시나리오를 실행하는 데 필요한 데이터 요소를 식별해서 시작하십시오. 그런 다음 각 시나리오에 대해 시나리오를 실행하기 위한 해당 조건을 포함하는 최소 테스트 케이스를 식별하십시오. 예를 들어, 아래의 매트릭스에서는 기본 플로우를 실행하려면 이 조건이 올바름을 나타내기 위해 V(올바름)를 사용하고, 원하는 대체 플로우를 호출할 조건을 나타내는 데에는 I(올바르지 않음)를 사용합니다.  아래의 표에서 "n/a"는 이 조건이 테스트 케이스에 적용 가능하지 않음을 나타냅니다.

TC ID# 시나리오/조건 PIN 계정 번호 입력된 금액

(선택한 금액)

계정의 금액 ATM의 금액 예상 결과
CW1. 시나리오 1 - 현금 인출에 성공함 V V V V V 현금 인출에 성공했습니다.
CW2. 시나리오 2 - ATM에 현금이 부족함 V V V V I 현금 인출 옵션을 사용할 수 없음, 유스 케이스 종료
CW3. 시나리오 3 - ATM의 잔고가 충분하지 않음 V V V V I 경고 메시지, 기본 플로우 6단계 - 금액 입력으로 돌아감
CW4. 시나리오 4 - 올바르지 않은 PIN (> 1번의 시도가 남음) V n/a V V 경고 메시지, 기본 플로우 4단계, PIN 입력으로 돌아감
CW5. 시나리오 4 - 올바르지 않은 PIN(= 1번의 시도가 남음) V n/a V V 경고 메시지, 기본 플로우 4단계, PIN 입력으로 돌아감
CW6. 시나리오 4 - 올바르지 않은 PIN(= 0번의 시도가 남음) V n/a V V 경고 메시지, 카드 보유됨, 유스 케이스 종료

위의 매트릭스에서는 여섯 가지 테스트 케이스가 네 가지 시나리오를 실행합니다. 기본 플로우에 대해 위의 테스트 케이스 CW1은 긍정적 테스트 케이스로 알려져 있습니다. 이는 경로 변경 없이 유스 케이스를 통해 기본 플로우 경로를 실행합니다. 기본 플로우의 포괄적 테스트는 부정적 테스트 케이스를 포함하여 조건이 올바른 경우에만 기본 플로우를 사용하도록 해야 합니다. 부정적 테스트 케이스는 테스트 케이스 CW2 - 6으로 표현됩니다(음영이 있는 셀은 대체 플로우를 실행할 필요가 있는 조건을 나타냄).  CW2 - 6은 기본 플로우에 대해서는 부정적 테스트 케이스이지만 대체 플로우 2 - 4에 대해서는 긍정적 테스트 케이스이며, 이들 각각의 대체 플로우에 대해 최소 하나의 부정적 테스트 케이스가 있습니다(CW1 - 기본 플로우).

시나리오 4는 시나리오별로 긍정적 및 부정적 테스트 케이스가 하나씩만 있는 충분하지 않은 예제입니다. 시나리오 4 - 올바르지 않은 PIN을 완전히 테스트하려면 적어도 세 개의 긍정적 테스트 케이스(시나리오 4를 호출하기 위해)가 필요합니다.

  • 올바르지 않은 PIN이 입력되었고 남은 시도 횟수가 있으며 이 대체 플로우는 기본 플로우 3단계 - PIN 입력과 재결합합니다.
  • 올바르지 않은 PIN이 입력되었고 남은 시도 횟수가 없으며 이 대체 플로우는 카드를 보유하고 유스 케이스를 종료합니다.
  • 올바른 PIN이 입력되고 남은 시도 횟수가 없습니다. 이 대체 플로우는 기본 플로우 5단계 - 금액 입력과 재결합합니다. 

위의 매트릭스에서는 조건에 대해 실제 값이 입력되지 않았음에 유의하십시오(데이터). 이렇게 테스트 케이스 매트릭스를 작성하는 이점은 테스트 중인 조건을 쉽게 볼 수 있다는 점입니다. V 및 I(또는 이 예처럼 음영이 있는 셀)만 보면 되므로 충분한 테스트 케이스가 식별되었는지 여부를 판별하기도 매우 수월합니다. 위의 표를 보면 음영 처리된 셀이 없는 조건이 여러 개 있으므로 시나리오 6 - 계정 없음 또는 올바르지 않은 계정 유형 및 시나리오 7 - 충분하지 않은 계정 잔액과 같은 테스트 케이스가 누락된 것입니다.

일단 충분한 테스트 케이스가 식별되면 이들을 검토하고 유효성을 검증해서 정확성과 적합성을 보증하고 복제되었거나 동등하거나 중복된 테스트 케이스를 제거하십시오. 자세한 내용은 개념: 테스트 아이디어 목록을 참조하십시오. 추가 세부사항은 테스트 케이스에 대한 테스트 데이터 정의 섹션도 참조하십시오.

TC ID# 시나리오/조건 PIN 계정 번호 입력된 금액

(선택한 금액)

계정의 금액 ATM의 금액 예상 결과
CW1. 시나리오 1 - 현금 인출에 성공함 4987 809 - 498 50.00 500.00 2,000 현금 인출에 성공했습니다. 계정 잔액이 450.00으로 갱신되었습니다.
CW2. 시나리오 2 - ATM에 현금이 부족함 4987 809 - 498 100.00 500.00 0.00 현금 인출 옵션을 사용할 수 없음, 유스 케이스 종료
CW3. 시나리오 3 - ATM의 잔고가 충분하지 않음 4987 809 - 498 100.00 500.00 70.00 경고 메시지, 기본 플로우 6단계 - 금액 입력으로 돌아감
CW4. 시나리오 4 - 올바르지 않은 PIN (> 1번의 시도가 남음) 4978  809 - 498 n/a 500.00 2,000 경고 메시지, 기본 플로우 4단계, PIN 입력으로 돌아감
CW5. 시나리오 4 - 올바르지 않은 PIN(= 1번의 시도가 남음) 4978 809 - 498 n/a 500.00 2,000 경고 메시지, 기본 플로우 4단계, PIN 입력으로 돌아감
CW6. 시나리오 4 - 올바르지 않은 PIN(= 0번의 시도가 남음) 4978  809 - 498 n/a 500.00 2,000 경고 메시지, 카드 보유됨, 유스 케이스 종료

위의 테스트 케이스는 이 반복에서 현금 인출 유스 케이스를 확인하는 데 필요한 테스트 케이스 중 일부일 뿐입니다. 필요한 기타 테스트 케이스에는 다음이 포함됩니다.

  • 시나리오 6 - 계정 없음 또는 올바르지 않은 계정 유형: 계정을 찾을 수 없거나 사용 가능하지 않음
  • 시나리오 6 - 계정 없음 또는 올바르지 않은 계정 유형: 인출이 허용되지 않는 계정임
  • 시나리오 7 - 충분하지 않은 계정 잔액: 요청한 금액이 계정 잔액을 초과함

이후 반복에서 다른 플로우가 구현되면 다음에 대한 테스트 케이스가 필요하게 됩니다.

  • 올바르지 않은 카드(카드가 유실됨, 도난됨, 허용된 은행의 카드가 아님, 자기 테이프가 손상됨 등)
  • 카드를 읽을 수 없음(카드 판독기가 걸렸음, 오프라인임 또는 오작동임)
  • 계정이 해지됨, 동결됨 또는 사용 불가능함
  • ATM의 금액이 충분하지 않거나 요청된 금액을 제공할 수 없음(한 종류의 금액 단위가 부족한 CW3과는 다름)
  • 승인을 위해 은행 업무 시스템에 접속할 수 없음
  • 은행 네트워크가 오프라인이거나 트랜잭션 중 전원 장애

기능적 테스트 케이스를 식별할 때에는 다음을 수행하십시오.

  • 각 유스 케이스 시나리오에 대해 충분한 테스트 케이스(긍정적 및 부정적)가 식별됨 
  • 테스트 케이스가 유스 케이스로 구현되는 모든 비즈니스 규칙을 다룸(내부, 외부 및 경계 조건 상태/값 비즈니스 규칙의 테스트 케이스를 가지도록 함).
  • 테스트 케이스가 이벤트 또는 조치의 시퀀스를 다룸(예: 사용자 인터페이스 오브젝트 상태나 조건 또는 디자인 모델의 시퀀스 다이어그램에서 식별된 사항).
  • 테스트 케이스가 유스 케이스에 대해 정의된 특별 요구사항을 다룸(예: 때때로 유스 케이스의 실행 중 최소/최대 로드 또는 데이터 볼륨과 결합되는 최소/최대 성능).

추가 안내는 테스트 케이스에 대한 테스트 데이터 정의 섹션을 참조하십시오.

보충 스펙에서 테스트 케이스 도출

테스트 대상에 대한 모든 요구사항이 유스 케이스 명세와 같은 기능적 요구사항 아티팩트에 반영되는 것은 아닙니다. 성능, 보안 및 액세스와 같은 비기능적 요구사항과 구성 요구사항은 테스트 대상의 추가 동작이나 특성을 지정하며 종종 기능적 요구사항과 별도로 문서화됩니다. 보충 스펙은 이러한 추가 요구사항에 대한 테스트 케이스를 도출하는 주요 소스 중 하나입니다.

다음은 추가 테스트 케이스를도출하는 데 필요한 가이드라인에 대한 설명입니다.

성능 테스트를 위한 테스트 케이스 도출

성능 테스트 케이스에 대한 기본 입력은 비기능적 요구사항을 포함하는 보충 스펙입니다(중간 산출물: 보충 스펙 참조). 성능 테스트를 위한 테스트 케이스를 도출하려면 다음 가이드라인을 사용하십시오.

  • 보충 스펙에서 성능 기준을 제시한 각 구문에 대해 최소 하나의 테스트 케이스가 매칭되도록 하십시오. 성능 기준은 일반적으로 트랜잭션당 시간, 트랜잭션/사용자 수 또는 백분위수로 표현됩니다.
  • 각 핵심 유스 케이스에 대해 최소 하나의 테스트 케이스가 식별되도록 하십시오. 핵심 유스 케이스는 성능 척도를 사용하여 평가해야 하는 워크로드 분석 문서 및/또는 위의 구문에서 식별된 유스 케이스입니다( 중간 산출물: 워크로드 분석 문서 참조).

기능 테스트를 위한 테스트 케이스의 경우처럼, 일반적으로 사용 시나리오 또는 요구사항별로 둘 이상의 테스트 케이스가 존재합니다. 일반적으로 여러 테스트 케이스를 정의합니다. 예를 들어, 하나는 성능 임계값 미만이고(평균 트랜잭션 비율), 다른 하나는 임계값에 있으며(높은 트랜잭션 비율), 세 번째 테스트 케이스는 임계값을 초과합니다(최대 트랜잭션 비율).

위의 성능 기준 외에, 다음을 포함하여 응답 시간에 영향을 주는 특정 조건을 식별하십시오.

  • 데이터베이스의 크기 - 존재하는 레코드의 수
  • 워크로드 - 트랜잭션 패턴:
    • 동시 사용자 조치의 유형, 수 및 빈도
    • 수행 중인 동시 트랜잭션의 유형, 수, 빈도 및 지속 기간
  • 환경 특성(하드웨어, 네트웨어, 소프트웨어 구성)

일반적인 사례는 성능 테스트를 위한 테스트 케이스를 기능 테스트에 사용된 것과 유사한 표 형식의 매트릭스로 캡처하는 것입니다.

추가 세부사항은 테스트 케이스에 대한 테스트 데이터 정의 섹션을 참조하십시오.

다음은 다른 유형의 성능 테스트에 대한 일부 예제입니다.

로드 테스트의 경우 다음과 같습니다.

TC ID# 워크로드 조건 예상 결과
PCW1.

1

(단일 ATM)

인출 완료 트랜잭션

완료 트랜잭션(비액터 종속적 타이밍) 발생 < 20초
PCW2.

2

(1,000 동시 ATM)

인출 완료 트랜잭션

완료 트랜잭션(비액터 종속적 타이밍) 발생 < 30초
PCW3.

3

(10,000 동시 ATM)

인출 완료 트랜잭션

완료 트랜잭션(비액터 종속적 타이밍) 발생 < 50초

스트레스 테스트의 경우 다음과 같습니다.

TC ID# 워크로드 조건 예상 결과
SCW1.

2

(1,000 동시 ATM)

데이터베이스 잠금 - 두 개의 ATM이 동일한 계정을 요청

ATM 요청을 대기열에 넣음
SCW2.

2

(1,000 동시 ATM)

은행 업무 시스템 통신을 사용할 수 없음

트랜잭션이 대기열에서 대기되거나 제한 시간 초과됨
SCW3.

2

(1,000 동시 ATM)

트랜잭션 중 은행 업무 시스템 통신이 종료됨

경고 메시지가 표시됨

보안/액세스 테스트를 위한 테스트 케이스 도출

액터와 유스 케이스는 시스템의 외부 사용자와 시스템이 특정 액터에 값을 산출하기 위해 수행하는 조치 사이의 상호 작용을 설명합니다. 복잡한 시스템은 여러 액터를 포함하며 유스 케이스를 실행하도록 지정된 액터만이 이를 수행할 수 있도록 테스트 케이스를 개발해야 합니다. 특히 액터 유형에 따라 이벤트의 유스 케이스 플로우에 차이가 있는 경우에 더욱 중요합니다.

예를 들어, 경쟁 은행의 은행 카드(및 계정)를 사용하거나 비참여 은행 카드를 사용하려는 "은행 고객"과 대비하여, ATM 유스 케이스에서는 ATM이 속한 은행의 카드와 계정을 사용하는 액터 "은행 고객"에게는 다른 이벤트 유스 케이스 플로우가 실행될 수 있습니다.

기능 테스트 케이스의 경우 위에 나열된 내용과 동일한 가이드라인을 따르십시오.

추가 안내는 테스트 케이스에 대한 테스트 데이터 정의 섹션을 참조하십시오.

보안 및 액세스에 대한 예제 테스트 케이스

TC ID# 조건 카드

(V는 올바른 카드를 나타냄)

카드 판독기

(V는 판독기가 제대로 작동함을 나타냄)

은행의 네트워크 예상 결과
ACW1. 은행 네트워크 내부 V V V 모든 유스 케이스가 사용 가능함
ACW2. 은행 네트워크 외부 V V I 현금 인출 유스 케이스 전용
ACW3. 카드를 읽을 수 없음 I V V 경고 메시지, 카드가 나옴
ACW4. 도난 카드로 보고됨 I V V 경고 메시지, 카드가 보유됨
ACW5. 카드가 만기됨 I V V 경고 메시지, 카드가 보유됨

구성 테스트를 위한 테스트 케이스 도출

일반 분산 시스템에는 지원되는 하드웨어 및 소프트웨어의 허용된 결합이 여러 개 있을 수 있습니다. 운영 체제, 브라우저 또는 CPU 속도에 차이가 있는 다른 구성에서 테스트 대상이 허용 가능하게 기능 또는 수행되는지 확인하는 테스트를 수행해야 합니다. 또한 서로 다른 컴포넌트의 상호작용으로 인한 결함을 발견하기 위해 컴포넌트의 조합에 대한 테스트도 필요합니다. 예를 들어, 한 응용프로그램이 설치한 DLL의 버전이 다른 응용프로그램이 예상한 동일한 DLL의 버전과 충돌하지 않는지 확인하는 경우입니다.

구성 테스트를 위한 테스트 케이스를 도출하려면 다음 가이드라인을 사용하십시오.

  • 각 핵심 구성을 식별하는 테스트 케이스가 적어도 하나 있는지 확인하십시오. 이를 수행하려면 테스트 대상의 환경에 맞는 필수 하드웨어 및 소프트웨어 구성을 식별하고 구성의 우선순위를 정해서 다음을 포함한 가장 일반적인 구성을 먼저 테스트하십시오.
    • 프린터 지원
    • 네트워크 연결 - 로컬 및 광역 네트워크
    • 서버 구성 - 서버 드라이버, 서버 하드웨어
    • 데스크탑 및/또는 서버에 설치된 기타 소프트웨어
    • 설치된 모든 소프트웨어의 소프트웨어 버전
  • 문제점이 있을 수 있는 각 구성에 대해 테스트 케이스가 적어도 하나 있는지 확인하십시오. 여기에는 다음이 포함됩니다.
    • 최저 성능의 하드웨어.
    • 호환성 문제점의 히스토리가 있는 공동 상주 소프트웨어.
    • 최저 속도의 가능한 LAN/WAN 연결을 통해 서버에 액세스하는 클라이언트.
    • 충분하지 않은 자원(느린 CPU 속도, 최소 메모리 또는 해상도, 디스크 공간 등).

설치 테스트를 위한 테스트 케이스 도출

설치 테스트에서는 모든 가능한 설치 시나리오로 테스트 대상을 설치할 수 있도록 해야 합니다. 설치 시나리오에는 테스트 대상을 처음으로 설치하거나, 새로운 버전이나 테스트 대상의 빌드를 설치(이전 버전을 포함하는 시스템에)하는 내용이 포함될 수 있습니다. 설치 테스트는 충분하지 않은 디스크 공간과 같은 비정상 조건이 발생할 때 테스트 대상이 제대로 동작하는지 여부도 확인해야 합니다.

테스트 케이스는 다음을 포함한 소프트웨어의 설치 시나리오를 포함해야 합니다.

  • 디스켓, CD-ROM 또는 파일 서버와 같은 분배 매체.
  • 새 설치.
  • 전체 설치.
  • 사용자 정의 설치.
  • 설치 업그레이드.

클라이언트-서버 소프트웨어에 대한 설치 프로그램에는 전문화된 테스트 케이스 세트가 있습니다. 호스트 기반 시스템과 달리, 설치 프로그램은 일반적으로 서버와 클라이언트 사이에서 분할됩니다. 따라서 설치 테스트가 클라이언트, 중간 층 및 서버를 포함하여 테스트 대상의 모든 컴포넌트의 설치를 수행해야 합니다.

기타 비기능적 테스트를 위한 테스트 케이스 도출

이론상으로는 유스 케이스 모델, 디자인 모델 및 보충 스펙 아티팩트에서 테스트 케이스를 도출하는 데 필요한 모든 입력을 찾아야 합니다. 그러나 한 시점에서 찾은 내용을 다른 시점에서 찾은 내용으로 보충하기도 합니다.

예제는 다음과 같습니다.

  • 오퍼레이션 테스트를 위한 테스트 케이스(실패가 발생한 사이 "오랜 기간" 동안 사용 중일 때 소프트웨어가 작동하는지 확인함).
  • 성능 병목 현상, 시스템의 볼륨 기능 또는 테스트 대상이 실패하게 만드는 스트레스를 조사하는 테스트 케이스.

대부분의 경우 이전에 식별한 테스트 케이스에서 도출한 테스트 케이스의 변형 또는 집계를 작성해서 이러한 테스트 케이스를 찾을 수 있습니다.

제품 적합성 테스트를 위한 테스트 케이스 도출

제품 적합성 테스트는 소프트웨어를 배치하기 전의 최종 테스트 조치입니다. 적합성 테스트의 목적은 소프트웨어가 준비가 되어 있고 사용자가 이를 사용하여 소프트웨어가 수행하도록 빌드된 기능과 타스크를 수행할 수 있는지 확인하는 것입니다. 보통 제품 적합성 테스트는 소프트웨어가 준비되었는지 실행해보는 것 이상을 의미합니다. 여기에는 훈련, 문서 및 패키지와 같이 고객에게 전달되는 모든 제품 중간 산출물도 포함됩니다.  

소프트웨어 중간 산출물에 대한 테스트 케이스 도출은 위 섹션에 설명된 방식으로 수행됩니다. 제품 적합성 테스트의 형식과 정도에 따라 테스트 케이스는 위에서 식별된 내용(정규)이나 서브세트(비정규)와 동일하거나 유사합니다. 테스트 케이스의 깊이와는 관련없이, 제품 테스트가 구현 및 실행되기 전에 테스트 케이스 및 제품 적합성 기준에 대해 합의해야 합니다.

비소프트웨어 중간 산출물의 평가는 평가 중인 중간 산출물에 따라 크게 달라집니다. 평가 사항/방법에 대한 정보는 각 특정 비소프트웨어 중간 산출물의 가이드라인 및 체크리스트를 참조하십시오.

회귀 테스트를 위한 검증 테스트 케이스 빌드

회귀 테스트는 동일한 테스트 대상의 두 가지 빌드 또는 버전을 비교하고 차이점을 잠재적 결함으로 식별합니다. 따라서 이는 새 버전이 이전 버전처럼 작동해야 한다고 가정하며, 변경으로 인해 결함이 발생하지 않았음을 확인합니다.

한 반복의 모든 테스트 케이스를 이후 반복에서도 테스트 케이스로 사용하는 것이 이상적입니다. 다음 가이드라인을 사용하여 유지보수를 최소화하면서 회귀 테스트 및 재사용 값을 최대화하는 테스트 케이스를 식별, 디자인 및 구현해야 합니다.

  • 테스트 케이스가 주요 데이터 요소(테스트 중인 조건을 작성/지원하는데 필요한 요소)만을 식별하십시오.
  • 각 테스트 케이스가 테스트 대상의 고유 동작을 발생시키는 고유 입력 세트 또는 이벤트의 시퀀스를 설명하거나 나타내도록 하십시오.
  • 중복되거나 동등한 테스트 케이스를 제거하십시오.
  • 테스트 대상 초기 상태 및 테스트 데이터의 상태가 동일한 테스트 케이스를 그룹화하십시오.

테스트 케이스에 대한 테스트 데이터 정의

테스트 케이스가 일단 논의되어 일반적인 합의/승인에 이르면 실제 데이터 값을 보다 상세히 식별하고(예: 테스트 케이스 구현 매트릭스에서) 테스트 데이터 아티팩트를 작성할 수 있습니다.

테스트 데이터 정의 및 유지보수에 대한 추가 정보는  가이드라인: 테스트 데이터를 참조하십시오.