[소프트웨어공학] Software Testing

양현지·2023년 6월 1일

소프트웨어공학

목록 보기

5/11

1. V&V

S/W Testing is V&V activity

Verification(검증) : User Requirement를 제대로 반영했는가?
=> '제대로'에는 기준이 필요
=> Requirement Spec을 기준으로 검증을 수행
Validation : 제대로된 S/W를 개발했는가?

1) Goals of V&V

SW가 원래 목적에 적합한가에 대한 신뢰를 얻고자
but, 결함으로부터 자유로울 수는 없음

내가 할 수 있는 test를 모두 통과하였다고 해서 완벽한 SW라고 할 수 X
=> 내가 의도한 바로 사용하는 데에는 충분하다고 판단할 수는 있음

2) Types of Verification

① Static verification(=inspection) : before compile

static system representation 분석
작성한 diagram, 소스 코드, class diagram 등 모든 것이 inspection object
※ Pair programming(of XP)
- 1명은 code writing
- 1명은 inspection (Reviewing)

② Dynamic verification(=testing) : runtime에 검증

Test case를 사용해 동작을 검증

모든 프로젝트는 inspection + testing이 모두 필요
S/W critical 할수록 inspection이 중요해짐
e.g. 핀테크 기업, 자율주행제어SW 등 (SW의 결함이 치명적인 결과로 이어지는 경우)

2. Inspections & Testing

① 상호 보완의 관계
: 둘 다 필요

② Inspection은 non-functional에 대해 검증을 수행할 수 없다. (실행을 통해서만 검증할 수 있음)

e.g. performance , usability(design), etc.

1) Inspection

: 이상 혹은 버그(defect)를 찾고자 소스 코드를 분석

즉, 소스코드의 빌드와 실행이 필요하지 않음 (static verification)
경험과 지식을 토대로 자주 버그가 발생하는 지점 혹은 포인트를 잘 찾을 수 있음
Testing과 달리 한 번에 여러 버그와 이상을 발견할 수 있음 (물론 프로젝트 규모에 따라 한 번에 보는 것이 거의 어려우나, Testing과 차이점이라고 할 수 있음)

(물론, 팀단위로 수행할 때는 개인의 능력에만 기대기 보다 포멀한 방식으로 진행)
(참고로,C/C++의 경우 포인터 사용 방식을 보연 개발의 수준이 보임..)

2) Program Inspection

: documents들을 리뷰하는 formal한 접근 방식을 통해 defect detection을 수행하고자 함(수정이 목적이 아님)

※ 일반적으로 QA에서 진행하며 QA팀은 "버그 리포팅"을 수행하고 "버그 개선"은 수행하지 않음

What is Defect?
ⓐ logical errors(구현 목적을 달성하지 못함)
ⓑ anomalies in the code (결함 발생 확률이 높은 곳)
▷ e.g. uninitialized variable or non-compliance with standard
▷ 여기서 standard란 compiler가 지원하는 spec, 사전에 협의한 coding convention 등을 의미

3) Pre-conditions of Inspection

⑴ precise specification
⑵ Syntactically correct code
⑶ error checklist should be prepared (② 글에서 다룰 예정)
⑷ Management(SW 개발의 결정권자)는 SW개발이 끝났어도 Inspection cost 발생에 대해 알고 관리해야함
⑸ staff을 평가하는데 inspection을 사용하지 말 것