실라버스 제 2 장. 소프트웨어 개발 수명주기와 테스팅

2.1 소프트웨어 개발 수명주기 모델

 

2.1.1 소프트웨어 개발과 소프트웨어 테스팅 (K2)

 

* 모든 SW 개발 수명주기 모델에 적용하기 좋은 테스팅의 특성
　① 모든 개발 활동은 그에 상응하는 테스트 활동이 있음
　② 각 테스트 레벨은 그 레벨에 맞는 구체적인 목적을 가짐
　③ 주어진 테스트 레벨에 맞는 테스트 분석과 설계는 상응하는 개발 활동이 이루어지고 있는 동안 시작해야 함
　④ 테스터가 요구사항과 설계의 정의와 개선을 위한 대화에 참여하고,

　　작업 산출물(예 : 요구사항, 설계, 사용자 스토리 등)의 초안이 나오는 즉시 리뷰에 참여함

 

* 테스트 활동은 수명주기 초반에 시작해야 함

(테스팅 원리 3 : 어떤 SW 개발 수명주기 모델을 선택하더라도 테스팅을 초기에 시작하면 시간과 비용을 절약할 수 있음)

 

* 대표적인 SW 개발 수명주기 모델
　- 순차적(sequential) 개발 모델
　- 반복적 점진적(iterative and incremental) 개발 모델

 

2.1.2 정황에 따른 소프트웨어 개발 수명주기 모델 (K1)

 

* SW 개발 모델이 프로젝트 및 제품 특성의 맥락에 맞게 조정되어야 하는 이유
　① 시스템의 제품 리스크의 차이 (복잡하거나 간단한 프로젝트)
　② 많은 사업부가 프로젝트나 프로그램의 일부일 수 있음 (순차적 및 애자일 개발의 조합)
　③ 제품의 짧은 출시 기간 (테스트 레벨에서 테스트 유형의 통합 및 테스트 레벨 병합)

 

2.2 테스트 레벨 (K2)

	테스트 레벨
	컴포넌트 테스팅 (= 단위 or 모듈)	통합 테스팅	시스템 테스팅	인수 테스팅
포커스	- 개별적으로 테스트할 수 있는 컴포넌트에 초점을 맞춤	- 컴포넌트 or 시스템 간의 상호작용에 초점을 맞춤	- 전체 시스템 or 제품의 동작이나 능력에 관심을 가짐 - 시스템이 수행할 엔드-투-엔드 작업과 작업을 수행할 때 나타나는 非기능 동작을 고려하는 경우가 많음	- 전체 시스템 or 제품의 동작이나 능력에 초점
목적	① 리스크 완화 ② 컴포넌트의 기능, 非기능 동작이 설계 및 명세와 일치하는지 여부 판단 ③ 컴포넌트 품질 수준에 대한 자신감 획득 ④ 컴포넌트에 존재하는 결함 발견 ⑤ 다음 단계로의 결함 전이 방지	① 리스크 완화 ② 인터페이스의 기능, 非기능 동작이 설계 및 명세와 일치하는지 여부 판단 ③ 인터페이스 품질 수준에 대한 자신감 획득 ④ 결함 발견 (결함은 인터페이스 자체 or 컴포넌트나 시스템에 존재할 수 있음) ⑤ 다음 단계로의 결함 전이 방지	① 리스크 완화 ② 시스템의 기능, 非기능 동작이 설계 및 명시된 대로 이루어지는지 검증 ③ 완성된 시스템이 기대한 대로 동작하는지 확인 ④ 전체 시스템 품질에 대한 자신감 획득 ⑤ 결함 발견 ⑥ 결함이 상위 테스트 레벨이나 생산 단계로의 전이 방지	① 전체 시스템의 품질에 대한 자신감 획득 ② 완성된 시스템이 기대한 대로 동작하는지 확인 ③ 시스템의 기능/非기능 동작이 명세대로 동작하는지 검증
테스트 베이시스	① 상세 설계 ② 코드 ③ 데이터 모델 ④ 컴포넌트 명세	① SW 및 시스템 설계 ② 시퀀스 다이어그램 ③ 인터페이스 및 통신 프로토콜 명세 ④ 유스케이스 ⑤ 컴포넌트나 시스템 레벨의 아키텍처 ⑥ 워크플로우 ⑦ 외부 인터페이스 정의서	① 시스템 및 SW 요구사항 명세 (기능/非기능) ② 리스크 분석 보고서 ③ 유스케이스 ④ 에픽(epic), 사용자 스토리 ⑤ 시스템 동작 모델 ⑥ 상태 다이어그램 ⑦ 시스템, 사용자 매뉴얼	① 비즈니스 프로세스 ② 사용자 or 비즈니스 요구사항 ③ 규제, 법적 계약, 표준 ④유스케이스, 사용자 스토리  ⑤ 시스템 요구사항 ⑥ 시스템 or 사용자 문서 ⑦ 설치 절차 ⑧ 리스크 분석 보고서
테스트 대상	① 컴포넌트, 단위, 모듈 ② 코드 및 데이터 구조 ③ 클래스 ④ DB 모듈	① 서브시스템 ② 데이터베이스 ③ 인프라 ④ 인터페이스 ⑤ APIs ⑥ 마이크로서비스	① 애플리케이션 ② HW/SW 시스템 ③ 운영 시스템 ④ 테스트 대상 시스템 (SUT, System Under Test) ⑤ 시스템 설정과 설정 데이터	① 테스트 대상 시스템 ② 시스템 설정과 설정 데이터 ③ 완전히 통합된 시스템의 비즈니스 프로세스 ④ 복원 시스템이나 비즈니스 연속성 및 긴급 복구 테스팅을 위한 핫 사이트 (hot site) ⑤ 운영 및 유지보수 프로세스 ⑥ 양식 ⑦ 보고서 ⑧ 기존 및 전환된 생산 데이터
결함, 장애	- 발견하는 즉시 수정 - 공식적인 결함 관리 프로세스 없이 이루어지는 경우가 많음 - 개발자가 결함에 대해 보고하는 경우, 근본 원인 분석 및 프로세스 개선에 활용할 수 있는 중요한 정보를 제공	1. 컴포넌트 통합 테스팅 2. 시스템 통합 테스팅	① 잘못된 연산 ② 시스템의 잘못 or 예상치 못한 기능/非기능 동작 ③ 시스템 내 잘못된 제어 및 데이터 프름 ④ 엔드-투-엔드 기능 작업 수행 실패 ⑤ 시스템 환경에서 시스템의 정상 동작 실패 ⑥ 시스템 및 사용자 매뉴얼대로의 시스템 동작 실패	① 비즈니스 or 사용자 요구사항을 충족하지 못하는 시스템 워크플로우 ② 잘못 구현된 비즈니스 규칙 ③ 계약 or 규제 요구사항을 충족하지 못하는 시스템 ④ 보안 취약성, 많은 부하가 걸렸을 때 성능 효율성 저하, 非기능 장애( 지원 대상 플랫폼상에서의 잘못된 운영 등)
접근법, 책임

 

* 인수 테스팅의 대표적인 형태

	사용자 인수 테스팅	운영 인수 테스팅	계약 및 규제 인수 테스팅	알파 및 베타 테스팅
정의	- 실제 or 시뮬레이션 된 운영 환경에서 예정된 사용자가 사용하기에 얼마나 적합한지 확인하는 데 관심	- 운영자 or 시스템 관리 직원에 의해 수행 - 시뮬레이션 된 생산 환경에서 이루어지는 경우가 많음 - 테스트는 운영 측면에 집중  - 포함하는 테스팅 　① 백업 및 복원 테스팅 　② 설치, 삭제, 업그레이드 　③ 긴급 복구 　④ 사용자 관리 　⑤ 유지보수 작업 　⑥ 데이터 로딩 및 이관 작업 　⑦ 보안 취약점 확인 　⑧ 성능 테스팅	1. 계약 인수 테스팅 　- 주문 개발 SW의 생산을 위한 계약서에 명시된 인수 조건을 가지고 수행 　- 인수 조건은 모든 계약 당사자가 계약에 동의할 때 정의 　- 사용자 or 독립적인 테스터가 수행하는 경우가 많음 2. 규제 인수 테스팅 　- 준수해야 하는 모든 규제(정부, 법적, 안전 규제 등)를 가지고 수행 　- 독립적인 테스터가 수행하는 경우가 많음 　- 규제 기관이 결과에 대한 실사나 감사를 진행하기도 함	1. 알파 테스팅 　- 개발 조직의 현장에서 신규 or 기존 고객이나 운영자, 독립적 테스트팀이 수행 2. 베타 테스팅 　- 알파 테스팅 후에 진행 or 사전 알파 테스팅 없이 수행할 수도 있음
목적	- 사용자들의 필요에 따라 요구사항을 충족하면서 최소한의 어려움, 비용, 리스크 등으로 비즈니스 프로세스를 수행할 수 있다는 자신감을 획득	- 운영자 or 시스템 관리자가 사용자를 위해 시스템을 정상적으로 유지할 수 있다는 자신감을 획득	- 계약 or 규제 준수에 대한 자신감을 획득	- 신규 or 기존 고객이나 운영자가 시스템을 일반적인 조건과 운영 환경에서 사용해 자신의 목적을 최소한의 어려움, 비용, 리스크 등으로 완수할 수 있다는 자신감을 획득 - 시스템을 사용할 조건 및 환경과 관련된 결함의 발견(조건, 환경을 개발팀에서 동일하게 연출하기 어려운 경우)

 

2.3 테스트 유형

 

* 테스트 유형
　- 특정 테스트 목적을 위해 SW 시스템이나 시스템의 일부 특정 속성을 테스트하는 활동의 집합
　- 목적
　　① 기능 품질 특성(완전성, 정확성, 적합성 등) 평가
　　② 非기능 품질 특성(신뢰성, 성능 효율성, 보안성, 호환성, 사용성 등) 평가
　　③ 컴포넌트나 시스템의 아키텍처 및 구조가 정확하고 완전하며 명시된 것과 일치하는지 평가
　　④ 수정의 효과 평가
　　(예 : 결함이 수정됐는지 확인(확인 테스팅),
　　　　SW나 환경의 변화로 인해 동작에 의도하지 않은 변화가 없는지(리그레션 테스팅))

 

2.3.1 기능 테스팅 (K2)

 

* 기능 시스템
　- 시스템이 수행해야 하는 기능을 평가하기 위한 테스트를 포함
　- 일반적으로 기능 요구사항 :
　　작업 산출물(비즈니스 요구사항 명세, 에픽(epic), 사용자 스토리, 유스케이스, 기능 명세 등)에 설명되어 있지만,
　　문서로 기록되지 않는 경우도 존재함 

　- 기능 : 시스템이 해야 하는 그 "무엇"
　- 모든 테스트 레벨(컴포넌트, 통합, 시스템, 인수 테스팅)에서 수행할 수 있음
　- SW 동작을 보기 때문에 컴포넌트나 시스템의 기능에 대한 테스트 컨디션과 TC 도출을 위해
　블랙박스 기법을 활용할 수 있음 (4.2절)
　- 기능 커버리지를 통해 얼마나 철저하게 수행됐는지 측정할 수 있음
　　: 어떤 기능이 테스트에 의해 어느 정도 실행됐는지, 커버되고 있는 요소 유형에 대해 백분율로 표기됨
　　(예 : 테스트와 기능 요구사항 간의 추적성을 사용해 이런 요구사항 중 테스팅이나 비율을 계산할 수 있고, 
　　결국 커버리지 어디에 빈틈이 있는지 식별할 수 있음)

 

2.3.2 비기능 테스팅 (K1)

* 非기능 테스팅
　- 시스템의 특성(사용성, 성능 효율성, 보안성)을 평가

　- 시스템이 "얼마나 잘" 동작하는지에 대한 테스팅 
　- 모든 테스트 레벨 (컴포넌트, 통합, 시스템, 인수 테스팅)에서 수행할 수 있음
　- 가능한 초반에 수행하는 것이 좋음
　- 테스트 컨디션과 TC를 도출하기 위해 블랙박스 기법 (4.2절) 사용
　　(예 : 성능 테스트를 위한 스트레스(stress) 조건을 정의하는 데 경계값 분석을 활용할 수 있음)
　- 非기능 커버리지를 통해 얼마나 철저하게 수행됐는지 측정할 수 있음

　　: 특정 非기능 요소가 테스트로 어느 정도 실행됐는지, 커버되고 있는 요소 유형에 대해 백분율로 표기됨
　　(예 : 테스트와 지원 기기 간의 추적성을 사용해 이런 기기 중 호환성 테스팅으로 커버된 비율을 계산,
　　결국 커버리지 어디에 빈틈이 있는지 식별할 수 있음)

 

2.3.3 화이트박스 테스팅 (K2)

 

* 화이트박스 테스팅

　- 시스템의 내부 구조(코드, 아키텍처, 워크플로우, 시스템 내 데이터 플로우 등)나 구현을 기반으로 테스트를 도출

　- 구조 커버리지를 통해 얼마나 철저하게 이루어졌는지 측정할 수 있음

　　: 특정 구조 요소가 테스트에 의해 어느 정도 실행됐는지, 커버되고 있는 요소 유형에 대한 백불율로 표기함

 

2.3.4 변경 관련 테스팅

 

* 확인 테스팅 
　- 원래 제대로 결함을 제대로 수정했는지 확인
　- 모든 테스트 레벨 (컴포넌트, 통합, 시스템, 인수 테스팅) 에서 수행 가능

* 리그레션 테스팅
　- 의도하지 않은 부작용을 발견하기 위한 테스트
　- 모든 테스트 레벨 (컴포넌트, 통합, 시스템, 인수 테스팅) 에서 수행 가능

　- 자동화에 적합

　(리그레션 테스트 스위트는 여러번 반복 수행, 대개는 서서히 변화하기 때문에)
　(프로젝트 초반에 시작해야 함 (6장))

 

* 반복적 점진적 개발 수명주기(예 : 애자일)에서는 
신규 기능, 기존 기능에 대한 변경, 코드 리팩토링 -> 코드에 잦은 변경 -> 변경 관련 테스팅이 필요

 

2.3.5 테스트 유형과 테스트 레벨

 

* 모든 테스트 유형(기능, 비기능, 화이트박스, 변경(확인, 리그레션 관련 테스팅)은
어느 테스트 레벨 (컴포넌트, 통합, 시스템, 인수 테스팅) 에서나 수행할 수 있음

 

* 기능 테스트의 예

　① 컴포넌트 테스팅에 적용
　　컴포넌트가 복잡한 이자 계산을 어떻게 해야 하는지를 기반으로 테스트 설계
　② 컴포넌트 통합 테스팅에 적용
　　사용자 인터페이스에서 포착하는 계정 정보가 어떻게 비즈니스 로직(logic)으로 전달되는지를 기반으로 테스트 설계
　③ 시스템 테스팅에 적용

　　계좌 소유주가 어떻게 자신의 예금 통장에 신용 한도를 부여할 수 있는지를 기반으로 테스트 설계
　④ 시스템 통합 테스팅에 적용

　　시스템이 외부 마이크로서비스를 사용해서 계좌 소유주의 신용 점수를 확인하는 방법을 기반으로 테스트 설계
　⑤ 인수 테스팅에 적용

　　은행이 신용 한도를 승인하거나 거절하는 방법을 기반으로 테스트 설계

 

* 非기능 테스트의 예

　① 성능 테스트 설계
　　- 컴포넌트 테스팅에 적용
　　- 복잡한 전체 이자 계산을 수행하기 필요한 CPU 사이클 횟수를 평가하기 위해
　② 보안 테스트 설계
　　- 컴포넌트 통합 테스팅에 적용
　　- 사용자 인터페이스에서 비즈니스 로직으로 전달되는 데이터로 인한 버퍼 오버플로우 취약성을 위해
　③ 이식성 테스트 설계
　　- 시스템 테스팅에 적용
　　- 보이는 화면이 모든 지원 대상 브라우저와 모바일 기기에서 제대로 동작하는지 확인하기 위해
　④ 신뢰성 테스트 설계
　　- 시스템 통합 테스팅에 적용
　　- 신용 점수 마이크로서비스가 응답하지 않을 때 시스템의 강건성(robustness)을 평가하기 위해
　⑤ 사용성 테스트 설계
　　- 인수 테스팅에 적용
　　- 은행 신용 처리 인터페이스에 장애인의 접근성을 평가하기 위해

 

* 화이트박스 테스트의 예

　① 컴포넌트 테스팅에 적용

　　금융 계산을 수행하는 모든 컴포넌트에 대한 완벽한 구문 및 결정 커버리지 (4.3장) 를 달성하기 위해
　② 컴포넌트 통합 테스팅에 적용
　　브라우저 인터페이스의 각 화면이 다음 화면과 비즈니스 로직을 기반으로 데이터를 어떻게 전달하는지 확인하기 위해
　③ 시스템 테스팅에 적용
　　신용 한도 신청 도중 순차적으로 거치게 되는 웹페이지를 커버하기 위해
　④ 시스템 통합 테스팅에 적용
　　신용 점수 마이크로서비스로 보내는 모든 조회(inquiry)  유형을 실행하기 위해
　⑤ 인수 테스팅에 적용
　　은행 간 이체에서 지원하는 모든 금융 데이터 파일 구조와 값 범위를 커버하기 위해

* 변경 관련 테스트의 예
　① 컴포넌트 테스팅에 적용
　　각 컴포넌트를 위한 자동 리그레션 테스트가 구축되고 지속적인 통합 프레임워크에 포함 
　② 컴포넌트 통합 테스팅에 적용
　　인터페이스 관련 결함 수정이 코드 저장소에 체크인됐을 때 해당 수정을 확인하기 위해
　③ 시스템 테스팅에 적용
　　특정 워크플로우에 속하는 화면 중 하나만 변경되더라도 해당 워크플로우에 대한 모든 테스트 실행
　④ 시스템 통합 테스팅에 적용
　　신용 점수 마이크로서비스에 대한 지속적인 개발의 일환으로
　　해당 마이크로서비스와 상호작용하는 애플리케이션에 대한 테스트를 매일 재실행
　⑤ 인수 테스팅에 적용

　　인수 테스팅에서 발견된 결함이 수정되면 기존에 불합격했던 모든 테스트를 재실행

 

* 모든 SW가 모든 레벨에 모든 테스트 유형을 적용해야 하는 것은 아님
but 각 레벨에서 가능한 테스트 유형을 수행하는 것이 중요
해당 테스트 유형이 처음으로 발생하는 첫 레벨에서 수행하는 것이 중요

 

2.4 유지보수 테스팅

* 유지보수
　- SW와 시스템이 생산 환경으로 배포되고 나면 필요
　- 배포된 SW와 시스템에 대한 변경 -> 운영 중 발견한 결함 수정, 신규 기능 추가, 기존 기능의 삭제나 개선 등
　- 컴포넌트나 시스템의 수명 동안 비기능 품질 특성을 보존 or 개선하기 위해서 필요
　(성능 효율성, 호환성, 신뢰성, 보안성, 이식성)
　- 계획된 릴리스나 계획되지 않은 릴리스(핫픽스)와 연관되어 발생할 수 있음

* 유지보수 테스팅 범위에 영향 받는 요소
　① 변경의 리스크 수준 (예 : 변경된 SW 영역이 다른 컴포넌트나 시스템과 통신하는 정도)
　② 기존 시스템의 규모
　③ 변경의 규모

 

2.4.1 유지보수가 필요한 상황 (K2)

 

* 유지보수의 계기
　① 개선을 위한 변경(modification), 계획된 확장(예 : 릴리스 기반), 수정 or 긴급 변경,
　　운영 환경 변경(예 : 계획된 운영 시스템 or DB 업그레이드), 상용 SW 업그레이드, 결함 및 취약성을 위한 패치 등
　② 이관(migration)을 위한 변경, 
　　하나의 플랫폼에서 다른 플랫폼으로 이관할 때, 변경된 SW + 신규 환경에 대한 운영 테스트가 필요할 수 있거나
　　or 유지보수하고 있는 시스템에 이관하는 다른 애플리케이션의 데이터를 위한 데이터 전환 테스트 등
　　- 단종(retirement), 애플리케이션의 수명이 다할 때 등, 애플리케이션이나 시스템이 단종될때 
　　데이터 이관이나 장시간의 데이터 유지가 필요한면 보관처리에 대한 테스팅이 필요할 수 있음
　　- 장시간의 보관이 필요한 경우 차후 복원/회수 절차에 대한 테스팅이 필요할 수 있음

　　- 여전히 서비스하고 있는 기능이 있다면,
　　해당 기능이 정상 동작할거라는 확신을 얻기 위한 리그레션 테스팅이 필요할 수 있음  

 

2.4.2 유지보수를 위한 영향도 분석 (K2)

 

* 영향도 분석
　- 유지보수 릴리스에 포함된 변경을 평가해서, 의도한 결과
　　+ 변경으로 인해 발생할 수 있는 예견된 부작용, 변경의 영향을 받는 시스템 영역을 식별하기 위해 실시함
　- 변경이 기존 테스트에 미치는 영향을 식별하기 위해 사용할 수 있음

　- 부작용과 영향 받은 시스템 영역에 대해서는, 필요한 경우 변경의 영향을 받는 기존 테스트를 업데이트해서
　리그레션 테스트를 수행할 필요가 있음

* 영향도 분석이 어려운 상황
　① 명세(예 : 비즈니스 요구사항, 사용자 스토리, 아키텍처)가 너무 오래 됐거나 없는 경우
　② TC가 문서화되어 있지 않거나 너무 오래된 경우
　③ 테스트와 테스트 베이시스 간 양방향 추적성이 유지되지 않은 경우
　④ 도구 활용이 적거나 없는 경우
　⑤ 연관된 인원이 도메인이나 시스템 지식을 가지고 있지 않은 경우
　⑥ SW의 개발 중 유지보수성에 충분히 신경을 쓰지 못한 경우

 

No	용어	설명	유의어	연관 항목
1	인수  테스팅 (acceptance testing)	시스템이  사용자의  필요  및  요구사항,  비즈니스  프로세스  측면에서  인수  조건을  만족하는지 확인하고  사용자, 고객, 기타 권한을 지닌 사람이 시스템의 인수 여부를 결정하기 위해 수행 하는 공식 테스팅		사용자 인수 테스팅 (user acceptance testing)
2	알파  테스팅 (alpha testing)	개발 조직이 아닌 제3자가 개발자의 테스트 환경에서 수행하는 시뮬레이션 또는 실제 운영 테 스팅
3	베타  테스팅 (beta testing)	개발 조직이 아닌 제3자가 외부 환경에서 수행하는 시뮬레이션 또는 실제 운영 테스팅	필드 테스팅 (field testing)
4	변경관련 테스팅 (change-related testing)
5	상용 소프트웨어 (COTSCommercial Off-The-Shelf)	많은 수의 고객, 즉 대중 시장을 대상으로 개발되고, 다수의 고객에게 같은 형태로 전달되는 소프트웨어 제품
6	컴포넌트 통합 테스팅 (component integration testing)	통합된 컴포넌트 간의 인터페이스와 상호작용에서의 결함을 노출시키기 위한 테스팅	링크 테스팅 (link testing)
7	컴포넌트 테스팅 (component testing)	개별 하드웨어나 소프트웨어 컴포넌트에 대한 테스팅	· 모듈 테스팅 (module testing),  · 단위 테스팅 (unit testing)
8	확인 테스팅 (confirmation testing)	결함 수정 후 결함으로 인한 장애가 더 이상 발생하지 않는지 확인하는 동적 테스팅	재테스팅 (re-testing)
9	계약 인수 테스팅 (contractual acceptance testing)	시스템이 계약상의 요구사항을 충족시키는지 검증하는 인수 테스팅
10	기능 테스팅 (functional testing)	컴포넌트나 시스템이 기능 요구사항(functional requirements)을 어느 정도 준수하고 있는지 평가하기 위해 실시하는 테스팅		블랙박스 테스팅 (black-box testing)
11	영향도 분석 (impact analysis)	변경을 완료하는 데 필요한 자원의 예상 견적과 변경에 의해 영향받는 모든 작업 산출물의 식별
12	통합 테스팅 (integration testing)	통합된  컴포넌트나  시스템  간의  인터페이스  및  상호작용에서  결함을  발견하기위해  수행하는 테스팅		· 컴포넌트  통합  테스팅 (component  integration  testing),   · 시스템  통합  테스팅 (system integration testing)
13	유지보수 테스팅 (maintenance testing	운영 중인 시스템에 대한 변화, 또는 운영 중인 시스템에 미치는 환경 변화의 영향에 대한 테스팅
14	비기능 테스팅 (non-functional testing)	컴포넌트나 시스템이 비기능 요구사항을 준수하는지 확인하고자 수행하는 테스팅
15	운영 인수 테스팅 (operational acceptance testing)	인수 테스트 단계에서의 운영 테스팅. 일반적으로 운영 및 시스템 관리 직원에 의해 (시뮬레이션된) 운영 환경에서 수행되며,  주로 복구성, 리소스-동작, 설치성, 기술 준수성 등 운영상 의 측면에 중점을 두고 있음	생산 인수 테스팅 (production acceptance testing)	운영 테스팅 (operational testing)
16	리그레션 테스팅 (regression testing)	개선을  위한 소프트웨어  수정  후 변경  결과로  소프트웨어의 변경되지  않은  영역에서 결함이 발견되거나 유입되지 않았는지 확인하기 위해  이전 테스트 구성 요소 또는 시스템에 대해 진 행하는 테스팅
17	규정 인수 테스팅 (regulatory acceptance testing)	시스템이 관련 법규나 정책, 규정을 준수하는지 확인하기 위해 수행하는 인수 테스팅
18	순차적 개발 모델 (sequential development model)	전체 시스템이 서로 겹치지 않는 여러 개의 개별적, 연속적 단계를 통해 개발되는 개발 수명 주기 모델의 한 유형
19	시스템 통합 테스팅 (system integration testing)	시스템의 통합과 상호작용을 테스팅하는 것
20	시스템 테스팅 (system testing)	통합 시스템이 제시된 요구사항을 충족하는지 확인하는 테스팅
21	테스트 베이시스 (test basis)	테스트 분석 및 설계의 기초로 사용되는 지식 체계
22	테스트 케이스 (test case)	테스트 컨디션을 기반으로 개발된 사전조건, 입력값, 행동(해당하는 경우), 기대 결과, 사후조건의 집합
23	테스트 환경 (test environment)	테스트 수행에 필요한 하드웨어, 계측, 시뮬레이터, 소프트웨어 도구 그리고 기타 지원 요소를 포함하고 있는 환경	· 테스트 베드 (test bed),  · 테스트 리그 (test rig)
24	테스트 레벨 (test level)	테스트 프로세스 중의 특정 예시 단계	테스트 단계 (test stage)
25	테스트 대상 (test object)	테스트할 컴포넌트나 시스템		테스트 항목 (test item)
26	테스트 목적 (test objective)	테스트를 설계하고 실행하는 근거나 목적
27	테스트 유형 (test type)	컴포넌트나 시스템의 특성을 목표로 하는 구체적인 테스트 목적에 기반한 테스트 활동의 집합
28	사용자 인수 테스팅 (user acceptance testing)	자신의 필요, 요구사항, 비즈니스 프로세스 등에 맞춰 예상된 사용자가 실제 또는 시뮬레이션된 운영 환경에서 수행하는 인수 테스팅		인수 테스트 (acceptance test)
29	화이트박스 테스팅 (white-box testing)	컴포넌트나 시스템의 내부구조 분석에 기반한 테스팅	· 투명 박스 테스팅 (clear-box testing),  · 코드 기반 테스팅 (code-based testing),  · 유리 박스  테스팅 (glass-box  testing),   · 논리  커버리지  테스팅 (logic-coverage  testing),  · 논리  주도  테스팅 (logic-driven  testing),   · 구조적  테스팅 (structural  testing),   · 구조 기반 테스팅 (structure-based testing)

 

Sample A

---

Sample B

---

Sample C