1. 소프트웨어 테스트의 기본 7원칙
| 원칙 | 설명 |
|---|---|
| 테스팅은 결함이 존재함을 밝히는 활동이다. | - 테스팅은 소프트웨어의 잠재적인 결함을 줄일 수 있지만, 결함이 발견되지 않아도 결함이 없다고 증명할 수 없음을 나타낸다. |
| 완벽한 테스팅은 불가능하다. | - 무한 경로, 무한 입력 값, 무한 시간이 소요되어 완벽하게 테스트할 수 없으므로 리스크 분석과 우선순위를 토대로 테스트에 집중할 것을 의미한다. |
| 테스팅은 개발 초기에 시작해야한다. | - 애플리케이션의 개발 단계에 테스트를 계획하고 SDLC(Software Development Life Cycle)의 각 단계에 맞춰 전략적으로 접근하는 것을 고려하라는 뜻이다. |
| 결함집중(Defect Clustering) | - 애플리케이션 결함의 대부분은 소수의 특정한 모듈에 집중되어 존재한다는 의미이다.(파레토 법칙) |
| 살충제 패러독스(Pesticide Paradox) | - 동일한 테스트 케이스로 반복 실행하면 결함을 발견할 수 없으므로 주기적으로 테스트 케이스를 리뷰하고 개선해야 한다. |
| 테스팅은 정황(Context)에 의존한다. | - 정황과 비즈니스 도메인에 따라 테스트를 다르게 수행하여야 한다. |
| 오류-부재의 궤변(Absece of Errors Fallacy) | - 사용자의 요구사항을 만족하지 못하면 오류를 발견하고 그 오류를 제거하였다 해도, 해당 애플리케이션의 품질이 높다고 말할 수 없다. 즉 사용자 요구와 기대에 만족하지 못해 사용성이 현저히 낮다면 결함을 찾는 과정은 아무 소용이 없다는 의미이다. |
2. 테스트와 디버깅의 차이
| 구분 | 테스트 | 디버깅 |
|---|---|---|
| 목적 | - 알려지지 않은 에러의 발견 | - 이미 알고 있는 에러의 수정 |
| 수행 | - 시스템 내부 관련자, 테스트 팀 등 외부의 제3자 | - 시스템 내부 관련자 |
| 주요작업 | - 에러의 발견(Fault Detection) | - 에러의 정확한 위치 파악(Fault Location) |
| - 에러의 타입 식별 | ||
| - 에러의 수정 |
3. 소프트웨어 테스트 기법
3-1. 명세기반 기법(Sepecification Based Techniques)과 구조기반 기법(Structural Based Techniques)
| 구분 | 명세기반 기법 | 구조기반 기법 |
|---|---|---|
| 개념 | 주어진 명세를 바탕으로 테스트케이스를 도축하며 표현 방식은 UML을 많이 사용함. | 소프트웨어나 시스템의 구조를 중식으로 테스트케이스를 도출 |
| 특정 커버리지를 달성하기 위한 테스트를 설계하고, 케이스를 도출하기 위해 사용되는 기법 | ||
| 특징 | 블랙 박스 기법 | 화이트 박스 기법 |
| 문서 분석 필요 | 컴포넌트/시스템 코드 분석 | |
| 기능적/비기능적 테스트케이스 도출 | 추가적 테스트케이스 도출 | |
| 종류 | 동등분할 | 구문커버리지 |
| 경계값 분석 | 결정커버리지 | |
| 결정테이블 | 조건커버리지 | |
| 상태전이 | 조건/결정커버리지 | |
| 유스케이스 | 변경조건/결정커버리지 | |
| 다중조건커버리지 |
3-2. 실행방법으로 분류
테스트 기법을 실행방법으로 나누면 화이트 박스 검사와 블랙박스 검사로 나누어짐.
1. 화이트박스 테스트 기법 유형
화이트박스 검사 : 소스코드를 보고 실행을 변경하면서 검사를 하는 기법
암기Tip. "제 데 루"
| 유형 | 설명 |
|---|---|
| 기본경로 | - Tom McCabe가 제안한 대표적인 화이트 박스 테스트 기법 |
| - 순환복잡도(Cyclomatic Complexity)를 통해 독립적인 경로의 수를 찾아 테스트하는 기법 | |
| 반복경로 검사(루프 검사) | - 프로그램의 반복 구조에 초점을 맞추어 검사 |
| 제어 구문 검사 | - 프로그램의 제어구문(if, case, else)을 테스트하는 기법 |
| 데이터 흐름 검사 | - 프로그램에서 변수의 정의와 변수 사용의 위치에 초점을 맞추어 검사 |
2. 블랙박스 테스트 기법 유형
블랙박스 검사 : 소스코드 참조 없이 외부에서 드러난 인터페이스만을 이용하여 검사하는 기법
암기Tip. 아래 4가지만 외우자!
| 유형 | 설명 |
|---|---|
| 동등분할 기법, 동치분할 기법(Equivalent Analysis) | - 입력값의 범위를 유사한 특징을 갖는 동등 그룹으로 나누고, 각 그룹마다 대표 값을 선정하여 테스트케이스를 선정하는 기법 |
| 경계값 분석 기법(Boundary Value Analysis) | - 경계값 분석은 등가 분할된 경계의 유효한 값과 경계에서 가장 가까운 유효하지 않는 값을 테스트 데이터로 선택하여 컴포넌트나 시스템을 테스트하는 기법 |
| 원인 효과 그래프 기법(Cause Effect Graph) | - 입력값을 원인으로, 효과를 출력 값으로 정하고 이에 따른 원인 결과 그래프를 만들어서 테스트 케이스를 작성하는 기법 |
| 의사결정테이블 테스팅 기법 | - 생성될 수 있는 결과를 테이블로 나열하여 가능한 모든 조합을 테스트하는 기법 |
4. 테스트 단계
테스트 단계 : 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트가 있음.
4-1. 테스트 레벨에 따른 테스트의 유형
| 단위 테스트(단위 검사) | 구현된 단위 모듈()의 기능 수행 여부를 판정하고 내부에 존재하는 논리적 오류를 검출 |
| 통합테스트(통합 검사) | 모듈 간의 인터페이스 연계를 검증하고 오류를 확인, 모듈 간의 상호 작용 및 연계 동작이 제대로 가능하는지 점검 |
| 시스템 테스트(시스템 검사) | 단위, 통합 테스트 후 전체 시스템이 정상적으로 작동하는지 판정하는 기능을 점검 |
| 인수 테스트(인수 검사) | 사용자 요구분석 명세서에 명시된 사항을 모두 충족하는지 판정하고 시스템이 예상대로 동작하고 있는지 점검 |
4-2. 통합테스트
통합테스트 : 모듈 간의 인터페이스 연계를 검증하고 오류를 확인, 모듈 간의 상호 작용 및 연계 동작이 제대로 가능하는지 점검하는 테스트 단계.
| 단계 | 상향식 통합 방법 | 하향식 통합 방법 |
|---|---|---|
| 1단계 | 최하위 레벨의 모듈 또는 컴포넌트들이 하위 모듈의 기능을 수행하는 클러스터(Cluster)로 결합됨 | 메인 제어 모듈은 작성된 프로그램을 사용하고, 아직 작성되지 않은 하위 제어 모듈 및 모든 하위 컴포넌트를 대신하여 더미 모듈인 스텁(Stub)을 개발함 |
| 2단계 | 상위 모듈에서 데이터의 입력과 출력을 확인하기 위한 더미 모듈인 드라이버(Driver)를 작성함 | 깊이-우선방식 또는 너비-우선 방식에 따라, 하위 모듈인 스텁이 한번에 하나씩 실제 모듈로 대체됨 |
| 3단계 | 각 통합된 클러스터 단위를 테스트 함 | 각 모듈 또는 컴포넌트를 통합하면서 테스트가 수행됨 |
| 4단계 | 테스트가 완료되면 각 클러스터들은 프로그램의 위쪽으로 결합되며, 드라이버는 실제모듈 또는 컴포넌트로 대체됨 | 테스트가 완료되면 스텁이 실제 모듈 또는 컴포턴트로 작성됨 |
| 구분 | 상향식 통합 방법 | 하향식 통합 방법 |
|---|---|---|
| 이미지 |  |  |
- 학습 Tip
- 상향식 통합 방법은 최하위 모듈 통합 후 위층의 모듈을 추가 테스트 하는 방법으로 테스트 드라이버가 필요한 테스트 방법
- 하향식 통합 방법은 모듈부터 통합하며 시험시 Stub가 필요한 테스트 방법
- 참조
- 드라이버(Driver) : 시스템 및 시스템 컴포넌트를 시험하는 환경의 일부분으로 시험을 지원하는 목적 하에 생성된 코드와 데이터.
- 스텁(Stub) : 특정한 시스템 컴포넌트의 개발이 완료되지 않은 상황에서도 필요한 시험을 진행하기 위해 생성된 더미 컴포넌트를 의미.
4-3. 인수테스트
인수테스트 : 사용자 요구분석 명세서에 명시된 사항을 모두 충족하는지 판정하고 시스템이 예상대로 동작하고 있는지 점검하는 테스트 단계.
인수테스트 유형
| 인수테스트 | 설명 |
|---|---|
| 알파 테스트(알파 검사) | 개발자의 장소에서 사용자가 개발자 앞에서 행해지며, 오류와 사용상의 문제점을 사용자와 개발자가 함께 확인하면서 검사하는 기법(즉, 개발자 환경에서 테스트하는 기법) |
| 베타 테스트(베타 검사) | 다수의 사용자를 제한되지 않은 환경에서 프로그램을 사용하게 하고 오류가 발견되면 개발자에게 통보하는 방식(즉, 사용자 환경에서 테스트하는 기법) |
4-4. 그 외...
회귀테스트 : 이미 테스트가 완료된 소프트웨어에 변경이 발생할 때 이로 인해 의도하지 않는 오류가 생기지 않았음을 보증하기 위한 테스트를 의미
5. 테스트 오라클
테스트 오라클 개념 : 테스트의 결과가 참인지 거짓인지를 판단하기 위해서 사전에 정의된 참 값을 입력하여 비교하는 기법 및 활동을 말함.
테스트 오라클의 유형
| 구분 | 설명 |
|---|---|
| 참(True) 오라클 | 모든 입력 값에 대하여 기대하는 결과를 생성함으로써 발생된 오류를 모두 검출할 수 있는 오라클 |
| 샘플링(Sampling) 오라클 | 특정한 몇 개의 입력 값에 대해서만 기대하는 결과를 제공해 주는 오라클 |
| 휴리스틱(Heuristic) 오라클 | 샘플링 오라클을 개선한 오라클, 특정 입력 값에 대해 올바른 결과를 제공하고, 나머지 값들에 대해서는 휴리스틱(추정)으로 처리하는 오라클 |
| 일관성 검사(Consistent) 오라클 | 애플리케이션 변경이 있을 때, 수행 전과 후의 결과 값이 동일한지 확인하는 오라클 |
6. 애플리케이션 성능 지표 및 테스트 도구
6-1. 애플리케이션 성능 지표
애플리케이션의 성능을 측정하기 위해서는 다양한 측정지표가 있다. 이러한 측정지표 개선을 통해서 애플리케이션이 최소의 자원을 사용하면서 얼마나 빨리, 많은 기능을 수행할 수 있도록 해야한다.
주요 성능 지표
| 스케줄링 기준 | 설명 | 목표 |
|---|---|---|
| 처리량(Throughput) | 주어진 시간에 최대한 많은 작업 처리(처리된 프로세스 수/시간) | 최대화 |
| 경과(반환)시간(Turnaround time) | 전체작업 수행시간을 최소화(System in -> System out 시간) | 최소화 |
| 대기 시간(Waiting time) | 준비 큐에서 기다리는 시간 최소화 | 최소화 |
| 응답 시간(Response time) | 애플리케이션에 요청을 전달한 시간부터 응답이 도착할때까지 걸린 시간 | 최소화 |
| 자원 사용률(Utilization) | 단위 시간당 작업을 수행하는 총 시간 비율 | 최대화 |
| Fairness | 프로세스별 자원 할당의 공정성 | 최대화 |
| Deadline | 실시간 환경 등에서의 즉시 처리 한계 시간 | 최대화 |
6-2. 테스트 도구
📍 소프트웨어 개발보안 구축관련 정리 잘된 자료들 모음
어떠한 가치를 창출할 수 있을까를 고민하는 개발자. 주로 Spring으로 개발해요. https://comclothing.tistory.com/ 👈🏻티스토리 블로그로 이전 완료