Introduction
시험(Test)는 제품 품질 평가, 향상 및 결함/문제 식별을 위해 수행하는 활동. 시험의 구성은 유한(Finite)개의 테스트케이스을 기반으로 프로그램 행동에 대한 동적(Dynamic) 검증(verification)을 통해 이루어지며, 테스트케이스는 기대되는(Expected) 행동에 대한 무한 실행 영역(infinite executions domain)에서 알맞게 선(select)됨. 여기서 굵은 글씨는 시험의 핵심 특성을 나타냄.
•
동적(Dynamic) : 시험은 언제나 입력 값에 대한 실행임을 암시. 이에 대비되는 것은 S/W 품질 KA에 기술된 정적(static) 기술
•
유한(Finite) : 단순한 프로그램에서 조차도 이론적으로는 매우 많은 테스트케이스를 만들 수 있어, 극단적으로 하자면 시험에 수개월 또는 수년을 소비할 수도. 따라서 시험은 언제나 제한된 자원과 일정, 무제한 시험 요구사항 간의 trade-off가 있어야.
•
선택(Selected) : 시험집합(test set)을 어떻게 선택하느냐에 따라서 테스트 기술이 나뉘기에, 선택 기준(criteria)을 식별하는 것이 핵심. 가장 적절한 선택 기준 설정이란 복잡한 문제로서, 실전에서는 이를 위해 위험 분석 기술과 시험 공학 기술(test engineering expertise)를 적용함.
•
기대(Expected) : 프로그램 실행 결과에 대한 수용 가능 여부를 판단할 수 있어야. 사용자의 기대(검증을 위한 시험; testing for validation) 또는 명세(검증을 위한 시험; testing for verification), 암시적 요구사항에 기반한 예상된 행동에 비추어 검사되어야 함. S/W 요구사항 KA의 6.4. 인수 테스트와 연계
시험의 목적은 더 이상 단순히 코딩 후 결함 검출(detecting failure)에 머무르지 않고, 개발/유지보수 전 영역에 걸친 제품 구현의 일부로 인지됨. 실제로 시험 계획 및 설계 활동은 S/W 설계자의 잠재적 약점(설계에서의 간과, 모순, 누락 등)을 보완하는데 유용.
품질에 대한 고려는 위험/문제 예방의 한 방법임(문제의 수정보다는 회피가 더 났다는 점에 기반하여)에 비추어 볼 때, 시험은 해당 예방의 유효성 ㅈ을 위한 수단임. 전 영역에 걸친 시험의 성공에도 불구하고 S/W는 결함(fault)를 가질 수 있는데, 배포 이후 발생된 S/W 결함에 대한 해결은 유지보수 활동을 통해 해결함.
S/W 품질 관리 기술은 정적 기법(비 코드 실행)과 동적 기법(코드 실행)으로 나뉘며, 시험은 동적 기법에 중점을 둠(S/W 품질 KA의 3.3. S/W 품질 관리 기법 참조).
S/W 시험은 S/W 작성 KA(3.4. 작성 시험 참조)과도 연계되어, 단위 및 통합 시험은 특히나 그러함.
Breakdown of topic
1. S/W 시험 기본(Software Testing Fundamentals)
1.1. 시험 관련 용어(Testing related Terminology) - IEEE610.12-90
S/W 오류(error) : 인간이 만들어 낸 문법적/논리적 실수로 인한 부분 또는 전체적으로 부정확(incorrect)한 코드 영역.
S/W 결함(Fault, Defect)이란 S/W 실패의 원인이며, S/W 실패(Failure)는 관찰된 원치 않은 결과임. 시험은 실패를 드러내는 반면, 결함은 제거 대상.
1.2. 핵심 이슈(Key Issues)
1.
시험 선택 기준 / 시험 적합 기준(또는 중지 규칙) (Test selection criteria / Test adequacy criteria) : 시험 선택 기준은 적합한 테스트케이스를 결정하기 위한 수단임과 동시에, 선택된 테스트 수트가 적합한지 여부를 검사하는 데 사용(즉, 시험이 중지될 수 있는지 여부에 대한 결정)
2.
시험 유효성 / 시험 목적(Testing effectiveness / Objectives for testing) : 시험은 프로그램 실행 예에 대한 관찰임. 선택된 동일 시험은 각기 다른 목적으로 사용 가능
3.
결함 식별을 위한 시험(Testing for defect identification) : 결함 식별을 위한 시험의 성공 요소는 해당 시험이 시스템을 실패시킬 수 있는지 여부. 이는 S/W가 명세와 타 설계 속성을 S/W가 준수하는지 여부를 보여주기 위한 시험과는 달라, 여기서는 실패가 나타나지 않아야 성공임.
4.
오라클(oracle) 문제 : 오라클이란 프로그램이 주어진 시험에서 올바르게 동작하는지 여부를 결정하는 (인간 또는 기계적) agent로서, 통과(pass), 실패(fail)이란 용어를 사용. 다양한 종류가 있음.
5.
시험의 이론적/실제적 한계(Theoretical and practical limitations of testing) : 통과된 시험에 대한 신뢰성 수준 문제. 시험은 문제를 드러낼 뿐이지 S/W의 완전성을 증명할 수는 없음. 이는 실제 S/W에 대한 완전한 시험이란 불가능하기 때문으로, 시험은 위험에 기반하여 수행되어야 하며, 따라서 위험 관리 전략의 한 방법으로도 볼 수 있음.
6.
실행 불가능 경로 문제(The problem of infeasible paths) : 어떤 입력 데이터로도 실행 불가능한 제어 흐름 경로는 경로 기반 시험, 특히 코드 기반 시험 기법에 기반한 자동적 시험에서의 주요 문제임.
7.
시험 가능성(Testability) : S/W 시험 가능성의 뜻은 두 가지. 하나는 주어진 시험 범위 기준에 대한 시험 수행의 용이성이며, 다른 하나는 시험을 통해 S/W 실패를 일으킬 가능성임.
1.3. 시험과 타 활동 간 관계(Relationships of Testing to Other Activities)
S/W 시험은 정적 S/W 품질 관리 기법, 정확성(correctness)의 증명, 디버깅, 프로그래밍에 관련이 있지만 다름. S/W 품질 분석가의 관점으로 바라보는 편이 좋음.
2. 시험 수준(Test Levels)
2.1. 시험 대상(The Target of the Test)
S/W 시험은 개발 및 유지보수 공정 전체의 각기 다른 수준에서 수행되기에 대상 역시 다양해짐(모듈, 모듈 그룹, 전체 시스템 등). 이는 세 개의 대단위 시험 단계, 즉 단위, 통합, 시스템 시험으로 개념적 구분을 이룰 수 있음.
1.
단위 시험(unit testing; IEEE1008-87) : 분리하여 시험 가능한 S/W 조각의 기능을 검증하는 활동. 이는 각각의 부 프로그램 또는 강결합된 단위로 묶인 더 큰 컴포넌트 역시 이에 포함된다는 의미임. 본 시험은 종종 대상 코드에 대해 프로그래머가 디버깅 도구를 사용하여 이룸.
2.
통합 시험(Integration testing) : S/W 컴포넌트간 상호작용을 검증하는 과정. 고전적 통합 시험 전략인 상/하향식 전략은 전통적 계층 구조의 S/W에 적용하는 반면, 현대적 시스템 통합 전략은 아키텍처 주도(Architecture-driven) 방식으로서, 식별된 기능적 분류(functional threads)에 따라 S/W 컴포넌트 또는 부시스템을 통합하는 방식임.
통합 시험은 연속적 활동으로서, 각 단계에서 S/W 기술자는 하위(lower-level)가 아닌 현재 통합하는 수준에 눈높이를 맞춤. 작은 S/W가 아니라면, '빅뱅' 전략보다는 체계적/점증적 통합 시험이 많이 쓰임
3.
시스템 시험(System testing) : 시스템 시험은 전체 시스템의 행동에 관계하여, 주요 기능적 실패는 단위 및 통합 시험에서 이미 식별되어야 함. 본 시험은 주로 보안, 속도, 정확성, 신뢰성 등의 비기능적 요구사항 준수 여부와 외부 모듈(운용 환경, 타 응용프로그램 등)과의 연동을 위한 외부 인터페이스에 대한 검사에 초점을 둠.
2.2. 시험 목적(Objectives of Testing)
시험은 다양한 목적을 갖고 수행되며, 목적이 정확성을 요구할 경우 정량적 수단을 통해 이룸.시험은 여러 속성을 검증(verify)하는 데 목적을 둠. 기능 요구사항의 구현 정확성 검사(conformance/correctness/functional test)를 위해 테스트케이스가 설계되기도 하지만, 비기능 요구사항(성능, 신뢰성, 사용성 등)의 속성 역시 검사 대상임. 시험 목적은 시험 대상에 따라 달라짐.
1.
인수(Acceptance)/자격(qualification) 시험 : 인수 시험은 고객의 요구사항에 시스템이 부합하는지를 검사. 고객이 본 시험에 해당하는 특정 작업을 지정/수행할 수도. 시험 활동에는 개발자가 결부될 수도 있음.
2.
설치(installation) 시험 : 보통 인수 시험이 완료된 후 수행되어 대상 환경으로의 설치에 대한 검증(verify)임. H/W 형상 요구사항에 따라 시스템 시험이 한번 더 수행되는 것으로 볼 수도 있어. 설치 절차 역시 검증 대상.
3.
알파(alpha) / 베타(beta) 시험 : S/W를 풀기(release) 전에 소규모의 잠재적 사용자 대표 집단에 트라이얼(trial)로 사용케 하는 것으로, 해당 사용자가 내부(in-house) 멤버일 경우 알파, 외부일 경우에는 베타 시험임. 이들 사용자는 사용 후 문제를 보고함. 본 시험은 종종 통제 밖으로 벋어나 시험 계획에 반드시 포함되지는 않음
4.
부합(conformance) / 기능(Functional) / 정확성(Correctness) 시험 : S/W가 자신의 명세에 맞게 동작하는지 여부를 검증하는데 목적을 둠.
5.
신뢰도 성취 및 평가(Reliability achievement and evaluation) : 결함을 식별하는 수단으로서 시험은 신뢰도 향상을 위한 한 수단임. 반면, 운영 프로파일(operational profile), 신뢰도에 대한 통계적 측정기준을 따라 무작위로 생성한 테스트케이스를 도출할 수도. 신뢰도 증대 모델을 통해 위 두 목적을 동시에 성취 가능함(4.1.4. 생명 시험(Life test), 신뢰도 평가 절 참조)
6.
회귀(regression) 시험 : 수정이 의도하지 않은 영향을 미치는지 여부를 검증하기 위한 시스템 또는 컴포넌트에 대한 선택적 재시험임(IEEE10.12-90), 실제에서의 본 시험은 이전에 통과한 시험이 여전히 유효한지 여부에 대한 판단.
회귀 시험의 수준과 이에 필요한 자원 간에는 언제나 trade-off가 요구됨.
'2.1. 시험 대상'의 모든 시험 수준에서 수행될 수 있으며, 기능/비기능 요구사항 모두에 적용됨.
7.
성능(performance) 시험 : 용량 및 반응 시간 등의 지정된 성능 요구사항에 부합하는지 여부에 대한 검증. 내부 프로그램 및 시스템 한계에 대한 시험인 부피 시험(volume testing; 일정량의 데이터를 갖고 성능을 시험)은 성능 시험의 일종.
8.
스트레스(stress) 시험 : S/W를 설계 부하(design load)의 최고치 또는 그 이상에서 수행
9.
Back-to-back 시험 : 단일 시험집합을 단일 S/W 제품의 두 버전에 수행하여 그 결과를 비교
10.
복구(recovery) 시험 : 본 시험의 목적은 재해(disaster) 이후의 S/W 재시작 능력에 대한 검증임
11.
형상(configuration) 시험 : S/W가 다양한 사용자를 위해 만들어졌을 경우, 다양한 특정 형상에서의 S/W 수행 능력을 분석함
12.
사용성(usability) 시험 : S/W 및 해당 문서에 대해, 최종 사용자의 사용/학습이 얼마나 용이한지 여부를 평가. 또한 S/W의 기능이 사용자 작업에 대한 지원에 얼마나 유효한지 여부와 사용자의 오류에 대한 복구 능력 역시 평가 대상
13.
시험 주도 개발(TDD; Test-driven development) : TDD 그 자체로는 시험 기법은 아니지만, 시험을 요구사항 명세 문서의 대용으로 하여 S/W가 요구사항을 정확히 구현하는지 여부를 검증하는 수단으로 사용.
3. 시험 기법(Test Techniques)
시험의 목적 중 하나는 잠재적 실패(failure)를 최대한 많이 발견함에 있어, 많은 기법이 이를 위해 개발됨. 이러한 기법의 기반 원칙은 프로그램 행동의 대표적 집합 식별을 최대한 조직적(systematic)으로 이루는 것이나, 모든 기법을 분류할 공통된 기반은 찾기 어려움.
S/W 설계 및 코드가 어떻게 이루어졌는지에 대한 정보에 의존하는 시험을 가리켜 White-box(또는 glassbox) 시험이라 부르는 반면, 입/출력 행동에 기반할 경우에는 Black-box 시험이라 칭함.
3.1. 시험자의 직관 및 경험 기반(Based on Tester's Intuition and Experience)
1.
임의(Ad hoc) 시험 : S/W 기술자의 기술, 직관 및 경험에 따라 임의로 시험을 수행. 가장 넓게 사용되는 기법
정형적 기법으로는 포착하기 어려운 특정 시험에 유용
2.
탐험적(Exploratory) 시험 : 동시적 습득, 시험 설계, 시험 수행으로 정의되는 본 시험은, 시험이 시험 계획에 따라 먼저 정의되기 보다는 동적으로 설계, 수행, 수정됨을 뜻함.
본 시험의 효과는 S/W 기술자의 지식에 좌우되며, 본 지식은 다양한 소스 즉, 시험 중에 관찰된 제품 행동, 응용프로그램에 대한 친숙도, 실패 과정, 가능한 결함 및 실패 유형, 특정 제품에 연계된 위험 등에서 추출됨.
3.2. 명세 기반(Specification-based)
1.
동등 분할(Equivalence partitioning) : 입력 영역(domain)이 특정 관계에 따라 동등한 부집단으로 나뉘어 각 부집단에 대해 시험을 이룸
2.
경계값 분석(Boundary-value analysis) : 변수의 입력 영역에 대한 경계 부근에 테스트케이스 지정. 본 시험은 많은 결함이 입력의 극한 값 주위에 집중되는 경향이 있다는 기반 원리를 따름. 본 기법의 확장으로 강건성(robustness) 시험이 있는데, 이는 변수의 입력 영역 바깥에서 테스트케이스를 선택하여 예상하지 못하거나 잘못된 입력에 대해 프로그램의 강건성을 검사함.
3.
결정표(Decision table) : 결정표란 조건(입력)과 이에 따른 활동(출력) 간 논리적 연관성을 나타냄. 테스트케이스는 조건과 활동에 대한 모든 가능한 조합을 고려하여 추출. 이에 관계된 기법으로 원인-결과 그래프(cause-effect graph)가 있음.
4.
유한상태 기계 기반(Finite-state machine-based) : 프로그램을 유한 상태 기계로 모델링하여, 이에 대한 상태와 변이를 다루기 위해 테스트가 선택됨.
5.
정형 명세 기반 시험(Testing from formal specifications) : 정형 언어 기반의 명세에서는 기능 테스트케이스를 자동 도출 가능케 하고, 시험 결과를 검사(check)하기 위한 참조 출력/오라클을 제공. 모델 기반 또는 대수적(algebraic) 명세로부터 테스트케이스를 추출하기 위한 방법이 따로 존재함.
6.
임의 시험(Random testing) : 시험이 순수하게 임의적으로 생성되어, '3.5.1. 운영 프로파일'의 그것으로 이루어지는 통계적 시험과는 다름. 그럼에도 불구하고 본 시험은 명세 기반으로 분류되는데, 이는 임의의 값 선택 시 최소한 입력 영역 내에서 이루어지기 때문.
3.3. 코드 기반(Code-based)
1.
제어 흐름 기반 기준(Control-flow-based criteria) : 프로그램 내 모든 문장과 문장 블록 또는 이들간 특정 조합을 다루는(covering) 데 목적을 두어, 조건/결정 커버리지 등의 여러 커버러지(coverage) 기준이 제안됨.
가장 강력한 제어 흐름 기반 기준은 경로(path) 시험으로서, 흐름도(flowgraph)의 모든 입구-출구 제어 흐름 경로를 실행함. 본 시험은 일반적으로 현실적이지 않기에(loop로 인해), 문장/분기/조건/결정 시험과 같은 덜 엄격한 시험이 사용되는 경향이 있음.
이러한 시험은 %로 측정됨(ex. 모든 분기가 한번이라도 시험에 의해 수행되면 100% 분기 커버리지가 성취(achieve)되었다고 표현함)
2.
데이터 흐름 기반 기준(Data flow-based criteria) : 데이터 흐름 기반 시험에서, 조건 흐름도(control flowgraph)에는 어떻게 프로그램 변수가 정의, 비정의, 사용되었는지가 표기됨. 가장 강력한 기준인 전 정의-사용(all definition-use) 경로의 경우, 모든 변수에 대해 정의부터 사용까지의 전 segment가 실행됨. 요구되는 경로의 수를 줄이기 위해 상대적으로 약한 전략인 전-정의(all-definitions) 또는 전-사용(all-use) 경로가 사용됨.
3.
코드 기반 시험 참조 모델(Reference models for code-based testing) - 흐름도(flowgraph), 호출도(call graph) : 코드 기반 기법에서는 프로그램의 제어 구조가 도식화(graphical)되어 표현됨. 흐름도는 직접도(directed graph)로서, 노드와 아크(arc)는 프로그램의 요소에 대응함. 예를 들어, 노드는 문장 또는 한 흐름의 문장(uninterrupted sequences of statement)을, 아크는 노드간 제어의 전이(transfer)를 나타낼 수 있음.
3.4. 결함 기반(Fault-based)
정형화의 각기 다른 수준에서 결함 기반 시험 기법은 가능한 또는 기정의된 결함을 드러낼 목적으로 테스트케이스를 고안함.
1.
오류 추측(Error guessing) : 오류 추측 기법에서의 테스트케이스는 S/W 기술자에 의해 특별히 설계되어, 프로그램 내에 가장 그럴듯한(? Plausible) 오류를 이해하기 위해 사용됨. 이를 위한 가장 쓸만한 정보는 이전 프로젝트에서 발견된 결함 이력과 S/W 기술자의 전문 기술(expertise)임.
2.
변이 시험(Mutation testing) : 변이(mutant)는 시험 내에서의 (구문 변화를 통한) 아주 작은 수정 버전으로, 모든 테스트케이스는 원 버전과 모든 변이 버전 모두에 수행됨; 만약 테스트케이스가 프로그램과 변이와의 차이를 성공적으로 식별하면, 해당 변이는 '죽었음(killed)'이라 함. 변이 시험은 원래 테스트 집합(4.2 참조)을 평가하기 위한 기법이지만 그 자체로도 시험 기준이 되는데, 이는 충분한 수의 변이가 죽을 때까지 테스트를 임의적으로 생성/수행하거나, 살아있는 변이를 죽이기 위해 특별히 설계함으로 이룸. 변이 시험의 기반 가정인 결합 효과(coupling effect)란 단순 구문적 결함을 찾음으로써 실재의 좀더 복잡한 결함을 찾는 것임. 본 기법을 좀더 효과적으로 수행하기 위해서는 시스템적인 방법으로 많은 수의 변이를 자동 생성해야.
3.5. 사용 기반(Usage-based)
1.
운영 프로파일(Operational profile) : 신뢰성 평가를 시험을 위해 시험환경은 S/W의 운영 환경에 최대한 가까워야. 핵심은 관찰한 시험 결과를 통해 실제 사용되는 시기에서의 신뢰성을 추론하는 것임. 이를 위해 입력으로는 확률적으로 분산되거나 실제 운영 시의 발생 가능한 값이 할당되어야.
2.
S/W 신뢰성 공학적 시험(SRET; Software Reliability Engineered Testing) : SRET는 전체 개발 공정을 둘러싸는 시험 기법으로, 여기서 시험은 '신뢰도 목표, 기대되는 상대적 사용 및 현장에서의 각기 다른 기능의 임계(criticality)를 기반으로 설계 및 안내'됨.
3.6. 응용 프로그램의 본성 기반(Based on Nature of Application)
상기 기법은 모든 종류의 S/W에 적용되는 반면, 어떤 응용프로그램은 시험 도출에 추가적 노하우를 요구하기도. 아래 나열된 시험은 응용프로그램의 본성에 기반한 특화된 시험임.
•
개체 지향 시험(Object-oriented testing)
•
컴포넌트 기반 시험(Component-based testing)
•
웹 기반 시험(Web-based testing)
•
GUI 시험(GUI testing)
•
동시적 프로그램 시험(Testing of concurrent programs)
•
프로토콜 적합 시험(Protocol conformance testing)
•
실시간 시스템 시험(Testing of real-time systems)
•
안전-중대 시스템 시험(Testing of safety-critical systems)
3.7. 기법 선택 및 조합(Selecting and Combining Techniques)
1.
기능 및 구조(Functional and structural) : 명세 기반 및 코드 기반 시험 기법은 종종 기능 vs 구조 시험으로 대비되지만, 이들 두 접근법은 상호간에 대안적이라기보다는 상보적인 관계에 있음. 실제로 이들은 각기 다른 소스의 정보를 사용하고 각기 다른 문제에 집중하므로 조합해서 사용될 수 있음.
2.
결정적 vs 임의적(Deterministic vs random) : 테스트케이스는 기 정의된 다양한 기법 또는 분산된 입력에서 추출된 값(신뢰성 시험 등에서 사용)을 따르는 결정적 방법으로 선택될 수 있는 반면, 여러 분석적/경험적 비교의 경우, 더 효과적인 접근법을 이루는 조건의 분석을 위해 수행됨.
4. 시험 관련 측정기준(Test related measures)
종종 시험 기법과 목적을 혼동하는 경우가 있는데, 시험 '기법'은 시험 목적 성취를 위한 조력자임. 예를 들어 분기 커버러지는 '기법'으로, 특정 분기 커버리지 측정기준이 시험 자체의 목적으로 받아들여져서는 안됨. 명시적으로 구분되어야 할 것은 관찰된 시험 결과를 기반으로 프로그램 평가를 가능케 하는 시험 관련 측정기준과, 시험 집합에 대한 완전성을 평가하는 것임. 관련 토픽은 SWE 관리 KA의 부영역인 6-SWE 측정기준과 SWE 공정 KA의 부영역인 4-공정 및 제품 측정기준.
4.1. 시험 하의 프로그램 평가(Evaluation of the Program Under Test)
1.
시험 계획과 설계를 위한 프로그램 측정(Program measurements to aid in planning and designing testing) : 프로그램 크기, 구조에 기반한 측정기준은 시험 안내를 위해 사용됨. 또한 구조적 측정기준은 프로그램 모듈 간 측정기준(모듈간 호출 회수를 통한)을 포함함.
2.
결함 유형, 분류, 통계(Fault types, classification, and statistics) : 어떤 유형의 결함이 시험 중 발견되는지 및 이전에 발생했던 결함에 비한 상대적 회수를 아는 것이 중요하여, 이를 통해 품질 예측 및 공정 향상(process improvement)를 이룰 수 있음. S/W 품질 KA의 3.2 결함 특성화 참조.
3.
결함 밀도(density) : 유형 기반의 결함 분류 및 회수 측정을 통해 시험 중의 프로그램을 평가할 수 있어. 각각의 결함 군에 대해, 발견된 결함 개수 및 프로그램의 크기 간 결함 밀도는 비율(ratio)로 측정됨.
4.
생명 시험(Life test), 신뢰도 평가 : 신뢰도 성취 및 평가(2.2.5)를 통한 S/W 신뢰도의 통계적 측정기준은 제품 및 시험의 중지 여부에 대한 평가에 사용 가능.
5.
신뢰도 성장 모형(Reliability growth models) : 신뢰도 성장 모형은 신뢰도 성취 및 평가(2.2.5)하에 관찰한 실패에 기반하여 신뢰도 예측을 가능케 함. 일반적으로 본 모형은 결함이 고쳐졌음(fix)을 가정하는데, 따라서 보통 제품의 신뢰도는 증가하는 경향을 보임. 본 모형 종류는 실패 회수(failure-count) 모형과 실패 간 시간(time-between-failure) 모형이 있음.
4.2. 수행된 시험의 평가(Evaluation of the Tests Performed)
1.
커버리지/완전도(thoroughness) 측정 : 여러 시험 적합성 기준은 테스트케이스가 프로그램 또는 명세에서 식별된 요소 집합을 시스템적으로 수행해야 함을 요구함. 실행된 시험의 완전성을 평가하기 위해 시험자는 전체 요소에 대한 다뤄진 요소 비율을 동적으로 측정함으로 다뤄진(coverage) 요소를 감시(monitor)할 수 있음. 프로그램 흐름도 내의 다뤄진 분기에 대한 비율을 측정하거나, 명세 문서에 나열된 기능 요구사항 비율에 대한 측정기준은 이에 대한 한 예. 코드 기반 적합성 기준은 시험 중의 프로그램에 대한 적절한 도구(instrumentation)을 요구.
2.
결함 뿌리기(seeding) : 일부 결함은 시험 전에 인위적으로 삽입되기도. 이를 통해 시험이 수행될 때 삽입된 이들 결함 뿐 아니라 이미 있었던 결함 역시 발견될 수 있음. 이론적으로 어느, 그리고 얼마나 많이 인위적 결함이 발견되었는지에 따라서, 시험 유효성이 평가되고 남겨진 순수 결함이 추정될 수 있음. 여기서 중요한 것은 결함이 분산되어 뿌려지고 대표성을 지녀야 한다는 것. 또한 결함이 후에 남겨져 위험을 유발할 수 있으므로 조심스럽게 본 기법을 사용해야 한다는 점임.
3.
변이 점수(Mutation score) : 변이 시험에서 생성된 변이에 대한 죽은 변이의 비율은 수행된 시험 집합의 효과성 측정에 이용됨.
4.
기법간 비교 및 상대적 효과 : 여러 문건에서 시험 기법 간 상대적 효과성을 비교하는데, 여기서 중요한 것은 평가 속성에 대해 정확히 인식해야 한다는 것. 예를 들어 '효과성'의 정확한 의미는, 첫 실패를 발견하기까지의 수행된 시험 회수, 시험을 통해 발견된 결함 개수, 신뢰도 향상 정도 로 해석될 수 있음. 분석 및 경험적 기법 비교는 위 효과성 기준에 따라 이루어짐.
5. 시험 공정(Test Process)
시험 개념, 전략, 기법, 측정기준은 기 정의/제어된, 인간에 의해 수행되는 공정으로 통합될 필요가 있음. 또한 시험 공정은 시험 활동을 지원하고, 시험 팀에게 시험 전 과정에 대해 비용 효과적인 목적 달성 가능하도록 안내하는 역할을 함.
5.1. 실제적 고려사항(Practical Considerations)
1.
태도/비이기적 프로그래밍(attitudes and egoless programming) : 시험을 성공적으로 이끄는 매우 중요한 요소는 협력적 태도임. 관리자에게는 개발/유지보수 중의 실패 발견에 대해 우호적인 분위기를 만들 임무가 있음. 코드에 대한 소유 개념을 갖지 않도록 하여, 그들의 코드로 인한 실패의 책임감을 느끼지 않도록 하는 것은 한 예.
2.
시험 안내(Test guides) : 다양한 목적에서 시험 공정이 안내될 수 있음. 예를 들어 위험 기반 시험의 경우, 시험 전략의 우선순위화 및 집중화를 위해 제품 위험이 이용되고, 시나리오 기반 시험에서는 테스트 케이스가 특정 S/W 시나리오에 기반하여 정의됨.
3.
시험 공정 관리(Test process management) : 각기 다른 수준의 시험 활동은 생명주기의 주요 일부가 되는 잘 정의된 프로세스로 구성해야(사람, 도구, 정책, 측정기준과 함께). IEEE12207에서 시험은 독립적 프로세스로 기술되지는 않지만 시험 활동에 대한 원칙은 타 주요 생명주기 및 지원 프로세스에 포함됨. IEEE 1074에서 시험은 전체 생명 주기의 핵심으로서 타 평가 활동과 함께 묶임.
4.
시험 문서화 및 작업 제품(work products) : 문서화는 시험 공정 정형화의 핵심 부분으로, IEEE829-98은 시험 문서와 문서 간 또는 시험 공정 간 관계를 기술. 시험 문서는 시험 계획, 시험 설계 명세, 시험 절차(procedure) 명세, 테스트케이스 명세, 시험 로그, 시험 사건 및 문제 보고를 포함. 시험 하의 S/W는 시험 항목으로서 문서화되어야 하며, SWE의 타 문서와 동일한 수준의 품질로 지속적으로 갱신되어야.
5.
내부 vs 독립적 시험 팀(Internal vs independent test team) : 시험 공정의 정형화는 시험 팀 조직의 정형화를 수반함. 시험 팀은 프로젝트 팀의 내부 멤버, 외부 멤버 모두가 될 수 있어. 비용, 일정, 조직의 성숙도 수준, 응용프로그램의 중대성이 (멤버 결정에 대한) 결정의 고려 요소.
6.
비용/노력 추정 및 타 공정 측정(Cost/effort estimation and other process measures) : 시험이 요구하는 자원에 관계된 여러 측정 요소 및 다양한 시험 단계(test phase)의 상대적 결함 발견 효과성이 시험 공정의 제어 및 향상을 위해 사용될 수 있어. 이들 시험의 측정기준은 지정된/수행된/통과한/실패한 테스트케이스의 개수와 같은 면을 다룰 수 있어. 시험 단계 보고서 평가는 근원 분석과 결합하여 결함 발견에 대한 시험 공정의 효과성을 초기에 평가할 수 있으며, 이러한 평가는 위험 분석과 연계됨 게다가 시험에 사용할만한 자원은 응용프로그램의 사용/중대성과 비례하여야. 각기 다른 기법은 각기 다른 비용을 요구하고 제품 신뢰성의 각기 다른 수준을 만들어냄.
7.
종료(Termination) : 완료된 코드 커버리지나 기능적 완전성, 예상 결함 밀도, 운영 신뢰도와 같은 완전성(Thoroughness) 측정기준은 유용하기는 하지만 충분하지는 않음. 종료 결정은 잠재적 실패로 인한 비용과 위험에 대한 고려를 요구함. 1.2.1 시험 선택 기준 및 시험 적합성 기준 참조.
8.
시험 재사용 및 시험 패턴(Test reuse and test patterns) : 조직적이고 비용 효과적인 방법으로 시험 또는 유지보수를 수행하기 위해, 각종 시험 수단은 시스템적으로 재사용되어야. 이러한 시험 문건의 저장소는 S/W 형상 관리의 통제하에 있어야 S/W 요구사항/설계의 변경이 시험의 영역에 반영될 수 있음.
특정 환경 하의 특정 응용프로그램 유형을 시험하기 위한 시험 솔루션이 도입되는데, 여기에는 비슷한 프로젝트에서 재사용하기 위해 문서화를 이루는 시험 패턴을 형성.
5.2. 시험 활동(Test Activities)
시험 활동에 대한 성공적 관리는 S/W 형상 관리 프로세스에 달림.
1.
계획(Planning) : 타 프로젝트 관리 측면과 마찬가지로 시험 활동 역시 계획되어야. 시험 계획의 주요 측면에는 인력 배치, 시험 도구 관리, 원치 않은 결과에 대한 계획이 포함됨. 하나 이상의 S/W 기준선이 설정될 경우 주요 계획 고려 사항으로, 시험 환경이 적절한 구성을 이루는지를 검증하기 위한 시간과 노력임.
2.
테스트케이스 생성(Test-case generation) : 테스트케이스의 생성은 수행될 시험 수준 및 특정 시험 기법에 기반함. 테스트케이스는 S/W 형상 관리의 통제하에 있어야 하며 각 시험에 대한 기대 결과를 포함하여야.
3.
시험 환경 개발(Test environment development) : 시험 환경은 SWE 도구와 호환성을 이루어야. 이는 테스트케이스를 개발 및 제어할 뿐 아니라 로깅 및 기대 결과, 스크립트 및 타 시험관련 자료를 복구 가능하여야.
4.
실행(Execution) : 시험 수행에는 과학적 실험의 기본 원칙을 지켜야. 시험 중의 모든 것들은 타인이 해당 결과를 재현 가능하기에 충분하도록 수행 및 문서화되어야. 따라서 시험은 명확히 정의된 버전을 사용한 문서화된 절차에 따라 수행되어야.
5.
시험 결과 평가(Test results evaluation) : 시험 결과는 해당 시험이 성공적인지 여부를 판별할 수 있도록 평가되어야. 대부분의 경우에서 '성공적'이란 S/W가 의도한 대로 수행되고 무시할 수 없는 예기지 않은 결과(major unexpected outcomes)도 보이지 않음을 뜻함. 모든 예기치 않은 결과가 반드시 결함인 것은 아니어 단순 잡음으로 판명할 수도. 실패를 제거에는 격리,식별,기술을 통한 분석과 디버깅 노력이 요구됨. 시험결과가 특히 중요할 경우 정형 검토 위원회(formal review board)가 소집되어 이를 평가할 수도.
6.
문제 보고/시험 로그(Problem reporting/Test log) : 시험 활동은 시험 수행 시기, 시험 수행 주체, 시험 때의 S/W 형상 형태를 식별하기 위해 테스트 로그로 남겨질 수도. 예기지 않은/부정확한 시험 결과는 문제 보고 시스템에 기록되고, 해당 데이터는 이후 디버깅 및 문제 해결을 위한 기반을 이룸. 또한 결함으로 분류되지 않은 비정상 요소(anomaly) 역시 이후를 위해 문서화될 수도. 시험 보고서는 변경 관리 요구 공정의 입력 요소임(S/W 형상 관리 KA, 3 S/W 형상 통제 참조).
7.
결함 추적(Defect tracking) : 실패를 통해 얻은 결함은 해당 S/W에 언제 발생했는지, 어떤 오류(error)가 결함을 야기했는지(미약하게 정의된 요구사항, 부정확한 변수 선언, 메모리 누수, 프로그래밍 구문 오류 등), 언제 처음 발견되었는지를 결정하기 위한 분석 소스가 됨. 결함 추적 정보는 SWE의 어떤 측면이 향상되어야 하고 얼마나 이전 분석과 시험이 효과적이었는지를 결정하기 위해 사용.