Software Testing Overview — 소프트웨어 테스팅 개요와 블랙 박스 테스팅
소프트웨어를 배포하기 전에 결함을 발견하지 못하면 사용자가 대신 발견하게 된다. 테스팅은 결함이 없음을 증명하는 것이 아니라, 결함이 존재함을 보여주는 작업이다.
테스팅 정의 및 목적
시스템이 정해진 요구를 만족하는지, 예상과 실제 결과가 어떤 차이를 보이는지 수동 또는 자동 방법을 동원하여 검사하고 평가하는 일련의 과정 [IEEE, 1993]
테스팅이란 노출되지 않은 숨어있는 결함(Fault)을 찾기 위해 소프트웨어를 작동시키는 일련의 행위와 절차이다. 오류 발견을 목적으로 프로그램을 실행하여 품질을 평가하는 과정이며, 일반적으로 테스트 케이스에 따라 SW를 동적으로 실행시켜 예상결과치와 비교 분석한다.
테스팅의 목적
- 프로그램의 잠재된 오류의 발견
- 기술적인 기능 및 성능의 확인
- 사용자 요구 만족도 향상
- 제품 신뢰도 향상
핵심은 결함이 없음을 증명하는 것이 아니고 결함이 존재함을 보여주는 작업이라는 점이다. Edsger Dijkstra의 말처럼: “Testing shows the presence, not the absence of bugs.”
테스팅의 한계
완벽한 테스트는 불가능하다.
- 한 프로그램 내의 내부 조건들은 무수히 많을 수 있다
- 입력이 가질 수 있는 모든 값의 조합이 무수히 많다
- GUI 이벤트가 발생하는 순서에 대한 조합도 무한정
테스팅의 이점
- 디버깅 감소: 테스트를 거친 후 서브밋되는 코드는 통상적으로 결함이 적기 때문에, 디버깅에 소모되는 시간을 줄일 수 있다
- 자신 있게 변경 가능: 좋은 테스트들로 무장한 팀은 수정한 소스코드가 여러 측면에서 잘 동작하는 것을 확인할 수 있어, 리팩터링 작업을 쉽게 진행할 수 있게 한다
- 더 나은 문서자료: 테스트 내용은 특정 상황에서 어떻게 동작하는지 알 수 있어 문서자료로서의 역할을 훌륭히 수행한다
- 더 단순한 리뷰: 테스트 코드는 리뷰어가 변경된 코드를 검증하는 시간을 절약하도록 도와준다
- 사려 깊은 설계: 테스트하기 어려운 코드는 너무 많은 역할을 짊어지거나 의존성을 관리하기 어렵게 구현됐을 가능성이 높다. 테스트는 모듈화가 잘 된 설계를 유도한다
- 고품질의 릴리즈를 빠르게: 자동 테스트 덕분에 릴리즈 시에 불안감에 떨 필요가 없다
테스트 작업 과정
테스트는 다음 단계로 진행된다:
- 목표 설정: 테스트에 의하여 무엇을 점검할 것인지 정한다 (예: 기능의 완벽성, 신뢰도)
- 방법 결정: 검사, 증명, 블랙박스 테스트, 화이트 박스 테스트, 자동화 도구 등에서 선택
- 테스트 케이스 선택: 테스트 자료, 시행 조건을 결정
- 테스트 케이스 작성: 테스트의 예상되는 올바른 결과를 작성한다 (테스트 오라클)
- 테스트 실행: 테스트 하니스(test harness)가 필요
- 실행 결과 분석
테스팅 종류
프로그램 실행 여부에 따른 분류
| 구분 | 설명 | 방법 |
|---|---|---|
| 동적 테스트 | 프로그램 실행을 요구하는 테스트 | 화이트 박스(구조 기반), 블랙 박스(명세 기반), 경험 기반 |
| 정적 테스트 | 프로그램 실행 없이 구조를 분석하여 논리성 검증 | 코드 검사(체크리스트), 워크스루(비공식적 검사) |
테스트 목적에 따른 분류
| 테스트 종류 | 설명 |
|---|---|
| 회복(Recovery) 테스트 | 소프트웨어가 다양한 방법으로 실패하도록 유도하고 회복이 적절하게 수행되는지를 검증한다. OS, DBMS, 통신용 소프트웨어 등의 안전성 test에 중요하다 |
| 안전(Security) 테스트 | 시스템 내의 보호 기능이 불법적인 침투로부터 시스템을 보호하는지에 대한 검증 테스트. 기밀성, 무결성, 사용자 인증, 접근 통제, 부인봉쇄 등의 보안 기능 테스트 |
| 강도(Stress) 테스트 | 비정상적인 값, 양, 빈도의 자원 입력에 대한 정상 수행 상태를 테스트. 부하, 메모리 부족 등 비정상적인 상황에서의 테스트. 인수 테스트의 한 종류이기도 하다 |
| 구조(Structural) 테스트 | 소프트웨어 내부의 논리적인 경로에 대한 복잡도를 평가하는 시험. 화이트 박스 테스트 및 유닛 테스트로도 분류된다 |
| 성능(Performance) 테스트 | 통합된 시스템의 전후 관계에서 소프트웨어의 실행 시간을 test. 자원이용, 처리 시간, 요구된 응답 등에 대한 목표치를 달성하는지에 대한 성능 테스트 |
테스트 단계에 따른 분류
SDLC의 V 모델과 많은 연관을 가지고 있다.
| 테스트 단계 | 설명 |
|---|---|
| 단위 테스트(Unit Test) | 개별 모듈 단위로 테스트. 주로 개발자가 수행 |
| 통합 테스트(Integration Test) | 모듈 간 인터페이스를 검증 |
| 시스템 테스트(System Test) | 전체 시스템의 요구사항 만족도 검증 |
| 인수 테스트(Acceptance Test) | 사용자 관점에서 시스템 검증 |
| 회귀 테스트(Regression Test) | 변경 후 기존 기능이 정상 동작하는지 재검증 |
블랙 박스 테스팅 기법들
블랙 박스 테스팅(Black Box Testing)은 소프트웨어가 수행할 특정 기능을 알기 위해서 각 기능이 완전히 작동되는 것을 입증하는 테스트로, 기능 테스트라고도 한다. 사용자의 요구사항 명세를 보면서 테스트하는 것으로, 주로 구현된 기능을 테스트한다. 소프트웨어 인터페이스에서 실시되며, 주로 테스트 과정의 후반부에 적용한다.
내부 구조를 모르는 상태에서 입력(Input)과 출력(Output)만으로 기능을 검증하는 방식이다.
동등(동치) 분할 기법 (Equivalence Partitioning)
입력 자료에 초점을 맞춰 테스트 케이스를 만들고 검사하는 방법이다. 입력 데이터를 동등한 클래스로 분할하고, 각 클래스에서 대표값을 선택하여 테스트한다. 같은 클래스 내의 값들은 동일한 결과를 낼 것이라고 가정한다.
경계 값 분석 기법 (Boundary Value Analysis)
입력 자료에만 치중한 동등 분할 기법을 보완하기 위한 기법이다. 입력 조건의 중간 값보다 경계 값에서 오류가 발생될 확률이 높다는 점을 이용한다. 입력 조건의 경계 값을 테스트 케이스로 선정하여 검사하는 기법이다.
오류 예측 기법 (Error Guessing)
과거의 경험이나 확인자의 감각으로 테스트하는 기법이다. 다른 블랙 박스 테스트 기법으로는 찾아낼 수 없는 오류를 찾아내는 보충적 검사 기법이다.
원인 결과 그래프 기법 (Cause-Effect Graph)
입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 체계적으로 분석한다. 분석을 활용하여 효용성이 높은 테스트 케이스를 선정하여 검사하는 기법이다.