소프트웨어 테스트
: 구현된 소프트웨어의 동작과 성능, 사용성, 안전성 등을 만족하기 위하여 소프트웨어의 결함을 찾아내는 활동
소프트웨어 테스트의 필요성
- 오류 발견 관점
- 오류 예방 관점
- 품질 향상 관점
파레토 법칙 : 전체 결과의 80%가 전체 원인의 20%에서 일어나는 현상
- 롱테일 법칙 : 주목받지 못하는 다수가 핵심적인 소수보다 더 큰 가치를 창출하는 현상
+ 브룩스의 법칙 : 지연되는 프로젝트에 인력을 더 투입하면 오히려 더 늦어진다.
살충제패러독스 : 동일한 테스트 케이스로 반복 실행하면 결함을 발견할 수 없으므로 주기적으로 테스트 케이스를 리뷰하고 개선해야 한다.
오류-부재의 궤변 : 사용자의 요구사항을 만족하지 못하는 오류를 발견하고 그 오류를 제거하였다 해도, 해당 애플리케이션의 품질이 높다고 할 수 없다.
테스트 케이스 : 기능 테스트를 위한 입력 값, 테스트 조건, 기대 결과로 구성된 테스트 항목의 명세서
테스트 시나리오 : 테스트 수행을 위한 여러 개의 테스트 케이스의 집합
테스트 오라클
: 테스트의 결과가 참인지 거짓인지를 판단하기 위해 사전에 정의된 참 값을 입력하여 비교하는 기법 및 활동
유형
1) 참오라클
- 모든 테스트 케이스 입력 값의 기대 결과를 확인
- 항공기, 임베디드, 발전소 소프트웨어 등 크리티컬한 업무
2) 샘플링 오라클
- 특정한 몇 개의 입력 값에 대해서만 기대하는 결과를 제공해주는 오라클
- 일반, 업무용, 게임, 오락 등의 일반적인 업무
3) 휴리스틱 오라클
- 샘플링 오라클을 개선한 오라클로, 특정 입력 값에 대해 올바른 결과를 제공하고 나머지 값들에 대해서는 휴리스틱 ( 추정 )으로 처리하는 오라클
4) 일관성 검사 오라클
- 애플리케이션 변경이 있을 때, 수행 전과 후의 결과 값이 동일한지 확인하는 오라클
테스트 레벨
1) 단위테스트
- 소프트웨어 개발에서 테스트 프로세스의 첫 단계로 작성된 코드에 대한 분석을 진행
- 모듈 설계 단계에서 준비된 테스트 케이스를 이용하며, 코드를 개발한 개발자가 직접 수행
2) 통합 테스트
- 각각의 모듈들을 통합하여, 통합된 컴포넌트 간의 인터페이스와 상호작용 과정의 오류를 발견하는 작업을 수행
- 코드를 직접 확인하는 형태가 아닌 프로그램을 실행하며 테스트를 진행
3) 시스템 테스트
전체 시스템이 정상적으로 작동하는지 확인
| 기능 테스트 | 고객의 기능적요구사항을 중점적으로 테스트 요구사항에 따른 기능의 구현 여부 및 동작 여부에 대한 테스트를 진행 |
| 비기능 테스트 | 고객의 성능 요구사항을 중점적으로 테스트 성능, 신뢰성, 안정성, 유효성, 적합성 등을 확인 |
4) 인수 테스트
시스템을 배포하거나 실제 사용할 만한 준비가 되었는지에 대해 평가
유형
알파 테스트 : 개발자의 통제 하에 사용자가 개발 환경에서 수행하는 테스트
베타 테스트 : 개발된 소프트웨어를 사용자가 실제 운영환경에서 수행하는 테스트
소프트웨어 테스트 기법
(1) 프로그램 실행 여부
1) 정적 테스트 : 소프트웨어 실행 없이 소스코드의 구조를 분석하여 논리적으로 검증하는 테스트
2) 동적 테스트 : 소프트웨어를 실행하여 실제 발생하는 오류를 발견하여 문제를 해결하는 분석 기법
(2) 테스트 기법
1) 화이트박스 테스트
- 소프트웨어의 내부 구조와 동작을 검사하는 테스트 방식
- 소프트웨어 내부 소스코드를 테스트하는 기법
| 문장 검증 | 프로그램의 모든 문장을 한 번 수행하여 검증 |
| 선택( 분기 ) 검증 | 선택하는 부분만 검증 |
| 경로 검증 | 수행 가능한 모든 경로 검사 |
| 조건검증 | 조건이나 반복문 내 조건식을 검사 |
2) 기초 경로 검사
- McCabe가 제안한 것으로 대표적인 화이트박스 테스트 기법
3) 블랙박스 테스트
- 구현된 기능을 테스트로 사용자 관점의 테스트 방법
블랙박스 테스트 기법
| 동등 분할 기법 | 입력 자료에 초점을 맞춰 테스트 케이스를 만들어 검사하는 방법 |
| 경계값 분석 | 입력 값의 중간보다 경계값에서 오류가 발생할 확률이 높다는 점을 이용해 입력 조건의 경계값을 테스트 케이스로 선정 |
| 원인-효과 그래프 검사 | 입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 체계적으로 분석한 다음 효용성이 높은 테스트 케이스르 선정하여 검사하는 기법 |
| 오류 예측 검사 | 과거의 경험이나 테스터의 감각으로 테스트하는 기법 |
| 비교 검사 | 여러 버전의 프로그램에 동일한 테스트 자료를 제공하여 동일한 결과가 출력되는지 테스트하는 기법 |
- 검증 ( Verification ) : 소프트웨어의 개발 과정을 테스트, 올바른 소프트웨어가 만들어지고 있는지를 검증
- 확인 ( Validation ) : 소프트웨어의 결과를 테스트, 완성된 소프트웨어가 정상적으로 동작하는지 확인
(3) 테스트 목적
- 회복 ( Recovery ) : 시스템에 고의로 실패를 유도하고 시스템이 정상적으로 복귀하는지 테스트
- 강도 ( Stress ) : 시스템에 과다 정보량을 부과하여 과부하 시에도 시스템이 정상 작동되는 지를 검증하는 테스트
- 회귀 ( Regression ) : 변경 또는 수정된 코드에 대해 새로운 결함 발견 여부를 평가하는 테스트
- 병행 ( Parallel ) : 변경된 시스템과 기존 시스템에 동일한 데이터를 입력 후 결과를 비교하는 테스트
- A / B 테스트 : 기존 서비스 A와 새로 적용하고 싶은 서비스 B를 통계적인 방법으로 비교하여 새로운 서비스가 기존 서비스에 비해 정말 효과가 있는지 알아보는 테스트
- 스모크 테스트 : 본격적인 테스트 수행에 앞서 테스트 환경의 테스트가 가능한지 여부를 판단하기 위해 테스트
테스트 커버리지
- 주어진 테스트 케이스에 의해 수행되는 소프트웨어의 테스트 범위를 측정하는 테스트 품질 측정 기준
- 테스트의 정확성과 신뢰성을 향상시키는 역할로 테스트를 얼마나 수행했는지 측정하는 기준
유형
1) 기능 기반 커버리지 : 애플리케이션의 전체 기능을 모수로 설정, 테스트가 수행된 기능의 수를 측정
2) 라인 커버리지 : 애플리케이션 전체 소스코드의 Line 수를 모수로 정하고, 테스트가 수행한 소스코드의 Line수를 측정
3) 코드 커버리지 : 소스코드의 구문, 조건, 결정 등의 구조 코드 자체가 얼마나 테스트되었는 지를 측정하는 방법
- 구문 커버리지 : 코드 구조 내의 모든 구문에 대해 한 번 이상 수행하는 테스트 커버리지
- 조건 커버리지 : 결정 포인트 내의 모든 개별 조건식에 대해 수행하는 테스트 커버리지
개별 조건식이 각각 T/ F만 만족하면 된다. - 결정 커버리지 : 결정 포인트 내의 모든 분기문에 대해 수행하는 테스트 커버리지
결정 포인트가 각각 T / F 만 만족하면 된다. - 조건 / 결정 커버리지 : 결정포인트 T / F, 개별조건식 T / F를 가져야한다.
- 변경 조건 / 결정 커버리지 : 모든 결정포인트 내외 개별 조건식은 적어도 한 번 T / F를 가져야 한다.
이론적으로 가장 안전한 조합이며 케이스도 줄일 수 있다. - 다중 조건 커버리지 : 결정포인트 내 모든 개별 조건식의 가능한 조합을 100% 보장해야 한다.
결함 관리 프로세스
에러 발견 > 에러 등록 > 에러 분석 > 결함 확정 > 결함 할당 > 결함 조치 > 결함 조치 검토 및 승인
테스트 자동화 도구 유형
1) 정적 분석 도구
- 애플리케이션을 실행하지 않고 분석하는 도구
- 종류 : pmd, SonarQube, cppcheck, checkstyle 등
2) 테스트 실행 도구
3) 성능 테스트 도구
4) 테스트 통제 도구
5) 테스트 장치 ( Test Harness )
구성요소
- 테스트 드라이버 : 상향섹 테스트에 필요, 테스트 완료 후 결과 값을 받는 역할
- 테스트 스텁 : 하향식 테스트에 필요
통합 테스트
1) 하향식 통합 테스트 : 스텁을 개발하여 테스트 진행
2) 상향식 통합 테스트 : 하위 모듈을 클러스터로 결합하면서 위쪽 방향으로 진행, 드라이버를 개발하여 테스트 진행
3) 빅뱅 테스트 : 모든 구성 요소들을 한꺼번에 통합하여 테스트
4) 백본 테스트 : 상향식과 하향식의 장점을 이용하는 방식
애플리케이션 성능 분석 지표
1) 처리량 ( Troughput ) : 일정 시간 내에 애플리케이션이 처리하는 일의 양
2) 응답 시간 ( Response Time ) : 애플리케이션에 요청을 전달한 시간부터 응답이 도착할 때까지 걸린 시간
3) 경과 시간 ( Turn Around Time ) = 반환 시간 : 애플리케이션에 요청을 전달한 시간부터 처리가 완료될 때까지 걸린 시간
4) 자원 사용률 ( Resource Usage ) : 애플리케이션이 작업을 처리하는 동안의 CPU 사용량, 메모리 사용량, 네트워크 사용량 등 자원 사용률
성능 분석 도구
- JMeter : HTTP / FTP 등 다양한 프로토콜을 지원하는 부하 테스트 도구
- LoadUI : 웹 서비스의 로드 테스트, 테스트 형태에 따른 분산 UI 제공
- OpenSPA : HTTP / HTTPS 프로토콜에 대한 부하 테스트 생산품 모니터링 도구
모니터링 도구
- Scouter : 단일 뷰 통합 / 실시간 모니터링
- NMon : 리눅스 서버 자원에 대한 모니터링 도구
- Zabbix : 웹기반 서버, 서비스, 애플리케이션 모니터링 도구
- Jeniffer : 애플리케이션에서 서버로 유입되는 트랜잭션 수량, 처리시간, 응답시간, 자원 활용률 등을 모니터링
FTR ( Formal Technical Review ) 정형 기술 검토회의
- 소프트웨어 엔지니어가 수행하는 소프트웨어 품질보증 활동
- S/W 개발 산출물을 대상으로 오류를 발견하기 위한 공식적인 활동
- 개발단계에서 제작되는 문서나 프로그램의 문제점을 찾고, 문제해결을 촉구하는 일반적인 용어
소스코드 품질 분석
1) 동료 검토
- 2 ~ 3 명이 진행하는 리뷰의 형태
- 작성자가 코드를 설명하고 이해 관계자들이 설명을 들으면서 결함을 발견하는 형태로 진행
2) 워크스루
- 계획된 개발자 검토 회의
- 검토 자료를 회의 전에 배포해서 사전검토 한 후 짧은 시간 동안 회의를 진행하는 형태
3) 인스펙션
- 공식적 검사 회의
- 작업자 외 다른 전문가가 검사하는 가장 공식적인 리뷰 기법
- 계획 > 사전 교육 > 준비 > 인스펙션 회의 > 수정 > 후속 조치
소스코드 품질 분석 도구 종류
| 정적분석도구 | PMD | 주로 Java에서 사용하지만 Javascript, PLSQL, XML 등의 언어도 지원 |
| checkstyle | 자바 코드에 대한 소스코드 표준 준수 검사, 다양한 개발 도구에 통합 가능 | |
| SonarQube | 중복 코드, 복잡도, 코딩 설계 등을 분석하는 소스 분석 통합 플랫폼 | |
| cppcheck | C, C++ 코드에 대한 메모리 누수, 오버플로우 등 문제 분석 | |
| ccm | 다양한 언어 코드 복잡도 분석 도구 | |
| cobertura | 자바 언어의 소스코드 복잡도 분석 및 테스트 커버리지 측정 | |
| 동적 분석 도구 | Avalanche | 프로그램에 대한 결함 및 취약점 분석 |
| Valgrind | 프로그램 내 존재하는 메모리 및 스레드 결함 분석 |
코드 스멜 관련 용어
- 스파게티 코드 : 소스코드가 복잡하게 얽힌 모습을 의미
- 외계인 코드 : 아주 오래되거나 참고 문서 또는 개발자가 없어 유지보수 작업이 어려운 프로그램 코드
리팩토링
- 외부 동작을 바꾸지 않으면서 내부 구조를 개선하는 방법
- 이미 작성한 소스코드에서 기능의 변경 없이 가독성과 유지보수성을 높이기 위해 내부 구조를 변경하는 것