수제비 2022 정보처리기사 실기 교재 개념 정리한 내용입니다.
소프트웨어 테스트 원리
- 결함 존재 증명
- 완벽 테스팅은 불가능
- 초기 집중 : 개발 초기 체계적인 분석, 설계가 수행되지 않으면 후반에 비용이 커짐(요르돈의 법칙)
- 결함 집중 : 적은 수의 모듈에서 대다수의 결함이 발견, 오류 80%는 전체 모듈 20% 내에서 발견(파레토 법칙)
- 살충제 패러독스 : 동일한 테스트 케이스에 의한 반복적 테스트는 새로운 버그를 찾지 못함
- 정황 의존성 : 정황과 비즈니스 도메인에 따라 테스트를 다르게 수행
- 오류-부재의 궤변 : 결함이 없다고 하더라도 사용자의 요구사항을 충족시키는 개발이 아니라면 품질이 높다고 볼 수 없음
소프트웨어 테스트 산출물
- 테스트 계획서
- 테스트 베이시스(basis) : 테스트 설계를 위한 기준이 되는 문서(요구사항 명세서 등)
- 테스트 케이스 : 테스트를 위한 설계 산출물
- 테스트 슈트(suites) : 테스트 케이스를 실행환경에 따라 구분해 놓은 테스트 케이스의 집합
- 테스트 시나리오 : 테스트 되어야할 기능, 테스트가 필요한 상황들을 작성한 문서, 하나 또는 여러 개의 테스트 케이스들 포함
- 테스트 스크립트=테스트 스텝=테스트 절차서(procedure) : 테스트 케이스의 실행 순서를 작성한 문서
- 테스트 결과서
소프트웨어 테스트 유형
1. 프로그램 실행 여부에 따른 분류
1-1. 정적 테스트
: 테스트 대상을 실행하지 않고 구조를 분석
1-1-1. 리뷰
- 동료 검토 : 2-3명이 진행하는 리뷰의 형태, 작성자가 설명
- 인스펙션 : 저작자 외의 다른 전문가가 검토, 개발초기에만
- 워크 스루 : 검토 자료를 회의전에 배포, 사전 검토한 후 짧은 시간동안 회의를 진행
1-1-2. 정적 분석(static analysis)
: 자동화된 도구를 이용하여 산출물의 결함 검출, 복잡도 측정
1-2. 동적테스트
: 소프트웨어를 실행
1-2-1. 블랙박스 테스트(명세 기반 테스트)
: 외부 사용자의 요구사항 명세를 보면서 수행(기능 테스트), 내부 구조나 작동 원리 몰라도 가능
- 동등분할 테스트=동치 분할 테스트=균등 분할 테스트=동치 클래스 분해 테스트(equivalence partitioning testing)
: 입력 데이터의 영역을 유사 도메인별로 유효값/무효값을 그룹핑하여 대푯값 테스트 케이스를 도출하여 테스트
- 경곗값 분석 테스트=한곗값 테스트(boundary value analysis testing)
: 등가 분할 후 경곗값 부근에서 오류 발생 확률이 높기 때문에 경곗값을 포함하여 테스트 케이스 설계
- 결정 테이블 테스트(decision table testing)
: 요구사항의 논리와 발생조건을 테이블 형태로 나열, 조건과 행위를 모두 조합하여 테스트
- 상태 전이 테스트(state transition testing)
: 데스트 대상/시스템/객체의 상태를 구분, 이벤트에 의해 다른 상태로 전이되는 경우의 수를 수행
- 유스케이스 테스트(use case testing)
: 시스템이 실제 사용되는 유스케이스로 모델링되어 있을 때, 프로세스 흐름 기반으로 테스트 케이스 명세화하여 수행
- 분류 트리 테스트(classification tree method testing)
: sw 일부 또는 전체를 트리 구조로 분석, 표현하여 테스트 케이스 설계
- 페어와이즈 테스트(pairwise tesing)
: 테스트 데이터값들 간에 최소한 한 번씩 조합하는 방식
- 원인-결과 그래프 테스트(cause-effect testing)
: 그래프를 활용, 입력 데이터 간의 관계/출력에 미치는 영향을 분석하여 효용성이 높은 테스트 케이스를 선정하여 테스트
- 비교 테스트(comparison testing)
: 여러 버전의 프로그램에 같은 입력값을 넣어서 동일한 결과 데이터가 나오는 지 비교해보는 테스트[테스트목적 분류의 병행테스트와 비슷]
1-2-2. 화이트박스 테스트(=구조 기반 테스트=코드 기반 테스트=로직 기반 테스트=글래스 박스테스트)
: 코드 분석과 프로그램 구조에 대한 지식을 바탕으로 각 응용 프로그램의 내부 구조와 동작을 검사하는 소프트웨어 테스트
- 구문 커버리지(문장 커버리지) (statement coverage)
: 모든 명령문을 적어도 한 번 수행, 조건문 결과와 관계없이 구문 실행 개수로 계산
- 결정 커버리지=선택 커버리지 (decision)=분기 커버리지 (branch)
: 결정 포인트 내의 전체 조건식이 적어도 한 번은 참과 거짓의 결과를 수행, 구문 커버리지 포함
- 조건 커버리지(condition)
: 결정 포인트 내의 각 개별 조건식이 적어도 한 번은 참과 거짓의 결과가 되도록 수행, 구문 커버리지 포함
- 조건/결정 커버리지(condition/decision)
: 전체 조건식뿐만 아니라 개별 조건식도 참 한 번, 거짓 한 번 결과가 되도록 수행
- 변경 조건/결정 커버리지(modified condition/decision)
: 개별 조건식이 다른 개별 조건식에 영향을 받지 않고 전체 조건식에 독립적으로 영향을 주도록, 조건/결정 커버리지 향상
- 다중 조건 커버리지(multiple condition)
: 결정 조건 내 모든 개별 조건식의 모든 가능한 조합을 100% 보장
- 기본 경로 커버리지=경로 커버리지(base path)
: 수행 가능한 모든 경로를 테스트, 맥케이브의 순환복잡도 기반
- 제어 흐름 테스트(control flow testing)
: 프로그램 제어 구조를 그래프 형태로 나타내어 내부 로직 테스트
- 데이터 흐름 테스트(data flow testing)
: 제어 흐름 그래프에 데이터 사용현황을 추가한 그래프로 테스트
1-2-3. 경험기반 테스트
- 탐색적 테스트(exploratory test) : 중대한 테스트 위주
- 오류 추정(error guessing)
2. 테스트 기법에 따른 분류
- 화이트박스 테스트
- 블랙박스 테스트
3. 테스트 시각에 따른 분류
- 검증(verification)
: sw 개발 과정을 테스트, 개발 규격과 요구를 충족시키는 지 판단, (개발자/시험자 시각)명세화된 기능을 올바로 수행하는 지 알아보는 과정
- 확인(validation)
: sw 결과를 테스트, 최종 사용자 요구/소프트웨어 요구에 적합한지 판단, (사용자 시각)올바른 소프트웨어가 개발되었는지 입증하는 과정
4. 테스트 목적에 따른 분류
4-1. 회복 테스트(recovery testing)
: 고의로 실패 유도, 시스템의 정상적 복귀 여부를 테스트
4-2. 안전 테스트(security testing)
: 소스 코드 내의 보안적인 결함을 미리 점검
4-3. 성능 테스트 (performance testing)
4-3-1.부하 테스트(load testing)
: 부하를 게속 증가시키면서 임계점 찾음, 병목 지점을 찾아 병목 현상을 제거하는 과정을 반복
4-3-2. 강도 테스트(stress testing)
: 임계점 이상의 부하를 가하여 비정상적인 상황에서의 처리를 테스트
4-3-3. 스파이크 테스트(spike testing)
: 짧은 시간에 사용자가 몰릴 때 시스템의 반응 측정 테스트
4-3-4. 내구성 테스트(endurance testing)
: 오랜 시간 동안 시스템에 높은 부하를 가하여 시스템 반응 테스트
4-4. 구조 테스트(structure testing)
: 시스템의 내부 논리 경로, 소스 코드의 복잡도를 평가
4-5. 회귀 테스트(regresstion testing)
: 오류를 제거하거나 수정한 시스템에서 오류 제거와 수정에 의해 새로이 유입된 오류가 없는지 확인하는 일종의 반복 테스트 기법
4-6. 병행 테스트(parallel testing)
: 변경된 시스템과 기존 시스템에 동일한 데이터를 입력 후 결과를 비교[블랙박스의 비교테스트와 비슷]
5. 테스트 종류에 따른 분류
- 명세기반 테스트(블랙박스 테스트)
- 구조기반 테스트(화이트박스 테스트)
- 경험기반 테스트(블랙박스 테스트)
테스트 레벨
: 함께 편성되고 관리되는 테스트 활동의 그룹
테스트 레벨의 종류
1. 단위 테스트
: 사용자 요구사항에 대한 기능성 위주의 테스트, 개별적인 모듈(컴포넌트) 테스트, 테스트 베드라는 환경 필요, 빠르게 수행되어야하고 다른 컴포넌트에 의존x, 여러 번 수행 시에도 동일한 결과값 가져야함
- 명세 기반(블랙박스) 테스트
- 구조 기반(화이트박스) 테스트-주로
+) 목(mock) 객체 생성 프레임워크
: 독립적인 컴포넌트 테스트를 위해 스텁의 객체 지향 버전인 목 객체 필요
- 더미 객체(dummy) : 객체의 기능까지는 말고 객체만 필요한 경우 사용
- 테스트 스텁(stub) : 더미 객체에의 단순 기능에 특정 상태를 가정, 상위 모듈에 의해 호출되는 하위 모듈의 역할
- 테스트 드라이버(driver) : 데스트 대상 하위 모듈을 호출하는 상위 모듈의 역할, 파라미터 전달
- 테스트 스파이(spy) : 테스트 대상 클래스와 협력하는 클래스로 가는 출력을 검증하는데 사용
- 가짜 객체(fake) : 실제 협력 클래스의 기능을 대체해야할 경우에 사용
2. 통합 테스트
: 단위 테스트를 통과한 모듈 사이의 인터페이스 관련 오류 및 결함을 찾아내기 위한 체계적인 테스트
3. 시스템 테스트
: 통합된 단위 시스템의 기능이 시스템에서 정상적으로 수행되는 지 검증
기능적 요구사항 테스트 : 명세서 기반의 블랙박스 테스트
비기능적 요구사항 테스트 : 구조적 요소에 대한 화이트박스 테스트
3. 인수 테스트
: 최종 사용자가 계약상의 요구사항이 만족되었는지 확인하기 위한 단계
- 사용자 인수 테스트 : 비즈니스 사용자가
- 운영상의 인수 테스트 : 시스템 관리자가 시스템 인수 시 수행
- 계약 인수 테스트
- 규정 인수 테스트
- 알파 테스트 : 선택된 사용자(회사 내 다른 사용자, 실제 사용자)가 개발자 환경에서 통제된 상태로 개발자와 함께 수행
- 베타 테스트 : 실제 환경에서 일정 수의 사용자에게 대상 소프트웨어를 사용하게 하고 피드백을 받음
'STUDY' 카테고리의 다른 글
(MAC) Pytorch 설치하기 (0) | 2022.11.14 |
---|---|
[정처기] 1과목 요구사항 확인 디자인 패턴 총정리, 쉽게 암기하는 법 (0) | 2022.10.19 |
[정처기] 7과목 SQL 응용 트랜잭션 총정리 (0) | 2022.10.19 |
[정처기] 9과목 소프트웨어 개발 보안 구축 시큐어 코딩 가이드 총정리 (0) | 2022.10.19 |
[정처기] 9과목 소프트웨어 개발 보안 구축 암호화 알고리즘 총정리 (1) | 2022.10.19 |