소프트웨어 테스트 개념
개발된 응용 애플리케이션이나 시스템이 사용자 요구사항에 만족하는지 확인하고 노출되지 않은 결함을 찾아내는 활동
소프트웨어 테스트 필요성
발예향 오류 발견/오류 예방/품질 향상
SW 테스트 원리 [2020 1회 기출]
결완초집 살정오
결함 존재 증명/완벽한 테스팅 불가/초기 집중(Snowball Effect)/결함 집중(Pareto Princeple)/살충제 패러독스/정황 의존성/오류-부재의 궤변
| 결함 존재 증명 | 결함이 없다는건 증명 불가하므로 결함 존재 증명 |
|---|---|
| 완벽한 테스팅 불가 | 불필요한 시간과 자원 낭비 |
| 초기 집중(Snowball Effect) | 요르돈의 법칙: SW 개발 초기 체계적 분석/설계 수행되지 못하면 후반에 영향을 미쳐 비용이 커진다는 원리 |
| 결함 집중(Pareto Princeple) | 파레토 법칙(Pareto Principle): 소프트웨어 테스트에서 오류 80%는 전체 모듈의 20% 내에서 발견 |
| 살충제 패러독스 | 동일한 테스트 케이스를 사용하여 반복적 테스트를 수행하면 새로운 버그를 찾지 못한다는 원리 |
| 정황 의존성 | 소프트웨어의 성격에 맞게 테스트 실시(정황과 비즈니스 도메인에 따라) |
| 오류-부재의 궤변 | 요구사항 미 충족 시, 결함 없다고 해도 품질이 높다고는 볼 수 없는 소프트웨어 테스트 원리 |
SW 공학 원칙 관련 법칙
| 브룩스의 법칙
| (Brooks’ Law) | 인력이 추가되서 개발 생산성이 향상되지 않고 오히려 그 인력 때문에 방해 된다는 의미 |
|---|---|
| 롱테일 법칙 | |
| (Long Tail) | 사소해 보이는 80% 다수가 20% 소수 핵심보다 뛰어난 가치 창출해낸다는 이론 |
SW 테스트 산출물 ❣️
테스트 계획서/테스트 베이시스/테스트 케이스/테스트 슈트/테스트 시나리오/테스트 스크립트/테스트 결과서
| 테스트 계획서
| (Test Plan) | 테스트 수행 계획한 문서 |
|---|---|
| 테스트 베이시스 | |
| (Test Basis) | 분석, 설계 단계의 논리적 Case로 테스트 설계위한 기준이되는 문서 |
| 테스트 케이스 | |
| (Test Case) | 응용 소프트웨어가 사용자 요구사항 준수하는지 확인하기 위해 설계된 입력값, 실행 조건, 기대 결과로 구성된 테스트 항목의 명세서 |
| 테스트 슈트 | |
| (Test Suites) | 실행 환경에 따라 구분해 놓은 테스트 케이스 집합 |
| 테스트 시나리오 | |
| (Test Scenario) | 애플리케이션의 테스트가 되야 할 기능/특징/상황을 작성한 문서 |
| 테스트 스크립트 | |
| (Test Script) | 테스트 케이스 실행 순서(절차) 작성한 문서(=테스트 스텝/절차서) |
| 테스트 결과서 | |
| (Test Results) | 테스트 결과를 정리한 문서 |
프로그램 실행 여부에 따른 분류
| 정적 테스트 | 테스트 대상 실행X 구조 분석하여 논리성 검증 | 리뷰, 정적 분석 | | --- | --- | --- | | 동적 테스트 | 소프트웨어 실행O 테스트 수행해 결함 검출 | 화이트 박스/블랙 박스/경험 기반 테스트 |
정적 테스트 종류
| 리뷰
| (Review) | SW 다양한 산출물에 존재하는 결함 검출하거나 프로젝트 진행 상황 점검하기 위한 활동으로, 전문가가 수행 |
|---|---|
| 정적 분석 | |
| (Static Analysis) | 도구 지원 받아 정적 테스트를 수행하는 방법으로 자동화된 도구 이용해 산출물 결함 검출하거나 복잡도 측정 |
리뷰 유형
동워인 동료 검토/워크 스루/인스펙션
| 동료 검토
| (Peer Review) | 2~3명 진행하여 요구사항 명세서 작성자의 설명을 들으며 결함을 발견 |
|---|---|
| 워크 스루 | |
| (Walk Through) | 검토 자료 회의 전에 배포해 사전 검토 후 짧은 시간동안 회의 진행하여 비형식적 |
| 인스펙션 | |
| (Inspection) | 저작자 외 다른 전문가/팀이 검사해 문제 식별/해결 찾아내는 형식적 검토로 초기에 검사해야 함 |
| 관리 리뷰 | |
| (Maangement Review) | 프로젝트 진행 상황에 대한 전반적 검토를 바탕으로 범위, 일정, 인력 등에 대한 통제 및 의사 결정 지원하는 리뷰 |
| 기술 리뷰 | |
| (Technical Review) | 정의된 계획 및 명세 준수하고 있는지 검토 수행하는 리뷰로 변경 사항 적절하게 구현되었는지 평가, 여러 대안 추천/대안 검토 |
동적 테스트 종류
| 화이트 박스 테스트 | • 각 응용 프로그램의 내부 구조와 동작을 검사하는 동적 소프트웨어 테스트 • 구조 기반/코드 기반/로직 기반/글래스 박스 테스트 | | --- | --- | | 블랙 박스 테스트 | • 프로그램 외부 사용자의 요구사항 명세를 보며 수행하는 테스트 • 자체가 명세 테스트이고 전체 소프트웨어 테스트 레벨에서 적용 가능 | | 경험 기반 테스트 | 유사 소프트웨어나 유사 기술 평가에서 테스터의 경험 토대로 한, 직관과 기술 능력 기반으로 수행하는 테스트 기법 |
화이트박스 테스트 유형 [2020 3회 기출] [2021 2회 기출]
화구결조 조변다 기제데 구문 커버리지/결정 커버리지/조건 커버리지/
조건-결정 커버리지/변경 조건-결정 커버리지/다중 조건 커버리지/
기본 경로 커버리지/제어 흐름 테스트/데이터 흐름 테스트
| 구문(문장) 커버리지
| Statement Coverage | 모든 명령문 최소 한 번 수행 |
|---|---|
| 결정(선택,분기) 커버리지 | |
| Decision(Branch) Coverage | 결정(분기) 포인트 내 전체 조건식이 적어도 한번은 참(T)과 거짓(F)의 결과 수행, 결정 검증 기준 |
| 조건 커버리지 | |
| Condition Coverage | 결정 포인트 내 각 개별 조건식이 적어도 한 번은 참과 거짓의 결과가 되도록 수행 |
| 조건-결정 커버리지 | |
| (Condition/Decision Coverage) | 전체 조건식 뿐 아니라 개별 조건식도 한번은 참, 거짓이 되도록 수행 |
| 변경 조건-결정 커버리지 | |
| Modified Condition/Decision Coverage | 개별 조건식이 다른 개별 조건식에 영향 받지 않고 전체 조건식에 독립적 영향을 주도록 함 |
| 다중 조건 커버리지 | |
| (Multiple Condition Coverage) | 결정 조건 내 모든 개별 조건식의 모든 가능한 조합 100% 보장 |
| 기본 경로(경로) 커버리지 | |
| (Base Path Coverage) | 수행 가능한 모든 경로 테스트(맥케이브) |
| 제어 흐름 테스트 | |
| (Control Flow Testing) | 프로그램 제어 구조 그래프 형태로 나타내 내부 로직 테스트 |
| 데이터 흐름 테스트 | |
| (Data Flow Testing) | 제어 흐름 그래프에 데이터 사용 현황 추가한 그래프 통해 테스트 |
맥케이브(McCabe)의 순환 복잡도 개념
소프트웨어 제어 흐름을 그래프로 표현하고 소스코드의 복잡도를 노드 수와 간선 수 의 계산을 통해 정량적으로 나타내는 지표
블랙박스 테스트 유형 [2020 3회 기출] [2020 4회 기출] [2021 1회 기출] [2021 3회 기출]
블동경결상 유분페원비
동등분할/경곗값 분석/결정 테이블/상태 전이/
유스케이스/분류 트리/페어와이즈/원인-결과 그래프/비교 테스트
| 동등 분할(동치 분할, 균등 분할, 동치 클래스 분해) 테스트
| Equivalence Partitioning Testing | 입력 데이터 영역 유사한 도메인별로 유/무효값 그룹핑해 대푯값 테스트 케이스 도출해 테스트 |
|---|---|
| 경곗값 분석(한곗값) 테스트 | |
| Boundary Value Analysis Testing | 등가 분할 후 경곗값 부분에서 오류 발생 확률 높아 경곗값 포함해 테스트 케이스 설계해 테스트 |