TTA(한국정보통신기술협회)에서 주관하는 소프트웨어 테스트 전문가 자격시험(CSTS)를 공부하면서 정리한 포스팅으로,
목차는 크게 6개로 이루어지고 TTA 교육 + 홍릉과학출판사 테스터와 관리자를 위한 소프트웨어 테스팅 + 예제문제 를 기반으로 공부하였다.
1. 소프트웨어 테스트 개요
1.1 소프트웨어 테스트
> 결함을 발견할 목적으로 프로그램을 실행하는 과정
> 소프트웨어 품질을 측정하고 개선하기 위한 프로세스
> 해야 되는 일을 실제로 수행하는지/정확한 값인지 확인
> 오류가 존재함을 보일 수는 있지만 오류가 없음을 보일 수는 없음
> 프로그램의 신뢰도를 높이기 위한 과정
> 프로그램이나 문서들을 분석하는 과정
> 좋은 테스트는 성공적인 수행이 아니라 발견되지 않은 결함을 검출할 수 있도록 오작동을 발생시키는 것
1.2 소프트웨어 에러/결함/오작동
- 에러(Error): 사용자 요구사항을 잘못 파악하거나 잘못 이해할 때 발생하는 실수이며 사람에 의해 발생
예) 타이핑 실수, 프로그램 명령어 잘못 이해
- 결함(Defect, Fault): 에러가 표현된 것
소프트웨어가 제품 사양에 명시된 대로 작동하지 않거나 하지 말아야 한다고 하는 기능을 수행하는 경우
제품 사양에서 언급하지 않은 것을 수행하거나 언급하지는 않았지만 해야 할 일을 수행하지 않는 경우
이해하기 어렵거나, 사용하기 어려운 경우
- 오작동(Failure): 결함의 실행으로 예상과 다른 결과
오작동은 결함에 의해 발생하지만, 결함이 있다고 반드시 오작동이 발생하는 것은 아님
[Example] 오상식 차장은 추석에 가족과 함께 고향인 부산에 내려가지고 자가용을 운전하였다. 경부고속도로를 따라 운전하다가 깜빡 졸아 호남고속도로로 핸들을 틀어 들어서게 되었다. 계속 그대로 운전하여 결국에는 광주까지 오게 되었다.
에러: 운전하다가 깜빡 졸았다.
결함: 결부고속도로에서 호남고속도로로 핸들을 틀었다.
오작동: 부산을 가야하는데 광주에 도착하였다.
1.3 소프트웨어 결함 원인
- 요구사항 결함: 요구사항의 잘못된 정의, 고객과 개발자간의 의사소통 부족, 고의적인 요구사항 미준수
- 설계 결함: 소프트웨어 요구사항을 설계에 반영하는 과정에서 실수로 인한 결함 발생
- 코딩 결함: 설계 문서를 잘못 이해하거나 프로그래밍 언어 또는 개발 도구에 익숙하지 않아 발생하는 결함
- 기타 결함: 문서나 코딩 표준에 따르지 않는 경우, 미흡한 테스트 프로세스, 요구사항 불확실, 잦은 변경, 테스트 시간 부족
1.4 Beizer의 소프트웨어 테스트 진화 과정
| 레벨1 | Debugging-oriented | 테스트와 디버깅의 차이가 없다. 즉, 우연히 발견된 오류를 수정하는 디버깅에 중점을 두며 프로그램의 오류를 찾기 위한 별도의 노력을 기울이지 않는다. |
| 레벨2 | Demonstration-oriented | 프로그램이 올바르게 동작한다는 사실을 입증하기 위해 테스트를 수행한다. |
| 레벨3 | Destruction-oriendted | 프로그램에 결함이 존재함을 보여주기 위해 테스트를 수행한다. |
| 레벨4 | Evaluation-oriented | 소프트웨어 개발 후에 결함을 찾는 것이 아닌 개발 전 단계에 발생하는 결함을 발견하는 개념으로 확장한다. |
| 레벨5 | Prevention-oriented | 프로그램의 오류를 사후에 발견하는 것이 아니라 아예 결함이 발생하지 않도록 사전에 방지하자는 개념이며 테스트 용이성을 고려하여 프로그램을 설계한다. |
1.5 소프트웨어 테스트 한계 및 고려사항
[한계]
- 테스트는 결함이 존재함을 보일 수는 있지만, 결함이 없다는 것을 보일 수는 없다.
- 프로그램의 입력 영역은 무한히 크기 때문에 현실적으로 가능한 모든 입력 값들을 테스트 데이터로 선정할 수 없다.
[고려사항]
- 테스트는 반드시 프로그램을 개발한 프로그래머나 팀과는 무관한 그룹에 의해서 수행되어야 한다.
- 테스트 작업은 가장 능력이 뛰어난 사람에게 할당한다.
- 오류가 발견되지 않을 것이란 가정하에서 테스트 계획을 수립해서는 안된다.
- 타당한 경우뿐만 아니라 타당하지 않고 예상하지 못한 경우들에 대해서도 테스트를 수행한다.
- 프로그램의 어떤 부분에 오류가 남아있을 확률은 이미 발견된 오류의 수에 직접적으로 비례한다.(Pareto 원칙)
- 테스트 케이스를 체계적으로 관리한다.
- 각각의 테스트 결과를 철저하게 점검한다.
1.6 테스트 용이성
프로그램이 테스트 가능한지를 나타내는 특성 또는 요구사항이 테스트로 증명 가능한지를 나타내는 특성
| 제어용이성 | 실행 제어가 용이하게 설계, 제어용이성↑=테스트 자동화 가능성↑ |
| 관찰가능성 | 프로그램 내부상태(중간, 최종)를 쉽게 파악할 수 있도록 설계 |
| 단순성 | 시스템 구조 등을 단순하게 설계, 시스템 단순 = 효율적 테스트 |
| 운영용이성 | 프로그램이 오작동해도 테스트 작업을 계속할 수 있도록 설계 |
| 안정성 | 테스트 간 소프트웨어 변경이 자주 안되게 설계 |
| 이해용이성 | 조직화된 설계정보 → 쉬운 접근, 소프트웨어 이해 |
| 분할용이성 | 테스트 대상 모듈 분리 → 독립적 테스트 |
1.7 제품 품질의 예
| 기능 적합성 | 시험 대상 제품의 기능 정상작동 여부 |
| 성능 효율성 | CPU, Memory 사용량 시험 대상 제품의 목표 성능 정의 |
| 호환성 | 다른 제품과 충돌 없이 동작 가능한지 확인 |
| 신뢰성 | 비정상종료 발생 확인 이중화 기능, 데이터 복구 기능 존재 여부 확인 및 동작 확인 |
| 유지보수성 | 프로그램 운영 중 발생할 수 있는 문제에 대한 해결 정보 여부 확인 |
| 이식성 | 버전업 제품 경우, 이전 버전과 데이터 호환 가능 여부 확인 |
| 일반적 요구사항 | 제품 운영을 위한 정보 제공 여부 확인 |
| 사용성 | 용어 일관성, 화면 깨짐 등 확인 예) 용어 일관성 오류: '정보 수정' 화면에서 '환자 첫지료'로 표시되지만, 다른 화면에서는 '환자 초진'으로 표시되어 일관되지 않음 2020년 2회 출제됨 |
| 보안성 | 기밀성/무결성/부인방지성/책임성/인증성 |
1.8 개발 단계별 테스트
| 대상 | 테스터 | 환경 | 방법 | 대상 | 문서(산출물) | |
| 단위테스트 (컴포넌트 테스트) |
단위 모듈 | 개발자 | 개발환경 | 화이트박스 (스텁, 드라이버, 시뮬레이터) |
최소단위함수, 기능(모듈) | 요구사항정의서, 개념/상세설계서, 기능설계서, 명세서, 인터페이스 설계서 등 |
| 통합테스트 | 통합 모듈 | 개발자 | 개발환경 | 그레이박스 | 외부 인터페이스 연결 (서버, 네트워크, DB), 내부모듈간 연결 |
(단위산출물)_통합시험 계획서/절차서/결과서 |
| 시스템테스트 | 전체 시스템 | 테스터 (제3자) |
실환경 (실제와 유사) |
그레이박스 | 기능/비기능 테스트 | (단위+통합산출물)+실증시험계획서/절차서/결과서, 메뉴얼 |
| 인수테스트 | 전체 시스템 | 사용자, 고객 | 실환경 | 블랙박스 (알파, 베타, 운영/사용자, 계약인수 테스트) |
출시 예정 제품 | (단위+통합+시스템)+결함리포트, 결과보고서 피드백 등 |
1.8.1 단위테스트(Unit Test)
> 테스트가 가능한 최소 단위로 나누어진 소프트웨어(모듈, 프로그램, 객체, 클래스 등)내에서 결함을 찾고 그 기능을 검증하는 것
> 구현 단계에서 각 모듈이 구현된 후에 단위 테스트를 수행
> 모듈을 단독적으로 실행할 수 있는 환경이 필요
- 테스트 드라이버(Test driver): 테스트 대상이 되는 모듈을 호출하여 준비한 테스트 데이터를 제공하고 모듈의 실행 결과를 받는 모듈
- 테스트 스텁(Test stub): 호출되는 모듈의 개발이 완료되지 않은 경우, 호출하는 모듈을 시험하기 위해 생성한 더미 모듈로 모든 기능을 완전히 구현할 필요는 없다.
1.8.2 통합 테스트(Integration Test)
> 모듈을 통합하는 과정에서 수행하는 테스트
> 모듈 간의 상호 작용이 올바르게 되는지 검사
> 개별적인 모듈에 대한 테스트가 불충분하거나 개별 모듈에서 동일한 전역 변수를 사용하여 오류가 발생할 수 있음
> 통합 전략
- 빅뱅(Big-bang) 통합: 전체 시스템에 대해 한번에 통합 테스트를 수행하여 단시간에 테스트가 가능하지만, 오류가 발 생했을 경우 오류가 발생한 모듈 및 원인을 찾기가 매우 어려움
- 점진적 테스트: 한번에 모듈들을 통합하지 않고 점진적으로 통합하면서 테스트(상향식/하향식/샌드위치 통합 방식)
하향식 통합: 가장 상위 모듈을 테스트하기 위해 하위 모듈을 테스트 스텁으로 대치한 후 테스트 수행
깊이 우선(depth first) 방식은 M1,M2,M3,M4,M5,M6,M7 순서로 통합
너비 우선(breadth first) 방식은 M1,M2,M6,M7,M3,M4,M5 순서로 통합
설계상의 오류를 빨리 발견할 수 있음
많은 수의 테스트 스텁이 필요하고 구현되는 비용이 많이 소요된다면 효과적이지 않음
상향식 통합: 하위 모듈을 먼저 통합하고 상위에 있는 모듈들을 통합하는 방식으로 테스트 드라이버가 필요
하위에 있는 모듈들을 충분하게 테스트할 수 있음
설계 오류를 조기에 발견하지 못함
샌드위치 통합: 상향식 통합 방식과 하향식 통합 방식을 절충하여 통합하는 방식
1.8.3 스모크 테스트(Smoke Test)
> 빌드가 테스트할만한 수준인지를 확인
> 각 모듈의 중요한 기능의 일부분, 화면 이동 경로, 회귀 테스트 범위의 일부분 등 체크
1.8.4 시스템 테스트(System Test)
> 통합 테스트가 완료된 후에 완전한 시스템으로 수행
> 시스템의 기능측면뿐만 아니라 비기능적인 요구사항도 검증
> 견고성/신뢰성/성능 테스트
- 견고성 테스트: 시스템이 비정상적인 경우에도 얼마나 동작이 원활하게 이루어지는지 나타내는 속성(네거티브 테스트)
- 신뢰성 테스트: 시스템이 어느 기간동안 요구되는 서비스를 제공하는 능력 측정
- 성능 테스트: 부하 테스트/스트레스 테스트/스파이크 테스트/안정성 테스트
1.8.5 인수 테스트(Acceptance Test)
> 실제 사용자 환경에서 사용자가 테스트 수행
> 인수 기준을 만족하는 가를 검사
> 시스템 테스트에서 사용한 테스트 케이스를 이용할 수 있음
1.8.6 회귀 테스트(Regression Test)
> 소프트웨어가 수정된 후에 변경이 올바르게 되었는지 검사
> 프로그램 수정 전에 정상 작동했던 기능들이 수정 후에도 정상인지 시험
> 수정되기 전에 작성된 테스트 케이스를 실행하여 수정 전의 기능들이 정상 작동하는지 확인