소프트웨어 테스팅 노트

출처: KOCW 강의, 소프트웨어검증 Chapter 17. Test Execution, 건국대학교 유준범, 2013년

테스팅 구현 및 실행 단계에서 마주하게 되는 주요 이슈들을 식별

테스트 실행 자동화(Automating Test Execution)

• 테스트 케이스와 테스트 스위트 설계는 창의적인 작업이다. 지적 활동 및 인간의 판단이 요구됨.
• 반면 테스트 케이스 실행은 자동화되어야 한다. 한 번 설계하고 여러 번 실행함.
• 테스트 자동화(Test automation)는 창의적인 인간 프로세스와 반복적이고 기계적인 테스트 실행 프로세스를 분리하는 것을 목표로 한다.
• 테스트 자동화는 대규모 테스트 스위트의 생성 및 실행을 가능하게 하고, 테스트 스위트를 자주 재실행 할 수 있다(예: 매일 밤 또는 프로그램 변경 후마다).

테스트 케이스 명세(Test Case Specifications)에서 테스트 케이스(Test Cases)로 전환

• 테스트 설계는 종종 구체적인 데이터가 아닌 테스트 케이스 명세서(test case specifications)를 산출한다.
• “큰 양수 값”이라는 명세는 “420,023”이라는 숫자로, “정렬된 시퀀스, 길이 > 2”라는 명세는 “알파, 베타, 카이, 오메가” 같이 구체적이고 실행 가능한 데이터로 전환이 필요할 수 있다.
• 구체적인 테스트 케이스 실행을 위한 기타 세부 사항이 생략되었을 수 있다.

Test Scaffolding

• 개발 및 테스팅 활동을 지원하기 위해 생성된 코드이며 최종 사용자가 보는 “제품”의 일부가 아니다. 건축 공사장의 비계처럼 임시적일 수 있다.
• 주요 유형으로 테스트 하네스(Test harnesses), 드라이버(Drivers), 스터브(Stubs)가 있다.
• 테스트 드라이버(Test driver): 테스트 실행을 위한 “메인” 프로그램으로 “실제” 메인 프로그램보다 먼저 생성될 수 있다. 테스트 케이스를 통해 테스트 대상 프로그램을 구동하기 위해 “실제” 메인 프로그램보다 더 많은 제어 기능 제공할 수 있다.
• 테스트 스터브(Test stub): 호출을 당하는 함수/메서드/객체를 대체한다.
• 테스트 하네스(Test harness): 배포된 환경의 다른 부분을 대체한다. 예: 어떤 하드웨어 장치를 소프트웨어 시뮬레이션으로 대체

테스트 오라클(Test Oracles)

• 결과를 수동으로 확인해야 한다면, 10,000건의 테스트 케이스를 자동으로 실행해도 소용이 없다.
• 비교 기반 오라클(Comparison-based oracle): 각 입력에 대한 예측 출력이 필요하다. 오라클은 실제 출력과 예측 출력을 비교하고 차이가 있을 경우 실패를 보고한다.
• 비교 기반 오라클은 수동으로 생성한 소수의 테스트 케이스에 적합하다.
  예: JUnit에서 각 테스트 케이스에 수동으로 코딩된 특정 오라클(“assert”)
• 셀프 체크 오라클(Self-checks oracle): 결과를 예측하지 않고도 정합성(correctness)을 판단할 수 있는 경우에 오라클은 자체 검사(self-checks)로도 구현될 수 있다.
  예: 데이터 구조의 구조적 불변 조건(structural invariants)
• 셀프 체크 오라클은 대규모 자동 생성 테스트 스위트에 활용 가능하다는 장점이 있으나, 대개 부분적 검증에 그치는 한계가 있다.

캡처 및 재생(Capture and Replay)

• 때로는 인간에 의한 입력 및 관찰을 대체할 방법이 없다. 프로그램 기능 테스트를 GUI와 분리하더라도, GUI에 대한 일부 테스트는 필요하다.
• 캡처 및 재생을 활용하면 최소한 인간 테스트의 반복 작업은 줄일 수 있다. 수동으로 실행한 테스트 케이스를 캡처하여 자동으로 재현한다. 이 때 비교 기반 테스트 오라클을 사용하면 재현된 동작이 이전에 캡쳐된 동작과 동일해야 한다.
• 재사용 수명은 입력과 출력의 추상화 수준에 따라 달라진다. 프로그램 변경으로 무효화되어 재사용이 불가해질 수 있음.