Testing

 

 

-테스팅의 정의

: 프로그램을 실행하고 주어진 입력값에 대해 원하는 방식으로 프로그램이 동작하는지, 원하는 결과를 출력하는지를 확인하는 것

 

-테스팅 하는 이유

: 원하는대로 동작하지 않을 가능성(software bug)이 있기 때문

-> 큰 재산상의 피해, 인명피해

 

-다른 입증 접근법들(Verification  approaches)

1) Testing

투자비용 대비 버그를 잘 찾아낸다. 효과적.

 

2) Static verification

: 모든 가능한 입력, 실행경로들을 전부 따져서 확인하는 방법

*static = 프로그램을 실행하지 않고.

 

3) Inspections (a.k.a. reviews or walkthroughs)

: 사람들이 모여서 코드를 한줄한줄 다같이 읽어 보는 것

 

4) Formal proofs of correctness

: 주어진 프로그램에 대해 수학적인 명세를 두고 이 프로그램의 동작이 명세에 일치 하는가를 증명하는 것.

가장 고비용.

큰 재산상의 피해, 인명피해를 입힐 수 있는 버그일 경우 사용.

 

 

-장단점

Testing : 버그를 찾으면 무조건 버그이다 / 버그가 있음에도 못찾는 경우도 있다.

Static verification : 모든 가능성을 고려한다 / 잘못된 판단을 할 수 있다-버그가 사실 없었지만 있었다고 판단하는 경우(false positive), 너무 과하게 경고

Inspections : 체계적, 철저함 / 비공식적, 주관적

Formal proofs of correctness : 강한 보장 / 전문성, 비용이 많이 든다

 

 

-과도한 테스팅은 비실용적이다.

글꼴에 있는 모든 경우를 테스팅하려면 매우 많은 테스팅을 해야한다.

 

 

-테스팅의 현실

: 버그의 존재를 보여주는 것은 효과적이지만 없다는 것을 보여주지는 않는다.

하지만 품질을 측정, 버그를 발견할 수 있는 최선의 방법이다.

 

 

-테스팅 용어

 

테스팅 : Input을 테스트 하고자 하는 프로그램에 주고 기대되는 출력이 나오나 안나오나 확인하는 작업

Test Case : 테스트 input과 기대하는 output

Test Suite : Test Case를 모아놓은 집합

Test procedure/script : 입력을 주고 프로그램을 돌려서 실제 결과를 뽑아내기 까지의 과정

IUT(Implementation Under Test) : Input을 주는 대상, 테스트하려고 하는 프로그램

Test Environment : IUT가 실행되기 위한 환경

 

 

Test Procedure

 

Test Environment

Unit test : 전체 main프로그램을 테스트 하는 것이 아니라 함수/클래스 하나만 테스트 하는 것

 

getAverage 함수를 테스트하기 위해서는 main함수가 있어야 한다.

IUT를 구동시키는 또다른 프로그램이 필요한데 그러한 구동 프로그램 = Driver(main함수)

 

getAverage만 테스트하고 싶은데 getAverage가 의존하는 getSum함수가 있다.

-> getSum함수를 만들어만 놓거나 컴파일만 되게 만들어 놓는다. =Stub 함수(getSum)

Test harness : 테스트하기위한 장치 (Driver, Stub)

 

 

-Test Case Design

목적 : 버그를 발견하기 위해

기준 : 완벽한 태도

비용, 시간 : 최소한

 

두가지 팁

1) 비정상적인 데이터를 넣고 테스트해봐야 한다. (Negative testing)

2) 버그가 증가하는 경향이 있으면 앞으로도 더 증가할 것이다.

: 어디에서 버그가 더 잘 발생할지 가늠

 

 

-테스팅 vs 디버깅

테스팅 : 문제의 위치를 알려준다.

 

디버깅 : 정말 문제의 근본원인이 되는 위치가 어디인지를 찾는 활동.

-다른 위치에서 문제가 있었는데 흘러서 결국 다른 위치에서 문제가 나올 수 있다.

그 오류를 수정

 

 

테스트 설계 방법에 따라 -

Black box : 소스코드 내부를 보지 않고 명세만 보고 테스트케이스를 설계

White box : 소스코드 내부를 보고 테스트케이스를 설계

 

IUT의 레벨(테스트 대상의 크기), 테스트 주체에 따라 -

Unit, Integration, System, Acceptance

 

Test items, 특징들에 따라 -

Availability, Performance, Reliability, Functionality

 

Unit test : 함수/클래스/컴포넌트를 테스트

Integration test : 둘 사이에 인터페이스가 맞나 안맞나 테스트

System test : 전체 프로그램을 테스트 (개발자가 스스로 테스트)

Acceptance test : 전체 프로그램을 테스트 (고객이 테스트)

Regression test : 버전이 업그레이드 되어도 잘 돌아가나 테스트, Agile 방법에서 중요하다.

 

 

 

문제가 발생하더라도 용납가능한 정도

Alpha test : 개발자 내부에서 사용자를 모집하여 테스트.

tolerance가 높다, 용납 가능

 

Beta test : 개발팀의 외부에서 사람들을 모집하여 테스트

tolerance가 낮다(인상에 영향을 미치기 때문), 용납 어려움