※ 애플리케이션 테스트의 기본 원리
- 파레토 법칙 : 애플리케이션의 20% 코드에서 80% 결함이 발견
- 살충제 패러독스 : 동일한 TC로 동일한 테스트를 반복하면 더 이상 결함이 발견되지 않는 현상
- 오류-부재의 궤변 : 소프트웨어의 결함이 모두 제거되었어도 사용자 요구사항을 충족시키지 못하면 소프트웨어 품질이 높다고 평가할 수 없음
※ 프로그램 실행 여부에 따른 테스트
정적 테스트
- 프로그램을 실행하지 않고 명세서나 소스 코드를 대상으로 분석하는 테스트
- 코딩 표준, 코딩 스타일, 코드 복잡도, 남은 결함 등을 발견하기 위함
- 종류 : 워크 스루, 인스펙션, 코드 검사 등
동적 테스트
- 프로그램을 실행하여 오류를 찾는 테스트
- 소프트웨어 개발의 모든 단계에서 테스트 수행
- 종류 : 블랙박스 테스트, 화이트박스 테스트
※ 테스트 기반에 따른 테스트
- 명세 기반 테스트 : 요구사항 명세를 테스트 케이스로 만들어 확인
- 구조 기반 테스트 : 논리 흐름에 따른 테스트 케이스로 확인
- 경험 기반 테스트 : 유사 소프트웨어나 기술 등에 테스터의 경험을 기반
※ 시각에 따른 테스트
검증[Verification] 테스트
- 개발자의 시각에서 제품의 생산 과정 테스트
확인[Validation] 테스트
- 사용자의 시각에서 제품의 결과를 테스트
※ 목적에 따른 테스트
- 회복[Recovery] 테스트
- 안전[Security] 테스트
- 강도[Stress] 테스트
- 성능[Performance] 테스트
- 구조[Structure] 테스트
- 회귀[Regression] 테스트 : 수정된 코드에 새로운 결함 여부
- 병행[Parallel] 테스트
※ 화이트박스 테스트
- 원시 코드의 논리적인 모든 경로를 테스트하여 테스트 케이스를 설계하는 방법
- 원시 코드의 모든 문장을 한 번 이상 실행함으로써 수행
※ 화이트박스 테스트 종류
- 기초 경로 검사 : 절차적 설계의 논리적 복잡성을 측정할 수 있게 해주는 테스트 기법
- 제어 구조 검사
- 조건 검사 : 논리적 조건
- 루프 검사 : 반복 구조
- 데이터 흐름 검사 : 변수의 정의와 변수 사용 위치에 초점
※ 화이트박스 테스트의 검증 기준
- 문장 검증 기준[Statement Coverage]
- 모든 구문이 한 번 이상 수행되도록 TC 설계
- 분기 검증 기준[Branch Coverage] (= 결정 검증 기준)
- 모든 조건문에 대해 조건식의 결과가 True인 경우와 False인 경우가 한 번 이상 수행되도록
- 조건 검증 기준[Condition Coverage]
- 조건문에 포함된 개별 조건식의 결과가 True인 경우와 False인 경우가 한 번 이상 수행되도록
- 분기/조건 기준[Branch/Condition Coverage]
- 조건문이 True인 경우와 False인 경우에 따라 조건 검증 기준의 입력 데이터를 구분
※ 블랙박스 테스트
- 각 기능이 완전히 작동되는 것을 입증하는 테스트
※ 블랙박스 테스트 종류
- 동치 분할 검사 [Equivalence Partitioning Testing]
- 경계값 분석 : 입력 조건의 경계값을 테스트 케이스로 선정
- 원인-효과 그래프 검사 [Cause-Effect Graphing Testing]
- 오류 예측 검사 [Error Guessing]
- 비교 검사 [Comparsion Testing]
※ 개발 단계에 따른 애플리케이션 테스트
- 요구사항
- 분석
- 서계
- 구현
- 단위 테스트
- 통합 테스트
- 시스템 테스트
- 인수 테스트 [알파 테스트 : 개발자, 베타 테스트 : 사용자]
※ 하향식 통합 테스트 [Top-Down Integration Test]
상위 모듈에서 하위 모듈 방향으로 통합하면서 테스트하는 기법
- 스텁(Stub) : 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구로, 일시적으로 필요한 조건만을 가지고 있는 시험용 모듈
※ 상향식 통합 테스트 [Bottom Up Integration Test]
하위 모듈에서 상위 모듈 방향으로 통합하면서 테스트하는 기법
- 클러스터(Cluster) : 하위 모듈들을 결합
- 테스트 드라이버(Test Driver) : 테스트 대상의 하위 모듈을 호출하고, 파라미터를 전달하고, 모듈 테스트 수행 후의 결과를 도출하는 도구
※ 테스트 오라클 [Test Oracle]
테스크 결과가 올바른지 판단하기 위해 사전에 정의된 참값을 대입하여 비교하는 기법 및 활동으로 제한된 검증, 수학적 기법, 자동화 기능 특징을 갖고 있음
- 참(True) 오라클
- 샘플링(Sampling) 오라클
- 추정(Heuristic) 오라클
- 일관성 검사(Consistent) 오라클
※ 애플리케이션 성능 측정 지표
- 처리량(Throughput) : 일정 시간 내 처리하는 일의 양
- 응답 시간(Response Time) : 애플리케이션에 요청을 전달한 시간부터 응답이 도착할 때까지 걸린 시간
- 경과 시간(Turn Around Time) : 처리가 완료될 때까지 걸린 시간
- 자원 사용률(Resource Usage) : 자원 사용률
※ 소스 코드 최적화
- 클린 코드(Clean Code) : 누구나 쉽게 이해하고 수정 및 추가할 수 있는 단순, 명료한 코드, 즉 잘 작성된 코드
- 나쁜 코드(Bad Code)
- 스파게티 코드 : 코드의 로직이 서로 복잡하게 얽혀 있는 코드
- 외계인 코드 : 아주 오래되거나 참조문서 또는 개발자가 없어 유지보수 작업이 어려운 코드
※ 클린 코드 작성 원칙
- 가독성
- 단순성
- 의존성 배제
- 중복성 최소화
- 추상화
※ 테스트 하네스
테스트 하네스는 애플리케이션의 컴포넌트 및 모듈을 테스트하는 환경의 일부분으로, 테스트를 지원하기 위해 생성된 코드와 데이터를 의미하고, 테스트 하네스 도구는 테스트가 실행될 환경을 시물레이션 하여 컴포넌트 및 모듈이 정상적으로 테스트되도록 한다.
[테스트 하네스 구성 요소]
- 테스트 드라이버 : 테스트 대상의 하위 모듈을 호출하고, 파라미터를 전달하고, 모듈 테스트 수행 후의 결과를 도출하는 도구
- 테스트 스텁 : 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구로, 일시적으로 필요한 조건만을 가지고 있는 테스트용 모듈
- 테스트 스크립트 : 자동화된 테스트 실행 절차에 대한 명세서
- 목 오브젝트 : 사전에 사용자의 행위를 조건분로 입력해두면, 그 상황에 맞는 예정된 행위를 수행하는 객체
※ 결함 관리 측정 지표
- 결함 분포 : 모듈 또는 컴포넌트의 특정 속성에 해당하는 결함 수 측정
- 결함 추세 : 테스트 진행 시간에 따른 결함 수의 추이 분석
- 결함 에이징 : 특정 결함 상태로 지속되는 시간 측정
'CS > CS' 카테고리의 다른 글
| [5, 6장] 인터페이스 구현 / 화면 설계 (0) | 2023.07.16 |
|---|---|
| [12장] 제품 소프트웨어 패키징 (0) | 2023.07.16 |
| [11장] 응용 SW 기초 기술 활용 (2) (1) | 2023.07.16 |
| [11장] 응용 SW 기초 기술 활용 (1) (0) | 2023.07.16 |
| [9장] 소프트웨어 개발 보안 구축 (0) | 2023.07.16 |