4.4 Structure-based or white-box techniques (구조 기반 또는 화이트 박스 기법)

Terms 

Code coverage, decision coverage, statement coverage, structure-based testing.

Background

Structure-based testing/white-box testing is based on an identified structure of the software or system, as seen in the following examples:

-    Component level : the structure is that of the code itself, i.e. statements, decisions or branches.

-    Intergration level : the structure may be a call tree (a diagram in which modules call other modules).

-    System level : the structure may be a menu structure, business process or web page structure.

In this section, two code-related structural techniques for code coverage, based on statements and decisions, are discussed. For decision testing, a control flow diagram may be used to visualize the alternatives for each decision.

4.4.1 Statement testing and coverage

In component testing, statement coverage is the assessment of the percentage of executable statements that have been exercised by a test case suite. The statement testing technique derives test cases to execute specific statements, normally to increase statement coverage.

4.4.2 Decision testing and coverage

Decision coverage, related to branch testing, is the assessment of the percentage of decision outcomes (e.g. the True and False options of an IF statement) that have been exercised by a test case suite. Decision testing derives test cases to execute specific decision outcomes, normally to increase decision coverage.

Decision testing is a form of control flow testing as it generates a specific flow of control through the decision points. Decision coverage is stronger than statement coverage: 100% decision coverage guarantees 100% statement coverage, but not vice versa.

4.4.3 Other structure-based technisuqes

There are stronger levels of structural coverage beyond decision coverage, for example, condition coverage and multiple condition coverage.

The concept of coverage can also be applied at other test levels (e.g. at integration level) where the percentage of modules, components or classes that have been exercised by a test case suite could be expressed as module, component or class coverage. 

Tools support is useful for the structural testing of code.

배경 설명

구조 기반 테스팅 / 화이트 박스 테스팅은 아래 예시와 같이 소프트웨어나 시스템의 구조를 중심으로 테스팅하는 것이다.

-    컴포넌트 레벨 : 구문, 결정 또는 분기문 등 코드 그 자체

-    통합 레벨 : 한 모듈이 다른 모듈을 호출하는 관계를 도식화한 콜 트리 등

-    시스템 레벨 : 메뉴 구조, 비지니스 프로세스 혹은 웹 페이지 구조 등

이번 섹션에서는 코드 커버리지를 위한, 코드와 관련된 구조 기법인 구문 테스팅과 결정 테스팅이 논의 된다. 결정 테스팅을 수행할 때 제어 흐름도는 각 결정문의 대체 흐름을 가시화하는데 사용될 수 있다.

4.4.1 구문 테스팅과 커버리지

컴포넌트 테스팅에서 구문 커버리지는 테스트 케이스 스위트(묶음)에 의해 실행된 구문이 몇 퍼센트인지를 측정하는 것이다. 구문 테스팅은 구문 커버리지를 늘리기 위해 특정 구문을 테스트하는 테스트 케이스를 도출하는 것이다.

4.4.2 결정 테스팅과 커버리지

분기문 테스팅과 관련된 결정 커버리지는 테스트 케이스 스위트에 의해 실행된 조건문 분기(if구문의 참 혹은 거짓)가 몇 퍼센트인지를 측정하고 평가하는 것이다. 결정 테스팅은 결정 테스팅은 결정 커버리지를 늘리기 위해 특정 조건문의 분기를 테스트하는 테스트 케이스를 도출하는 것이다.

결정 테스팅은 결정 포인트에 해당하는 제어 흐름을 다루므로 제어흐름 테스팅의 한가지 형태이다. 결정 커버리지는 구문 커버리지보다 강력하여 100% 결정 커버리지를 달성할 경우, 100% 구문 커버리지를 달성함을 보장한다. 그러나 반대의 경우는 성립하지 않는다.

4.4.3 다른 구조 기반 기법

조건 커버리지나 다중 조건 커버리지와 같이 결정 커버리지 보다 강력한 레벨의 구조적 커버리지가 존재한다. 커버리지의 컨셉은 다른 테스트 레벨에도 적용될 수 있다. 예를 들어, 통합 테스팅에서는 테스트 케이스 스위트에 의해 몇 퍼센트의 모듈, 컴포넌트, 클래스가 실행되었는가를 기준으로 모듈, 컴포넌트, 클래스 커버리지를 생각할 수 있다.

코드의 구조를 테스팅할 때에는 툴의 지원이 유용하다.