[소프트웨어 공학] Verification, Validation and Testing

Fundamentals of SW Test

1. Verification: 잘 만들고 있는가? Are we builing the product right?
2. Validation: 잘 만들었는가? Are we building the right product?
3. Testing: 실행 결과를 확인한다.

 

Testing vs. Debugging

1. Testing: bug로 인해 발생한 문제를 찾는다. (by. tester)
2. Debugging: bug를 발생시킨 문제를 찾고, 코드를 고친다. (by. developer)
3. Confirm testing: failure가 해결되었음을 다시 확인한다. (by. tester)

 

Test Process

• Unit test: 개발자가 자신이 구현한 부분을 테스트한다.
• Integration test: 상호 연동하는 동작을 테스트한다. (by. tester)
• System test: unit test, integration test가 완료된 후, system test
• Acceptance test: 완성된 시스템이 얼마나 사용자의 요구사항을 만족하였는지 테스트한다. (사용자 관점)

 

주요 테스트 활동

• Test identification(테스트 항목 정의)
• Test data selection(테스트 케이스 선정): 효과적으로 테스트될 수 있도록 하는 테스트 데이터를 선정한다.

---

 

Static test

: Non-execution based testing

• Review: 사람에게 의존하는 테스트 방법
• Static analysis
  : 설계/코딩 작성 표준 가이드라인 위반 검사, 설계/코드 메트릭 측정, 런타임 오류 가능성 검사
  • 설계/코드 검증을 위한 품질 측정 도구를 이용하면 자동화가 가능하다.
  • 호스트 PC에서 적용이 가능하다. (임베디드의 경우 장점이 됨)

호스트 PC에서 적용이 가능하다. (임베디드의 경우 장점이 됨)

 

Dynamic test

: Execution based testing

• White-box test
• Black-box test

---

White-box Test

: SW code의 구조에 기반하여 테스트한다.

 

Code-coverage based test

 : 코드가 얼마만큼 실행되었는가?

• Code coverage(All path): 모든 경로를 실행하는 테스트
• Statement coverage(All node): 프로그램 문장을 적어도 한번 실행하도록 하는 테스트
• Branch coverage: 모든 조건문의 결과(decision)에 대한 coverage
• Condition coverage: 모든 조건문의 세부 항목(condition)에 대한 coverage
• Multiple condition coverage: 모든 condition에 대한 coverage
• Condition/Decision coverage: 모든 조건문의 모든 decision과 그 안의 모든 condition에 대해 T/F가 모두 수행되도록 하는 테스트 --> decision/condition 모두에 대해 보장한다.
  
  • MC/DC(Modified Condition/Decision coverage): 전체 decision에 영향을 주는 condition인 major condition이, 전체 decision 결과에 실질적인 기여를 하도록 테스트

임베디드 SW에서 code-coverage based test가 자주 이용되는 이유

 

Mutation test

• Mutant: 결함이 있는 프로그램 (대상의 일부를 변경시켜서 만든다.)

: 프로그램과 뮤턴트를 구분해주는 결과값을 내는 뮤턴트를 찾아서, 결함을 감지해내는지 테스트한다.

 

Mutation test는 뮤턴트를 굉장히 많이 만들어야 하기 때문에, 오버헤드가 커서 잘 사용하지 않는 방법이다.

- Mutation test 이용 예) 자동차 -- 사전에 예외적인 상황을 결함으로 만들어서 테스트한다.

---

Black-box Test

: 테스트 대상 SW 코드 내용은 보지 않고, 입력값에 대한 프로그램 실행 결과가 올바른 출력인지 테스트한다. (by. tester)

• Equivalent partitioning(동치분할): 동치분할하여 valid/invalid equivalence class로 나누고, 클래스 내에서 그룹화하여 대표값을 선정한다. 그 대표값들을 테스트 케이스에 반영하여 테스트한다.
• Boundary value analysis(경계값 분석): 동치분할 --> 클래스 내에서 그룹화하여, 경계 부분에서 대표값을 정한다.
• Decision table(결정 테이블): 요구사항을 단순화하여 결정테이블을 만든다.
• State-based testing(상태 기반 테스트): state, transition, event, guard(조건), action으로 상태도를 구성하여, 상태 및 변화를 표현한다.
• Pair-wise(조합 테스트): 2개 요소의 상호작용에 의한 테스트가 결함을 보다 더 잘 발견한다는 경험에 기반한 테스트 방법으로, 테스트 대상 아이템의 모든 factor에 더하여, 두 개 요소의 모든 조합을 생성한다.

 

---

Q. 테스트가 중요한 이유?

1) To save cost.

- Therefore, in my opinion unit-test especially is important. (Early testing: testing should be held as soon as possible in software system development life cycle).

- And the developer does unit test not the tester.

 

2) 소프트웨어 품질 평가

- debugging과 testing이 구별되지 않는 단계에서 testing은 '소프트웨어가 작동하는 것'을 보여줄 뿐, 소프트웨어의 품질 보증과는 무관하다.

- 하지만 testing capability level이 높아지고 전문적인 테스팅이 진행되고 나면, 테스트 측정 프로그램이 개발되고, 수집된 측정 데이터를 정량적으로 분석하여, '소프트웨어 품질'을 평가할 수 있게 된다.

 

 

Q. 테스트에서 중요한 것?

- Not only deciding what to test but also the selection of test data is important. 

- Software testing: Process of selecting good test data locating fault in the program.

 

Q. Black-box test가 이해가 안 된다고 하였다. 무엇이 이해가 안 되는가?

- 블랙박스 테스트: 소프트웨어가 작동하지 않는 부분을 확인할 수 있다. But, 결국 고치려면 코드를 봐야 하기 때문에 화이트박스 테스트가 필요할 것 같다.

- But there must be some benefits for black-box test and that must be the reason why it exists. I would like to know what that is. 

- Also, I studied that white-box test - related to embedded system ..~

+ White box test 중 code-coverage based test를 통해서 로봇 테스트 코드를 작성해보고 싶어요!!