영국 컴퓨터 협회의 소프트웨어 테스팅 용어집 BS 7925-1

제목: 소프트웨어 테스팅 용어집 버전 6.3(Glossary of terms used in software testing -Version 6.3)

저자: British Computer Society, Specialist Interest Group in Software Testing (BCS SIGIST)

문서유형: 표준 용어집

http://www.testingstandards.co.uk/bs_7925-1_online.htm

 

 

영국 컴퓨터 협회(British Computer Society)의 소프트웨어 테스팅 전문가 그룹(Specialist Interest Group in Software Testing)에서 정의한 소프트웨어 테스팅 용어집(BS 7925-1)을 정리한 자료

---

 

5장 용어 정의(Definitions)

5.1 승인 테스팅(acceptance testing): 사용자, 고객, 그 밖에 권한을 가진 주체가 시스템 또는 컴포넌트를 받아들일지 결정할 수 있도록 하기 위해 수행되는 공식 테스팅 [IEEE]

5.2 실제 결과(actual outcome): 명세 된 조건에서 오브젝트가 테스트 될 때 실제 나타나는 동작(behavior)

5.3 애드혹 테스팅(ad hoc testing): 인정받는 테스트 케이스 설계 기법을 사용하지 않고 수행되는 테스팅

5.4 알파 테스팅(alpha testing): 소프트웨어 개발자의 관여 없이 인하우스 사이트에서 수행되는 시뮬레이션 테스팅 또는 실 운영 테스팅

5.5 아크 테스팅(arc testing): 브랜치 테스팅(branch testing) 참조

5.6 배커스-나우어 형식(Backus-Naur form): 언어의 신텍스(syntax)를 공식 기술하기 위해 사용되는 메타 언어(meta language)

5.7 기본 블록(basic block): 브랜치를 포함하지 않은 일련의 실행 문장들(executable statements)

5.8 기초 테스트 집합(basis test set): 100% 브랜치 커버리지를 달성하도록 코드 로직으로부터 도출된 테스트 케이스 집합

5.9 비버깅(bebugging): 에러 심기(error seeding) 참조 [Abbott]

5.10 동작(behaviour): 입력 값과 사전 조건의 조합에 대한 시스템 기능의 반응. 기능(function)은 하나 또는 그 이상의 동작으로 구성될 수 있다.

 

5.11 베타 테스팅(beta testing): 소프트웨어 개발자가 관여하지 않은 사이트에서의 운영 테스팅

5.12 빅뱅 테스팅(big-bang testing): 컴포넌트들이 하나의 시스템으로 조합되기 전에 점진적 테스팅(incremental testing)을 수행하지 않는 통합 테스팅

5.13 블랙 박스 테스팅(black box testing): 기능 테스트 케이스 설계 참조

5.14 상향식 테스팅(bottom-up testing): 가장 낮은 계층의 컴포넌트를 먼저 테스트하고 그 상위 계층 컴포넌트를 테스트 하는데 활용하는 통합 테스팅 방법. 계층 구조의 가장 상단 컴포넌트가 테스트 될 때까지 이 프로세스를 반복한다.

5.15 경계 값(boundary value): 동등 클래스(equivalence classes)의 경계 상에 위치한 입력 값 또는 출력 값, 또는 경계 양쪽 사이의 간격

5.16 경계 값 분석(boundary value analysis): 대표적인 경계 값을 포함하도록 컴포넌트의 테스트 케이스를 설계하는 테스트 케이스 설계 기법

5.17 경계 값 커버리지(boundary value coverage): 테스트 케이스 집합에 의해 실행된 동등 클래스 경계 값의 퍼센트

5.18 경계 값 테스팅(boundary value testing): 경계 값 분석(boundary value analysis) 참조

5.19 브랜치(branch): 조건적으로 또는 비조건적으로 컴포넌트의 한 문장에서 다른 문장으로 콘트롤 이전

5.20 브랜치 조건(branch condition): 의사결정 조건(decision condition) 참조

 

5.21 브랜치 조건 조합 커버리지(branch condition combination coverage): 의사결정(decision)의 브랜치 조건 결과(branch condition outcomes)의 모든 조합에서 테스트 케이스 집합에 의해 실행된 것의 퍼센트

5.22 브랜치 조건 조합 테스팅(branch condition combination testing): 브랜치 조건 결과의 조합을 실행하도록 테스트 케이스가 설계되는 테스트 케이스 설계 기법

5.23 브랜치 조건 커버리지(branch condition coverage): 의사결정의 모든 브랜치 조건 결과에서 테스트 케이스 집합에 의해 실행된 것의 퍼센트

5.24 브랜치 조건 테스팅(branch condition testing): 브랜치 조건 결과를 실행하도록 테스트 케이스가 설계되는 테스트 케이스 설계 기법

5.25 브랜치 커버리지(branch coverage): 테스트 케이스 집합에 의해 실행된 브랜치의 퍼센트

5.26 브랜치 결과(branch outcome): 의사결정 결과(decision outcome) 참조

5.27 브랜치 포인트(branch point): 의사결정(decision) 참조

5.28 브랜치 테스팅(branch testing): 브랜치 결과를 실행하도록 테스트 케이스를 설계하는 테스트 케이스 설계 기법

5.29 버그(bug): 결함(fault) 참조

5.30 버그 심기(bug seeding): 에러 심기(error seeding) 참조

 

5.31 C-사용(C-use): 컴퓨테이션 데이터 사용(computation data use) 참조

5.32 캡쳐/플레이백 도구(capture/playback tool): 테스트 대상 소프트웨어에 주어진 테스트 입력을 그대로 기록하고, 기록된 입력 케이스를 나중에 테스트를 재생하는데 사용하는 테스트 도구

5.33 캡쳐/리플레이 도구(capture/replay tool): 캡쳐/플레이백 도구(capture/playback tool) 참조

5.34 CAST: 컴퓨터 기반 소프트웨어 테스팅(computer-aided software testing)의 약자

5.35 원인-결과 그래프(cause-effect graph): 입력/자극(원인)과 그에 대한 출력(결과)을 그림으로 표현한 것으로 테스트 케이스 설계에 사용됨

5.36 원인-결과 그래핑(cause-effect graphing): 원인-결과 그래프(cause-effect graphs)를 기반으로 테스트 케이스를 설계하는 테스트 케이스 설계 기법

5.37 인증(certification): 시스템 또는 컴포넌트가 명세된 요구사항에 부합하며 운영/사용에 적합하다는 것을 확증하는 프로세스 [IEEE]

5.38 차우 커버리지 메트릭(Chow's coverage metrics): N-스위치 커버리지(N-switch coverage) 참조 [Chow]

5.39 코드 커버리지(code coverage): 소프트웨어의 어떤 부분이 테스트 케이스 집합에 의해 실행되었는지(커버되었는지) 또한 어떤 부분이 실행되지 않았는지(즉, 추가적인 관심이 필요한 부분)를 결정하는 분석 방법

5.40 코드 기반 테스팅(code-based testing): 특정 콘트롤 플로우 경로를 실행하는 테스트 또는 특정 데이터 항목을 사용하는 테스트 같은 구현 코드에 기반하여 테스트를 설계하는 방법

 

5.41 호환성 테스팅(compatibility testing): 시스템이 의사소통 할 필요가 있는 타 시스템과 호환되는지 확인하는 테스팅

5.42 완전 경로 테스팅(complete path testing): 완전 테스팅(exhaustive testing) 참조

5.43 컴포넌트(component): 별개의 명세가 가용한 최소 소프트웨어 항목

5.44 컴포넌트 테스팅(component testing): 개별 소프트웨어 컴포넌트의 테스팅 [IEEE]

5.45 컴퓨테이션 데이터 사용(computation data use): 조건(condition) 이외에서의 데이터 사용. C-use라고도 불림

5.46 조건(condition): 부울 연산자를 포함하는 부울 연산식(Boolean expression). 예를 들어 A<B는 조건(condition)이지만 A와 B는 조건이 아니다 [DO-178B]

5.47 조건 커버리지(condition coverage): 브랜치 조건 커버리지(branch condition coverage) 참조

5.48 조건 결과(condition outcome): 참(TRUE) 또는 거짓(FALSE)으로 조건 평가

5.49 준수 기준(conformance criterion): 특정 입력 값에 대한 컴포넌트의 동작이 그 명세서에 부합하는지 여부를 판단하는 방법

5.50 준수 테스팅(conformance testing): 구현물이 그 명세서에 부합하는지 확인하는 테스팅 프로세스

 

5.51 콘트롤 플로우(control flow): 프로그램 실행에서 가능한 모든 이벤트 순서(sequences of events)의 추상적인 표현

5.52 콘트롤 플로우 그래프(control flow graph): 컴포넌트의 가능한 콘트롤 플로우 경로를 다이어그램으로 표현한 것

5.53 콘트롤 플로우 경로(control flow path): 경로(path) 참조

5.54 전환 테스팅(conversion testing): 현 시스템의 데이터를 대체 시스템에서 사용하기 위해 전환하는 프로그램 또는 절차를 테스트 하는 것

5.55 정확성(correctness): 소프트웨어가 해당 명세에 부합하는 정도

5.56 커버리지(coverage): 특정 커버리지 항목이 테스트 케이스 집합에 의해 실행된 정도(퍼센트로 나타냄)

5.57 커버리지 항목(coverage item): 테스트 근거로 사용되는 엔터티 또는 속성(property)

5.58 데이터 정의(data definition): 변수에 값을 할당하는 실행문

5.59 데이터 정의 C-사용 커버리지(data definition C-use coverage): 데이터 정의 C-사용 쌍(data definition C-use pairs)들에서 테스트 케이스 집합에 의해 실행된 것의 퍼센트

5.60 데이터 정의 C-사용 쌍(data definition C-use pair): 데이터 정의(data definition)에서 정의된 값을 데이터 사용(data use)에서 사용하는 데이터 정의(data definition)와 컴퓨테이션 데이터 사용(computation data use) 조합을 가리킴

 

5.61 데이터 정의 P-사용 커버리지(data definition P-use coverage): 데이터 정의 P-사용 쌍(data definition P-use pairs)들에서 테스트 케이스 집합에 의해 실행된 것의 퍼센트

5.62 데이터 정의 P-사용 쌍(data definition P-use pair): 데이터 정의(data definition)에 정의된 값을 데이터 사용(data use)에서 사용하는 데이터 정의(data definition)와 프레디킷 데이터 사용(predicate data use)의 조합

5.63 데이터 정의-사용 커버리지(data definition-use coverage): 데이터 정의-사용 쌍(data definition-use pairs)들에서 테스트 케이스 집합에 의해 실행된 것의 퍼센트

5.64 데이터 정의-사용 쌍(data definition-use pair): 데이터 정의(data definition)에 정의된 값을 데이터 사용(data use)에서 사용하는 데이터 정의(data definition)와 데이터 사용(data use)의 조합

5.65 데이터 정의-사용 테스팅(data definition-use testing): 데이터 정의-사용 쌍(data definition-use pairs)을 실행하도록 테스트 케이스를 설계하는 테스트 케이스 설계 기법

5.66 데이터 플로우 커버리지(data flow coverage): 코드 내의 변수 사용을 기반으로 한 테스트 커버리지 측정 방법. 예를 들어 데이터 정의-사용 커버리지(data definition-use coverage), 데이터 정의 P-사용 커버리지(data definition P-use coverage), 데이터 정의 C-사용 커버리지(data definition C-use coverage) 등이 있다.

5.67 데이터 플로우 테스팅(data flow testing): 코드 내의 변수 사용을 기반으로 테스트 케이스를 설계하는 테스팅

5.68 데이터 사용(data use): 변수 값 접근이 있는(accessed) 실행문

5.69 디버깅(debugging): 소프트웨어 실패(failures)의 원인을 찾고 제거하는 프로세스

5.70 의사결정(decision): 콘트롤 플로우가 둘 또는 그 이상의 선택 경로를 갖게 되는 프로그램 지점

 

5.71 의사결정 조건(Decision condition): 의사결정에 존재하는 조건

5.72 의사결정 커버리지(decision coverage): 의사결정 결과들(decision outcomes)에서 테스트 케이스 집합에 의해 실행된 것의 퍼센트

5.73 의사결정 결과(decision outcome): 콘트롤 플로우 선택을 결정하는 의사결정의 결과

5.74 설계 기반 테스팅(design-based testing): 소프트웨어의 아키텍쳐 설계 또는 상세 설계를 기반으로 테스트를 설계하는 방법(예, 특정 호출 경로를 실행하는 테스트, 알고리즘의 최악 시나리오를 탐사하는 테스트 등)

5.75 데스크 체킹(desk checking): 소프트웨어 실행을 수동으로 시뮬레이션 하여 테스트 하는 방법

5.76 더티 테스팅(dirty testing): 네가티브 테스팅(negative testing) 참조 [Beizer]

5.77 문서 테스팅(documentation testing): 문서의 정확성에 관심을 둔 테스팅

5.78 도메인(domain): 값 선정이 이루어지는 모집합

5.79 도메인 테스팅(domain testing): 동등 분할 테스팅(equivalence partition testing) 참조

5.80 동적 분석(dynamic analysis): 실행 중의 동작에 기반하여 시스템 또는 컴포넌트를 평가하는 프로세스 [IEEE]

 

5.81 에뮬레이터(emulator): 대상 시스템과 동일한 입력을 받고 동일한 출력을 생성해 낼 수 있는 기기, 컴퓨터 프로그램, 또는 시스템 [IEEE, do178b]

5.82 시작점(entry point): 컴포넌트 내의 첫 실행문

5.83 동등 클래스(equivalence class): 컴포넌트 명세 측면에서 동작이 동일한 것으로 여겨지는 컴포넌트 입력 도메인의 조각 또는 출력 도메인의 조각

5.84 동등 분할(equivalence partition): 동등 클래스(equivalence class) 참조

5.85 동등 분할 커버리지(equivalence partition coverage): 컴포넌트의 동등 클래스들 중 테스트 케이스 집합에 의해 실행된 것의 퍼센트

5.86 동등 분할 테스팅(equivalence partition testing): 동등 클래스의 대표 값을 실행하도록 테스트 케이스를 설계하는 테스트 케이스 설계 기법

5.87 에러(error): 부정확한 결과를 초래하는 사람의 행동(action) [IEEE]

5.88 에러 추정(error guessing): 발생 가능한 결함(faults) 추정 및 이러한 결함을 찾아내기 위한 구체적인 테스트 설계에 테스터의 경험을 사용하는 테스트 케이스 설계 기법

5.89 에러 심기(error seeding): 결함 발견율과 제거율을 모니터링하고 프로그램에 남아 있는 결함 수를 추정하기 위한 목적으로 의도적으로 알려진 결함(faults)을 컴퓨터 프로그램에 추가하는 프로세스 [IEEE]

5.90 실행문(executable statement): 컴파일 시 오브젝트 코드로 변환되고, 프로그램 실행 시 순차적으로 실행되며, 프로그램 데이터에 특정 작업을 수행하기도 하는 문장

 

5.91 실행됨(exercised): 입력 값이 특정 프로그램 요소(예, 문장, 브랜치, 기타 다른 구조적 요소)의 실행을 유발했을 때 이 요소는 테스트 케이스에 의해 실행된 것으로 간주된다.

5.92 완전 테스팅(exhaustive testing): 컴포넌트 변수에 대한 입력 값과 사전 조건의 모든 조합이 테스트 케이스 집합에 포함되는 테스트 케이스 설계 기법

5.93 출구(exit point): 컴포넌트 내의 마지막 실행문

5.94 예상 결과(expected outcome): 예측 결과(predicted outcome) 참조

5.95 기능 테스팅(facility testing): 기능 테스트 케이스 설계(functional test case design) 참조

5.96 실패(failure): 의도된 전달물 또는 서비스로부터 벗어난 소프트웨어 오차 [Fenton]

5.97 결함(fault): 소프트웨어 에러가 표면적으로 드러난 것(징후로 나타난 것). 결함(fault)이 실패(failure)로 이어질 수도 있다. [do178b]

5.98 실현 가능 경로(feasible path): 실행을 유발하는 입력 값 및 실행 조건의 집합이 존재하는 경로

5.99 기능 테스팅(feature testing): 기능 테스트 케이스 설계(functional test case design) 참조

5.100 기능 명세(functional specification): 제품 특성을 의도된 기능과 연관하여 자세하게 기술한 문서 [BS 4778, Part2]

 

5.101 기능 테스트 케이스 설계(functional test case design): 내부 구조에 대한 참고 없이 컴포넌트의 명세서 분석을 기반으로 테스트 케이스를 선정

5.102 글래스 박스 테스팅(glass box testing): 구조적 테스트 케이스 설계(structural test case design) 참조

5.103 점진적 테스팅(incremental testing): 전체 시스템이 완성될 때까지 시스템 컴포넌트가 한번에 하나씩 통합되어가는 통합 테스팅

5.104 독립성(independence): 객관적인 평가를 달성할 수 있도록 책임을 분리 [do178b]

5.105 실현 불가능한 경로(infeasible path): 어떤 입력 값으로도 실행을 할 수 없는 경로

5.106 입력(input): 컴포넌트에 의해 읽혀지는 변수(컴포넌트 내부에 저장되거나 또는 외부에 위치)

5.107 입력 도메인(input domain): 모든 가능한 입력 값의 집합

5.108 입력 값(input value): 입력의 실례(instance)

5.109 인스펙션(inspection): 명세된 산출물에 대한 그룹 검토 품질 개선 프로세스. 제품 측면(문서 자체)의 개선과 프로세스 측면(문서 산출 프로세스와 인스펙션 프로세스)의 개선 두 가지로 구성됨 [Graham]

5.110 설치 테스팅(installability testing): 시스템 설치 절차에 관심을 둔 테스팅

 

5.111 인스트루멘테이션(instrumentation): 실행 중인 프로그램의 동작에 대한 정보를 수집하기 위한 추가 코드를 프로그램에 삽입

5.112 인스트루멘터(instrumenter): 인스트루멘테이션을 수행하는 소프트웨어 도구

5.113 통합(integration): 더 큰 단위로 컴포넌트를 조합하는 프로세스

5.114 통합 테스팅(integration testing): 통합된 컴포넌트의 인터페이스(interfaces) 및 상호작용(interaction)에 있는 결함(faults)을 찾기 위해 수행되는 테스팅

5.115 인터페이스 테스팅(interface testing): 시스템 컴포넌트 간의 인터페이스가 테스트 되는 통합 테스팅(Integration testing)

5.116 독립 테스팅(isolation testing): 한 컴포넌트를 이를 둘러싼 주변의 컴포넌트로부터 독립하여 개별적으로 테스팅. 주변 컴포넌트의 역할은 스터브(stubs)로 시뮬레이션 함

5.117 LCSAJ: 선형 코드 순서 및 점프(A Linear Code Sequence And Jump)를 의미. 1) 실행문의 선형 순서의 시작점, 2) 선형 순서의 종료점, 3) 선형 순서의 종료점에서 컨트롤 플로우가 이전되는 목표점인 타겟 라인의 세 개 항목으로 구성됨. 통상적으로 소스 코드 목록에서 라인 번호로 식별됨

5.118 LCSAJ 커버리지(LCSAJ coverage): 테스트 케이스 집합에 의해 실행된 LCSAJ의 퍼센트

5.119 LCSAJ 테스팅(LCSAJ testing): LCSAJ를 실행하도록 테스트 케이스가 설계되는 테스트 케이스 설계 기법

5.120 로직-커버리지 테스팅(logic-coverage testing): 구조적 테스트 케이스 설계(structural test case design) 참조 [Myers]

 

5.121 로직 위주 테스팅(logic-driven testing): 구조적 테스트 케이스 설계(structural test case design) 참조

5.122 유지보수성 테스팅(maintainability testing): 명세된 유지보수성 목표를 시스템이 충족하는지에 관심을 둔 테스팅

5.123 변경 조건/의사결정 커버리지(modified condition/decision coverage): 의사결정 결과(decision outcome)에 독립적으로 영향을 미치는 모든 브랜치 조건 결과(branch condition outcomes) 중에서 테스트 케이스 집합에 의해 실행된 것의 퍼센트

5.124 변경 조건/의사결정 테스팅(modified condition/decision testing): 의사결정 결과(decision outcome)에 독립적으로 영향을 미치는 브랜치 조건 결과(branch condition outcomes)를 실행하도록 테스트 케이스를 설계하는 테스트 케이스 설계 기법

5.125 다수 조건 커버리지(multiple condition coverage): 브랜치 조건 조합 커버리지(branch condition combination coverage) 참조

5.126 뮤테이션 분석(mutation analysis): 테스트 대상 프로그램과 그로부터 살짝 변형된 프로그램(뮤턴트)들의 차이를 구분해 낼 수 있는지를 기준으로 설계된 테스트 케이스 집합의 적정성(테스트 케이스가 충분한지 여부)을 판단하는 방법. 에러 심기(error seeding) 참조

5.127 N-스위치 커버리지(N-switch coverage): N-전이 순서(sequences of N-transitions)들에서 테스트 케이스 집합에 의해 실행된 것의 퍼센트

5.128 N-스위치 테스팅(N-switch testing): 모든 타당한 N-전이 순서(sequences of N-transitions)를 실행하도록 테스트 케이스를 설계하는 상태 전이 테스팅(state transition testing)의 한 형태

5.129 N-전이(N-transitions): N+1 전이(transitions)의 일련의 순서

 

5.130 네가티브 테스팅(negative testing): 소프트웨어 제대로 동작하지 않음을 보이는 것을 목적으로 하는 테스팅 [Beizer] 

 

 

 

5.131 비기능 요구사항 테스팅(non-functional requirements testing): 기능성과 관련되지 않은 요구사항의 테스팅(예, 성능, 사용성 등)

5.132 운영 테스팅(operational testing): 시스템 또는 컴포넌트를 해당 운영 환경에서 평가하기 위해 수행되는 테스팅 [IEEE]

5.133 오라클(oracle): 테스트 대상 소프트웨어의 실제 결과(the actual outcomes)와 비교할 예상 결과(the predicted outcomes)를 생성하는 메커니즘 [adrion]

5.134 결과(outcome): 실제 결과 또는 예상 결과. 테스트의 결과물. 브랜치 결과(branch outcome), 조건 결과(condition outcome), 의사결정 결과(decision outcome) 참조

5.135 출력(output): 변수(컴포넌트 내부에 저장되었거나 또는 외부에 위치)에 컴포넌트에 의한 쓰기가 이루어짐

5.136 출력 도메인(output domain): 모든 가능한 출력의 집합

5.137 출력 값(output value): 출력의 실례(An instance)

5.138 P-사용(P-use): 프레디킷 데이터 사용(predicate data use) 참조

5.139 분할 테스팅(partition testing): 동등 분할 테스팅(equivalence partition testing) 참조 [Beizer]

5.140 경로(path): 시작점(an entry point)에서부터 출구(an exit point)까지 컴포넌트 실행문의 일련의 순서

 

5.141 경로 커버리지(path coverage): 컴포넌트의 경로 중 테스트 케이스 집합에 의해 실행된 것의 퍼센트

5.142 경로 센서타이징(path sensitizing): 컴포넌트 실행 시 특정 경로가 선택되도록 만드는 입력 값 집합을 선정

5.143 경로 테스팅(path testing): 컴포넌트의 경로들을 실행하도록 테스트 케이스를 설계하는 테스트 케이스 설계 기법

5.144 성능 테스팅(performance testing): 시스템 또는 컴포넌트가 명세된 성능 요구사항을 준수하는지 평가하기 위해 수행되는 테스팅 [IEEE]

5.145 호환성 테스팅(portability testing): 소프트웨어가 특정 하드웨어 플랫폼 또는 소프트웨어 플랫폼에 이식 가능함을 증명하는 것이 목적인 테스팅

5.146 사전 조건(precondition): 특정 입력 값으로 컴포넌트가 실행되기 위해서 사전에 충족되어야 할 환경적 조건과 상태 조건

5.147 프레디킷(predicate): 참 또는 거짓으로 평가되는 논리식(A logical expression), 대개 코드의 실행 경로를 결정한다.

5.148 프레디킷 데이터 사용(predicate data use): 프레디킷에서의 데이터 사용(A data use)

5.149 예측 결과(predicted outcome): 특정 조건 하에서 오브젝트의 명세에 의해 예측된 동작

5.150 프로그램 인스트루멘터(program instrumenter): 인스트루멘터(instrumenter) 참조

 

5.151 전진 테스팅(progressive testing): 이전 기능의 회귀 테스팅(regression testing) 후에 신규 기능을 테스팅 [Beizer]

5.152 유사 랜덤(pseudo-random): 무작위로 보이지만 실제는 사전 정해진 어떤 순서에 의해 생성된 시리즈

5.153 복구 테스팅(recovery testing): 다양한 수준의 실패(failure)로부터 시스템이 복구할 수 있는 능력을 검증하는데 목표를 둔 테스팅

5.154 회귀 테스팅(regression testing): 변경으로 인한 새로운 결함(faults)이 생기거나 미발견 결함이 있는지 확인하기 위해 변경 후에 이전에 테스트 된 프로그램을 재테스팅 하는 것

5.155 요구사항 기반 테스팅(requirements-based testing): 소프트웨어 컴포넌트의 요구사항을 기반으로 테스트를 설계 하는 것(예, 특정 기능을 실행하는 테스트, 성능이나 보안 같은 비기능 제약사항을 조사하는 테스트 등). 기능 테스트 케이스 설계(functional test case design) 참조

5.156 결과(result): 결과(outcome) 참조

5.157 검토(review): 프로젝트 인원, 관리자, 사용자, 기타 다른 이해관계자의 승인이나 코멘트를 얻기 위해 제품에 대하여 설명(프리젠테이션)을 하는 프로세스 또는 회의 [IEEE]

5.158 보안 테스팅(security testing): 시스템이 명세된 보안 목표를 충족하는지 확인하는 테스팅

5.159 서비스성 테스팅(serviceability testing): 유지보수성 테스팅(maintainability testing) 참조

5.160 단순 서브경로(simple subpath): 꼭 필요한 프로그램 부분만 실행되는 콘트롤 플로우 그래프의 서브경로

 

5.161 시뮬레이션(simulation): 물리적 또는 추상적 시스템의 특정한 동적 특성을 다른 시스템으로 표현한 것(흉내 낸 것)  [ISO 2382/1]

5.162 시뮬레이터(simulator): 통제된 입력 값 집합이 주어졌을 때 대상 시스템이 동작하는 것과 동일하게 동작하는 기기, 컴퓨터 프로그램, 또는 시스템. 소프트웨어 검증에 사용됨 [IEEE, do178b]

5.163 소스 문장(source statement): 문장(statement) 참조

5.164 명세(specification): 컴포넌트 기능을 특정 사전 조건 하의 특정 입력 값에 대해 생성되는 출력 값 측면으로 기술한 것

5.165 명세된 입력(specified input): 입력에 대한 결과가 명세서에 예측(기술)되어 있는 입력

5.166 상태 전이(state transition): 시스템 또는 컴포넌트에서 허용하는 두 개의 상태 간의 전이

5.167 상태 전이 테스팅(state transition testing): 상태 전이를 실행하기 위한 테스트 케이스가 설계되는 테스트 케이스 설계 기법

5.168 문장(statement): 프로그래밍 언어의 엔터티로 대개 분할이 불가능한 가장 작은 실행 단위

5.169 문장 커버리지(statement coverage): 컴포넌트의 실행 문장들 중 테스트 케이스 집합에 의해 실행된 것의 퍼센트

5.170 문장 테스팅(statement testing): 컴포넌트의 문장을 실행하도록 테스트 케이스가 설계되는 테스트 케이스 설계 기법

 

5.171 정적 분석(static analysis): 프로그램 실행 없이 수행되는 프로그램 분석

5.172 정적 분석기(static analyzer): 정적 분석(static analysis)을 수행하는 도구

5.173 정적 테스팅(static testing): 컴퓨터 상의 실행 없이 오브젝트를 테스팅

5.174 통계적 테스팅(statistical testing): 대표 테스트 케이스를 구축하는데 있어 입력의 통계적 분포 모델이 사용되는 테스트 케이스 설계 기법

5.175 저장 테스팅(storage testing): 시스템이 명세된 저장 목표(storage objectives)를 충족하는지 에 관심을 둔 테스팅

5.176 스트레스 테스팅(stress testing): 시스템 또는 컴포넌트가 명세된 요구사항의 한계치에 또는 그 이상에 놓인 경우를 평가하기 위해 수행되는 테스팅 [IEEE]

5.177 구조적 커버리지(structural coverage): 컴포넌트의 내부 구조를 기반으로 한 커버리지 측정

5.178 구조적 테스트 케이스 설계(structural test case design): 컴포넌트 내부 구조의 분석을 기반으로 테스트 케이스를 선택

5.179 구조적 테스팅(structural testing): 구조적 테스트 케이스 설계(structural test case design) 참조

5.180 구조적 기초 테스팅(structured basis testing): 코드 로직에서 100% 브랜치 커버리지를 달성하도록 테스트 케이스를 도출하는 테스트 케이스 설계 기법

 

5.181 구조적 워크쓰루(structured walkthrough): 워크쓰루(walkthrough) 참조

5.182 스터브(stub): 특정 소프트웨어 모듈을 호출하거나 또는 의존 관계에 있는 컴포넌트를 개발 및 테스트 하기 위해서 해당 소프트웨어 모듈의 뼈대만 또는 특정 부분만 구현한 것 [IEEE]

5.183 서브경로(subpath): 컴포넌트 내의 일련의 실행 문장 순서(A sequence of executable statements)

5.184 기호 평가(symbolic evaluation): 기호 실행(symbolic execution) 참조

5.185 기호 실행(symbolic execution): 프로그램 경로들의 기호 표현(a symbolic expression)을 도출하는 정적 분석 기법

5.186 신텍스 테스팅(syntax testing): 입력의 신텍스(syntax)을 기반으로 테스트 케이스를 설계하는 테스트 케이스 설계 기법

5.187 시스템 테스팅(system testing): 명세된 요구사항을 충족하는지 검증하기 위하여 통합된 시스템을 테스팅 [Hetzel]

5.188 기술 요구사항 테스팅(technical requirements testing): 비기능 요구사항 테스팅(non-functional requirements testing) 참조

5.189 테스트 자동화(test automation): 테스트 실행, 실제 결과와 예상 결과 비교, 테스트 사전 조건 셋업, 테스트 통제 및 보고 등을 자동으로 통제하기 위하여 소프트웨어를 사용하는 것

5.190 테스트 케이스(test case): 특정 목적(예, 특정 프로그램 경로를 실행, 특정 요구사항의 준수 여부를 검증 등)을 위해 개발된 입력 집합, 실행 사전 조건, 예상 결과 [IEEE, do178b]

 

5.191 테스트 케이스 설계 기법(test case design technique): 테스트 케이스를 도출하는데 또는 선택하는데 사용되는 방법

5.192 테스트 케이스 집합(test case suite): 테스트 대상 소프트웨어에 대한 하나 또는 그 이상의 테스트 케이스를 모은 것

5.193 테스트 비교기(test comparator): 테스트 대상 소프트웨어가 생성한 실제 출력 결과를 해당 테스트 케이스의 예상 출력 결과와 비교하는 테스트 도구

5.194 테스트 완료 기준(test completion criterion): 언제 계획된 테스팅이 완료되는지를 결정하는 기준으로 테스트 측정 기법을 통하여 정의된다.

5.195 테스트 커버리지(test coverage): 커버지리(coverage) 참조

5.196 테스트 드라이버(test driver): 테스트 케이스 집합으로 테스트 대상 소프트웨어를 실행하는데 사용되는 프로그램 또는 테스트 도구

5.197 테스트 환경(test environment): 테스트가 실행되는 하드웨어 및 소프트웨어 환경을 기술한 것. 스터브와 테스트 드라이버 같은 테스트 중에 테스트 대상 소프트웨어와 상호 작용하는 모든 소프트웨어를 포함

5.198 테스트 실행(test execution): 테스트 대상 소프트웨어에 의해 테스트 케이스 집합이 처리(프로세싱)되어 결과적으로 출력 결과가 생성되는 것

5.199 테스트 실행 기법(test execution technique): 실제 테스트 실행을 하는데 사용되는 방법(예, 수동 실행, 캡쳐/플레이백 도구 등)

5.200 테스트 생성기(test generator): 명세된 전략 또는 휴리스틱에 따라 테스트 케이스를 생성하는 프로그램 [Beizer]

 

5.201 테스트 하니스(test harness): 테스트 드라이버(a test driver)와 테스트 비교기(a test comparator)로 구성된 테스팅 도구

5.202 테스트 측정 기법(test measurement technique): 테스트 커버리지 항목을 축정하는데 사용되는 방법

5.203 테스트 결과(test outcome): 결과(outcome) 참조

5.204 테스트 계획(test plan): 테스터의 독립성 정도, 테스트 환경, 테스트 케이스 설계 기법, 테스트 측정 기법, 이런 기법들을 선정한 근거 등을 상세히 하는 테스트 계획 프로세스의 기록

5.205 테스트 절차(test procedure): 하나 또는 그 이상의 테스트 케이스를 실행하기 위한 상세한 방법을 제공하는 문서

5.206 테스트 기록(test records): 각 테스트에 대해 테스트 대상 컴포넌트의 식별자와 버전, 테스트 명세서, 실제 출력 결과를 명확하게 기록한 것

5.207 테스트 스크립트(test script): 통상적으로 테스트 하니스(a test harness)와 함께 사용되는 자동화된 테스트 절차를 지칭

5.208 테스트 명세(test specification): 각 테스트 케이스에 대해 커버리지 항목, 테스트 대상 소프트웨어의 초기 상태, 입력, 예상 결과를 기술한 것

5.209 테스트 타겟(test target): 테스트 완료 기준(test completion criteria)의 집합

5.210 테스팅(testing): 소프트웨어가 명세된 요구사항을 충족하는지 검증하고 에러를 발견하기 위해 소프트웨어를 동작시키는 프로세스 [do178b]

 

5.211 쓰레드 테스팅(thread testing): 하향식 테스팅(top-down testing)의 변형. 컴포넌트의 점진적 통합을 하는데 있어 연속된 하위 계층의 컴포넌트를 통합하는 대신 요구사항의 서브집합 구현에 따라서 통합을 하는 것이 차이점이다.

5.212 하향식 테스팅(top-down testing): 컴포넌트 계층도의 최상위 컴포넌트가 가장 먼저 테스트 되는 통합 테스팅 방법(하위 계층 컴포넌트들은 스터브 시뮬레이션으로 대체). 먼저 테스트 된 컴포넌트는 아래 계층의 컴포넌트를 테스트 하는데 사용되며, 가장 낮은 계층의 컴포넌트가 테스트 될 때까지 프로세스가 반복된다.

5.213 단위 테스팅(unit testing): 컴포넌트 테스팅(component testing) 참조

5.214 사용성 테스팅(usability testing): 사용자가 제품을 배우고 사용하기 쉬운 정도에 대한 테스팅

5.215 확인(validation): 사용자 요구(the user needs)와 요구사항(requirements)에 대한 소프트웨어 개발 제품이 정확한지를 판단

NOTE: BS 7925-1:1998는 “의도한 사용에 관한 특정 요구사항이 충족되었다는 객관적인 증거 조사 및 제시를 통한 확증”으로 정의

5.216 검증(verification): 주어진 개발 단계의 제품이 해당 단계의 시작 시점에 부여한 조건을 충족하는지 판단하기 위해 시스템 또는 컴포넌트를 평가하는 프로세스 [IEEE]

NOTE: BS 7925-1:1998는 “명세된 요구사항이 충족되었다는 객관적인 증거 조사 및 제시를 통한 확증”으로 정의

5.217 볼륨 테스팅(volume testing): 시스템이 대용량 데이터 하에 놓인 경우를 테스팅

5.218 워크쓰루(walkthrough): 요구사항, 설계, 코드의 검토. 검토 대상 오브젝트의 작성자가 검토의 진행을 가이드 함.

 

5.219 화이트 박스 테스팅(white box testing): 구조적 테스트 케이스 설계(structural test case design) 참조