X
STEN 회원이 되시면 테스팅에 관한 많은 정보와 자료를 공유할 수 있도록 저희가 돕겠습니다.
아이디
패스워드
자동로그인 사용
 
아직 회원이 아니십니까?    
아이디/패스워드를 잊으셨습니까?    

   
테스팅 용어 사전 한 번 제대로 봅시다. 일일이 typing한 것임. 효과좋음
글쓴이 : sayhelloyo 날짜 : 10-11-01 16:07 조회 : 148894
결정 테스팅 : 결정 결과값 (decision outcomes)을 이행하도록 테스트 케이스를 설계하는 화이트박스 (white box) 테스트 설계 기법.
결정 테이블 : 테스트 케이스를 설계할 때 사용할 수 있는 입력과 자극(원인)의 조합을 연관된 출력과 활동(결과)과 함께 보여주는 테이블.
결정 테이블 테스팅 : 테스트 케이스가 결정 테이블에 표시된 입력값과 자극(의) 조합을 테스트하도록 설계하는 블랙박스 설계 기법
결함 관리 : 결함을 인지하고 조사하고 행동을 취해 처리하는 절차. 결함을 기록하고 분류하고 영향력을 식별하는 것을 수반하나.
결함 관리 툴(결함 추적 툴) : 결함을 기록하고 결함의 상태 추적을 용이하게 하는 툴 주로 결함의 할당, 정정과 재테스트를 추적하고 제어하는 업무흐름 지향성 기능을 가지고 있으며 리포팅 기능을 제공한다. 인시턴트 관리 툴 참고.
결함 마스킹 : 하나의 결함이 다른 결함의 검출을 방해하는 현상.
결함 밀도 : 식별된 결함 수를 컴포넌트나 시스템의 크기 (e.g. 코드의 라인 수, 클래스의 수 또는 기능 점수로 나눈 값.
결함 발견률 : 테스트 단계에서 발견한 결함의 수를 테스트 단계와 그 이후에 다른 방법으로 발견한 결함을 합산한 수로 나눈 값.
결함 분류 : 컴포넌트나 시스템 결함의 유형별 구분. 다양한 유형으로 구분하며, 각 구분 항목에 대하여 실질적인 결함 세부 항목이 존재한다.
결함 허용성 : 소프트웨어 결함이 있거나 특정 인터페이스가 틀린 경우에도 명시된 성능 수준을 유지하는 소프트웨어 제품의 능력. 오류 허용성.
경계값 분석 : 경계값에 기반하여 테스트케이스를 설계하는 블랙박스 테스트 설계 기법. 즉, 경계값 분석은 등가 분할된 경계의 유효한 값과 경계에서 가장 가까운 유효하지 않은 값을 테스트 데이터로 선택하여 컴포넌트나 시스템을 테스트하는 기법이다. 개발자가 분할된 경걔값을 처리하면서 개발상의 실수 가능성이 높다는 것에 착안하여 테스트 데이터를 선정한다. 결국 경계값 분석은 등가 분할 기법을 확장하여 등가 분할 내에 있는 임의의 값이 아닌 분할된 영역의 경계에 있는 값을 테스트 데이터로 이용하여 보다 많은 결함을 발견하는 테스트 케이스를 작성하는 기법이다.
경계값 커버리지 : (전체 경계값 대비) 테스트 스위트에 의해 이행된 경계값의 비율.
경로 : 시작 시점부터 종료 지점까지 컴포넌트나 시스템 이벤트(예:실행문)의 흐름.
경로 분석 : 컴포넌트나 시스템 내부의 불완전한 경로 또는 경로 내의 실행 불가능한 코드를 찾아내기 위하여 모든 경로를 파악하는 분석 방법.
경로 커버리지 테스트 : 컴포넌트나 시스템에 존재하는 모든 경로를 유한 클래스의 집합으로 구분한 후, 시스템에 내재하는 논리적인 경로를 한 번 이상 수행하여 테스트하는 기법.
경로 테스트 : 경로를 실행하도록 테스트케이스를 설계하는 화이트박스 테스트 설계 기법.
계측 코드 : 컴포넌트나 시스템의 수행을 모니터링 하기 위하여 일시적으로 하드웨어나 프로그램에 삽입하는 장치나 명령어.
계측 코드 삽임 : 프로그램이 실행되는 동안 해당 프로그램의 동작 정보를 수집할 목적으로 해당 프로그램에 추가 코드를 삽입하는 것. 코드 커버리지를 측정할 목적으로 사용하는 경우가 많다.
계측기 : 계측 코드 삽입을 수행하는데 쓰이는 소프트웨어 툴.
공식 리뷰 : 인스펙션과 같이 문서화된 절차와 검토를 위한 요구사항을 갖는 리뷰.
공존성 : 공통 자원을 공유하는 공동의 환경에서 다른 독립적인 소프트웨어와 공존하는 소프트웨어 제품의 능력.
경영층이 직접 또는 대리자를 통해 소프트웨어 획득, 공급, 개발, 운영, 또는 유지보수 프로세스를 체계적으로 평가하는 것. 목적에 부합하도록 하기 위해 진척도를 감시하고 계획과 일정의 상태를 결정하며, 요구사항과 시스템 할당을 확정하거나 관리 접근법의 효과성을 평가하는 활동을 포함한다.
구문 : 프로그래밍 언어에서의 개체. 일반적으로 개별적인 실행 단위 중 가장 작다.
구문 커버리지 : 테스트 스위트에 의해 이행되는 실행문의 백분율.
구문 테스트 : 테스트 케이스가 구분을 이행하도록 설계하는 화이트박스 테스트 설계 기법.
구성 테스팅 : 호환성 테스트라고도 하며 제품이 실행되는 사용자 환경의 다양한 하드웨어와 소프트웨어 환경에서 테스트 대상이 제대로 동작하는가를 검증하는 테스팅. 이식성 테스팅 참고.
구조 기반 테스트 설계 기법 : 소프트웨어 구현정보. 특정 유형의 구조 커버리지를 평가하여 테스팅의 보장성 또는 충분함을 측정하는 것이므로 명세 기반 기법을 적용한 다음에 사용할 때 좋은 결과. .
기능성 : 소프트웨어가 명시된 조건하에서 사용될 때, 명시적이고 암묵적인 요구를 만족하는 기능을 제공하는 소프트웨어 제품의 능력.
기록/재생 툴 : 수동으로 테스팅하는 동안에 입력을 기록하여 나중에 수행될 자동화된 테스트 스크립트를 생성하는 테스트 실행 툴의 한 종류. 이러한 툴은 주로 자동화된 리그레션 테스팅을 지원한다.
기본 블록 : 분기문을 포함하지 않은 하나 이상의 순차적이고 연속된 실행문.
기술적 리뷰 : 선택하고자 하는 기술적 접근법에 대한 합의에 초점을 맞춘 동료 그룹 토의 활동. 기술적 리뷰는 동료 검토로도 알려져 있다.
다중 V-모델 : 임베디드 컴포넌트나 시스템을 위해 기존의 V-모델이 모델, 프로토타입, 최종 제품 각각을 개발하는데 별도로 존재한다고 보고 해당하는 V-모델 세 가지를 연결한 VVV형태의 모델.
다중 조건 테스팅 : (한 개의 구문 내에서) 테스트 케이스가 개별 조건식 결과값의 모든 조합을 수행하도록 설계하는 화이트박스 테스트 설계 기법.
단위 테스팅 : 개개의 소프트웨어 컴포넌트가 정상적으로 기능을 수행하는지의 여부를 테스트하는 하위 레벨 테스트.
대체성 : 동일 목적을 위해 동일 환경에서 다른 명시된 소프트웨어 제품으로 대체하여 사용하는 소프트웨어 제품의 능력.
데이터 주도 테스팅 : 테이블이나 스프레드쉬트에 테스트 입력값과 예상결과를 저장하여 스크립트를 작성하고 테스트하는 기법. 이를 통해 한 개인의 제어 스크립트로 해당 테이블 내에서 모든 테스트를 수행할 수 있다. 데이터 주도 테스팅은 주로 기록/재생 툴 같은 테스트 실행 툴을 활용하도록 지원하는데 쓰인다.키워드 주도 테스팅 참고.
데이터 흐름 테스팅 : 테스트케이스가 변수들의 정의-사용 쌍을 이행하도록 설계하는 화이트박스 테스트 설계 기법.
도달불가 코드 : 도달하지 못하여 실행할 수 없는 코드.
독립성 : 객관적인 테스팅을 하기 위한 책임의 분리.
동료 검토 : 결함과 개선을 식별하기 위하여 개발자의 동료가 소프트웨어 작업산출물을 검토하는 것. 예, 인스펙션, 기술리뷰, 워크스루.
동작 : 입력값과 사전조건의 집합 및 이들간의 조합에 대한 컴포넌트 또는 시스템의 반응. 기능 명세서는 일반적으로 하나 또는 그 이상의 동작들로 이루어져 있다.
동적 분석 툴 : 소프트웨어 코드 상태에 대한 실행 중의 정보를 제공하는 툴. 할당되지 않은 포인터를 식별하고, 포인터 계산을 점검하고, 메모리의 할당, 사용, 그리고 수거를 감시하고, 메모리 누수를 알려주는데 이 툴을 주로 사용한다.
동적 비교 : 소프트웨어가 테스트 실행 툴 등에 의해 실행될 때 실제 결과와 예상 결과를 비교하는 것.
드라이버 : 컴포넌트나 시스템을 제어하거나 호출하는 (실제) 상위 컴포넌트를 대체하는 테스트용의 소프트웨어 컴포넌트 또는 툴
등가 분할 : 명세에 기반하여 볼 때 컴포넌트나 시스템의 동작이 같을 것이라고 추정되는 입력 또는 출력 도메인의 부분.
등가 분할 기법 : 등가 분할된 영역에서 대표값으로 수행하도록 테스트케이스를 설계하는 블랙박스 테스트 설계 기법. 원칙적으로 테스트케이스는 각 영역을 적어도 한번은 커버할 수 있게 설계된다.
디버거 프로그램 : 작성한 프로그램을 실행하면서 결함을 검출하고자 할 때 사용되는 프로그램.
디버깅 툴 : 프로그래머가 장애를 재현하고 프로그램의 상태를 조사하여 대응하는 결함을 찾아내기 위해 사용하는 툴. 디버거는 프로그래머가 프로그램을 단계적으로 실행하고, 특정 프로그램 문장에서 프로그램을 중지하고 프로그램 변수들을 수정하고 검사할 수 있게 해준다.
랜덤 테스팅 : 의사난수 생성 알고리즘을 이용하여 운영 프로파일과 비교하기 위해 테스트 케이스를 선정하는 블랙박스 테스트 설계 기법. 이 기법은 신뢰성과 기능성 같은 비기능성 속성을 테스팅 하는데 사용할 수 있다.
리뷰 툴 : 리뷰 프로세스 지원을 제공하는 툴. 일반적 특징은 계획과 추적, 커뮤니케이션을 지원하고, 공동 리뷰 기능을 제공하고 메트릭의 수집/리포팅을 위한 저장소를 가지고 있다는 것이다.
리뷰어 : 리뷰 대상 제품이나 프로젝트에서 이상현상을 식별하고 기술할 사람. 리뷰 프로세스에서 다른 관점과 역할을 대표하는 사람을 리뷰어로 선출할 수 있다.
리스크 : 미래에 부정적 결과로 끝날 수 있는 요소. 주로 영향력(impact)과 발생가능성(likelihood)으로 표현된다.
리스크를 식별하고 분석하고 우선순위 정하고 제어하는 일에 절차와 프랙티스를 체계적으로 적용하는 것.
리스크 분석 : 리스크의 영향력(impact)과 발생가능성(likelihood)을 측정하기 위해 식별된 리스크를 평가하는 절차
리스크 식별 : 브레인 스토밍, 체크리스크 그리고 장애 이력 관리와 같은 기법을 사용하여 리스크를 식별하는 절차
리스크 제어 : 리스크를 특정 수준으로 줄이거나 해당 수준 내에서 유지하기 위해, 의사결정하고 방어적 수단을 구현하는 절차
테스트 실행 초기 단계에 개발 측에서 테스팅 측이나 이해관계자 측에 전달하는 테스트 항목. 이들의 구성, 현재 상태와 그 밖의 인도 관련 정보를 식별하는 문서.
링크 테스팅 : 컴포넌트 통합 테스팅
마스터 테스트 계획 : 일반적으로 여러 테스트 레벨을 다루는 종합 테스트 계획. 프로젝트 테스트 계획 참고.
마이그레이션 테스팅 : 컨버전 테스팅 참고.
정의된 개발 (중간) 산출물과 결과가 준비되는 프로젝트에서의 어느 한 시점.
맞춤 소프트웨어 : 주문 소프트웨어 참고.
메모리를 사용한 후 메모리 회수에 실패하여 결국 메모리의 부족으로 인해 프로그램에 장애를 발생시키는 프로그램의 동적 할당 로직의 결함.
명세 : 요구사항, 설계, 동작 또는 컴포넌트나 시스템의 다른 특성을 완전하고 정확하며 입증 가능한 방법으로 명세한 문서. 명세에는 종종 명세에서 제공하고 있는 내용의 충족여부를 판단하는 절차가 있다.
명세 기반 테스트 설계 기법 : 컴포넌트나 시스템의 명세 (일반적으로 모델의 형태)를 빠뜨리지 않고 테스트케이스에 반영하고자 하는 테스트 설계 기법의 분류. 블랙박스 테스트 설계 기법.
모델 기반 개발 : 컴포넌트나 시스템을 공식적인 모델로 설계하여 개발하는 방법. 코드는 모델로부터 자동으로 생성된다.
모듈 테스팅 : 컴포넌트 테스팅.
모범 사례 : 주어진 상황에서 조직의 능력 (또는 생산성) 향상에 기여하는 우수한 방법 또는 혁신적인 사례. 주로 다른 관련 조직에서 ‘최고’로 인식된다.
뮤테이션 분석
뮤테이션 테스팅
반복 개발 모델 : 일반적으로 프로젝트가 수 많은 반복으로 분할되는 개발 수명주기. 반복은 그 결과로 실행 가능한 제품 또는 개발 중인 최종 제품의 일부를 (내부 또는 외부로) 릴리즈하는 요구분석, 설계, 개발, 테스팅의 모든 개발 단계를 거치는 완전한 개발 사이클이다.
발견적 접근법 : 테스트를 정해진 절차나 문서화된 절차 또는 테스트 스크립트를 이용하지 않고 시행착오를 통해 축적된 경험적인 지식이나 테스터의 직감을 동원하여 발견적으로 테스트하는 접근법. 이는 테스트 대상 컴포넌트나 시스템을 적절히 테스트할 기법이 존재하지 않거나, 존재하더라도 테스트 수행에 시간이나 비용이 너무 많이 소요되어 현실적으로 사용할 수 없을 때 유용하다. 또한 공식적인 테스팅을 수행한 후, 테스팅 결과에 대한 확신을 얻기 위해 사용할 수 있다.
밸리데이션 : 요구사항이 컴포넌트나 시스템을 특정하게 의도적으로 사용 또는 활용하는 것을 충족시키는지 조사에 의해서나 객관적인 증거 제공용으로 확인하는 것.
버그 정정 : 컴포넌트나 시스템에서 발견된 결함을 정정하기 위해 별도의 수정용 코드를 만들어 본래의 컴포넌트나 시스템을 수정하는 것. 일반적으로 컴포넌트나 시스템이 제한된 시간과 예산 범위에서 출시된 후 나타나는 결함을 해결하기 위해 버그 정정코드를 별도로 제작한다.
배리피케이션 : 명시된 요구사항이 충족되었는지를 조사에 의해서나 객관적인 증거 제공으로 확인하는 것.
베이스라인 : 공식적으로 리뷰 되었거나 합의된 명세 또는 소프트웨어 제품. 이러한 명세나 소프트웨어는 그 후의 추가 개발을 위한 토대로 쓰인다. 그리고 공식적인 변경 제어 프로세스를 통해서만 수정될 수 있다.
컴포넌트나 시스템이 사용자/고객의 요구를 충족하는지 비즈니스 프로세스에 적합한지 등을 결정하기 위해 개발자를 참여시키지 않고, 잠재/기존 고객(사용자)이 외부사이트에서 직접 수행하는 운영상의 테스팅. 베타 테스팅은 주로 상용 소프트웨어가 시장의 피드백을 얻기 위한 목적으로 외부 인수테스트의 한 형태로 수행된다.
벤치마크 테스트 : 측정 또는 비교를 가능하게 하는 기준. 컴포넌트 또는 시스템을 서로 비교하거나 기준과 비교하기 위한 테스트.
변경 제어 : 형상 제어 (configuration control)
변경 제어 위원회 : 형상 제어 위원회
변형 다중 조건 테스팅 : 조건/확정 테스팅.
병렬 테스팅 : 동일 시간 간격 내에서 동시에 실행되거나 교차하여 실행되는 두 가지 이상의 동작 발생을 컴포넌트나 시스템이 어떻게 처리하는지 결정하는 테스팅.
병행 테스팅 : 2개 또는 그 이상의 다양한 컴포넌트나 시스템을 동일한 입력 값으로 실행하는 테스팅. 실행 결과를 비교하여 불일치한 경우 이를 분석한다.
보안성 : 우연이든지 고의적이던지 프로그램과 데이터에 허가되지 않은 접속을 막기 위한 능력과 관련한 소프트웨어 제품의 속성.
보안성 테스팅 툴 : 보안 특성과 취약성 테스팅을 지원하는 툴.
복구 : 어떤 장치의 동작 중 또는 프로그램의 실행 중에 발생한 장애에 대해 적당한 처리를 하여 장애 이전의 상태로 되돌아오게 하는 것. 장애가 발생했을 때 장애 이전의 정확한 상태로 데이터베이스를 복구하는 방법.
복구 처리 : 장애가 발생한 경우에 그 영향을 최소한으로 하고 신속히 복구하기 위한 하드웨어 및 소프트웨어의 각종 기능.
복구성 : 장애발생시 직접적으로 영향을 주는 데이터를 복구하고 명시된 성능 수준을 재설정하는 소프트웨어 제품의 능력
복구성 테스팅
복잡도 : 순환 복잡도.
벅잡도 메트릭 : 컴포넌트나 시스템의 복잡도를 측정하는 측정치. 시스템을 어느 정도의 수준까지 테스트해야 하는지 또는 시스템을 개발하는데 어느 정도의 노력을 소요해야 하는지를 결정하는 근거를 제공한다.
복합 조건 : 둘 이사의 개별 조건이 논리 연산(AND, OR or XOR)에 의해서 조합된 조건.
부하 테스팅 : 부하를 가중시키면서 컴포넌트나 시스템의 동작을 측정하는 것과 관련된 테스트 유형. 동시 사용자의 수 및 트랜잭션의 술 컴포넌트나 시스템이 처리할 수 있는 부하를 결정한다.
분기 : 둘 또는 그 이상의 대안 프로그램 경로가 존재하는 프로그램 구성체인 case, jump, go to , if-then-else 드의 구문을 토대로 실행 시 선택될 수 있는 기본 블록.
분기 조건 조합 커버리지 : 다중 조건 커버리지 참고.
분기 커버리지 : 테스트 스위트에 의해 이행된 분기의 백분율 100%분기 커버리지는 100% 결정 커버리지와 100% 구문 커버리지를 포함한다.
블랙박스 테스트 설계 기법 : 컴포넌트나 시스템의 내부구조 참조 없이 기능적 또는 비기능적 명세 분석을 토대로 하여 테스트케이스를 도출하고 선정하기 위한 절차.
비유효 테스팅
비즈니스 프로세스 기반 테스팅 : 테스트 케이스를 비즈니스 프로세스 상세와 지식에 기반하여 설계하는 테스팅 접근법.
사용성 : 명시된 조건 하에서 사용될 때 사용자에게 이해되고, 학습되고, 사용자에게 매력적일 수 있는 소프트웨어의 능력.
사용자 인터페이스 테스팅 : UI테스팅.
사용자 테스트 : 사용성 테스팅.
사이클로매틱 복잡도 : 프로그램의 독립적인 기본 경로의 수.
사전조건 : 컴포넌트나 시스템이 특정 테스트케이스 또는 테스트절차를 수행하기 전에 반드시 충족되어야 하는 환경 및 상태 조건.
테스트 또는 상세 절차를 실행한 후에 충족되어야 하는 환경 또는 상태 조건.
상용 소프트웨어 : 일반적인 시장, 즉 대규모의 고객을 대상으로 개발되어 동일한 형식으로 많은 고객들에게 전달되는 소프트웨어 제품.
상위 수준 테스트 케이스 : 입력 데이터와 예상 결과에 구체적인(구현 수준의) 값이 없는 테스트 케이스. 논리적 연산자가 사용되는데 여기에서 실제값의 실례는 정의되지 않았거나 가용하지 않다.
상태 전이 테스팅 : 유효하고 비유효한 상태 전이를 수행하도록 테스트케이스를 설계하는 블랙박스 테스트 설계 기법.
하나 또는 여러 개의 명시된 컴포넌트나 시스템이 서로 상호작용하는 소프트웨어 제품의 능력
새너티 테스트, 인테이크 테스트, 스모크 테스트.
서비스 용이성 테스팅 : 컴포넌트 디바이스 시스템이 유지되고 수리되는 용이성을 테스팅하는 절차.
LCSAJ
설계 기반 테스팅 : 컴포넌트나 시스템의 아키텍처 및 상세 설계를 기반으로 테스트 케이스를 설계하는 테스팅 접근법. (예: 컴포넌트 또는 시스템 간의 인터페이스 테스트).
설치 가이드 : 적절한 매체를 통해 설치 순서에 따라 설치자를 안내하기 위해 제공된 지침. 해당 지침은 매뉴얼 가이드, 단계별 절차, 절차 마법사, 또는 다른 유사한 프로세스 설명서 등이 될 수 있다.
설치 마법사 : 어떤 적절한 매체를 통해 제공된 소프트웨어로, 설치 절차에 따라 설치자를 안내한다. 일반적으로 설치 프로세스를 수행하고, 설치 결과에 대해 피드백을 제공하며 옵션을 선택할 수 있는 인터페이스를 제공한다.
설치성 : 명시된 환경에 설치할 수 있는 소프트웨어 제품의 능력.
성능 : 컴포넌트나 시스템이 처리시간과 처리율 등에 대한 제약 범위 내에서 설계된 기능을 완수하는 정도.
성능 지표 : 효과성 또는 효율성을 측정하는 상위 수준의 메트릭. 진보적인 개발활동을 가이드하고 제어하는데 사용되며, 테스팅 성능 지표의 대표적인 사례는 결함 발견율이다.
성능 테스팅 : 소프트웨어 제품의 성능을 측정하기 위한 테스팅 절차. 효율성 테스팅 참고.
성능 테스팅 툴 : 성능 테스팅을 지원하는 툴. 주로 부하 발생과 테스트 트랜잭션 측정이라는 두 가지의 주요기능을 가지고 있다. 부하 발생을 통해 다수의 사용자 또는 많은 양의 입력데이터를 모의 테스트할 수 잇다. 테스팅 수행 중에 선정된 트랜잭션으로부터 응답시간이 측정되고 기록된다. 성능 테스팅 툴은 일반적으로 응답시간에 대한 부하 테스트 로그와 그래프를 기반으로 리포트를 제공한다.
센서 : 환경으로부터 자극을 수신하는데 사용하는 모듈로서, 자극은 (임베디드) 시스템의 입력으로 변환된다.
수평적 추적성 : 단계별 테스트 문서를 통해 특정 테스트 레벨에 대한 요구사항이 테스트되는 것을 추적하는 것. 단계별 테스트 문서는 테스트 계획서, 테스트 설계 명세서, 테스트 케이스 설계 명세서와 테스트 절차 명세서 이다.
스모크 테스트 : 컴포넌트나 시스템의 주요 기능을 다루는 모든 정의된/계획된 테스트 케이스의 부분집합, 이런 주요 테스트로 대부분의 프로그램 핵심 기능이 동작한다는 것을 확인한다. 일일 빌드와 스모크 테스트는 업계 우수 사례(best practices)에 속한다. 인테이크 테스트, 새너티 테스트 참고.
스퀘어 : ISO/IEC 9126과 ISO/IEC 14598을 대체할 목적으로 국제표준화 기구인 ISO/IEC의 JTC1/SC7(소프트웨어 및 시스템공학) 기술위원회에서 추진 중인 표준화 프로젝트 이름.
스크립트 기반 테스팅 : 테스트 스크립트 또는 테스트 케이스를 문서로 작성하여 작성된 문서에 따라 테스트 대상의 기능을 수행하면서 테스트하는 기법.
스크립팅 언어 : 실행 가능한 테스트 스크립트를 작성하는 것을 통해 (기록/재생 툴과 같은) 테스트 실행 툴에 사용되는 프로그래밍 언어.
스텁 : 골격만 있는 또는 특별한 목적의 소프트웨어 컴포넌트를 구현한 것. 스텁을 호출하거나 또는 스텁에 의존적인 컴포넌트를 개발하거나 테스트할 때 사용한다. 스텁은 호출된 컴포넌트를 대체한다.
스트레스 테스팅 : 시스템이나 컴포넌트를 평가하기 위해 시스템이나 컴포넌트의 명시된 요구사항의 한계(버위)를 넘는 부하를 주어 수행하는 테스팅.. 부하 테스팅 참고.
시간 반응성 : 성능 참고.
시나리오 테스트 : 유즈케이스 테스팅 참고.
시뮬레이션 : 하나의 물리적 또는 추상적 시스템의 선택된 동작 특성을 다른 시스템으로 표현하는 것.
시뮬레이터 : 테스팅 중 사용되는 컴퓨터 프로그램 또는 시스템으로, 제어된 입력 집합이 제공될 때 주어진 실제 시스템과 같이 행동하거나 동작한다.
시스템 : 명시된 기능 혹은 기능 집합을 구현하기 위해 구성된 컴포넌트의 모음.
시스템 소프트웨어 : 운영 체계. 컴퓨터 시스템의 각 장치를 통제하여 정상적으로 작동하도록 검사하고 제어하는 등 컴퓨터를 사용하기 위해 기본적으로 필요한 프로그램이다.
시스템 테스팅 : 명시된 요구사항을 만족하는지 확인하기 위해 통합된 시스템을 테스트하는 절차. 컴포넌트나 부분 시스템이 하나의 시스템으로 동작하게 되면서 시스템 기능 및 성능과 관련된 고객의 요구사항이 완벽하게 수행되는지를 모든 시스템 구성요소를 통합한 후 평가하는 테스팅이다.
시스템 통합 테스팅 : 시스템과 패키지의 통합 테스팅. 외부 조직 또는 시스템 (예: EDPS, 인터넷 등) 과의 인터페이스를 테스팅 하는 것.
시작점검 : 테스트 목표가 완전히 수행되어 다음 단계로 시작하는 데 충분한 품질을 가지고 있는지 여부를 점검하는 것.
시작 조건 : 정의된 (다음 단계) 작업의 진행을 허가하는 일반적이고 특정한 조건의 집합. 시작 조건의 목적은 시작 조건을 만족하지 못한 채 테스트 되어 추후에 더 많은 (헛된) 노력이 소요되는 테스크(task)를 시작하지 못하도록 하는 것이다.
시작 지점 : 컴포넌트의 첫 실행문.
신뢰성 : 명시된 시간간격이나 동작 수 등과 같은 정해진 조건하에서 요구 기능을 수행할 수 있는 소프트웨어 제품의 능력.
신텍스 테스팅 : 입력 도메인 및 출력 도메인의 정의를 바탕으로 테스트케이스를 설계하는 블랙박스 테스트 기법.
실패 : 실제 결과가 예상 결과와 비교하여 다를 경우 테스트는 실패라고 간주됨.
실행 가능 경로
실행 불가 경로
실행시간 결함 : 프로그램 실행 중에 나타나 실행에 영향을 미치는 결함. 적절하지 못한 입력 데이터, 0으로 나누기, 배열의 첨자 범위 초과 등으로 인해 프로그램의 실행이 멈춘다.
아크테스팅 : 분기 테스팅 참고.
안전성 : 특정 사용환경에서 사람, 비즈니스 소프트웨어, 재산 또는 환경을 해하는 측면에서 허용될만한 수준의 리스크에 도달하는 소프트웨어 제품의 능력.
알파 테스팅 : 개발조직 외부에 위치한 개발 환경 또는 개발자 사이트에서 잠재적 사용자, 고객 또는 독립된 테스트 팀에 의해 수행되는 가상 혹은 실제 운영상의 테스팅. 알파 테스팅은 내부 인수 테스팅의 한 형태로 상용 소프트웨어 테스팅에 주로 사용된다.
애드혹 리뷰 : 비공식 리뷰 참고.
애자일 테스팅 : XP와 같은 민첩 개발 방법론을 사용하는 프로젝트를 위한 테스팅 방법. 참고로, 민첩 개발 방법론에서는 개발을 테스트의 대상 또는 고객으로 다루고 테스트 우선 설계(test-first-design) 패러다임을 강조한다. 테스트 주도 개발 참고.
애뮬레이터 : 주어진 시스템과 동일한 입력을 받아들이고 동일한 출력을 생성하는 장치나 컴퓨터 프로그램 또는 시스템.
에스유엠아이 : 사용자 만족도와 같은 컴포넌트나 시스템의 사용성을 평가하는 질문서 기반 테스트 기법.
앤-스위치 커버리지 : 특정 테스트 스위트에 의해 이행되는 순차적 N+1(상태) 전이의 백분율.
앤-스위치 테스팅 : 테스트케이스가 모든 유효한 순서의 N+1 전이를 수해하도록 설계하는 상태 전이 테스팅의 한 형태. 상태 전이 테스팅 참고.
역량 성숙도 모델 : 효과적인 소프트웨어 프로세스의 핵심 요소를 기술하는 다섯 단계 기반의 프레임워크 소프트웨어 개발 및 유지보수를 계획, 설계 및 처리, 관리하기 위한 모범사례를 포함한다.
역량 성숙도 모델 통합 : 효과적인 제품개발 및 유지보수 프로세스의 핵심요소를 기술하는 프레임워크. 역량 성숙도 모델 통합은 제품 개발과 유지보수를 계획, 설계 및 처리, 관리하기 위한 모범사례를 포함한다.
영향도 분석 : 명시된 요구사항에 대한 변경을 구현하기 위해 각 단계별 개발문서, 테스트 문서, 컴포넌트에 대한 변경을 평가하는 것.
예외 처리 : 사용자 또는 다른 컴포넌트나 시스템으로부터의 잘못된 입력이나 내부적인 장애에 대응하는 컴포넌트나 시스템의 동작.
완료 조건 : 절차가 공식적으로 완료되었음을 허가할 목적으로 이해관계자들이 합의한 일반적이고 특별한 조건의 집합. 완료조건의 목적은 아직 종료하지 못한 미해결의 일부 업무가 여전히 존재 함에도 완료한 것으로 간주하려는 것을 방지하는 것이다. 완료조건은 언제 테스팅을 중지할 것인지에 대해 보고하고 계획하기 위해 사용된다.
요구사항 관리 툴 : 요구사항 자체는 물론 요구 사항 속성과 주석의 기록을 지원하고 요구사항 변경 관리 단계에 걸쳐 추적성을 용이하게 하는 툴. 어떤 요구 사항 관련 툴은 일관성 점검과 미리 정의된 요구사항의 규칙위반과 같은 정적 분석을 위한 기능도 제공한다.
요구사항 기반 테스팅 : 요구사항에서 도출한 테스트 목적과 테스트 상황에 기반하여 테스트케이스를 설계하는 테스트 접근법. 예를 들어, 특정 기능을 이행하는 또는 신뢰성이나 사용성 같은 비기능적 속성을 조사하는 것을 통해 테스트케이스를 도출할 수 있다.
우선순위 : 결함과 같은 항목에 부여된 (비즈니스) 중요도.
운영 프로파일 테스팅 : 시스템 동작 모델과 전형적으로 사용되는 확률(패턴)을 이용하여 수행하는 통계적 테스팅. 통계적 테스팅, 통계적 사용 기반 테스팅 참고.
운영 환경 : 테스트 대상 컴포넌트나 시스템이 실제 사용될 사용자나 고객 사이트에 설치되어 있는 하드웨어 또는 소프트웨어 제품. 소프트웨어는 운영체제, DBMS, 그리고 다른 어플리케이션을 포함할 수 있다.
운용성 : 사용자가 어플리케이션을 작동하고 제어할 수 있게 하는 소프트웨어 제품의 능력. 사용성 참고.
원인-결과 그래프 : 입력과 자극(원인)을 연관된 출력(결과)과 함께 시각적으로 표현한 것. 테스트 케이스 설계 시 사용되며 테스트 케이스의 완벽성과 모호성을 체크하는데 도움이 된다.
유즈케이스 테스팅 : 사용자 시나리오를 실행하도록 테스트케이스를 설계하는 블랙박스 테스트 설계 기법.
유지 보수 : 결함을 정정하고, 성능이나 다른 품질 속성을 향상시키기 위하여 또는 변경된 환경에 적용시키기 위해서 출시된 다음에 진행하는 소프트웨어 제품의 변경.
유지보수성 : 소프트웨어 제품이 결함을 정정하고 새로운 요구를 만족시키기 위해 수정될 수 있고, 추후 보다 쉬운 유지보수를 위하여 수정될 수 있거나 또는 변경된 환경에 적용할 수 잇는 용이성.
유한 상태 머신 : 수반하는 액션이 있을 수 있는 유한 수의 상태와 상태간의 전이로 구성된 계산적인 모델.
의사 난수 : 무작위로 나타나는 연속물. 그러나 사실은 예정된 순서에 따라 생성된 것이다.
이상현상 : 요구명세, 설계문서, 사용자 문서, 표준 등에 근거한 기대값에서 벗어나거나,어떤 사람의 직관 또는 경험에서 벗어난 모든 상태. 이상현상은 소프트웨어 제품이나 참조 문서의 리뷰, 테스팅, 분석, 편집, 사용 중에 발견될 수 있다. 물론, 이상현상이 발견되는 것은 위의 상황에만 제한된 것은 아니다. 결함, 편차, 오류, 결점, 장애, 인시던트, 문제 참고.
이식성 : 소프트웨어 제품이 다른 하드웨어나 소프트웨어 환경으로 전이될 수 있는 용이성.
이해가능성 : 소프트웨어가 적합한지 그리고 특정작업과 사용
인수 조건 : 사용자, 고객 또는 다른 인가된 개체에 의해 인수 되어지기 위해 컴포넌트 또는
시스템이 만족시켜야 하는 완료조건.
인수 테스팅 : 시스템이 인수조건을 만족시키는지 사용자, 고객 또는 다른 인가된 개체가 시스템을 인수할지 결정할 수 있도록 사용자의 필요, 요구, 그리고 비즈니스 프로세스를 고려하여 수행하는 공식적인 테스팅. 즉, 계약상의 요구 사항이 만족되었는지 확인하기 위해, 설치 후, 구입자 운영 환경에서 납품자도 참가하여 구입자에 의해 실시되는 시스템 또는 기능 단위의 공식적인 테스팅이다. 이 결과를 기초로 고객(구입자)이 개발된 시스템을 인수할 것인지 결정한다.
인스팩션 : 개발 표준 위반과 상위 레벨 개발 문서와의 불일치 등과 같은 결함을 발견하기 위해 문서를 눈으로 검사하는 리뷰의 한 종류 가장 공식적인 리뷰 기법.
인시던트 : 테스팅 중 발생하여 조사가 요구되는 모든 이벤트.
인시던트 관리 툴 : 테스트 중 발견한 인시던트를 기록하고 상태 추적을 용이하게 하는 툴. 주로 인시던트의 할당, 수정과 재테스트를 추적하고 제어하는 업무흐름 지향성 기능을 가지고 있으며 리포팅 기능을 제공한다.
인테이크 테스트 : 컴포넌트나 시스템이 세분화되고 심도 깊은 테스팅을 수행할 준비가 되었는지를 결정하기 위한 스모크 테스트의 특별한 사례. 인테이크 테스트는 대체로 테스트 수행 단계의 시작시점에서 수행한다.
일별 빌드 : 일관성 있는 시스템이 가장 최근의 수정을 모두 반영하여 언제라도 이용가능 하도록, 매일(보통 밤에) 변경이 마감된 시스템을 컴파일하고 링크하는 개발 활동.
임베디드 소프트웨어 : 시스템의 특정 하드웨어 제어를 목적으로 개발된 임베디드 시스템 내의 소프트웨어.
임베디드 시스템 : 엑터와 센서를 이용하여 실제 물리적 세계와 상호작용 하는 시스템.
입력 도메인 : 선택할 수 있는 유효한 입력값의 집합. 도메인 참고.
장애 모드 : 장애의 물리적 또는 기능적인 표현. 정애 모드에 있는 시스템의 특성은 느린 작업, 부정확한 결과값, 완전 실행 종료 등이다.
재개 조건 : 정지 후 테스팅이 다시 시작될 때 반드시 반복되어야 하는 테스팅 활동.
재테스팅 : 수정 활동이 성공적이었는지를 검증하기 위해, 마지막으로 실행했을 때 실패되었던 테스트케이스를 다시 실행하는 테스팅.
적응성 : 다른 특정 환경에 적응하기 위한 목적으로 해당 소프트웨어 자체에 구현하고 있는 동작 또는 수단만을 활용하여 해당 환경에 적응할 수 있는 소프트웨어 제품의 능력.
점증적 개발 모델 : 전반적인 프로젝트 요구사항을 리스크에 따라 우선순위를 정하여 ‘증분’으로 나누고, 이를 점진적으로 개발하여 순차적으로 기능의 일부를 릴리즈하는 개발 수명주기 모델. 요구사항의 우선순위 순서에 따라 적절한 크기의 기능(증분)을 릴리즈한다. 이와 같은 수명주기 모델 중 특정 유형에서는 각각의 서브 프로젝트가 설계, 코딩, 테스팅 단계를 갖는 ‘미니 ‘V-모델’에 따른다.
점증적 테스팅 : 모든 컴포넌트나 시스템이 통합되고 테스트될 때까지 한번에 하나 또는 몇 개의 컴포넌트나 시스템이 점진적으로 통합되고 테스트되는 테스팅.
접근성 테스팅 : 신체적 장애를 가진 사용자가 컴포넌트나 시스템을 쉽게 사용하는지 평가하는 테스팅.
정적 분석 : 요구사항이나 코드와 같은 소프트웨어 산출물을 실행하지 않고 분석하는 것.
정적 코드 분석
정적 코드 분석기 : 정적 코드 분석을 수행하는 툴. 이 툴은 코딩 표준, 품질 메트릭 또는 데이터 흐름 이상현상에 적합한지와 같은 특정 속성을 분석하기 위해 소스 코드를 점검한다.
정적 테스팅 : 리뷰 또는 정적 코드 분석
정확성 : 요구되는 정밀도로 정확하거나 합의된 결과 또는 효과를 제공하기 위한 소프트웨어 제품의 능력. 기능성 테스팅 참고.
주문 소프트웨어 : 정해진 사용자 또는 고객 대상으로 특수하게 맞춰 개발된 소프트웨어. 이와 반대되는 의미를 갖는 용어는 상용 소프트웨어 이다.
중단조건 : 테스트를(일시적으로) 모두 정지하거나 일부를 정지하기 위해 사용되는 조건.
체크리스트 : 테스트하기 위한 항목을 통과/실패 또는 예/아니오로 답할 수 있게 나열한 목록.
출력 : 컴포넌트가 작성(생성)하는 변수. 컴포넌트 내부에 또는 외부에 저장된다.
측정 : 개체(실체)의 속성을 기술하기 위해 해당 개체에 수치 또는 카테고리를 할당하는 절차.
친밀성 : 사용자에게 매력적일 수 있는 소프트웨어 제품의 능력.
침투 테스트 : 정보시스템에 취약성이 존재하여 실제로 악용될 수 있는지를 확인하기 위해 테스트 엔지니어 또는 평가자가 직접 침투를 실시하는 테스팅. 컴포넌트나 시스템의 정보보호 기능의 취약점을 찾아내기 위하여 시도하는 테스팅.
커버리지 분석 : 테스트 수행 중 미리 정해놓은 기준을 참고하여 추가 테스트가 필요한지, 만약 그렇다면 어던 테스트케이스가 필요한지를 결정하기 위해 명세된 커버리지 항목 대비 달성된 커버리지를 측정하는 분석.
커버리지 툴 : 어떤 구조적 요소(예: 구문, 분기문) 가 테스트 스위트에 의해 이행되었는지에 대한 객관적인 측정치를 제공하는 툴.
커버리지 항목 : 테스트 커버리지의 토대로 사용되는 개체 또는 특성. 예, 동등분할 또는 코드 구분.
커서리 테스팅 : 개발자가 테스팅의 주체가 되어 테스트케이스 없이 주요한 단위 모듈이나 시스템 모듈을 즉층적으로 테스팅하는 기법. 세너티 테스팅 이전에 실시한다. 스모크 테스팅, 새너티 테스팅과는 테스트 수행 주체, 대상, 방법, 시기 등에서 차이를 보인다.
컨버전 테스팅 : 대체되는 시스템에서 사용하기 위해 기존 시스템의 데이터를 변환하는 것과 관련된 테스팅.
컴파일러 : 고급언어로 표현된 프로그램을 해당 기계어로 번역하는 소프트웨어 툴.
컴포넌트 : 덕립적으로 테스트될 수 있는 최소 소프트웨어 항목.
컴포넌트 통합 테스팅 : 통합된 컴포넌트 간의 인터페이스와 상호작용에서 결함을 찾아내기 위해 수행하는 테스트.
컴포넌트 상세 : 특정한 조건하에서 특정 입력값에 대한 툴력값의 관점에서 컴포넌트 기능을 기술하고, 자원 효율성과 같은 요구되는 비기능적 동작을 기술한 것.
컴포넌트 테스팅 : 개별적인 소프트웨어 컴포넌트에 대한 테스트. 단위 테스팅.
코드 커버리지 : 테스트 스위트로 소프트웨어의 어떤 부분이 실행되었고(커버되었고) 어떤 부분이 실행되지 않았는지 결정하는 분석기법. 예) 구문 커버리지, 결정 커버리지, 조건 커버리지 등.
키워드 주도 테스팅 : 테스트 데이터와 예상 결과뿐만 아니라 테스트 대상 어플리케이션과 관련된 키워드를 포함한 데이터 파일을 사용하는 스크립트 기법. 제어 스크립트가 테스트하기 위한 목적으로 호출한 특별 지원 스크립트로 키워드를 해석한다. 데이터 주도 테스팅.
탐사 효과 : 성능 테스팅 툴 또는 모니터링 툴로 컴포넌트나 시스템을 측정(테스팅)하고 있을 때 측정 계측 코드가 컴포넌트나 시스템에 미치는 영향. 예를 들면 성능 테스팅 툴이 사용될 때 성능이 약간 영향을 받을 수 있다.
탐색적 테스팅 : 테스터가 테스트를 수행하면서 테스트 설계를 능동적으로 제어하고 새롭고 보다 나은 테스트를 설계하기 위해, 테스트를 수행하는 동안 얻은 정보를 활용하는 비공식적인 테스트 설계 기법
테스터 : 컴포넌트나 시스템의 테스트에 참여하는 테스팅 관련 기술 측면에서 숙련된 전문가.
테스트 가능한 요구사항 : 요구사항이 충족되었는지를 결정하기 위해 테스트를 설계하고 테스트를 실행할 수 있게 하는 용어로 요구사항이 정의한 정도(또는 그런 용어로 정의된 요구사항).
테스트 관리 : 일반적으로 테스트 매니저에 의해 실시되는 테스트 활동의 계획, 추정, 모니터링과 제어.
테스트 관리 툴 : 테스트 프로세스의 테스트 관리와 제어 부분을 지원하는 툴. 테스트 관리 툴은 테스트웨어 관리, 테스트 스케줄링, 결과 로깅, 진척도 추적, 인시던트 관리, 그리고 테스트 리포팅을 지원하는 여러가지 기능이 있다.
테스트 기반구조 : 테스트를 수행하기 위해 필요한 조직 차원의 구성체. 테스트 환경, 테스트 툴, 오피스 환경과 절차로 구성되어 있다.
테스트 깊이 수준 : 연속적인 결정 포인트 간 종속성이 테스트되는 정도.
테스트 단계 : 특정 테스트 레벨에서의 테스트 계획 활동이나 실행 활동과 같이 프로젝트에서 관리 가능하도록 특정한 단계로 분리하여 관련 활동을 모아 놓은 (테스트를 수행하는 절차 단계별로 구별되는)테스트 활동의 집합.
테스트 단위 : 집합적으로 테스트 되는 프로세스. 트랜잭션 그리고 기능의 집합.
테스트 데이터 준비 툴 : 테스팅에서 사용하기 위해 데이터베이스에서 데이터를 선정하거나, 데이터를 생성하고, 산출하고, 조작하고, 수정하는 테스트 툴의 한 유형.
테스트 드라이버 : 컴포넌트나 시스템을 제어하거나 호출하는 컴포넌트를 대체하는 소프트웨어 컴포넌트 또는 테스트 툴.
테스트 라이브러리 : 시스템의 동작을 진단하기 위한 프로그램이나 루틴 또는 기타 데이터의 집합을 포함하는 라이브러리. 실환경 라이브러리와 대칭되는 용어다.
테스트 레벨 : 함께 편성되고 관리되는 테스트 활동의 그룹. 테스트 레벨은 프로젝트에서 책임과 연관이 있다. 테스트 레벨의 예로는 컴포넌트 테스트, 통합 테스트, 시스템 테스트 그리고 인수 테스트가 있다.
테스트 명세 : 테스트 설계 명세, 테스트케이스 명세 및 테스트 절차 명세로 구분된 문서.
테스트 베이시스 : 요구사항을 내포하고 있는 모든 문서. 테스트케이스는 테스트 베이시스를 토대로 만들어 진다. 문서가 오직 공식적 수행절차의 방법에 의해 수정될 수 있다면, 해당 테스트 베이시스를 동결 테스트 베이시스라 부른다.
테스트 상황 : 하나 또는 그 이상의 테스트케이스에 의해 검증될 수 있는 컴포넌트나 시스템의 항목 또는 이벤트. 테스트 상황의 예는 기능, 트랜잭션, 품질 속성, 또는 구조적 요소 등이다.
테스트 수명주기 : 컴포넌트나 시스템의 테스팅을 위한 계획을 세우고 분석/설계하고 구현하여 이를 실행하고 최종적으로 테스트 실행 결과를 평가하고 제어하는 일련의 과정.
테스트 스위트 : 테스트 대상 컴포넌트나 시스템에 사용되는 여러 테스트케이스의 집합. 테스트 스위트는 테스트 사후조건이 주로 다음 테스트를 위한 사전조건이 되는 테스트케이스로 구성된다.
테스트 실행, 테스트 수행 : 테스트 대상 컴포넌트나 시스템에 대해 테스트를 수행하여 실제 결과를 생성하는 절차.
테스트 오라클 : 테스트 대상 소프트웨어의 실제 결과와 비교할 목적으로 예상 결과를 결정하는 근거. 테스트 오라클은(벤치마크를 위한) 기존 시스템, 사용자매뉴얼, 또는 개인의 전문 지식일 수 있으나 코드가 될 수는 없다.
테스트 용이성 검토 : 테스트 베이시스가 테스트 프로세스의 입력 문서가 되기에 충분한 품질 수준인지를 결정하기 위해 테스트 베이시스를 상세하게 점검하는 것.
테스트 유형 : 하나 이상의 상호 연관된 품질속성에 대해 컴포넌트나 시스템을 테스팅하고자 목표하는 테스트 활동 묶음. 테스트 유형은 신뢰성 테스트, 사용성 테스트, 회귀 테스트 등과 가은 특정 테스트 목표에 집중한다. 그리고 테스트 유형은 하나 이상의 테스트 레벨 또는 테스트 단계에서 발생할 수 있다.
테스트 자동화 : 테스트 활동을 수행하거나 지원하는 소프트웨어 툴의 사용하여 테스팅 하는 것. 테스트 자동화는 테스트 관리, 테스트 설계, 테스트 실행과 결과 점검과 같은 테스트 활동을 수행하고 지원한다.
테스트 주도 개발 : 테스트케이스를 실행하기 위한 소프트웨어가 개발되기 전에, 테스트케이스를 먼저 개발하고 주로 자동 실행되도록 한 후, 해당 테스트를 통과하도록 소프트웨어를 개발하는 방법.
테스트 케이스 : 특별한 목표 또는 테스트 상황을 테스트하기 위해 개발된 입력값, 실행 사전조건, 예상 결과, 실행 사후조건 들의 집합. 특별한 목표와 테스트 상황은 특정 프로그램 경로를 실행하거나 지정된 요구사항을 준수하는지 검증하는 것을 의미한다.
테스트 평가 보고서 : 모든 테스트 활동과 결과를 요약한 테스트 프로세스의 마지막 단계에서 생성된 문서. 테스트 평가 보고서는 테스트 프로세스의 평가와 해당 테스트 활동을 통해 배운 교훈도 담고 있다.
테스트 프로세스 : 기본적인 테스트 프로세스는 테스트 기획, 명세, 실행, 기록 그리고 완료 여부의 점검으로 구성된다.
테스트 프로세스 개선 : 테스트 프로세스의 개선을 위한 연속적인 프레임워크. TPI는 효과적인 테스트 프로세스의 핵심 요소를 기술하고 있으며, 특별히 시스템 테스팅과 인수테스팅에 초점이 맞춰져 있다.
테스트 하네스 : 테스트를 수행하기 위해 필요한 스텁과 드라이버로 구성된 테스트 환경.
테스트웨어 : 테스트를 계획, 설계, 실행하는 테스트 프로세스 동안 생성된 산출물. 테스트웨어는 테스팅에 사용되는 문서, 스크립트, 입력값, 예상결과, 시작과 마무리 절차, 파일, 데이터베이스, 환경, 그리고 모든 추가적인 소프트웨어 또는 유틸리티를 포함한다.
테스팅 : 소프트웨어 제품과 관련 작업 산출물이 특정 요구명세를 만족하는지 결정하고, 목적에 부합하는지 입증하고 결함을 찾아내기 위해 해당 산출물을 계획, 준비, 평가하는 정적/동적인 모든 수명주기 활동으로 구성된 프로세스.
통합 테스팅 : 통합된 컴포넌트나 시스템 간의 인터페이스와 상호작용에서의 결함을 중점적으로 찾는 테스팅
플랜트 : 임베디드 시스템과 상호작용하는 환경.
하이브리드 테스팅 : 통합할 컴포넌트의 우선순위와 준비 스케줄을 고려하여 상향식 테스트와 하향식 테스트를 혼합한 통합 테스팅 방법.
하향식 테스팅 : 하위 수준의 컴포넌트를 스텁으로 대체하면서 가장 상위 수준의 컴포넌트를 먼저 테스트하는 통합 테스팅을 점증적으로 접근하는 방법. 테스트된 컴포넌트는 하위 수준의 컴포넌트를 테스트하는데 사용된다. 가장 하위 레벨의 컴포넌트를 테스트 할 때까지 해당 절차가 반복된다. 상향식 테스팅 참고.
현장 인수 테스팅 : 컴포넌트나 시스템이 사용자/고객의 요구를 만족시키는지 비즈니스 프로세스에 적합한지를 결정하기 위해 사용자/고객의 장소에서 하는 인수 테스팅. 일반적으로 소프트웨어 뿐만 아니라 하드웨어도 포함된다.
현장 테스팅 : 베타 테스팅 참고.
 


출처 : 테스팅 정보의 생산, 유통, 소비
http://www.sten.or.kr/club/club_main.php?cb_id=cb_darwin