결함(defect)
1. 소프트웨어 개발자에 의하여 만들어진 오류 표출
2. 원시코드 또는 문서에서 발견된 소프트웨어 개발자에 의하여 저질러진 오류
A flaw in a component or system that can cause the component or system to fail to perform its required function, e.g. an incorrect statement or data definition. A defect, if encountered during execution, may cause a failure of the component or system.
결함분석
지속적인 품질 향상을 위하여 결함을 자료로 사용하는 분석. 결함을 카테고리 별로 구별하고 결함을 원인을 찾아내어 프로세스 향상 노력에 도움이 되게 한다.
결함빈도(defect density)
단위 프로그램 길이 (보통 1000라인) 당 결함의 수. 경계값 분석 데이터 범위의 경계선에 놓여있는 값을 선택하여 테스트 테이터로 선택하는 방법. 경계값은 최대, 최소, 경계안쪽/바깥쪽, 정상적 대표값, 오류값으로 구성된다.
The number of defects identified in a component or system divided by the size of the component or system (expressed in standard measurement terms, e.g. lines-ofcode, number of classes or function points).
경로분석
프로그램 안에 있는 불완전한 경로 또는 실행 불가능한 코드를 찾아내기 위하여 모든 경로를 파악하는 분석 방법.
경로 커버리지(path coverage)
프로그램에 존재하는 모든 경로를 한번 이상 수행하는 테스트 방법. 프로그램의 경로는 유한클래스의 집합으로 그루핑될 수 있으며 클래스 당 하나의 경로만을 테스트 한다.
The percentage of paths that have been exercised by a test suite. 100% path coverage implies 100% LCSAJ coverage.
공식리뷰 ( formal review)
분석, 설계, 코딩 등 여러가지 작업 단계가 완료된 후 고객(formal review)과 함께 수행하는 기술적인 검토
A review characterized by documented procedures and requirements, e.g. inspection.
구조적 커버리지 (structural coverage)
대규모 시스템의 테스트 완료를 위하여 모든 모듈이 적어도 한번씩 수행되어야 하는 검증 기준
Coverage measures based on the internal structure of a component or system.
기능 테스트(functional testing)
원시 프로그램을 자세히 조사하지 않고 명시된 기능적 요구를 기초로 테스트 하는 방법
Testing based on an analysis of the specification of the functionality of a component or system. See also black box testing.
기술검토(technical review)
기술문서의 내용을 검토하는 기술측면의 회의
A peer group discussion activity that focuses on achieving consensus on the technical approach to be taken. [Gilb and Graham, IEEE 1028] See also peer review.
데이터 흐름분석(data flow)
원시코드에 표현된 데이터(변수)의 정의와 사용에 대한 패턴을 모아 그래프로 분석하는 기법. 원시코드가 수행되는 도중에 특정 위치에서 데이터에 가해진 제약조건을 결정하는 데 도움이 된다.
An abstract representation of the sequence and possible changes of the state of data objects, where the state of an object is any of: creation, usage, or destruction. [Beizer]
동등 클래스 분할(equivalence partition)
여러가지 입력 조건들의 대표값을 파악하여 테스트 하는 기법
A portion of an input or output domain for which the behavior of a component or system is assumed to be the same, based on the specification.
동료검토 (peer review)
소프트웨어의 결함이나 수정이 필요한 부분을 찾기 위하여(peer review) 개발 당사자가 아닌 동료가 조사 검토하는 작업.
A review of a software work product by colleagues of the producer of the product for the purpose of identifying defects and improvements. Examples are inspection, technical review and walkthrough.
동적분석(dynamic analysis)
선택한 테스트 테이터를 이용하여 프로그램을 수행하여 테스트 하는 방법.
The process of evaluating behavior, e.g. memory performance, CPU usage, of a system or component during execution. [After IEEE 610]
디버깅(debugging)
테스트 또는 사용자의 불만제기에 의하여 발견된 기능장애의 원인을 찾아내려는 작업.
The process of finding, analyzing and removing the causes of failures in software.
랜덤 테스트(random testing)
프로그램에 가능한 모든 입력값 중에서 임의의 값을 택하여 시험하는 블랙박스 테스트 기법
A black box test design technique where test cases are selected, possibly using a pseudo-random generation algorithm, to match an operational profile. This technique can be used for testing non-functional attributes such as reliability and performance.
리그레션 테스트(regression testing)
시스템의 일부 또는 전체를 수정하는 동안 변경에 의한 영향이 문제를 일으키지 않는지 또는 변경한 시스템이 의도한 요구사항을 잘 만족하는지 발견하기 위하여 선택적으로 다시 테스트 하는 기법
Testing of a previously tested program following modification to ensure that defects have not been introduced or uncovered in unchanged areas of the software, as a result of the changes made. It is performed when the software or its environment is changed.
매트릭
제품이 가지는 품질, 특성, 속성 등의 정도를 측정함
문장 커버리지(statement coverage)
테스트가 완료되기 위하여 각 문장이 적어도 한번씩 수행되어야 하는 검증 조건
The percentage of executable statements that have been exercised by a test suite.
뮤테이션 테스트(mutation testing)
테스트 데이터가 프로그램의 작은 오류에 얼마나 민감한지 보기 위하여 의도적으로 프로그램을 변경시켜 준비된 테스트 데이터를 실행시키는 기법.
See back-to-back testing.
Testing in which two or more variants of a component or system are executed with the same inputs, the outputs compared, and analyzed in cases of discrepancies. [IEEE 610]
베타 테스트(beta testing)
소프트웨어 제품의 고객이 될 엔드유저에 의하여 고객의 사이트에 설치하고 시험하는 테스트.
Operational testing by potential and/or existing users/customers at an external site not otherwise involved with the developers, to determine whether or not a component or system satisfies the user/customer needs and fits within the business processes. Beta testing is often employed as a form of external acceptance testing for off-the-shelf software in order to acquire feedback from the market.
분기 커버리지 테스트 (branch coverage)
프로그램 안에 포함된 분기점의 참과 거짓 모든 가지(branch)를 적어도 한번식 테스트 하는 조건을 요구 하는 테스트 방법
The percentage of branches that have been exercised by a test suite. 100% branch coverage implies both 100% decision coverage and 100% statement coverage.
블랙박스 테스트(black-box testing)
프로그램의 내부 구조나 데이터에 대한 지식이 없이 요구사항에 근거하여 수행하는 기능 시험
Testing, either functional or non-functional, without reference to the internal structure of the component or system.
사이클로매틱(cyclomatic number)
복잡도 프로그램 모둘을 통과하는 독립적인 수행 경로의 수
상향식 테스트
하위층의 컴포넌트를 먼저 구현하고 이를 호출하기 위하여 테스트 드라이버를 사용 통합테스트 유형
실행 불가능 경로
조건 설정이 잘못되어 도저히 실행이 될 수 없는 프로그램의 문장
스텁(stub)
하양식 통합 테스트할 때 아직 통합되지 않은 모듈을 호출 할 때 그 모듈의 기능을 최소한으로 시물레이션한 모의 모둘.
A skeletal or special-purpose implementation of a software component, used to develop or test a component that calls or is otherwise dependent on it. It replaces a called component. [After IEEE 610]
시스템 테스트(system testing)
시스템이 명시된 기능 및 성능을 발휘하는지 모든 시스템 구성요소를 통합한 후 시험하는 기술
The process of testing an integrated system to verify that it meets specified requirements. [Hetzel]
알파 테스트(alpha testing)
개발자 사이트에서 사용자가 수행하는 소프트웨어 제품의 테스트
Simulated or actual operational testing by potential users/customers or an independent test team at the developers’ site, but outside the development organization. Alpha testing is often employed for off-the-shelf software as a form of internal acceptance testing.
오류
1. 수행된 결과값이나 조건과 예상하였던, 이론에 의하면 올바른 값이나 조건과의 불일치
2. 프로그래머에 의하여 생성된 실수로 프로그램의 결함으로 나타남
오류기반 테스트
프로그래밍 스타일, 오류가 많이 발생하는 문법, 기타 프로그래밍 지식을 이용하여 많이 출현하는 결함을 예측하고 이를 발견하기 위한 테스트 데이터를 선택하는 방법.
워크스루(wolkthrough)
가상의 입력에 대하여 원시코드의 수행을 문장 하나씩 짚어보는 작업. 테이터 정의부분, 매뉴얼, 명세 등 프로그램이 아닌 부분도 검토 대상이 된다.
A step-by-step presentation by the author of a document in order to gather information and to establish a common understanding of its content. [Freedman and Weinberg, IEEE 1028] See also peer review.
원인-효과 그래프(cause-effect graph)
테스트 케이스를 만들기 위하여 원인과 그 효과의 관계를 체계적으로 나타내는 방법. 테스트 케이스의 완벽성과 모호성을 체크하는데 도움이 된다.
A graphical representation of inputs and/or stimuli (causes) with their associated outputs (effects), which can be used to design test cases.
인수테스트(acceptance testing)
시스템이 인수조건에 만족하는지 결정하기 위한 공식테스트. 이 결과를 기초로 고객이 시스템 개발을 인수할 것인지 결정한다.
Formal testing with respect to user needs, requirements, and business processes conducted to determine whether or not a system satisfies the acceptance criteria and to enable the user, customers or other authorized entity to determine whether or not to accept the system. [After IEEE 610]
인스트루멘트시스템 (instrumentation)
컴포넌트의 수행을 모니터링하기 위하여 일시적으로 프로그램에 삽입하는 명령어
The insertion of additional code into the program in order to collect information about program behavior during execution, e.g. for measuring code coverage.
인스펙션(inspection)
소프트웨어 요구, 설계, 원시코드 등을 저작자 이외의 다른 전문가 또는 팀이 검사하여 오류를 찾아내는 공식적 검토 방법, 소프트웨어 품질을 높이는 한 가지 방법이며 결과물 자체의 품질 측면 뿐만 아니라 결과물을 만들어내는 과정도 인스펙션의 대상이다.
A type of peer review that relies on visual examination of documents to detect defects, e.g. violations of development standards and non-conformance to higher level documentation. The most formal review technique and therefore always based on a documented procedure. [After IEEE 610, IEEE 1028] See also peer review.
정적분석(static analysis)
원시코드나 개발 문서가 요구 및 표준 규격에 맞는지 수동인 방법으로 체크하는 기법
Analysis of software artifacts, e.g. requirements or code, carried out without execution of these software artifacts.
단위테스트(component testing)
독립적으로 컴파일 되고 링크 될 수 있는 소프트웨어의 작은 단위를 테스트하는 작업. 단위는 독립적인 기능이나 의도하는 설계 구조와 매칭되지 않을 수도 있다.
The testing of individual software components. [After IEEE 610]
테스트(test)
시스템이 정해진 요구를 만족하는지, 예상과 실제 결과가 어떤 차이를 보이는지 수동 또는 자동 방법을 동원하여 검사하고 평가하는 일련의 과정
A set of one or more test cases [IEEE 829]
테스트계획(test plan)
테스트 작업을 통제하고 관리하기 위하여 따라야 할 테스트 절차 또는 과정, 도구등을 적은 문서.
A document describing the scope, approach, resources and schedule of intended test activities. It identifies amongst others test items, the features to be tested, the testing tasks, who will do each task, degree of tester independence, the test environment, the test design techniques and entry and exit criteria to be used, and the rationale for their choice, and any risks requiring contingency planning. It is a record of the test planning process. [After IEEE 829]
테스트 드라이버(test driver)
상향식 통합테스트에서 아직 통합되지 않은 상위 컴포넌트들의 동작을 시뮬레이션하는 모의 모듈. 테스트 하니스의 일종
See driver.
A software component or test tool that replaces a component that takes care of the control and/or the calling of a component or system. [After TMap]
테스트 베드(test bed)
1. 논리적 및 물리적으로 분리된 컴포넌트를 테스트하기 위하여 하드웨어. 인스트루먼트, 시뮬레이터, 소프트웨어 도구 등을 통합한 환경
2. 컴포넌트나 시스템 테스트를 수행하기 위하여 필요한 테스트 프로그램 슈트.
See test environment.
An environment containing hardware, instrumentation, simulators, software tools, and other support elements needed to conduct a test. [After IEEE 610]
테스트 사이클(test cycle)
연속적인 테스트 슈트로 구성되어 있고 처음 테스트 환경 준비 단계부터 보고, 해체 단계까지의 완벽한 수행 과정을 이룬다.
Execution of the test process against a single identifiable release of the test object.
테스트 슈트(test suite)
일정한 순서에 의하여 수행될 개별 테스트들의 집합, 또는 패키지, 슈트는 응용분야나 우선순위, 내용에 연관된다.
A set of several test cases for a component or system under test, where the post condition of one test is often used as the precondition for the next one.
테스트 스크립트(test script)
테스트 케이스를 수행하여 그 결과를 보고할 목적으로 명령어 또는 이벤트 중심의 스크립트 언어로 작성한 파일. 프로그램과 같이 테스트 스크립트는 수행 경로에 영향을 미칠 논리 조건들을 포함하고 있다. 채택된 자동화 방법에 따라 다르겠지만 상수와 시행 과정에 변경될 변수 값을 포함한다. 자동화 접근 방법은 테스트 스크립트를 개발하는데 필요한 기술적 역량의 정도를 나타낸다.
Commonly used to refer to a test procedure specification, especially an automated one.
테스트 절차
테스트를 수행할 때 따라야 할 순서. 최소의 훈련으로 테스트를 수행하게 하는 문서
테스트 케이스(test case)
요구에 맞게 개발되었는지 확인하기 위하여 테스트할 입력과 예상 결과를 정의한 것 . 테스트 자동화를 도입하면 테스트 케이스는 데이터 레코드로 저장될 수 있고 테스트 스크립트로 정의할 수 있다.
A set of input values, execution preconditions, expected results and execution postconditions, developed for a particular objective or test condition, such as to exercise a particular program path or to verify compliance with a specific requirement. [After IEEE 610]
테스트 하니스(test harness)
소프트웨어 컴포넌트의 테스트를 가능하게 하거나 프로그램의 입력을 받아들이거나 빠진 컴포넌트의 기능의 대신하거나 실행 결과와 예상 결과를 비교하기 위하여 동원된 소프트웨어 도구
A test environment comprised of stubs and drivers needed to execute a test.
통합(integration)
소프트웨어 컴포넌트들을 묶어 전체 시스템으로 묶는 작업
The process of combining components or systems into larger assemblies.
통합 테스트(integration testing)
소프트웨어 컴포넌트들을 묶어 전체 시스템이 될 때 까지 순서대로 통합하며 시험하는 기법
Testing performed to expose defects in the interfaces and in the interactions between integrated components or systems. See also component integration testing, system integration testing.
하이브리드
테스트 모듈의 우선순위와 준비 스케줄을 고려하여 상향식 테스트와 하향식 테스트를 혼합한 통합 테스트 방법
화이트 박스 테스트(white-box testing)
테스트 대상이 되는 원시코드를 자세히 관찰하면 테스트 한다는 의미로 클래스(glass) 박스 또는 오픈(open) 박스 테스트라고도 한다.
Testing based on an analysis of the internal structure of the component or system.
하향식 테스트(top-down testing)
상위층의 컴포넌트를 먼저 테스트하고 아직 구현되지 않은 컴포넌트를 시뮬레이션 하는 모의 컴포넌트 즉 스텁을 이용하여 통합하는 테스트 유형
An incremental approach to integration testing where the component at the top of the component hierarchy is tested first, with lower level components being simulated by stubs. Tested components are then used to test lower level components. The process is repeated until the lowest level components have been tested. See also integration testing.
[출처] CSTE 용어정리|작성자 dejavu_blog