테스트란?

테스트가 뭔지 모르시는 분은 없으시겠죠?

“Too little testing is a crime – too much testing is a sin”
“너무 적은 테스트 수행은범죄 지만, 너무 많은 테스트 수행은 죄악 이다 ! ! !”
이 뜻은
과소 테스트 위험은 프로덕션 환경에 존재하는 시스템 결함으로 직접 연결되며, 과잉 테스트의 위험은 결함이 없거나 거의없는 시스템에서 귀중한 자원을 불필요하게 사용한다는 것입니다.

소프트웨어공학에서의 테스트의 정의는

Test : An Activity in which a system orcomponent is executed under specified conditions, the results are observed orrecorded, and evaluation is made of some aspect of the system or component. (IEEE 정의)
→ 특정 조건에서 시스템이나 콤포넌트가 수행되고, 결과가 관찰, 기록되고 평가가 이루어지는 활동

또한 Verification 과Validation 측면으로 테스트를 구분할 수 있습니다.

CMMI 에서의 정의를 보면

*Verification : To ensure that selectedwork products meet their specified requirements
*Validation : To demonstrate that a productor product component fulfills its intended use when placed in its intendedenvironment

• Verification : You built it right

• Validation : You built the right thing

  정리를 해보면 Verification(검증)은 요구된 설계대로 산출물(제품)이 제대로 만들어 졌는지를 보증하는 것이며, Validation(확인)은 (고객이) 의도한 바 대로 사용할 수 있는 제품인지를 충족하는지를 나타내는 것이다.

  핵심키워드는 Verification은 설계대로 이며, Validation은 의도된 사용(Intended Use)입니다.

  첫날 그네 그림으로 설명했듯이 설계대로 제대로 만들어서 Verification은 통과하여 고객에게 인도하려고 했으나, 고객이 의도한 바대로 만들어 진 것은 아니기 때문에 Validation에서는 만족하지 못할 수 있는 이유입니다.

  이 분류에 따른 테스트는 보통,

  Verification : 단위테스트, 통합테스트, 사용자테스트 이고
  Validation : 사용자 승인테스트라고 할 수 있지만,

  사실은 고객(End User)이 단위테스트, 통합테스트, 사용자 테스트에 같이 참석하면 Validation이 될수 있는 것이다. 물론 개발자도 사용목적에 부합되도록 테스트를 제대로 할수 있다면 이것도 Validation이 될 수 있습니다.

  물론 테스트 이전의 Verification & Validation 활동도많이 있습니다.

Verification	Validation
- Inspection - Walkthrough - Prototype - Modeling - 경로 범위 테스트 - 부하, 스트레스, 성능 테스트 - 의사 결정 –테이블-기반 테스트 - 기능적 –분할-기반 테스트	- 공식검토 형태의 사용자와 토의 - 프로토타입 demonstration - 기능 demonstration - 교육 교재 파일럿 - 최종 사용자와 이해관계자에 의한 테스트 - 제품과 제품 컴포넌트 분석(시뮬레이션, 모델링, 사용자 분석)

이번 시간은 테스트에 대한 이야기 이므로 테스트에 대한 이야기만 하겠습니다.

우리가 제대로 테스트하고 있는지 자신있게 말씀하실 분 계신지 궁금합니다.

서두에 언급한 격언을 되새겨보면서 어느 정도로 테스트를 수행해야 테스트가 충분한가? 라는 질문도 드리고 싶습니다.

 

 

본인이 프로젝트 PM이라고 가정하고,단위테스트, 통합테스트, 사용자승인테스트를 차례로일정수립을 하였습니다. 단위테스트가 완료되면 통합테스트를 하도록 일정을 잡았을 겁니다.

여기서 단위테스트가 완료되었다는 것을 어떻게 판단해야 할까요?

100% 모든 경우의 수가 테스트 되면 단위테스트가 완료된 것이겠지만 가능할 까요? IF ELSE 문이하나 있으면 테스트 케이스는 최소 2개, IF ELSE 문이 10개 있으면210 즉 1024개가 나옵니다.

실제로 프로젝트를 하다보면 요구사항을 확정했지만 요구사항대로 개발이 되지 못하거나, 요구사항대로개발은 했지만 테스트 실패를 하고 설계 문제로 재작업이 어려움에 봉착할 수 도 있습니다. 이럴때 단위테스트 결과가 100% 되지 않을 겁니다. 그렇다고 프로젝트 일정을 미루고 계속적으로 단위테스트를 수행할 것인가, 실패이지만 다음단계인 통합테스트를 수행해야 하느냐 결정을 해야 겠죠. 아마 테스트를 100% 완료한다는 것은 영원히 불가능할 겁니다.

이때, 테스트 커버리지 관리가 필요한 이유입니다. 단위테스트커버리지가 90% 이면 다음단계로 진행한다라고 테스트계획서에 정의를 하고 일정을 수립하는 거죠.

테스트 커버리지에 대한 이론은 다양하게 있습니다만,

많이 이야기 하는 것이 요구사항커버리지, 기능커버리지, 프로그램 커버리지 등이 있습니다.
요구사항 커버리지는 전체 정의된 요구사항 대비 테스트된 요구사항을 관리하는 것이고,
기능커버리지는 정의된 전체 기능 중 테스트 된 기능을 관리하는 것이며,
프로그램커버리지는 전체 프로그램 중 테스트된 프로그램을 관리하는 것입니다.
프로그램커버리지는 다시 코드/브랜치/문장커버리지로 나뉘어 집니다.
대표적인 코드 커버리지는 전체 코딩된 라인수 대비 테스트 된 라인수를 관리하는 것인데, 라인을 셀수 있는 툴이 있어야 제대로 된 코드커버리지를 계산할 수 있을 겁니다.

단순히 코드커버리지만을 관리하는 것이 아니라 하나 이상의 커버리지 전략을 수립하는게 테스트 성공요소가 될 것 입니다.

-To Be Continued -