<9> Verification, Validation, and Test

이 글은 기말고사가 22시간 남은 학부생이 기말고사 암기를 위해 작성한 내용입니다... 내용은 지현박교수님의 강의자료를 참고하였음을 밝힙니다...........크리스마스니까 🎄

 
 

 
🎄용어 정의 🎄

 

1) Verification : 완전성의 결정과 단계 or 하위단계의 요구사항의 정확한 명세와 구현
" Are we building 'right product'? "-> 올바른 방향으로 프로덕트를 만들고 있나?
 
2) Validation : 시스템이 고객의 요구사항을 만족하는지 확인
" Are we building 'product right'? " -> 제대로된 제품인가?
 
3) Review : 작업제품검사 .. -> 체크리스트로 진행 가능 / 단계마다 검토 (static test)
 
4) Testing : 요구사항을 만족하는지 확인 + 이상 감지.
실행시킨 결과 == 기대한 결과 ? (dynamic test)
 
 
-- 1) 과 2)의 차이 알기 / 3) 과 4)는 모두 결함 찾기에 focus --

 
자 implementation의 결과물이 1) source 파일과 2) exe 실행파일이 있는데,
1)은 Design phase verification에 사용함! 
ㄴ reveiw, simulation, analysis techniques를 이용해서 corrctness, completeness, consistency 등을 확인함 
ㄴ 추가로, 이전 단계가 잘 됐는지 확인하는 과정도 거침(둥근 화살표)
 
2)는 Test phase verification에 쓰임!
ㄴ 직접 실행파일을 돌려 보고 시험환경 내에서 작업 제품이 요구사항을 준수하는지 확인!
 

---

 
🎄 TEST CASE 🎄

 

- 요구사항, 설계문서를 바탕으로 테스트 케이스 생성

• 테스트 케이스명, 목적
• 사전 조건(test를 위해 만족되어야 하는 조건)
• 테스트 데이터
• 테스트 절차 (어떤식으로 테스트할 건지)
• 예상결과 
• 테스트 환경
• 실제결과
• 테스트 소요시간, 우선순위 .. 등

 

---

 

🎄 error, fault, failure의 구분🎄
 

 
자 위 그림을 보겠습니다.파란 네모와 보라색 네모가 있네요.
파란색은 우리가 만들고자 했던 제품의 스펙이고, 보라색은 실제로 만들어진 제품의 스펙인데요.
원 스펙에서 실제 구현된 스펙을 제외한 찐한 파란색 부분이 Omission(누락 부분)입니다. 그림이 재밌다고 설명해주셨는데
재미...어믕더음
 

---

Error : 사람이 만드는. . 실수
Fault : Error가 어떤 식으로 나타나는지 (bug, defect)

• SW fault (non-phy) : Incorrct specification, coding, sw design ..
• HW fault (phy) 
  • 영구적 fault : damage, fatigue, improper manufacturing 으악 폰 깨짐 이런 거
  • 일시적 fault : due to voltage fluctuations, electromagnetic inference, radiation 큰 자석 때문에 작동 오류 이런 거

Failure : 잘못된 결과, 이상한 동작..
 
--  Error -> Fault -> Failure 이런 식으로 인과관계가 성립됨!

---

🎄 Testing and Debugging의 구분🎄
 

이거 빈칸문제로 나와도 맞출 수 있게.. 해자

 
Testing(테스터가!!!!!!!!!!!) : finds failure that are caused by bugs (문제를 찾기 위해)
Debugging (개발자가!!!!!!!!) : identifies the root cause of a bug, repairs the code, checks that the defect is fixed correctly
Confirmation Testing(테스터가!!!!!!!!!!!) : ensure the fix resolves the observed failure

 
 
다시 그림을 봅시다 그림 아래쪽부터 설명드러감!

 

🎄단위테스트 (unit/component test)

• 개발자가 구현한 모듈을 테스트 (개발자가 테스트!!!!!!!!!!!!!!!)
• 각 모듈에 대하여 검사하며, low-level design 단계의 설계서 상의 정의된 내용 이용
• 결함이 발견되면 -> 수정이 용이
• 뒤에서 배울 white-box 테스트가 주된 방법

  *Driver : 내가 원하는 함수를 실행하게 해주는 main과 같은..
  *Stub : 다른 사람이 작성해둔 함수를 호출해야하는 경우

---

🎄통합테스트 (Integration test)

• 단위 테스트를 통과한 개발 SW 모듈, SW와 HW 사이의 인터페이스 및 동작 테스트
• 개발자 외 제 3자 테스터가 테스트!!!!!!!!!!!!!!!!!!
• high-level design 단계에서 나오는 설계산출물의 정보를 이용하여 테스트

---

🎄시스템테스트 (system test)

• 단위, 통합 T 완료 후 진행
• 분석 단계의 요.사에 따라 시스템 개발되었는지 검사 
• requirement Specification 단계로부터 나오는 정보를 이용하여 T data 생성
• 기능 T(기능적합성)와 비기능 T(성능효율성, 호환성, 사용성 기타 등)

---

🎄인수테스트 (acceptance test)

• 완성된 sys가 얼마나 사용자의 요.사를 만족하였는지 test (사용자가 사용할 만 한가?)
• requirement 단계로부터 나오는 정보를 이용하여 T data 생성
• alpha test : 개발환경에서, beta test : 사용자 환경에서 T

 
*각 테스트 단계마다, plan -> design -> Generation -> Execution & Analysis 단계를 거쳐야 함

 

---

cf 주요 test 활동
1) Test Identification (테스트 대상/항목 정의)
: 도메인 특성, 개발 패러다임, 테스트 단계에 따른, 테스트가 집중되어야 할 테스트 항목을 명확히 파악
 
2) Test data selection (T.C 선정)
: 도메인 특성, 개발 패러다임, 테스트 단계에 맞춘, 즉 파악된 테스트 항목이 효과적으로 테스트 될 수 있도록 하는 T data 선정
 

---

 

 
🎄Test의 원칙🎄
 

" Test는 bug가 있다는 것을 보여주는 활동이지, bug가 없다는 것을 보여주는 활동이 아니다! "
Testing show presence of defect
 

*Exhaustive testing (들어올 수 있는 입력을 모두 Test) 은 불가능!
-> Exhaustive tesing을 할 수 있는 '이론적' test set인 Reliable test set이 있다지만, 그런 알고리즘은 실제로 찾을 수 X
 

"적절한 test set (Adequate test set)을 찾자!"
 

 

•  Pesticide paradox : 새로운 테스트 기술을 시도해라 -> 벌레마다 살충제가 다 다르듯
•  Absence of error fallacy : 많은 bug를 잡아도 고객만족이 높아지지 않을 수 있다
• Context depent :  각 Test는 다 다른 문맥이 있다 ex) u->i->s->a 단계마다 찾고자하는 게 다름
• Defect clustering : 결함이 발생하는 확률이 높은 특정부분이 있다
• Early testing : 테스트를 빨리 시작하는 게 좋다. 뒤에서 결함 찾으면 해결비용이 더 든다악
•  

---

 
🎄Testing Capability level🎄
 

LEVEL1 : performed - 디버깅을 테스트로 인식하는 단계

전략
- SW가 작동하는 것을 보여줄 뿐, SW 품질 보증과 무관 (사실 디버깅임 그냥)

---

 

LEVEL2 : managed - 디버깅과 테스트를 구분(개발자와 테스터를 구분)하는 단계

전략
- 프로젝트 수준에서 프로세스 관리
- 테스트 계획이 늦게 세워짐
- 기능성 중심의 테스트 수행, TC가 수행 직전에 설계
- 독립적 테스트 조직은 없지만, 테스트 연구하는 기술 그룹의 도움을 받음

** 목적은 showing correctness, Test managers are powerless

---

 
LEVEL3 : Defined- SW 개발 생명주기와 통합된 표준 T 프로세스가 정의되는 단계

전략
- 테스트 계획은 요.사 단계에서부터 시작. V-model(앞에서 계속 배운 거) 체계 갖춤
- SW 개발 생명 주기의 단계별 검증과 확인 수행, TC가 관련 생명주기에서 계획됨
- 독립적인 T 전문가 그룹 구성

** 목적은 showing failure, put tester & developers into an adversarial R
 

---

 

LEVEL4 : Quantitatively Managed - 단계별로 진행되는 V&V 작업을 통한 측정 데이터 수집으로 품질이 측정되는 단계

전략
-품질 보증위원회를 구성 -> 테스트 측정 프로그램을 개발 + 수집된 측정 data를 정량적으로 분석하여 SW 품질 평가

  **Test engineers can become technical leaders of the project

---

 

LEVEL5 : Optimizing  

 
전략
- 지속적으로 개선 활동 계획/추진
- 결함 예방과 품질 제어 수행
- 독립적인 T 프로세스 개선 그룹의 지원으로 개선 활동을 계획/추진