요약정리 – 상태, 상태 그래프, 전이 테스팅 by Beizer

출처: 책 Software Testing Techniques by Boris Beizer, Chapter 11 STATES, STATE GRAPHS, AND TRANSITION TESTING, p227-250, 1983년

 

상태 그래프(STATE GRAPHS)

2.1. 상태(states)

특정 시점에서의 애트리뷰트들의 조합이나 관심을 끄는 조건들을 그림으로 나타낸다.

상태 그래프에서 원(노드)이 상태를 표현한다.

 

예를 들어, 문자시퀀스 “ZCZC”를 탐지하는 프로그램은 아래와 같은 상태에 있을 수 있다.

• ZCZC가 발견되지 않았고, ZCZC의 일부 중 어느 것도 발견되지 않음
• Z가 발견됨
• ZC가 발견됨
• ZCZ가 발견됨
• ZCZC가 발견됨

 

2.2. 입력(inputs)과 전이(transitions)

입력으로 인해 상태는 변화하게 되며, 이것을 전이(transition)라고 한다. 전이는 상태들을 잇는 연결선(link)으로 나타내며, 해당 전이를 야기하는 입력은 연결선 상에 표기한다.

 

위 “ZCZC” 탐지 예는 아래의 입력 유형을 가진다.

• Z
• C
• Z 또는 C를 제외한 모든 문자(편의상 A로 표기)

 

2.3. 출력(Outputs)

각 입력(전이)은 결부된 출력(또는 액션)이 있을 수 있으며, 슬래시를 사용하여 “입력/출력” 형태로 표기한다. 어떤 전이와 관련된 모든 입력이 동일한 출력을 야기하면 “입력1, 입력2, 입력3/출력”과 같이 표기하며, 여러 개의 다른 입력/출력 조합이 존재하는 경우라면 각 출력에 대해 별도의 병렬 연결선을 그리는게 좋다.  

 

 “output”은 유형 출력물(tangible outputs)에 국한하지 않고 관찰가능한(observable) 거의 모든 것을 의미한다. 용어 “outcome”이 아니라 “output”을 사용한 이유는 outcome은 출력과 더불어 새로운 상태로의 전이를 포함하기 때문이다(즉, outcome = output + a transition to the new state).

 

상태 그래프 모델. 대표적인 상태 그래프 모델로 Mealy 모델과 Moore 모델이 있는데, 이 책에서 사용한 것은 출력이 전이에 결부된 Mealy 모델이다. Moore 모델은 출력(outputs)을 전이(transitions)가 아니라 상태(state)와 연결 짓는다.

 

2.4. 상태-테이블 표현(State-Table Representation)

상태 그래프는 규모가 커지면 어수선해지고 알아보기 힘들 수 있기 때문에 아래와 같이 표 형식으로 전환하여 사용하기도 한다.

1. 표의 각 행(row)이 상태를 나타냄
2. 표의 각 열(column)이 입력 조건을 나타냄
3. 행과 열의 교차 위치에 다음 상태(전이)와 출력을 표기함

 

좋은 상태 그래프와 나쁜 상태 그래프

3.1. 일반

테스팅 작업자는 좋은(good) 상태 그래프뿐만 아니라 나쁜(bad) 상태 그래프도 마주치게 되는데, “좋다” “나쁘다”의 판단은 소프트웨어 테스트 설계에 사용할 수 있는 종류의 상태 그래프인지에 어느 정도 편향적이다. 상태 그래프를 판단하는 몇 가지 원칙이 아래와 같다.

1. 총 상태 수(the total number of states)가 상태를 이루는 인자들의 모든 가능성을 곱(the product of the possibilities of factors)한 것과 동일하다.
2. 모든 상태와 입력에 대해 정확히 하나의 상태로 정확히 하나의 전이(transition)가 지정된다. 이 때 전이가 지정되는 상태가 자기 자신일 수도 있다.
3. 모든 전이에 대해 하나의 출력 액션이 지정된다. 이 출력이 하잖을 수도 있지만 적어도 하나의 출력은 뭔가 쓸모 있는 일을 한다.*
4. 각 상태에서 시스템을 같은 상태로 다시 돌아오게 하는 입력 시퀀스가 존재한다.**

*출력이 없는 상태 그래프는 실상에서 아무 것도 할 수 없으며, 따라서 무시되기 마련이다. 후속 액션을 야기할 수 있는 뭐라도(하다 못해 1 비트 세팅을 하는 일이라도) 출력으로 포함시켜라.

 **다른 말로 하면 상태 그래프가 “강력 연결된 그래프(strongly connected)” 이어야 한다는 제한을 가한 것이다. 많은 상태 그래프가 강력 연결된 그래프가 아니므로 이 제한이 지나치게 편협해 보일 수도 있지만, 소프트웨어 분야에서는 폭파 장치를 터뜨리는 상황이거나 실패, 복구, 비논리적 또는 회복불가능한 조건을 다루는 경우에만 강력 연결되지 않은 상태 그래프의 사용을 볼 수 있다. 강력 연결되지 않은 상태 그래프는 대개 버그가 있다.

그래프 이론. 방향 그래프(directed graph)에서 정점의 모든 쌍(pairs) 간에 도달가능한 경로가 존재할 때 그래프가 “강력 연결되었다(strongly connected)”고 한다.

 

아래는 부적절한 상태 그래프의 예를 보여준다.

상태 그래프 원칙 3에서 각 전이에 출력이 지정되어 있어야 한다고 했지만, 위 예에서는 이를 위반함. 출력이 현재 관심사가 아니라서 그림이 어수선해지지 않도록 출력 명세 부분은 의도적으로 생략함

 

3.2. 상태 버그(State Bugs)

3.2.1. 상태 수(Number of States)

상태 그래프에서 상태 수는 우리가 인식하고자(또는 모델화하고자) 선택한 상태의 합계이다. 하지만 현실에서는 데이터베이스에 등장하는 변수 값들의 조합이 직접 또는 간접적으로 상태로 기록된다. 예를 들어, 가능한 값 범위가 0~9이고 2-비트 플래그 세팅을 하는 카운터(counter)의 경우 그 값으로 구성된 총 40개의 상태가 나올 수 있다(2´2´10=40).

 

상태 그래프로 모델링하는 소프트웨어 관련 흔한 버그 중 하나가 “모든 상태를 헤아리는데 실패”이다. 상태 그래프의 값들을 기계적으로 인코딩하는 것이 일반적이지 않기 때문에 누락된 상태(missing states)가 생길 가능성이 아주 많다. 상태 수를 아래와 같이 찾아낸다.

1. 상태의 모든 컴포넌트 인자(component factors)를 식별한다.
2. 각 컴포넌트의 모든 허용되는 값(allowable values)을 식별한다.
3. 모든 컴포넌트의 허용되는 값의 수를 곱(product)한 것이 상태 수이다.

 

테스터는 뭔가를 하기에 앞서 내가 생각하는 상태 수와 프로그래머가 생각하는 상태 수를 확인해야 하며, 여기서 의견 차이가 나타나는 것은 흔한 일이다. 얼마나 많은 상태가 존재하는지에 대한 합의 없이 다양한 상태의 시스템 동작을 체크하는 테스트를 설계하는 것은 어불성설이다. 얼마나 많은 상태가 있는지에 대한 합의가 없다면, 특정 상태에서 시스템이 무엇을 하는지와 어떤 전이/출력이 일어나는지에 대해서도 의견이 불일치할 수 밖에 없다.

 

어쩌면 사소할 수도 있는 상태 수를 세는 행위를 이렇게 과도하게 강조하는 이유는 이 행위가 종종 근본적인 설계 결함(design deficiencies)을 발굴하기 때문이다. 설계가 완료될 때까지 기다릴 필요 없이 기능 명세서(functional specification)만 있으면 대개 충분한데, 테스터는 기능 명세서를 읽고 인자와 각 인자의 가능한 값의 수를 식별한 후에 설계자에게 질문을 던진다. 식별된 인자 값들의 조합(combination)에 상응하는 각 상태를 일일이 확인하는 일은 때때로 설계자로부터 “아, 그건 잊고 있었군요”라는 대답을 듣게 되는 보람 있는 작업이다.

 

3.2.2. 불가능한 상태(Impossible States)

인자의 일부 조합은 불가능한 경우가 있다. 예를 들어, 아래와 같은 인자가 있다고 하자.

기어(gear)	R, N, 1, 2, 3, 4	6개 인자
방향(direction)	전진, 후진, 정지	3개 인자
엔진 오퍼레이션	가동중, 정지	2개 인자
변속기(transmission)	정상, 고장	2개 인자
엔진 상태	정상, 고장	2개 인자
총 상태 수 = 6*3*2*2*2 = 144

 

고장난 엔진으로는 가동이 불가하므로 엔진 상태와 엔진 오퍼레이션의 인자 조합이 4개가 아니라 3개 상태만 생성하며, 따라서 총 상태 수는 많아야 108개 이다. 또한 변속기가 고장난 차는 오래 움직이지 못하므로 가능한 상태 수는 더 줄어들 수 있다. 프로그래머가 집계한 상태 수와 테스터가 집계한 상태 수의 불일치는 종종 "불가능한 상태(impossible states)"에 대한 양측의 의견 차이로부터 기인한다.

 

“불가능한(impossible)” 보다는 “추정상 불가능한(supposedly impossible)”이라는 표현이 더 적절한데, 다른 루틴에 존재하는 버그나 알파 입자 같은 예외적인 상황이 항상 있을 수 있기 때문이다. 컴퓨터에서 암시적 또는 명시적으로 기록된 인자 값과 현실에서 해당 인자의 값이 항상 같은 것은 아니다. 이런 대표적인 예가 쓰리마일 아일랜드 원전 사고이다(이 사고에 대해 설명한 다큐영상 보려면 클릭). 이 사고의 기여 요인 중 하나는 액츄에이터(actuator)의 실제 위치와 그것의 보고된 위치에 차이가 있었던 것인데, 설계자들은 액추에이터의 실제 위치가 보고된 위치와 달라지는 것은 "불가능" 하다고 잘못된 가정을 했다(즉, 아래 두 가지 상태가 불가능하다고 가정함). 

"Actuator-UP/Actuator-Indicates-DOWN"

"Actuator-DOWN/Actuator-Indicates-UP"

 

우리가 컴퓨터 내에서 다루는 상태는 현실 세계의 상태라기 보다는 그것의 수치 표현(numerical representation)이기 때문에, “불가능한” 상태로 생각했던 것이 현실에서는 일어날 수도 있다. 현실에서 그런 상태가 나올 수 없다 하더라도 테스터는 프로그램을 그런 불가능한 상태로 몰아갈만한 비정상적인 시나리오를 생각하기 위해 머리를 짜내야 한다. 정상적인 방식으로는 도저히 안된다면 알파 입자나 낙뢰 폭풍을 불러내서라도 그런 상태가 될만한 시나리오를 찾는다. 견고한 소프트웨어는 “불가능한 상태”를 무시하는 대신에 이를 인지하고, 이런 비논리적 조건이 발생하는 경우 처리할 수 있는 모듈(illogical-condition handler)을 호출해야 한다.

 

3.2.3. 동등한 상태(Equivalent States)

하나의 상태에서 시작하는 모든 입력 시퀀스가 ​다른 하나의 상태에서 시작할 때와 정확히 동일한 출력 시퀀스를 생성한다면 이 두 상태는 “동등하다(equivalent)”. 이 개념은 상태 셋(여러 상태들의 집합)에서도 똑같이 적용된다.

 

아래 예에서 시스템이 상태 S에 있을 때 입력 a는 상태 A로 입력 b는 상태 B로 각각 전이를 야기한다. 회색 커브 도형은 자세한 사항이 중요하지 않은 상태 그래프의 부분을 표현한 것이다. 만약 상태 A에서 시작된 모든 가능한 입력 시퀀스가 그것이 상태 B에서 시작되었을 때와 정확하게 같은 출력 시퀀스를 생성한다면, 외부 관찰자로서는 내부 상태 기록을 보지 않는 한 시스템이 두 상태 셋 중 어디에 있는지 알 방법이 없다. 따라서 이 상태 그래프는 그림 11-6으로 간소화 될 수 있다.

 

‘상태 동등성(state equivalency)’ 개념이 존재하다는 사실은 어떤 상태가 동등 상태인지에 대한 의견 차이로부터 기인하는 버그 가능성이 있다는 것을 의미한다. 동등하지 않은 두 개의 상태 셋이 무심코 병합되었을 수도 있고, 역으로 동등한 상태를 병합하지 않아 소프트웨어 복잡도를 줄일 기회를 잃을 수도 있다. 주의할 점은 동등 상태가 향후 개선(future enhancements)을 고려한 계획의 결과로 나올 수도 있다는 것이다. 즉, 두 개 상태가 현재는 구별 불가능하지만 미래에 개선을 통해 구별 인자가 추가됨에 따라 구분가능하게 될 수도 있다.

 

아래 예에서 상태 그래프를 상태 테이블로 표현했을 때 전이(입력)와 출력이 완전히 동일한 두 개의 행들이 존재한다(A1=B1, A2=B2, A3=B3). 여기서 다음 상태명은 달라도 상관없다. 주어진 입력 시퀀스에 의해 생성되는 출력 시퀀스가 A 상태 셋에서와 B 상태 셋에서 똑같으며, 따라서 이 상태 그래프가 병합된 단순 버전으로 대체될 수 있다.

아래는 처음 몇몇 시퀀스를 분석했을 때 동등한 상태처럼 보이지만 병합을 하면 안되는 예이다. 모든 입력 시퀀스에 대해 출력 시퀀스가 동일한 것은 아니기 때문이다. 입력 시퀀스 abbbb가 출력 시퀀스 uxuyy를 생성하는 반면 입력 시퀀스 bbbbb는 출력 시퀀스 uxuyu를 생성하므로 이 두 상태 셋이 동등하지 않다.

 

3.3. 전이 버그(Transition Bugs)

3.3.1. 명시되지 않은 전이 및 모순되는 전이(Unspecified and Contradictory Transitions)

모든 상태-입력 조합에 대해 하나의 전이가 지정되어 있어야 하며, 만일 이 전이가 불가능하다면 해당 상태에서 해당 입력이 발생하는 것을 막는 메커니즘이 있어야 한다(이런 메커니즘이 없다면 오작동이나 알파 입자를 통해 해당 상태에서 불가능한 입력이 실제 발생했을 때 프로그램이 어떻게 동작할지 알 수가 없음). 부주의로 인해 특정 상태-입력 조합의 전이가 명시되지 않는 경우가 생길 수 있으며, 해당 조합에서 시스템이 무엇을 할 지가 정해지지 않았으므로 버그의 가능성이 있다.

 

실제 소프트웨어는 모순되는 전이(contradictory transitions)를 가질 수 없는데, 컴퓨터가 한 번에 한 가지 작업만 수행 할 수 있기 때문이다. 모델에서 모순처럼 보이는 것이 나타나는 것은 테스터가 상태를 구성하는 모든 인자와 모든 입력을 헤아리는데 실패하였기 때문이다. 디버깅에서 “어떤 때는 되고 또 어떤 때는 안된다”와 같은 말이 나오는 것은 우리가 모르고 있는 어떤 컴포넌트(아마도 버그에 의해 야기된 컴포넌트)가 상태에 영향을 주고 있음을 인정하는 것이다. 상태 다이어그램을 꼼꼼하게 흝으면서 각 상태-입력 조합에 대한 전이와 출력을 기록하는 과정을 통해 이런 버그를 발견하게 될 수도 있다.

 

3.3.2. 도달 불가능한 상태(Unreachable States)

도달 불가능한 상태는 어떤 입력 시퀀스로도 도달할 수 없는 상태를 말한다. ‘도달 불가능한 코드(unreachable code)’가 불가능하지 않은 것처럼 도달 불가능한 상태도 불가능하지 않다. 뿐만 아니라 도달불가능한 상태로부터 다른 상태로 가는 전이가 존재할 수도 있다. 대개 하나 또는 하나 이상의 부정확한 전이(incorrect transitions)로 인해 도달불가능한 상태가 만들어진다.

 

하나의 고립된 도달불가능 상태가 여기저기 눈에 띄는 것은 용인할만 하다(현실에서 상태 조건의 불가능한 조합과 관련 있음). 하지만 연결된 상태들로 구성된 그룹이 다른 것들로부터 동떨어져 발견된다면 주의가 필요하다. 두 가지 가능성이 있는데, 1) 버그가 있거나(일부 전이가 누락됨), 2) 전이는 존재하지만 그걸 모르고 있을 수 있다(즉, 고려해야 할 다른 입력 및 관련 전이가 존재함). 보통 이런 숨은 전이(hiddne transitions)는 높은 우선순위로 운영되는 소프트웨어 또는 인터럽트 프로세싱에 의해 야기된다.

 

3.3.3. 데드 상태(Dead States)

데드 상태는 일단 진입하면 빠져나갈 수 없는 상태를 말한다. 반드시 버그라고 볼 수는 없지만 의심스러운 상태이다. 만일 소프트웨어가 폭탄 퓨즈로 설계된 것이라면 데드 상태가 적어도 하나는 있을 것으로 예상가능 하지만, 이렇게 데드 상태의 존재가 정당한 사례는 드물다. 시스템 레벨 이슈나 장치 핸들러(device handler)에서 주로 나타나며, 일반적인 소프트웨어에서 데드 상태가 발견된다면 주의가 필요하다.

 

3.4. 출력 에러(Output Errors)

상태와 전이 그리고 전이를 야기하는 입력이 모두 정확하고 데드 상태나 도달 불가능한 상태도 없지만, 전이로 인해 발생하는 출력이 부정확할 수 있다. 따라서 출력 액션은 상태 및 전이로부터 독립적으로 검증해야 한다. 즉, 테스터는 상태 그래프는 정확하지만 전이 시 잘못된 출력이 발생하는 프로그램과 상태 그래프 자체가 부정확한 프로그램을 구별해야 한다. 부정확한 출력이 생기는 이유는 해당 출력을 실행하는 루틴 호출이 정확하지 않아서일 가능성이 높다. 이런 에러는 대개 지엽적인 사소한 문제이다. 오히려 상태 그래프에 있는 에러가 근본적인 제어 구조 문제와 관련 있는 경향이 있어서 더 심각하다.

 

3.5. 버그의 영향(Impact of Bugs)

어떤 루틴이 상태 그래프로 명세되고, 이 상태 그래프의 정확성이 검증되었다고 가정하자. 코드나 테이블 형식으로 해당 상태 그래프를 구현 시 하나 또는 하나 이상의 아래 증상으로 버그가 나타날 수 있다

1. 상태 수가 부정확
2. 어떤 상태-입력 조합에 대한 전이가 부정확
3. 어떤 전이에 대한 출력이 부정확
4. 어떤 상태 쌍 또는 상태 집합이 동등한 것으로 잘못 간주됨(인자가 소실됨)
5. 어떤 상태 또는 상태 집합이 분할되어 동등하지 않은 복제(nonequivalent duplicates)를 생성함. 즉, 위 4번과 반대로 동등한 상태가 동등하지 않은 상태로 분할됨
6. 어떤 상태 또는 상태 집합이 데드 상태가 됨
7. 어떤 상태 또는 상태 집합이 도달 불가능한 상태가 됨

 

상태 테스팅

4.1. 일반 원칙

상태 테스팅 방법은 순서도(flowchart)를 대상으로 하는 경로 테스팅(path testing) 방법과 유사하다. 순서도의 모든 가능한 경로를 방문하는 것이 비현실적인 것처럼 상태 그래프의 모든 경로를 방문하는 것은 현실적이지 않다. 상태 그래프에서 ‘경로(a path)’는 입력 시퀀스가 초래하는 일련의 전이(a succession of transitions)를 말한다. 순서도에 사용하는 커버리지 개념을 동일하게 적용 가능하다. 예를 들어, 상태 그래프의 각 링크를 통과하도록 테스트를 수행한다(즉, 각 전이가 반드시 실행되어야 함).

 

대부분의 현실적인 상태 그래프가 “강력 연결된(strongly connected)” 그래프이므로, 초기 상태(initial state)에서 시작한 경우 모든 상태를 방문하고 다시 초기 상태로 돌아가는 것이 가능해야 한다. 상태 테스팅의 출발점은 아래와 같다.

1. 초기 상태에서 시작할 때 다시 초기 상태로 돌아가도록 만드는 경로를 커버하는 입력 시퀀스들의 집합을 정의한다.
2. 각 입력 시퀀스의 모든 단계에 대해 예상되는 다음 상태, 전이, 출력을 정의한다.

 

이렇게 도출한 테스트들은 아래의 세 가지 시퀀스로 구성된다.

• 입력 시퀀스
• 상응하는 전이 또는 다음 상태명
• 출력 시퀀스

 

상태 그래프가 대개 강력 연결된 그래프이므로 McCabe 메트릭을 통해 최소 입력 시퀀스 수(the minimum number of input sequences)를 찾아낼 수 있으며, 이를 커버리지 기준으로 활용 가능하다.

 

4.2. 제약 사항(Limitations)

프로그램 순서도 모델의 노드-링크 커버리지가 완전한 테스팅을 보장하지 못하는 것처럼 상태 그래프 모델의 상태-전이 커버리지(state-transition coverage)도 완전한 테스팅을 보장하지는 않는다. 하지만 총 상태 수를 넘는 길이의 시퀀스는 고려하지 않아도 되기 때문에 상태 그래프의 상황이 약간 더 낫다.

 

Chow는 상태 그래프의 커버리지를 위해 경로 계층 구조(a hierarchy of paths)와 경로를 조합하는 방법을 정의하였다. 가장 간단한 것은 “0 스위치”라고 불리며 각 전이를 개별적으로 테스팅 하는 것을 말한다. 다음 단계는 두 개의 전이로 구성된 전이 시퀀스를 테스팅 하는 것으로 “1 스위치”라고 부른다. 최대 길이 스위치는 “n-1 스위치”이며, 여기서 n은 상태 수이다. Chow의 연구 결과에 따르면 “0 스위치” 커버리지가 출력 에러는 포착하지만 일부 전이 에러는 발견하지 못할 수도 있다. 일반적으로 더 긴 커버리지 시퀀스를 사용해야 전이 에러, 누락된 상태, 잉여 상태 등을 찾아낼 수 있다. 특정 상태 그래프 에러 유형을 찾아내는데 충분한 테스트 수(즉, 입력 시퀀스)가 몇 개인지에 대한 이론은 아직 초기 단계에 머무르고 있으며 이 책의 범위를 벗어난다.

 

한편 아래는 경험에 따른 결과들이다.

1. 단순히 상태에 기여하는 인자를 식별하고, 총 상태 수를 집계하고, 이 수를 설계자가 생각하는 수와 비교하는 것만으로도 일부 버그를 찾는다.
2. 데드 상태, 도달 불가능한 상태, 불가능한 상태 및 전이라고 결정된 것들이 정말로 그런지 따져보는 일을 통해 몇몇 버그를 더 포착하게 된다.
3. 모든 입력-상태 조합에 대한 전이 및 출력이 분명하게 명시되었는지 따져보는 것으로 많은 버그를 더 포착하게 된다.
4. 모든 노드와 링크를 커버하는 입력 시퀀스 집합은 의무적인 최소 요구사항이다(커버리지 기준).
5. 상태 테스트를 실행할 때는 입력 시퀀스의 결과로 나오는 출력 뿐만아니라 그로 인한 상태 시퀀스를 기록하는 수단(예, 계측 소프트웨어)을 필수적으로 제공해야 한다.

 

4.3. 모델링 대상(What to Model)

상태 그래프는 동작 모델(behavioral model)이다. 구조적이라기보다는 기능적이므로 소스 코드와는 거리가 멀고, 동작에 집중하기 위해 구조적 세부사항을 무시하는 실용적인 테스팅 방법이다. 하지만 상태를 생성하는 인자(factors)가 어떻게 표현되는지 데이터베이스를 들여다 보는 것이 상태 수를 파악하는데 도움이 되기도 한다. 상태 그래프 테스트는 테스트를 실행하는 동안 보다는 테스트를 설계하는 동안 가장 큰 성과를 거둘 수 있는 테스트 방법이다. 순서도나 코딩이 나오기 훨씬 전에 설계 명세에 기반하여 테스트를 구축할 수 있기 때문에, 수정 비용이 저렴한 초반에 심각한 버그를 포착하는데 도움을 준다.

 

상태 그래프 테스트를 설계하는 것이 유용할만한 상황으로 아래를 들 수 있다.

1. 출력이 하나 또는 하나 이상의 이벤트 시퀀스 발생에 기반하는 프로세싱. 예, 지정된 입력 시퀀스 탐지, 순차 형식의 유효성 검사, 입력 순서가 중요한 기타 상황 등
2. 시스템 간, 사람과 기계 간, 시스템 내부의 모듈 간 프로토콜
3. 상태에 의존하는 액션과 복잡한 재시도/복구 절차가 있는 장치 핸들러(device handlers). 예, 테이프 핸들러, 디스크 핸들러
4. 시스템에 무기한 남아있을 수 있는 트랜잭션이 존재하는 트랜잭션 흐름(transaction flows). 예,  온라인 사용자, 멀티 태스킹 시스템의 작업(tasks)
5. 운영체제 내의 높은 레벨 제어 기능. 사용자 상태 간, 슈퍼바이저 상태 간 전이. 레코드 보안 핸들링, 읽기/쓰기/수정 권한 퍼미션, 인터럽트 상태와 레벨 간 우선순위 인터럽트 및 전이, 복구 이슈 및 복구 데이터 기록과 관련된 레코드/프로세스의 안전 상태
6. 자원 관리(resource management)와 관련한 시스템의 동작(다양한 수준의 리소스 사용률에 도달 할 때 시스템의 반응). 임계치(thresholds)에 대한 반응과 관련한 제어 기능(시스템의 액션이 임계 값뿐만 아니라 임계 값이 교차하는 방향에도 의존하는 경우)
7. 하나 또는 하나 이상의 상태-전이 테이블로 직접적이고 명시적으로 구현되는 기능

 

요약

1. 상태 테스팅은 주로 기능 테스팅 도구로 사용되며 설계 초기 단계에 가장 빛을 발한다.
2. 실제 프로그램에는 모순되거나 모호한 전이 또는 출력이 없지만 명세서에는 존재한다. 명세서의 유효성(validity)을 확인하는데 상태 테이블을 사용하라.
3. 상태 수를 집계하라.
4. 상태-입력의 모든 조합에 대한 전환 및 출력이 명시되었는지 따져본다.
5. 최소한의 커버리지 테스트 셋을 적용하라.
6. 출력 시퀀스만 포착하지 말고 상태 시퀀스도 수집하기 위해 전이를 계측하라(instrument).
7. 상태 수를 집계하라.