주제

설명 페이지 맨 위

스테이크홀더의 기대값에 대한 명확한 스펙의 사용 가능성이 소프트웨어로 스테이크홀더의 만족을 보장하는 프로젝트 팀 기능에 가장 큰 영향을 미칩니다. 충분한 요구사항 스펙 세트 사용 여부에 상관 없이 테스트 케이스는 스테이크홀더의 기대값을 확인하고 유효성을 검증하여 스테이크홀더의 기대값을 반영할 수 있도록 지원하는 결과물입니다.

유용한 요구사항 세트를 사용할 수 있는 경우 테스트 팀에서는 해당 요구사항에 대한 유효성을 적절히 검증할 수 있는 테스트를 계획해야 합니다. 요구사항에 대한 소프트웨어 유효성 검증은 요구사항 유형에 따라 다르게 수행될 수 있습니다. 예를 들어, 테스터에서 자동 테스트 기술을 통해 소프트웨어를 실행하여 그 기능 및 성능 요구사항에 대한 유효성을 검증할 수 있는 한편, 수동 테스트 기술을 통해 형상 요구사항(예: 호스트 컴퓨터 시스템 종료)을 확인할 수 있습니다.

모든 요구사항을 확인할 수 없기 때문에 현재 작업의 범위에 대해 가장 적합하거나 중요한 요구사항에 초점을 맞추는 것이 중요합니다. 확인할 요구사항은 요구사항 확인에 대한 비용, 위험 및 필요성 사이에서 조절되며, 일반적으로 현재 반복 범위로 제한됩니다.

요구사항은 테스트를 실행할 수 있는 중요한 소스이지만 유일한 정보 소스는 아닙니다. 실제로 많은 경우 요구사항은 테스트를 개발하는 완전한 기초를 제공하는 데에는 충분하지 않습니다. 또한 테스트 케이스는 정보 소스(예: 위험, 제한조건, 기술 변경 요청(결함) 및 결함 등)에 기반한다고 간주됩니다.
테스트를 실행할 수 있는 아이디어 접근 방법에 관한 자세한 정보는 개념: 테스트 아이디어를 참조하십시오.

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

  • 테스트 케이스는 실제 테스트를 설계하고 구현하기 위한 기초로 사용될 수 있습니다. 테스트 케이스 검토에 소요되는 시간은 설계 및 구현 요구사항을 더 잘 이해하는 데 도움을 주며, 설계 및 구현 활동의 수행 시간을 절약할 수 있는 잠재력을 제공합니다.
  • 일부 테스트는 매우 복잡하고 상세합니다. 이러한 특성의 테스트에서는 테스트 구현의 시작에 앞서 신중하게 고려하여 이익을 얻을 수 있으며, 테스트 케이스와 테스트 설계 결과물은 이러한 고려사항의 탐색에 적합한 툴입니다.
  • 테스트의 "깊이"는 대개 테스트의 수에 비례하는 것으로 간주됩니다. 식별된 테스트 케이스의 수에 기반하여 테스트의 잠재적 "깊이"를 추론하면 테스트 프로세스 자체에 대해 더 많은 신뢰성을 확보할 수 있습니다.
  • 테스트 작업의 완성도에 대한 측정은 일부 동기 부여 요소 세트에 대한 모니터링 커버리지에 기반합니다. 커버리지 보고는 식별된 테스트 케이스 수, 각 테스트 케이스에 대해 구현되거나 실행된 테스트 수 또는 각 테스트 케이스에 소요된 작업량 등과 같은 측정 기준에 기반할 수 있습니다.
  • 테스트 작업의 배율 및 복잡도는 테스트 케이스 수에 비례합니다. 테스트 케이스를 구분하면 테스트 작업을 정밀한 레벨의 세분성으로 추론할 수 있습니다.
  • 테스트 설계와 개발 유형 및 필수 자원은 어느 정도 테스트 케이스의 수와 복잡도로 결정됩니다.

그러나 테스트 케이스와 관련하여 고려해야 할 일부 사항이 있습니다.

  • 모든 테스트가 검토하거나 유지 보수해야 할 테스트 케이스 결과물의 작성 오버헤드를 보증할 만큼 복잡한 것은 아닙니다. 간단한 텍스트 설명에서 필요한 내용을 전달하기에 충분할 정도로 테스트가 단순합니다. 실제로 대다수의 테스트 케이스는 카테고리별로 정렬할 수 있습니다. 많은 수의 단순 테스트 케이스 문서화에 소요되는 시간으로 인해 중요한 테스트 활동 시간이 손실될 수 있습니다.
  • 테스트에 적용할 초기 아이디어 중 일부가 몇 가지 관점에서 무효화되도록 검증됩니다. 이는 해당 아이디어에 기반하여 초기에 식별한 일부 테스트 케이스를 폐기한다는 것을 의미합니다. 이는 상세한 테스트 케이스 문서화에 수행하는 작업도 뒤이어 폐기될 수 있으며, 테스트 케이스에 기반한 커버리지 보고에서도 이러한 상황을 고려할 필요가 있다는 것을 의미합니다. 이와 같이 테스트 커버리지 보고의 근거를 테스트 케이스보다 더 높은 레벨의 중요성에 둔 다음 필요한 만큼 사용되는 내부 테스트 팀 결과물로 테스트 케이스를 수행하는 것이 좋습니다.

테스트 케이스는 종종 연관되는 테스트 요구사항 또는 테스트 유형별로 분류 또는 카테고리화되며, 유형에 따라 서로 다릅니다. 테스트 케이스 식별을 위한 학습 방법은 다음 두 가지 관점을 고려하여 시작할 수 있습니다.

  • 포지티브 테스트 케이스는 보통 요구사항이 실행되었음을 나타냅니다.
  • 네거티브 테스트는 요구사항이 원하는 조건에서만 실행되었음을 나타냅니다. 이 테스트 케이스는 승인할 수 없거나 비정상적이거나 예기치 않은 조건 또는 적절하게 소프트웨어를 종속시킬 수 있는 데이터를 반영합니다.

유스 케이스에서 테스트 케이스 구동 페이지 맨 위

기능 테스트의 테스트 케이스는 테스트 대상의 유스 케이스에서 구동됩니다(결과물: 유스 케이스 참조). 테스트 케이스는 유스 케이스 시나리오별로 전개되어야 합니다. 유스 케이스 시나리오는 기본 플로우 및 대체 플로우 시작을 통과하여 유스 케이스를 통해 종료되는 유스 케이스 통과 경로를 설명하여 식별됩니다.

예를 들어, 다음 다이어그램에서는 기본 및 대체 플로우를 반영하는 별도의 유스 케이스를 통한 서로 다른 각각의 경로가 화살표로 나타납니다. 검은색 직선으로 나타나는 기본 플로우는 유스 케이스를 통한 가장 단순한 경로입니다. 각각의 대체 플로우가 기본 플로우에서 시작된 후 특정 조건에 따라 해당 대체 플로우가 실행됩니다. 대체 플로우는 기본 플로우와 재결합하거나(대체 플로우 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에서 은행 카드의 자기띠(Magnetic Strip)로부터 계정 코드를 읽은 다음 승인할 수 있는 은행 카드인지를 확인합니다.
  3. PIN 입력 - ATM에서 고객의 PIN 코드(4자리)를 요청합니다.
  4. 계정 코드 및 PIN 확인 - 계정 코드와 PIN을 확인하여 유효한 계정인지와 입력한 PIN이 해당 계정에 대한 올바른 PIN인지를 판별합니다. 이 플로우에서 계정은 유효한 계정이며, PIN은 이 계정과 연관되어 있는 올바른 PIN입니다.
  5. 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을 입력할 수 있도록 고객에게 3회 시도를 허용합니다.  

잘못된 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 - "차단" 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) 및 루프 조합이 포함되지 않습니다.

이러한 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 경고 메시지 표시, 카드 보류, 유스 케이스 종료

위의 매트릭스에서는 6개 테스트 케이스가 4개의 시나리오를 실행합니다. 기본 플로우의 경우 위의 테스트 케이스 CW1(포지티브 테스트 케이스로 알려져 있음)은 유스 케이스를 통한 기본 플로우 경로를 이탈 없이 실행합니다. 조건이 올바른 경우에만 기본 플로우를 수행할 수 있도록 전체적인 기본 플로우 테스트에는 네거티브 테스트 케이스가 포함되어야 합니다. 테스트 케이스 CW2 - 6은 이러한 네거티브 테스트 케이스를 나타냅니다(음영 표시 셀은 대체 플로우 실행에 필요한 조건을 나타냄). CW2 - 6은 기본 플로우의 경우에는 네거티브 테스트 케이스이지만, 대체 플로우 2 - 4의 경우에는 포지티브 테스트 케이스가 됩니다. 이러한 대체 플로우 각각에는 하나 이상의 네거티브 테스트 케이스가 있습니다(CW1 - 기본 플로우).

시나리오 4는 충분하지는 않지만 시나리오별로 포지티브 및 네거티브 테스트 케이스가 하나씩 있는 예입니다. 시나리오 4 - 잘못된 PIN을 완전히 테스트하려면 3개 이상의 포지티브 테스트 케이스(시나리오 4 호출용)가 필요합니다.

  • 올바르지 않은 PIN이 입력되고 잔여 시도 횟수가 있어 현재 대체 플로우에서 기본 플로우 3단계 - PIN 입력과 재결합합니다.
  • 올바르지 않은 PIN이 입력되고 잔여 시도 횟수가 없어 현재 대체 플로우에서 카드를 보유한 채로 유스 케이스를 종료합니다.
  • 잔여 시도 횟수가 없는 경우 CORRECT 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과는 다름, 일부 화폐 금액이 잘못되어 있음)
  • 승인 접속이 불가능한 뱅킹 시스템
  • 트랜잭션 중에 오프라인으로 전환했거나 전원 장애가 발생한 은행 네트워크

기능 테스트 케이스를 식별할 경우 다음 사항을 확인하십시오.

  • 각 유스 케이스 시나리오에 대해 충분한 테스트 케이스(포지티브 및 네거티브)가 식별되었습니다. 
  • 테스트 케이스에서 유스 케이스로 구현되는 모든 비즈니스 규칙을 지정하여 비즈니스 규칙의 감시 조건/값 및 이 값의 내부 및 외부에 테스트 케이스가 있게 합니다.
  • 테스트 케이스에서 설계 모델의 순서 다이어그램에서 식별된 것과 같은 이벤트 또는 조치의 순서 또는 사용자 인터페이스 객체 상태 또는 조건을 지정합니다.
  • 테스트 케이스에서는 최소/최대 성능과 같은 유스 케이스에 정의되거나 유스 케이스 실행 중에 가끔씩 최소/최대 로드 또는 데이터 볼륨과 결합되는 특수 요구사항을 지정합니다.

추가 가이드는 테스트 케이스의 테스트 데이터 정의 섹션을 참조하십시오.

추가 스펙에서 테스트 케이스 도출 페이지 맨 위

테스트 대상에 대한 모든 요구사항이 반드시 기능 요구사항 결과물(예: 유스 케이스 스펙)에 반영되는 것은 아닙니다. 비기능 요구사항(예: 성능, 보안 및 액세스, 형상 요구사항)에서는 테스트 대상의 추가 작동 또는 특성을 지정하며, 종종 기능 요구사항과는 별도로 설명됩니다. 추가 스펙은 이러한 추가 요구사항의 테스트 케이스를 도출하는 기본 소스 중 하나입니다.

이러한 추가 테스트 케이스를 도출하기 위한 가이드라인은 다음과 같습니다.

성능 테스트의 테스트 케이스 도출 페이지 맨 위

성능 테스트 케이스의 기본 입력은 비기능 요구사항을 포함하는 추가 스펙입니다. 결과물: 추가 스펙을 참조하십시오. 성능 테스트의 테스트 케이스를 도출할 경우 다음 가이드라인을 사용하십시오.

  • 성능 기준을 설명하는 추가 스펙의 각 명령문에 대해 하나 이상의 테스트 케이스가 식별되는지 확인하십시오. 일반적으로 성능 기준은 트랜잭션별 시간, 트랜잭션/사용자 수 또는 백분율로 나타납니다.
  • 각 중요 유스 케이스에 대해 하나 이상의 테스트 케이스가 식별되는지 확인하십시오. 중요 유스 케이스는 성능 측정을 사용하여 평가해야 하는 워크로드 분석 문서 또는 위의 명령문에서 식별되는 유스 케이스입니다.

기능 테스트의 테스트 케이스와 마찬가지로 대개 사용법 시나리오 또는 요구사항별 테스트 케이스가 하나 이상 있습니다. 여러 개의 테스트 케이스를 정의하는 것은 일반적입니다. 예를 들면, 한 테스트 케이스는 성능 임계값 이하(평균 트랜잭션 처리율)이고 다른 테스트 케이스는 임계값(상위 트랜잭션 처리율)에 있으며 세 번째 테스트 케이스는 임계값 이상(최대 트랜잭션 처리율)입니다.

위의 성능 기준 이외에도 다음을 포함한 응답 시간에 영향을 주는 지정 조건을 식별하도록 하십시오.

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

일반적으로 기능 테스트에 사용된 것과 유사한 테이블 매트릭스에서 성능 테스트의 테스트 케이스를 캡처합니다.

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

여러 개의 성능 테스트 유형에 대한 몇 가지 예는 다음과 같습니다.

로드 테스트의 경우:

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 또는 파일 서버)
  • 새 설치
  • 전체 설치
  • 사용자 정의 설치
  • 업그레이드 설치

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

기타 비기능 테스트의 테스트 케이스 도출 페이지 맨 위

유스 케이스 모델, 설계 모델 및 추가 스펙 결과물에서 테스트 케이스를 도출하는 데 필요한 모든 입력을 찾는 것이 좋습니다. 그러나 이때 찾아낸 사항을 보완할 필요가 있습니다.

다음과 같은 예가 있습니다.

  • 운영 테스트의 테스트 케이스(장애 사이에서 "장시간" 동안 사용 중인 소프트웨어가 작동하는지 확인)
  • 시스템의 성능 병목 현상, 볼륨 기능을 조사하거나 장애에 대해 테스트 대상을 압박하는 테스트 케이스

대부분의 경우 이전에 식별된 테스트 케이스에서 도출한 테스트 케이스의 변량 또는 총계를 작성하여 해당 테스트 케이스를 찾을 수 있습니다.

제품 승인 테스트의 테스트 케이스 도출 페이지 맨 위

제품 승인 테스트는 소프트웨어 전개 이전의 최종 테스트 조치입니다. 승인 테스트의 목표는 일반 사용자가 소프트웨어에 빌드된 해당 기능과 타스크를 수행할 수 있도록 소프트웨어가 준비 및 사용될 수 있는지를 확인하는 것입니다. 제품 승인 테스트에는 종종 소프트웨어의 실행에 대비하여 그 이상이 포함되며, 고객에게 전달되는 모든 제품 결과물(예: 훈련, 문서 및 패키지)도 포함됩니다. 

소프트웨어 결과물의 테스트 케이스 도출이 위 섹션에서 설명한 방식으로 수행됩니다. 제품 승인 테스트의 범위와 형식에 기초하는 테스트 케이스는 위에서 식별된 테스트 케이스(정식) 또는 서브세트(약식)와 동일하거나 유사합니다. 테스트 케이스의 깊이와는 별도로, 제품 테스트를 구현 및 실행하기 전에 테스트 케이스와 제품 승인 기준에 대해 계약해야 합니다.

비소프트웨어 결과물 평가는 평가할 결과물에 따라 매우 다릅니다. 평가 대상 및 방법에 관한 정보는 각 특정 비소프트웨어 결과물의 가이드라인 및 체크리스트를 참조하십시오.

회귀 테스트의 검증 테스트 케이스 빌드 페이지 맨 위

회귀 테스트는 동일한 테스트 대상의 버전 또는 두 개의 빌드를 비교하여 그 차이를 잠재적 결함으로 식별합니다. 따라서 새 버전이 이전 버전처럼 작동한다고 가정하고, 변경 결과로 해당 결함을 채택하지 않도록 합니다.

하나의 반복에 있는 모든 테스트 케이스는 이후 반복에서 테스트 케이스로 사용되는 것이 좋습니다. 다음 가이드라인은 유지보수를 최소화하는 동안 회귀 테스트 값을 최대화하고 재사용하는 테스트 케이스의 식별, 설계 및 구현에 사용되어야 합니다.

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

테스트 케이스의 테스트 데이터 정의 페이지 맨 위

테스트 케이스를 검토하여 일반적인 계약/승인에 도달한 경우에는 실제 데이터 값을 자세히 식별하고(예: 테스트 데이터 구현 매트릭스) 테스트 데이터 결과물을 작성할 수 있습니다.



Rational Unified Process   2003.06.15