책 발췌 – 테스트케이스의 주요 구성요소

출처: A Practitioner's Guide to Software Test Design by Lee Copeland, 2004년

 

테스트 케이스 설계

잘 설계된 테스트케이스는 입력, 출력, 실행순서의 세 부분으로 구성된다.

 

입력(Inputs)

• 키보드에서 입력한 데이터
• 인터페이스 시스템에서 오는 데이터
• 인터페이스 장치의 데이터
• 파일 또는 데이터베이스에서 읽어 들이는 데이터
• 데이터가 도착했을 때의 시스템 상태
• 시스템이 실행되는 환경

 

출력(Outputs)

• 컴퓨터 화면에 표시되는 데이터
• 인터페이스 시스템 또는 외부 장치로 내보내는 데이터
• 파일 또는 데이터베이스에 쓰기(write) 하는 데이터
• 시스템의 실행으로 인해 변경되는 상태나 환경

 

테스트 케이스 설계에서 예상 출력을 결정하는 것이 "오라클(oracle)"의 역할이다. 오라클은 테스트 설계자에게 예상되는 테스트 결과를 제공하는 모든 프로그램, 프로세스 또는 데이터를 말한다. Beizer는 오라클의 유형 5가지를 나열하였다.

1. 키디 오라클(Kiddie Oracles): 프로그램을 실행하고 어떤 결과가 나오는지 본다. 결과가 별 이상 없이 보이면 그게 올바른 결과라고 생각한다.
2. 회귀 테스트스위트(Regression Test Suites): 프로그램을 실행하고 그 결과를 이전 버전의 프로그램에 대해 실행한 동일한 테스트의 결과와 비교한다.
3. 검증된 데이터(Validated Data): 프로그램을 실행하고 그 결과를 어떤 표준/기준(예, 표, 공식, 유효한 출력으로 허용되는 정의)과 비교한다.
4. 상용/구매용 테스트스위트(Purchased Test Suites): 이미 생성되어 검증을 마친 표준화된 테스트스위트를 사용하여 프로그램을 실행한다. 컴파일러, Web 브라우저, SQL 프로세서 같은 프로그램은 종종 이러한 스위트를 사용하여 테스트를 한다.
5. 기존 프로그램(Existing Program): 프로그램을 실행하고 결과를 기존 프로그램의 것과 비교한다(기존 프로그램이 존재하는 경우 적용 가능).

 

실행순서(Order of Execution)

테스트 실행순서와 관련하여 두 가지 스타일의 테스트 케이스 설계가 있다.

• 연속적인 테스트 케이스(Cascading test cases): 테스트 케이스가 서로를 기반으로 구축된다. 예를 들어, 첫 번째 테스트 케이스가 소프트웨어의 특정 기능을 실행한 후에야 두 번째 테스트 케이스를 실행할 수 있는 시스템 상태가 만들어진다. 만약 데이터베이스를 테스트할 때 아래와 같은 테스트 케이스를 고려한다면,
  (1) 레코드를 하나 생성하기
  (2) 생성된 레코드 읽기
  (3) 생성된 레코드 업데이트하기
  (4) 업데이트된 레코드 읽기
  (5) 업데이트된 레코드 삭제하기
  (6) 삭제된 레코드 읽기
  위 테스트 각각을 앞선 테스트를 기반으로 구축할 수 있다. 이러한 설계의 장점은 각 테스트 케이스를 더 작고 단순하게 할 수 있다는 것이고, 단점은 하나의 테스트가 실패하면 후속 테스트가 모두 무효화될 수 있다는 점이다.
• 독립적인 테스트 케이스(Independent test cases): 각 테스트 케이스가 완전히 독립적이다. 테스트가 서로를 기반으로 구축되거나 또는 다른 테스트가 성공적으로 실행될 것을 요구하지 않는다. 이러한 설계는 임의의 수의 테스트를 임의의 순서로 실행할 수 있다는 장점이 있고, 반면 각각의 테스트가 더 크고 더 복잡한 경향이 있기 때문에 설계, 생성 및 유지 관리가 더 어렵다는 단점이 있다.