Software Test (소프트웨어 테스트) 종류와 방법
소프트웨어 테스트. (소프트웨어 테스팅).
간단하게 말하자면 “소프트웨어의 결함이 존재함을 보이는 과정”.
소프트웨어가 문제가 없다를 보이는 것이 아니라 문제가 있다를 밝히는 과정이다.
SWLC(소프트웨어 생명주기)의 프로세스 [요구사항 분석 - 설계 - 구현 - 테스트 - 유지보수] 에서 거의 마지막 단계이다.
소프트웨어 테스터들은 “이 소프트웨어가 완벽하군요!” 라고 하는 것이 아니라,
“이 소프트웨어는 결함이 없군요!” 라고 말해야 한다.
요구사항 설계와 다르게 동작하는 것은 모두 “결함“이며 이미 제작된 소프트웨어에 대해서 테스트 케이스를 만들고 테스팅하는 것은 매우 노력이 많이 들어가므로
요즘엔 개발 초기부터 테스트케이스를 만들고 이것으로 개발하는 방식이 각광받고 있다. (이것이 TDD. 그런데 TDD는 테스트와 함께 개발이라서, 개발 시간이 느려진다는 단점이 있다.)
최근 여러 프로젝트 방법론에서 TDD(Test Driven Development) 가 뜨고 있으니 이에 대해서도 알아두면 좋다.
http://youtu.be/dWayn0QsJr8?t=1m17s
소프트웨어 테스트는,
IEEE의 거창한 정의를 보자면 ” 시스템이 정해진 요구를 만족하는지, 예상과 실제 결과가 어떤 차이를 보이는지 수동 또는 자동 방법을 동원하여 검사하고 평가하는 일련의 과정” 이라고 하였다.
소프트웨어 테스트는 능력있는 컴퓨터공학 전공자(개발자 보다 더 뛰어나면 좋음)가 최대한 자동화하여 테스트 하는 것이 좋다. 개발 로직을 이해할 수 있는 테스터를 권장한다.
테스트는 지속적이고(continuous), 반복적이고(repetitious), 자주 일어나는(frequentis) 작업이기 때문이다.
물론 전공이나 개발 지식 상관없이 꼼꼼하고 근면성실한 테스터가 테스트를 해도 되긴 한다. (대개 이런 경우, 테스트 품질이 떨어지고 문제 생겨서 금방 이직하더라.)
삼성전자 같은 대기업에 컴퓨터공학 전공자로써 취업하게 되면 대부분 테스트팀(QA Team)으로 배정된다. (테스트는 하찮은 작업이 아니라 중요한 작업이다.)
테스트가 올바르게 진행되어야 소프트웨어의 품질이 보증된다.
Validation-유효성 (우리가 필요했던 프로그램인가? 요구사항에 맞는 프로그램인가? Are we building the right product?)
-> 소프트웨어가 명시된 요구사항을 만족하는지 확인. 요구사항 명세서 보고 판단. invalid 프로그램은 쓸모가 없음.
Verification-검증 (올바르게 제작되었는가? 개발방법론이 제대로 평가되고 진행되었는가? Are we building the product right?)
-> 개발 프로젝트 중 각 단계별로 고객의 요구사항이 반영되었는지 검사. 품질검토(워크스루, 인스펙션) 등의 기법이 있다.
하지만 대부분의 경우에 테스트를 개발자의 역량에 맡긴다던가, 문제가 안일어난다고 가정하고 프로젝트를 진행하더라.
아무튼 테스트의 종류는 다음과 같다.
*시험 방법
– 화이트 박스 테스트 (코드기반 시험)
1) statement coverage :
모든 코드가 한번은 실행되게 입력. (코드의 에러여부 파악)
2) decision coverage(branch test) :
코드의 흐름에서 모든 진행을 테스트. 예를들어 if 구문이 2개라면 4개의 흐름(4종류의 입력)을 만들어야함.
3) condition coverage :
조건문이 있을 떄 , 예를들어 If 구문의 조건을 보고 조건에 맞는 input과 안맞는 input을 넣어서 유입되는지 테스트.
IF(조건상황들) 이라면 조건상황들이 true인 조건과, false인 조건을 찾아서 입력
4) multiple condition coverage :
조건문의 true false에 모든 상황을 고려.
조건이 IF (A&B) 일때 4가지 입력이 발생(T,T T,F F,T F,F)
– 블랙 박스 테스트 (Input, Output 기반의 시험)
1) syntax testing :
입력에 올바른 값과 올바르지 않는 값을 넣어서 테스트
2) Equivalent partitioning :
입력을 동등하게 쪼개고(예를들어서 학점 프로그램이라면 0~70,71~80,81~90,91~100 으로 쪼갠다.), 각 영역의 대표값을 입력하는 테스트(45,73,87,95 를 입력해서 각각 F,C,B,A 가 나와야 할것이다).
3) Boundary testing :
입력값의 경계를 테스트한다.
예를들어 학점 프로그램이라면 A와 B의 경계인 89,90,91 을 입력해본다.
4) Decision table :
입력값의 종류를 결정
표 출처 : 어떤 전공서적의 보조자료 PDF.
입장료 프로그램의 경우 위와 같은 표를 작성해서 테스트.
– 기능 시험 : 기능이 동작하는가?
– 성능 시험 : 성능이 잘 나오는가? (예 : 40명 사용시스템 이라면 40명이 사용해봄)
– 스트레스 시험 : 극한에서 버티는가? (40명 시스템에 100명을 넣어봄)
– Benchmark 시험 : 기존의 다른 시스템과 비교
– Field 시험 : 실 사용자와 테스트
– 리그레션 테스트 : 수정하고 다시 테스트진행.(수정할 때 마다 많은 테스트를 또 해야하므로 비용이 많이든다.)
– 품질 보증 : ISO 나 인증받을 곳 있으면 인증 받을 수 있는지 테스트. (웹 프로그램의 경우 웹 접근성인증 같은것을 받기도 한다. 이러한 테스트&보증을 받는 것.)