테스팅 (Testing)

개발하는, 또는 개발된 소프트웨어가 제대로 동작하고 있는지 검증하는 단계

코드속에 에러가 있음을 증명하는 것이 목적

코드를 육안으로 읽거나, 실제 데이터를 주고 실행하면서 테스팅

완벽한 테스팅은 불가능

---

테스팅의 두가지 형태

- 실행 기반 테스팅 (동적 테스팅) : 프로그램에 데이터를 적용해서 실행

- 비실행 기반 테스팅 (정적 테스팅) : 문서를 육안으로 검사

 

V&V

검증(Verification) : 과정 및 프로세스에 중점 (Is it right?)

- 각 개발 단계에서 정확하게 수행됐는지를 결정하는 프로세스

- 요구사항 명세대로 개발이 이루어지는 지를 검사

확인(Validation) : 최종 제품에 중점 (Is it correct)

- 최종 프로덕트가 그것의 요구사항을 모두 만족하는지를 결정하는 프로세스

---

실수(Mistake)

->

결함(Fault)

-> 에러 전달(Error propagation)

오작동(Failure)

 

예시

s=d/t

print s

실수(mistake)	시간이 0인 경우에 어떤 처리를 해야 하는지 프로그래머가 고려하지 않음
결함(fault)	시간이0이 되는 경우에 처리하는 코드가 없음
에러(error)	시간이 0이 되는 경우에 예외가 발생한다
오작동(failure)	예외가 전달되어 프로그램의 실행이 중단

 

** 결함 허용 (Fault tolerance)

어떤 프로그램에서 결함이 생겨도 극복 가능 .. HW, SW 적으로 가능

 

테스팅을 하기 이전에 테스트의 상황을 미리 정의

- 테스트 대상 항목

- 테스트 조건

- 테스트 데이터

- 예상 결과

Test Data : 테스트 입력값

Test Case : 테스트할 입력값과 예측 결과 값의 쌍

Test Suite : Test Case의 모임

 

Software Quality

- 우수함을 의미하지는 않음

- 소프트웨어가 기능을 정확하게 갖추게 하는 것

- 모든 소프트웨어 전문가들은 자신의 작업이 정확한지를 보장할 책임을 가짐 * 품질은 처음부터 구축해야 하는 것

 

SQA (Software Quality Assurance) 그룹은 개발자가 고품질의 작업을 수행했는지를 보증해야 함

*각각의 개발 단계를 마치고 프로덕트가 최종 완성되었을 때

* 테스트 후 바로 디버깅하면 안됨. 디버깅은 발견이 목적

 

관리의 독립성

- 개발팀 그룹과 SQA 그룹은 관리의 독립성을 가져야 하고, 다른 팀을 결코 지배해서는 안됨

- 선임 매니저는 만족스럽지 못한 두가지 선택 사항 중 하나 선택 필요 .. (결함 때문에 고생을 해도 정시에 결함을 인도? 인도가 늦어지더라도 개발자가 소프트웨어에 있는 결함을 수정?)

---

테스트 방식

실행 테스팅

- 블랙 박스 테스팅

- 화이트 박스 테스팅

비실행 테스팅

- 리뷰(walkthrough)

- 인스펙션

- Formal proofs of correctness (Formal Method 방식으로 개발할 때 가능)

---

비실행 기반 테스팅

근본적인 원칙: 작성한 사람이 검토를 책임지게 하는 것은 좋은 아이디어가 아님, 그룹 시너지

 

워크스루 (Walkthrough)

- 워크스루 팀은 4~6명의 멤버들로 구성

- 다음의 대표자로 구성

    - 현재 워크플로(개발 단계)에 책임을 지는 팀의 멤버

    - 다음 워크플로에 책임을 질 팀의 멤버

    - SQA

- 워크스루는 준비할 수 있도록 자료를 사전에 배포

    - 이를 통해 참가자들은 두가지 목록을 개발 .. 이해할 수 없는 항목, 부정확하다고 생각되는 항목

 

워크스루 관리

- 워크스루 팀의 의장 - SQA 대표자가 의장

- 워크스루에서 우리가 결함을 발견했을 때, 그것을 수정해서는 안됨

-  위원회가 작성한 수정은 훈련받은 사람이 작성한 것보다 저품질일 수 있음

> 위원회 수정의 비용은 너무 높음

> 결함으로 간주했던 모든 항목들이 모두 결함은 아닐 수도 있음

> 워크스루는 2시간 이상 계속하면 안됨

> 결함을 정확하게 수정하기에는 시간이 짧음

- 워크스루는 참가자 보다는 문서 중심으로 수행해야 함

- 언급이나 제안 설명은 결함을 발견하게 함

- 워크스루는 성능 평가에 이용되면 안됨

 

인스펙션(Inspection)

인스펙션은 5개의 정형화된 단계로 구성

- 개요(Overview)

- 준비(Preparation) .. 발견된 결함들의 유형을 이해

- 인스펙션

- 재작업(Rework)

- 사후검토(Follow-up)

 

인스펙션 팀의 구성 (4명의 멤버)

- 중재자

- 현재 워크플로를 수행하는 팀의 멤버

- 다음 워크플로를 수행할 팀의 멤버

- SQA 그룹의 멤버

 

특별한 멤버

- 조정자(Moderator)

- 판독자(Reader)

- 기록자(Recorder)

 

결함 통계

- 결함들은 수준에 따라 엄격하게 기록되어짐

- 결함들은 결함 유형에 따라 기록되어짐

- 주어진 워크플로에 따라 이전의 프로덕트와 현재 결함율을 비교

- 만약 산출물에 결함의 수가 불균등하게 발견되면 차라리 시작부터 재설계하는 것은 좋은 대안이 될 수 있음

- 다음 워크플로에 결함 통계를 활용 가능

---

인스펙션과 워크스루의 비교

워크스루

- 2단계, 비정형 프로세스 .. 준비, 분석

인스펙션

- 5단계, 정형화된 프로세스 .. 개요, 준비, 인스펙션, 재작업, 사후검토

 

인스펙션용 척도

- 인스펙션율 (Inspection rate) .. 시간당 인스펙션된 설계 페이지의 비율

- 결함 밀도 (Fault density) .. 검사된 KLOC(코드당 1000라인 단위) 당 결함 수

- 결함 발견율 (Fault detection rate) .. 시간당 발견된 주요/단순 결함들의 수

- 결함 발견 효율성 (Fault detection efficiency) .. 사람 당 발견한 주요/단순 결함들의 수

 

결함 발견율 50% 증가가 의미하는 건?

- 품질이 저하되고, 인스펙션 프로세스가 더 효율적이라는 것

---

실행 기반 테스팅

- 프로그램 코드에 실제 테스트 데이터를 적용해서 실행을 시켜서 검증

- 완전한 테스트(exhaustive test)는 불가능

 

테스트의 한계

- 테스트는 오류가 없음을 보여주지 않는다

- 어떤 테스트를 선정할 것인가? .. 테스트 선정 기준

- 언제 테스트를 종료할 것인가? .. 테스트 종료 조건

 

실행 기반 테스팅의 정의

- 알고 있는 환경에서 선택된 데이터를 프로덕트에 실행시켜 나온 결과를 기준으로 프로덕트의 어떤 행위의 성질을 추론하는 과정

 

테스팅 방법에 따른 분류

- 블랙박스 테스팅

- 화이트박스 테스팅

 

테스팅 절차에 의한 분류

- 단위 테스트 (모듈 테스트)

- 통합 테스트

- 시스템 테스트

- 인수 테스트

- 설치 테스트

---

블랙 박스 테스팅

- 블랙 박스 테스팅 : 내부 구조를 참조하지 않고 주어진 입력에 요구되는 결과가 나오는가를 시험하는 것

- 프로그램과 외부와의 인터페이스에 대해서 시험이 이루어짐

- 프로그램의 기능에 대해 초점을 맞추고, 주어진 입력 값들의 조합에 의해 요구되는 결과가 나오는가를 점검

 

화이트 박스 테스팅

- 프로그램 내부의 구성을 시험

- 프로그램을 참조하여 이루어지며, 구조 또는 코드에 기초한 시험

- 철저한 화이트박스 시험은 많은 오류를 제거시켜주나, 모든 가능한 시험 사례의 생성은 가능하지 않음

---

단위 테스팅

- 단위 테스트는 프로그램의 기본 단위인 모듈에 대한 테스트를 의미

- 설계를 할 때 각 모듈에 대한 설계 지침을 기반으로 모듈의 중요한 경로와 경계 값을 테스트해야 한다.

- 코드가 효율적으로 작성되었는지, 프로젝트 내에 합의된 코딩 표준을 준수하고 있는지도 검증

- 주로 화이트 박스 테스팅을 수행

- 모듈의 단위 : 함수 또는 클래스

 

단위 테스팅의 점검 사항

- 입력 변수의 개수가 정확한가

- 입력 변수의 타입이 정확한가

- 변수의 단위가 정확하고 호츌 모듈과 호출되는 모듈에서 일치하는지 확인한다

- 입력 변수의 순서가 정확한지 확인한다

- 읽기 전용인 입력 변수가 모듈 내부에서 변경되었는지 확인한다

- 모듈 간 전역 변수에 대해 정확히 사용하고 있는지 확인한다

- 라이브러리 모듈에 대한 호출에서 입력 변수가 정확한지 확인하다

- 파일에 대한 사용 방법이 정확한지 확인한다

 

단위 테스트 자료구조 점검 사항

- 부정확하거나 일치하지 않는 타입이 존재하는지 확인

- 변수에 대한 초기화가 부정확하거나 부정확한 디폴트 값을 사용하였는지 확인한다

- 변수 이름이 부정확하게 타이핑되었거나 컴파일러에 의해 잘리지 않는지 확인한다

- 불일치한 데이터 타입을 이용하였는지 확인한다

- 수식의 계산에서 언더플로우 또는 오버플로우가 발생하지 않는지 확인한다

---

테스트 드라이버(Test Driver) : 가짜 상위 모듈

- 테스트 될 모듈을 호출하는 모듈

- 가상의 주 프로그램 역할

- 테스트 케이스 자료를 입력받고 검사를 위해 연관된 결과를 출력하는 제어 프로그램

 

스텁(Stub) : 가짜 하위 모듈

- 테스트하려는 모듈이 호출하는 가상 모듈

- 가상의 부 프로그램 역할

- 모듈 간의 통합 검사를 위해 일시적으로 필요한 조건만을 가지고 임시로 제공되는 시험용 모듈

 

IUT(Implmentation Under Test)

- 테스팅하는 대상 모듈

 

통합 테스트 (Integration Test)

- 각각의 모듈들을 통합하여 통합된 컴포넌트 간의 인터페이스와 상호작용 상의 오류를 발견

- 주로 블랙 박스 테스트, 일반적으로 개발자가 진행

- 모듈을 한 번에 전부 통합하여 비점진적으로 프로그램 테스트 시 오류를 발견한 후 오류 위치를 확정하기 매우 어려움

- 통합 테스트에서 점진적 통합 테스트 실시

- 점진적 통합 테스트 -> 하향식, 또는 상향식

 

Top-down 테스팅 (하향식)

- 프로그램의 상위 모듈에서 하위 모듈 방향으로 통합하여 검사

> 시스템의 최상위에 있는 주 프로그램 모듈을 먼저 테스트

> 이 모듈이 직접 호출하는 다음 레벨의 모듈을 테스트하여 점차 하위 레벨로 테스트를 이동

- 스텁 모듈 필요, 드라이버 모듈 필요 없음

- 깊이 우선(depth-first)과 너비 우선(breadth-first) 방법

- 깊이 우선 통합의 기본 원칙은 한 모듈을 선택한 후 우선 그 모듈의 하위 모듈을 통합하는 것

 

하향식 장점

- 하위 모듈에서 테스트가 완료된 상위 모듈을 이용 -> 실제 가동 환경과 유사한 환경에서 테스트

- 테스트의 최초 단계에서 인터페이스 검증이 가능

 

하향식 단점

- 테스트 초기에 병행 작업이 곤란

- 스텁이 필요 -> 스텁 작성에 많은 노력이 필요

 

Bottom-up 테스트 (상향식)

- 프로그램이 하위 모듈에서 상위 모듈 방향으로 통합항 검사

- 하위 레벨에 있는 모듈들을 클러스터로 결합하여 특정 소프트웨어의 부분 기능을 수행

- 테스트 케이스의 입출력을 조정하기 위해 드라이버 작성

- 추후 드라이버를 제거하고 클러스터를 상위 모듈과 결합

- 드라이버 모듈 필요, 스텁 필요 없음

 

상향식 장점

- 드라어버 모듈 설계가 더 쉬움

- 테스트 초기부터 병행 작업 가능

- 모듈 단위의 철저한 테스트

 

상향식 단점

- 프로그램 전체의 윤곽을 통합 테스트 최후 단계에서 볼 수 있음

> 고객의 요구사항과 위배되는 큰 오류를 일찍 발견할 수 없음

- 마지막 순간까지 독립된 소프트웨어의 형태를 가지지 못함

- 인터페이스의 테스트가 가정인 상태로 행해짐

 

실제 통합 테스트는 하향식과 상향식 방법을 결합하여 테스트를 수행

---

시스템 테스트 (System Test)

- 소프트웨어와 다른 시스템 요소 통합 .. 모든 요소들이 적절히 조화를 이루어 시스템의 기능을 만족하는지 확인하는 시스템 테스트 수행

- 실제 구현된 시스템과 계획된 사양을 서로 비교하는 작업이 수행

- 시스템 테스트는 모듈이 통합된 후 시작

- 시스템의 기능을 시험 확인하고 시스템의 성능이나 기능에 제한이 없는지 확인

- 비기능 테스트 포함

 

시스템 테스팅의 종류

- 복구 테스트(Recovery Testing) .. 에러가 발생하고 얼마나 빨리 복구되는가

- 보안 테스트(Security Testing) 

- 스트레스 테스트(Stress Testing) .. 얼마나 많은 리퀘스트를 받아도 다운되지 않는가

- 성능 테스트(Performance Testing)

- 결함 허용 시스템(Fault-tolerance system) .. 결함이 있어도 극복할 수 있는가

---

인수 테스트 (Acceptance Test)

- 개발된 소프트웨어가 고객의 요구사항을 만족하는지 조사하는 시험

- == 확인 테스트 (Validation Test)

- 개발자, 독립적인 테스터(ITG, Independent Testing Group) 및 사용자가 수행

- 요구사항 분석 단계에서 도출된 시스템의 사양이나 계약을 만족하는지 확인

- 시스템 테스트가 완료된 후 시작 

- 고객이 참여

- α-테스트, β-테스트

- α-테스트: 사용자가 개발 환경에 와서 테스트하는 것

- β-테스트: 개발자 팀이 소프트웨어를 사용자에게 배포하여 사용자가 자신의 컴퓨터 환경 또는 실제 상황에서 수행

---

회귀 테스트(Regression Test)

- 소프트웨어 유지보수 과정에서 새로운 기능이 추가되거나 변경 후 하는 테스팅

- 소프트웨어의 전체 기능을 수행할 수 있는 대표적인 테스트 케이스를 재수행

- 새로운 모듈에 의해 영향을 받을 수 있는 기능에 대하여 회귀 테스트를 수행

- 변경된 소프트웨어 구성 요소에 대해 집중적으로

---

프로그래머의 테스팅

- 프로그래밍인 건설적, 테스팅은 파괴적

- 프로그래머는 단위 테스팅까지만 주로 책임을 짐

- 나머지 테스팅은 SQA(Sofware Quality Assurance) 팀에서

 

체계적인 테스팅

- 프로그래머는 정형적 단위 테스팅을 수행

- 그 후 SQA 그룹은 체계적인 테스팅을 수행

- 모든 테스트케이스는 반드시 예상되는 출력과 함께 사전에 계획되고 계속 유지되어야 함

 

테스트 종료

- 프로덕트 폐기 시 테스팅도 종료

 

테스팅 도구

- 정적 분석기

- 코드 감사기

- 테스트 파일 생성기

- 단정 처리기

- 테스트 검증기

- 테스트 장치

 

테스팅과 디버깅

테스팅

- 프로그램 에러의 존재를 발견하는 과정

디버깅

- 프로그램 내 에러 발생 위치를 찾아서 그 에러를 제거하는 과정

- 테스팅 결과에 따른 연속 과정