-테스팅의 정의
: 프로그램을 실행하고 주어진 입력값에 대해 원하는 방식으로 프로그램이 동작하는지, 원하는 결과를 출력하는지를 확인하는 것
-테스팅 하는 이유
: 원하는대로 동작하지 않을 가능성(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가 낮다(인상에 영향을 미치기 때문), 용납 어려움
'소프트웨어공학론' 카테고리의 다른 글
Black box testing (0) | 2023.06.10 |
---|---|
Code quality improvement (0) | 2023.05.27 |
Code smell (0) | 2023.05.26 |
Refactoring - Catalogue (0) | 2023.05.25 |
Refactoring - overview (0) | 2023.05.24 |
댓글