Test Case Selection and Adequacy

Learning Objectives

• Test Adequecy Criteria를 정의하는 이유와 한계 이해하기
• Test Selection과 Test Adequecy의 기본 용어 이해하기

1. 개요

• 테스트를 다 통과하면 correct하고 할 수 있지만, 모든 테스트를 execute할 수는 없다.
• Adequacy of test suites는 Undecidable하다.
• 따라서 Adequacy의 weaker proxy를 잘 설정해야 한다.

2. Source of Test Specification (#166)

1) Functional Testing

• 분류 기준 : Test Code를 Spec에 적힌 functionality를 보고 만들어서 가져왔니?
• Black box testing
• Project Plan, Software requirement Specification, Sw design spec, Project Functional Requirement ⇒ 을 가지고 testing

2) Structural Testing

• 분류 기준 : Test code를 코드를 보고 structure를 기반으로 만들었니?
• White box testing (Glass-box testing, code-based testing)

3) Model-based Testing (Functional Testing)

• Spec을 모델로 만들어서 하는 testing

4) Fault-based Testing (Functional Testing)

• 경험에 의존해서 이 부분에 이런 fault가 발생할 수 있으니 우선 순위를 줘서 먼저 검사하게 하자.

3. Terminologies in Testing

1. Test Case

• a set of inputs(입력)
• execution conditions(Expected output)
• pass/fail criterion (Test Oracle : output=Expected output 비교를 한번에 할 수 없으니 거치는 과정)

2. Test case specification (Test specification)

• 하나 이상의 test case가 만족해야 하는 requirement
• 즉, test case를 만들기 위한 spec

3. Test Obligation

• Test case specification의 일부로, 철저한 testing을 하기 위해 필요한 속성

4. Test suite

• test case들의 집합

5. Test (Test execution)

• test case를 실행시키고, 결과를 비교하는 과정
• output = expected output 비교

6. Adequacy Criterion

• <program, test suite> 쌍의 True 혹은 False predicate
• Adequacy Criterion = Set of test obligations (의무들의 집합이다)

4. Adequacy Criterion

• Test Suite는 다음과 같은 상황에서 Adequacy Criterion을 만족한다.

  1. 모든 test를 성공적으로 통과하고,

  2. 모든 test obligation들이 test suite에 존재하는 적어도 하나의 test case를 만족해야 한다.

     (obligation들이 무조건 한 번 씩은 만족해야 한다.)

  ex) "The statement coverage adequacy criterion is satisfied by test suite S for program P, if each executable statement in P is executed by at least one test case in S, and the outcome of each test execution was pass"

  

  • But 100% 만족시키기는 사실상 불가하므로 coverage로 나타낸다.
  1. Satisfiability

  • Defensive programming style(예외처리를 엄청 많이 하는) 등의 코딩 스타일은 어떠한 test suite라도 해당 statement를 지나가지 못하게 하는 경우가 존재한다.

  • 해결방법

    1. unsatisfiable obligation을 criterion으로부터 제외하기

       → But 진짜 안지나는지 확신하기 힘들다.

    2. test suite가 adequacy criterion을 얼마나 만족하는지를 퍼센트로 나타내기

       -원래) Adequacy criterion = 만족하는지 안하는지 T/F만

       -수정 후) Coverage measure = obligation을 만족하는 정도

    

  2. Coverage

  : test suite의 thoroughness라고 할 수 있음 (coverage높다 = 충실해 했다)

  • But, coverage는 thoroughness 혹은 adequacy의 대략적인 값일 뿐이지 절대적인 값은 아니다.

  • Functional Coverage : 우리의 test case가 시스템의 functionality (Spec,SRS,SDS) 를 얼마나 cover하는지

    → functional coverage는 항상 100% 여야 한다.

    ⇒ 100%가 아니라면, 해당되는 functional requirement에 대해 test case가 존재하지 않는다(test를 안해봤다)는 것.

  • Structural Coverage : 코드에 있는 structure를 얼마나 cover하는지 (코드에 존재하는 element를 test case가 얼마나 지나는지 봄)

    ⇒ 판단 기준 : statement → decision/branch → condition → mc/dc

    

    • MC(modified condition)/DC(decision coverage)를 만족하면 아래 모든 것들을 만족한다.
    • But, Branch를 만족한다고 해서 MC/DC를 만족하지는 않는다.

    Summary

    • Adequacy criteria는 test suite를 철저하게 할 수 있는 개념을 제공한다.

      → But, 완전히 보장하지는 않는다.

    • Adequacy criteria는 coverage로 나타낼 수 있다. (spec, code, model 등)