[정보처리기사] 실기 10단원 '애플리케이션 테스트 관리' 정리
소프트웨어 테스트 원리 (결완초집 살정오)
| 결함 존재 증명 | 결함이 없다는 것을 증명할 수는 없음 |
| 완벽 테스팅은 불가능 | 완벽하게 테스팅하려는 시도는 불필요한 시간과 자원낭비 |
| 초기 집중 | 개발 초기 체계적인 분석 및 설계가 수행되지 못하면 그 결과가 프로젝트 후반에 영향을 미치게 되어 비용이 커지게 된다는 요르돈의 법칙 적용 |
| 결함 집중 | - 소프트웨어 테스트에서 오류의 80%는 전체 모듈의 20% 내에서 발견 - 파레토 법칙 적용 |
| 살충제 패러독스 | 동일한 테스트 케이스에 의한 반복적 테스트는 새로운 버그를 찾지 못함 |
| 정황 의존성 | - 소프트웨어의 성격에 맞게 테스트 실시 - 정황과 비즈니스 도메인에 따라 다르게 수행 |
| 오류-부재의 궤변 | 요구사항을 충족시켜주지 못한다면, 결함이 없다고 해도 품질이 높다고 볼 수 없음 |
화이트박스 테스트 (구결조 조변다 기제데)
- 코드 분석과 프로그램 구조에 대한 지식을 바탕으로 문제가 발생할 가능성이 있는 모듈 내부를 테스트하는 방법
| 구문 / 문장 커버리지 (Statement Coverage) |
모든 명령문을 적어도 한 번 수행하는 커버리지 |
| 결정 / 선택 커버리지 (Decision Coverage) 분기 커버리지 (Branch Coverage) |
전체 조건식이 적어도 한 번은 참과 거짓의 결과를 수행 (구문 커버리지를 포함) |
| 조건 커버리지 (Condition Coverage) |
개별 조건식이 적어도 한 번은 참과 거짓의 결과를 수행 |
| 조건 / 결정 커버리지 (Condition / Decision Coverage) |
전체 조건식뿐만 아니라 개별 조건식도 참 한 번, 거짓 한 번 결과가 되도록 수행 |
| 변경 조건 / 결정 커버리지 (Modified Condition / Decision Coverage) |
개별 조건식이 다른 개별 조건식에 영향을 받지 않고 전체 조건식에 독립적으로 영향을 주도록 함으로써 조건 / 결정 커버리지를 향상시킨 커버리지 |
| 다중 조건 커버리지 (Multiple Condition Coverage) |
모든 개별 조건식의 모든 가능한 조합을 100%로 보장 |
| 기본 경로 커버리지 (Base Path Coverage) |
수행 가능한 모든 경로를 테스트 |
| 제어 흐름 테스트 (Control Flow Testing) |
프로그램 제어 구조를 그래프 형태로 나타내어 내부 로직을 테스트 |
| 데이터 흐름 테스트 (Data Flow Testing) |
제어 흐름 그래프에 데이터 사용현황을 추가한 그래프를 통해 테스트 |
블랙박스 테스트 (동경결상 유분페원비)
: 프로그램 외부 사용자의 요구사항 명세를 보면서 수행하는 테스트
(내부 구조나 작동 원리를 알지 못해도 가능)
| 동등분할 / 동치 분할 / 균등 분할 / 동치 클래스 분해 테스트 (Equivalence Partitioning Testing) |
- 입력 데이터의 영역을 유사한 도메인 별로 유횻값/무횻값을 그룹핑하여 대푯값 테스트 케이스를 도출하여 테스트 ex) 수우미양가 |
| 경계값 분석 / 한계값 테스트 (Boundary Value Analysis Testing) |
- 최솟값 바로 위, 최대치 바로 아래 등 입력값의 극한 한계를 테스트 ex) 0<=x<-10 이면 -1, 0, 10, 11 검사 |
| 결정 테이블 테스트 (Decision Table Testing) |
|
| 상테 전이 테스트 (State Transition Testing) |
|
| 유스케이스 테스트 (Use Case Testing) |
|
| 분류 트리 테스트 (Classification Tress Method Testing) |
SW의 일부 또는 전체를 트리 구조로 분석 및 표현하여 테스트 케이스를 설계하여 테스트하는 기법 |
| 페어와이즈 테스트 (Pairwise Testing) |
- 테스트 데이터 값들 간에 최소한 한 번씩을 조합하는 방식 - 적은 양의 테스트 세트를 구성하기 위한 테스트 기법 |
| 원인-결과 그래프 테스트 (Cause-Effect Graph Testing) |
- 그래프를 활용해 입력 데이터 간의 관계 및 출력에 미치는 영향을 분석하여 효용성이 높은 테스트 케이스를 선정 |
| 비교 테스트 (Comparison Testing) |
테스트 목적에 따른 분류 (회안성 구회병)
회복 테스트
: 시스템에 고의로 실패를 유도하고, 시스템의 정상적 복귀 여부를 테스트하는 기법
안전 테스트
성능 테스트
부하 테스트 : 시스템의 사용량을 계속 증가시키면서 시스템의 임계점을 찾는 테스트, 병목현상 제거하는 과정을 반복
강도 테스트 : 시스템 처리 능력 이상의 부하, 즉 임계점 이상의 부하를 가하여 비정상적인 상황에서의 처리를 테스트
스파이크 테스트 : 짧은 시간에 사용자가 몰릴 때 시스템의 반응 측정 테스트
구조 테스트 / 회귀 테스트 / 병행 테스트
테스트 종류에 따른 분류 (명구경)
| 명세 기반 테스트 (블랙박스 테스트) |
프로그램의 요구사항 명세서를 기반으로 테스트 케이스를 선정하여 테스트하는 기법 |
| 구조 기반 테스트 (화이트박스 테스트) |
소프트웨어 내부 논리 흐름에 따라 테스트 케이스를 작성하고 확인하는 테스트 기법 |
| 경험 기반 테스트 (블랙박스 테스트) |
테스터의 경험을 토대로 한, 직관과 기술 능력을 기반으로 수행하는 테스트 기법 |
테스트 오라클 (참샘휴일)
: 테스트의 결과가 참인지 거짓인지를 판단하기 위해서 사전에 정의된 참값을 입력하여 비교하는 기법
| 참 오라클 | 모든 입력값에 대해 기대하는 결과를 생성함으로써 발생된 오류를 모두 검출할 수 있는 오라클 |
| 샘플링 오라클 | 특정한 몇 개의 입력값에 대해서만 기대하는 결과를 제공해 주는 오라클 |
| 휴리스틱 오라클 | 셈플링 오라클을 개선한 오라클로, 특정 입력 값에 대해 올바른 결과를 제공하고, 나머지 값들에 대해서는 휴리스틱(추정)으로 처리하는 오라클 |
| 일관성 검사 오라클 | 애플리케이션 변경이 있을 때, 수행 전과 후의 결괏값이 동일한지 확인하는 오라클 |
테스트 레벨 종류
| 단위 테스트 | 사용자 요구사항에 대한 단위 모듈, 서브루틴 등을 테스트하는 단계 |
| 통합 테스트 | 단위 테스트를 통과한 모듈 사이의 인터페이스, 통합된 컴포넌트 간의 상호 작용을 검증하는 테스트 |
| 시스템 테스트 | 통합된 단위 시스템의 기능이 시스템에서 정상적으로 수행되는지를 검증하는 테스트 기능 / 비기능 요구사항 테스트 기법이 있다. |
| 인수 테스트 | 계약상의 요구사항이 만족하였는지 확인 하기 위한 테스트 |
| 알파 테스트 | 선택된 사용자가 개발자 환경에서 통제된 상태로 개발자와 함께 수행하는 인수 테스트 |
| 베타 테스트 | 실제 환경에서 일정 수익 사용자에게 대상 소프트웨어를 사용하게 하고 피드백을 받는 인수 테스트 |
| 회귀 테스트 | 오류를 제거하거나 수정한 시스템에서 오류 제거와 수정 때문에 새로이 유입된 오류가 없는지 확인하는 반복 테스트 |
| 상태 전이 테스트 | 테스트 대상이 되는 시스템이나 객체의 상태를 구분하고, 이벤트에 의해 어느 한 상태에서 다른 상태로 전이되는 경우의 수를 수행하는 테스트 |
프로그램 실행 여부에 따른 테스트의 분류
| 정적 테스트 | - 테스트 대상을 실행하지 않고 구조를 분석하여 논리성을 검증 - 리뷰, 정적 분석 |
| 동적 테스트 | - 소프트웨어를 실행하는 방식으로 테스트를 수행하여 결함을 검출 - 화이트박스 테스트, 블랙박스 테스트, 경험 기반 테스트 |
- 워크 스루 : 정적 테스트 기법 중 하나로 검토 자료를 회의 전에 배포해서 사전 검토한 후 짧은 시간 동안 회의를 진행하는 형태
소프트웨어 테스트 산출물
| 테스트 슈트 | - Test Case를 실행환경에 따라 구분해 놓은 Test Case의 집합 - 시나리오가 포함되지 않은 단순한 테스트 케이스들의 모음 |
| 테스트 시나리오 | - 애플리케이션의 테스트 되어야 할 기능 및 특징, 테스트가 필요한 상황을 작성한 문서 - 하나의 단일 테스트 시나리오가 하나 또는 여러 개의 테스트 케이스들을 포함 가능 - 테스트 시나리오가 테스트 케이스와 일 대 다의 관계를 가짐 |
| 테스트 스크립트 | - 테스트 케이스의 실행 순서를 작성한 문서 - 테스트 스텁, 테스트 절차서라고도 함 |
| 테스트 케이스 | - 테스트를 위한 설계 산출물 - 응용 소프트웨어가 사용자의 요구사항을 준수하는지 확인하기 위해 설계된 입력값, 실행조건, 기대결과로 구성된 테스트 항목의 명세서 |
테스트 자동화 도구 (정실성통)
| 정적 분석 도구 | - 만들어진 애플리케이션을 실행하지 않고 분석하는 도구 - 소스 코드에 대한 코딩 표준, 코딩 스타일, 코드 복잡도 및 낮은 결함을 발견하기 위해 사용하는 도구 |
| 테스트 실행 도구 | - 테스트를 위해 작성된 스크립트를 실행하고, 작성된 스크립트는 각 스크립트마다 특정 데이터와 테스트 수행방법을 포함 1) 데이터 주도 접근 방식 : 다양한 테스트 데이터를 이용하여 동일한 테스트 케이스를 반복해서 실행 가능, 스크립트에 테스트 데이터만 추가하면 쉽게 테스트 수행 2) 키워드 주도 접근 방식 : 키워드를 이용해 테스트 수행 동작 정의 가능, 테스트 대상 애플리케이션의 특성에 맞추어 키워드에 대해 테일러링 수행 가능 |
| 성능 테스트 도구 | - 성능 목표를 달성하였는지를 확인하는 도구 |
| 테스트 통제 도구 | - 테스트 관리 도구, 형상 관리 도구, 결함 추적/관리 도구 - 조직의 요구사항에 최적화된 형태의 정보를 생성, 관리하기 위해 다른 도구들과 연계 사용 가능 |
상향식 테스트
: 최하위 모듈부터 점진적으로 상위 모듈과 함께 테스트
- 테스트 드라이버 필요
하향식 테스트
: 최상위 모듈부터 하위 모듈들을 통합하면서 테스트
- 테스트 스텁 필요
빅뱅 테스트
: 모든 모듈을 동시에 통합 후 테스트 수행
- 둘다 필요 없음
- 단시간 테스트 가능, 작은 시스템에 유리
샌드위치 테스트
: 상위는 하향식 + 하위는 상향식
- 둘다 필요
- 병렬 테스트 가능, 시간 절약 가능
- 객체 지향 프로그램에서는 컴포넌트 텍스트 수행 시 테스트 되는 매서드가 다른 클래스의 객체에 의존한다.
이런 경우 매서드를 고립화하여 테스트하는 것이 불가능하므로 독립적인 컴포넌트 테스트를 위해서는 스텁의 객체 지향 버전인 목 객체가 필요하다.
목 객체 유형 (더스드 스가)
| 더미 객체 | - 테스트할 때 객체만 필요하고 해당 객체의 기능까지는 필요하지 않은 경우 사용 - 더미 객체의 매서드가 호출되면 정상 동작은 수행하지 않고 예외 수행 |
| 테스트 스텁 | - 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구 - 더미 객체에의 단순 기능에 특정 상태를 가정해서 특정한 값을 리턴하거나 특정 메시지 출력 |
| 테스트 드라이버 | - 테스트 대상 하위 모듈을 호출하고, 파라미터를 전달하고, 모듈 테스트 수행 후의 결과를 도출 |
| 테스트 스파이 | - 주로 테스트 대상 클래스와 협력하는 클래스 |
| 가짜 객체 | - 실제 협력 클래스의 기능을 대체해야 할 경우에 사용 - 실제 협력 클래스의 기능 중 전체나 일부를 훨씬 단순하게 구현 |
애플리케이션 성능 측정 지표 (처응경자)
| 처리량 | - 애플리케이션이 주어진 시간에 처리할 수 있는 트랜잭션의 수 - 웹 앱 = 시간당 페이지 수로 표현 |
| 응답 시간 | - 사용자 입력이 끝난 후, 애플리케이션의 응답 출력이 개시될 때까지의 시간 |
| 경과 시간 | - 사용자가 요구를 입력한 시점부터 트랜잭션을 처리 후 그 결과의 출력이 완료할 때까지 걸리는 시간 |
| 자원 사용률 | - 애플리케이션이 트랜잭션을 처리하는 동안 사용하는 CPU 사용량, 매모리 사용량, 네트워크 사용량 |
리팩토링(Refactoring)
: 유지보수 생산성 향상을 목적으로 기능을 변경하지 않고, 복잡한 소스 코드를 수정, 보완하여 가용성 및 가독성을 높이는 기법
리팩토링 목적
| 유지보수성 향상 | 복잡한 코드의 단순화, 소스의 가독성 향상 |
| 유연한 시스템 | 소프트웨어 요구사항 변경에 유연한 대응 |
| 생산성 향상 | 정제 및 최적화된 소스의 재사용 |
| 품질향상 | 소프트웨어 오류발견이 용이하여 품질 향상 |
애플리케이션 성능 분석 도구
1) 성능 테스트 도구
: 애플리케이션 부하나 스트레스를 적용해 애플리케이션의 성능 측정 좌표를 점검하는 도구
ex) JMeter, LoadUI, OpenSTA
2) 시스템 모니터링 도구
: 애플리케이션이 실행되었을 때 시스템 자원 사용량을 확인하고, 분석이 가능한 도구
ex) Scouter, Zabbix
인스펙션
: 소프트웨어 요구, 설계, 원시 코드 등의 저작자 외의 다른 전문가 또는 팀이 검사하여 문제를 식별하고 문제에 대한 올바른 해결을 찾아내는 형식적인 검토 기법
테스트 케이스 작성 절차
: 테스트 계획 검토 및 자료 확보 -> 위험 평가 및 우선순위 결정 -> 테스트 요구사항 정의 -> 테스트 구조 설계 및 테스트 방법 결정 -> 테스
트 케이스 정의 -> 테스트 케이스 타당성 확인 및 유지보수
클린 코드 작성 원칙 (가단의 중추)
가독성 / 단순성 / 의존성 최소 / 중복성 제거 / 추상화
