4.3 Specification-based or black-box techniques (명세 기반 기법 또는 블랙 박스 기법)

Terms 

Boundary value analysis, decision table testing, equivalence partitioning, state transition testing, use case testing.

4.3.1 Equivalence partitioning 

inputs to the software or system are divided into groups that are expected to exhibit similar behavior, so they are likely to be processed in the same way. 

equivalence partitions (or classes) can be found for both valid data and invalid data, i. e. values that should be rejected. Partitions can also be identified for outputs, internal values, time-related values (e.g. before or after an event) and for interface parameters ( e.g. during integration testing). Tests can be designed to cover partitions. Equivalence partitioning is applicable at all levels of testing.

Equivalence partitioning as a technique can be used to achieve input and output coverage. It can be applied to human input, input via interfaces to a system, or interface parameters in integration testing.

4.3.2 boundary value analysis

Behaviour at the edge of each equivalence partition is more likely to be incorrect, so boundaries are an area where testing is likely to yield defects. The maximum and minimum values of a partition are its boundary values. A boundary value for a valid partition is a valid boundary value; the boundary of an invalid partition is an invalid boundary value. Tests can be designed to cover both valid and invalid boundary values. When designing test cases, a test for each boundary value is chosen.

Boundary value analysis can be applied at all test levels. It is relatively easy to apply and its defect-finding capability is high; detailed specifications are helpful.

This technique is often considered as an extension of equivalence   partitioning. It can be used on equivalence classes for user input on screen as well as, for example, on time ranges (e.g. time out, transactional speed requirements) or table ranges (e.g. table size is 256*256). Boundary values may also be used for test selection.

4.3.3 Decision table testing

Decision tables are a good way to capture system requirements that contain logical conditions, and to document internal system design. They may be used to record complex business rules that a system is to implement. The specificatioin is analyzed, and conditions and actions of the system are identified. The input conditions and actions are most often stated in such a way that they can either be ture or false (Boolean). The decision table containes the triggering conditions, often combinations of true and false for all input conditions, and the resulting actions for each combination of conditions. Each column of the execution of the actions associated with that rule. 

The coverage standard commonly used with decision table testing is to have at least one test per column, which typically involves covering all combinations of triggering conditions.

The strength of decision table testing is that it creates combinations of conditions that migth not otherwise have been exercised during testing. It may be applied to all situations when the action of the software depends on several logical decisions.

The coverage standard commonly used with decision table testing is to have at least one test per column, which typically involves covering all combinations of triggering conditions.

The strength of decision table testing is that it creates combinations of conditions that might not otherwise have been exercised during testing. It may be applied to all situations when the action of the software depends on several logical decisions.

4.3.4 State transition testing

A system may exhibit a different response depending on current conditions or previous history (its state). In this case, that aspect of the system can be shown as a state transition diagram. It allows the tester to view the software in terms of its state, transitions between states, the inputs or events that trigger state changes(transitions) and the actions which may result from those transitions. The states of the system or object under test are separate, identifiable and finite in number. A state table shows the relationship between the states inputs, and can highlight possible transitions that are invalid. Tests can be designed to cover a typical sequence of states, to cover every state, to exercise every transition, to exercise specific sequences of transitions or to test invalid transitions.

State transition testing is much used within the embedded software industry and technical automation in general. However, the technique is also suitable for modeling a business object having specific state or testing screen-dialogue flows (e.g. for internet applications or business scenarios).

4.3.5 Use case testing

Tests can be specified from use cases or business scenarios. A use case describes interactions between actors, including users and the system. which produce a result of value to a system user. Each use case has preconditions, which need to be met for a use case to work successfully. Each use case terminates with post-conditions, which are the observable results and final state of the system after the use case has been completed. A use case usually has a mainstream (i.e most likely) scenario, and something alternative branches.

Use cases describe the "process flows" through a system based on its actual likely use, so the test cases derived from use cases are most useful in uncovering defects in the process flows during real-world use of the system. Use Cases, often referred to as scenarios, are very useful for designing acceptance tests with customer/user participation. They also help uncover integration defects caused by interaction and interference of different components, which individual components testing would not see.   

4.3.1 등가 분할 

소프트 웨어나 시스템의 입력 값은 입력의 결과로 나타날 결과 값이 동일할 경우 하나의 그룹(클래스)으로 간주될 수 있다. 그리고 이러한 그룹 내의 입력값은 내부적으로 같은 방식으로 처리 됨을 가정한다. 동등 분할 클래스는 유효한 입력 데이터와 유효하지 않은 입력 데이터(입력되지 말아야 할 값)를 포함할 수 있다. 입력 값 이외에도 출력 값(Outputs), 내부 값(Internal values), 시간 관련 값(Time-related values, 이벤트 이전과 이후), 통합 테스팅에서 다루는 모듈간 인터페이스 파라미터(Interface parameters) 에 등가 분할을 적용할 수 있다. 테스트는 등가로 분할된 영역을 커버하기 위해 설계된다. 이 기법은 사람에 의한 입력, 인터페이스를 통한 시스템의 입력, 혹은 통합 테스팅에서 인터페이스 파라미터에 적용될 수 있다.

4.3.2 경계 값 분석

동등 분할의 경계 부분에 해당되는 입력 값에서 결함이 발견 될 확률이 경험적으로 높기 때문에 결함을 방지하기 위해 경계 값까지 포함하여 테스트하는 기법이다. 해당 분할영역의 최대값과 최소값은 그 영역의 경계 값이 된다. 유효한 분할 영역의 경계 값은 유효 경계 값이 되며, 비 유효한 분할 영역의 경계 값은 비 유효 경계 값이 된다. 테스트는 유효 경계 값과 비 유효한 경계 값 모두 커버될 수 있도록 설계 될 수 있다. 테스트 케이스 설계 시에, 각 경계 값이 선택된다.

경계 값 분석은 모든 테스트 레벨에서 적용이 가능하다. 상대적으로 적용하기 쉽고 결함 발견 확률이 높다. 경계값을 명시한 자세한 명세서가 지원 될 경우 적용하기가 수월하다.

경계값 분석 기법은 종종 등가 분할의 확장으로 여겨지며, 등가 분할과 동일한 방식으로 커버리지를 보장한다. 또한 스크린에서 사용자에 입력에 대한 등가 클래스에서도 사용 될 수 있다. 예를 들면, 시간 경과, 트랜잭션 속도 요구 사항과 같은 시간 범위(Time ranges) 또는 테이블 크기와 같은 테이블 범위(Table ranges)에 적용이 가능하다.  경계값 분석은 테스트 데이터 선택에도 사용 될 수 있다.

4.3.3 결정 테이블 테스팅 

결정 테이블은 논리적인 조건이나 상황을 구현하는 시스템 요구사항을 도출하거나 내부 시스템 디자인을 문서화하는 매우 유용한 도구이다. 이것은 시스템이 구현해야 하는 복잡한 비지니스 규칙을 문서화하는데 사용된다. 명세를 분석하고, 시스템의 조건과 동적을 식별한다. 입력 조건과 동작은 참과 거짓으로 주로 표현한다. 결정 테이블은 동작을 유발시키는 조건 또는 상황, 그리고 각 해당 조합에 대한 예상 결과까지 포함한다. 테이블의 각 컬럼은 비지니스 규칙과 대응 관계를 갖는다. 해당 비지니스 규칙은 유일한 조건의 조합을 정의하고, 조건의 조합은 해당 비지니스 규칙과 연관된 동작을 수행하게 한다. 실무에서 결정 테이블을 사용할 때 일반적인 커버리지는 각 컬럼당 적어도 하나의 테스트 케이스를 생성하는 것이다. 이는 일반적으로 모든 가능한 동작을 유발시키는 조건의 조합을 커버 한다.

결정 테이블은 테스팅 기간 동안 결정 테이블을 사용해야만 발견할 수 있는 조건들의 조합을 찾아내고 생성 해낼 수 있다.  해당 기법은 소프트웨어의 동작이 여러 가지 논리적 조건에 의존적인 모든 경우에 적용이 가능하다.

4.3.4 상태 전이 테스팅 

시스템은 현재 상황이나 이전의 이력을 반영하는 상태 및 그 변화에 따라 다르게 동작할 수 있다. 시스템의 이러한 측면을 상태 전이 다이어그램으로 표현할 수 있다. 상태 전이 다이어그램을 통해 테스트 엔지니어는 소프퉤어 또는 시스템을 상태 사이에 관계 즉, 상태 간의 전이, 상태를 변화시키는 이벤트와 입력값, 상태의 변화로 유발되는 동작 등으로 파악한다. 이때 테스트 대상 시스템이나 객체의 상태는 개별적으로 식별 가능하고 유한한 개수로 표현된다. 상태 전이다이어그램을 테이블 형태로 전환한 상태 테이블은 상태와 입력값 간의 관계를 보여주고 개연성은 있지만 요구사항과 맞지 않는 전이를 보여줄 수도 있다. 상태 전이 테스팅을 통해 전형적인 상태의 순서를 커버하는 방식, 모든 상태를 커버하는 커버하는 방식, 모든 상태 전이를 실행하는 방식, 특정한 상태 전이 순서를 실행하는 방식 또는 불가능한 상태 전이를 테스트하는 방식으로 테스트 설계하는 것이 가능하다.

상태 전이 테스팅은 일반적으로 임베디드 소프트웨어 산업분야나 기술적으로 자동화가 필요한 부분에서 사용된다. 그 뿐만 아니라 특정한 상태를 갖는 비지니스 객체 모델링이나 (인터넷 애플리케이션 또는 비지니스 시나링ㅗ와 같이) 화면 - 대화창 흐름을 테스팅 할 때도 적절히 적용할 수 있다.

4.3.5 유즈케이스 테스팅

유즈케이스나 비지니스 시나리오를 기반으로 테스트를 명세화할 수 있다. 하나의 유즈케이스는 액터(유저 혹은 시스템)와 액터 사이에 상호작용을 표현하고, 해당 상호작용은 시스템 유저에게 결과값을 제공한다. 각각의 유즈케이스는 그 유즈케이스가 성공적으로 수행되기 위한 전제 조건을 가지고 있다. 또한 각각ㄱ의 유즈케이스는 임무를 완료한 후 후속 조건을 가지면서 종료된다. 유즈케이스는 대게 주류 시나리오 또는 기본 흐름과 대체 흐름으로 구성되어 있다. 

유즈케이스는 시스템이 실제 사용되는 방식에 기반하여 "프로세스 흐름"을 기술하고 있다. 따라서 유즈케이에 기반하여 생성된 테스트 케이스는 시스템이 실제 사용되는 프로세스 흐름에서 결함을 발견하는데 상당히 유용하다. 시나리오라고 불리는 유즈케이스는 고객이나 유저 그룹을 참여시키는 인수 테스트를 디자인 할 때 매우 유용하다. 또한, 유즈케이스 테스팅은 통합 단계에서 서로 다른 컴포넌트 사이에 상호작용과 간섭으로 발생하는 통합 결함을 찾는데 도움이 된다.