가이드라인: 상태 차트 및 플로우 다이어그램에 대한 테스트 아이디어
테스트 아이디어는 그럴듯한 소프트웨어 결함과 해당 결함을 가장 잘 발견할 수 있는 방법을 기반으로 합니다. 이 가이드라인은 상태 차트 및 기타 그래픽 형식의 디자인 구조에서 테스트 아이디어를 식별하는 방법을 표시합니다.
관계
기본 설명

소개

이 가이드라인은 주로 연결 화살표를 사용하여 연결된 노드로 구성되고 프로그램의 가능한 제어 플로우를 표시하는 상태 차트 및 기타 디자인 구조에서 테스트 아이디어를 식별하는 방법을 표시합니다. 이러한 테스트의 기본 목적은 일부 테스트에서 모든 연결 화살표를 순회하는 것입니다. 연결 화살표를 연습해 본적이 없으면 고객이 사용할 때도 올바르게 동작하는지를 보증할 수 없습니다.

구현 테스트

다음 상태 차트를 가정해 보십시오.

함께 표시된 텍스트에서 설명되는 다이어그램

그림 1: HVAC 상태 차트

테스트 아이디어의 첫 번째 목록은 다음과 같습니다.

  • 대기 상태가 너무 더움 이벤트를 받음
  • 대기 상태가 너무 추움 이벤트를 받음
  • 냉방/시작 상태가 압축기 실행 중 이벤트를 받음
  • 냉방/준비 상태가 송풍기 실행 중 이벤트를 받음
  • 냉방/실행 중 상태가 확인 이벤트를 받음
  • 냉방/실행 중 상태가 실패 이벤트를 받음
  • 실패 상태가 실패 해결 이벤트를 받음
  • 난방 상태가 확인 이벤트를 받음
  • 난방 상태가 실패 이벤트를 받음

이러한 테스트 아이디어는 단일 테스트에서 모두 연습할 수도 있고, 또는 일부를 연습하는 몇 개의 테스트를 작성할 수도 있습니다. 모든 테스트 디자인과 마찬가지로, 단순 테스트의 구현 용이성과 복잡한 테스트의 추가 결함 발견 능력 사이에서 밸런스를 맞추십시오. (개념: 테스트 아이디어 목록 페이지에서 "목록을 사용하는 테스트 디자인"을 참조하십시오.) 상태 차트를 통해 특정 경로를 설명하는 유스 케이스 시나리오가 있는 경우, 이러한 경로를 가진 테스트를 우선해야 합니다.

어느 경우든 테스트는 실제로 발생하는 상태 차트에 필요한 모든 조치를 확인해야 합니다. 예를 들어, 시작 시 실패 상태로 알람이 시작되어 종료 시 중지되었습니까?

전이 이후 올바른 상태로 되는지도 테스트로 확인해야 합니다. 상태를 외부에서 볼 수 없을 경우 이는 어려운 문제가 될 수 있습니다. 잘못된 상태를 발견하는 유일한 방법은 잘못된 결과를 가져오는 일부 이벤트 시퀀스를 주입하는 것입니다. 보다 정확하게 말하면, 올바른 상태에 대해 외부적으로 가시적인 결과를 가지는 이벤트의 후속 시퀀스를 생성해야 합니다. 이런 이벤트는 가능한 올바르지 않은 상태에서 동일한 시퀀스가 야기되는 것과는 다릅니다.

위 예제에서, 실패 상태의 실패 해결됨 이벤트가 실패 상태에 머무르는 대신 올바르게 대기 상태로 되는지 어떻게 알 수 있습니까? 알람 중지를 통해 전이가 생성되었다고 생각할 수 있지만 난방기가 시작될 만큼 온도를 낮추거나 냉방기를 사용할 만큼 온도를 높여 확인하는 것이 바람직합니다. 어떤 반응이 일어나면 전이가 올바르다는 확신을 가질 수 있습니다. 아무 반응이 없으면 장치가 실패 상태에 있는 것입니다.

이제 결과 상태로 테스트 디자인이 적절한 수준으로 복잡해졌는지 판별하십시오. 종종 상태 머신을 명백하게 하고 테스트에서 상태를 볼 수 있도록 하는 것이 좋습니다.

기타 상태 차트 생성

상태 차트는 하나 이상의 연결 화살표와 화살표로 구성됩니다. 상태 차트 생성 목록과 테스트 아이디어 목록에 영향을 미치는 내용은 다음과 같습니다.

이벤트 조치, 시작 조치 및 종료 조치

이들은 그 자체로 테스트 아이디어를 생성하지 않습니다. 테스트는 조치가 지정한 대로 동작하는지를 확인해야 합니다. 조치가 실제 프로그램을 나타내면 해당 프로그램을 테스트해야 합니다. 프로그램에 대한 테스트 아이디어는 상태 차트의 테스트 아이디어와 결합될 수 있지만 분리하는 것이 관리하기에 용이합니다. 관련된 노력과 이벤트 사이에서 상호 작용을 할 것이라는 가정을 기반으로 결정하십시오. 즉, 한 연결 화살표의 특정 조치가 다른 연결 화살표의 조치와 데이터를 공유하지 못하면 같은 테스트에서 두 조치를 연습할 이유가 없습니다(상태 차트 테스트에 걸쳐 같은 경로의 일부분이면 그렇게 함).

보호 조건

보호 조건은 부울 표현식입니다. 보호 조건에 대한 테스트 아이디어는 중간 산출물 가이드라인: 부울 및 경계에 대한 테스트 아이디어에 설명된 대로 파생됩니다.

위 예제에서 대기 상태의 너무 추움 전이는 [restart time >= 5 mins]을 사용하여 보호됩니다. 이는 두 개의 별도 테스트 아이디어를 이끌어 냅니다.

  • 다시 시작 시간이 5분인 경우 대기 상태가 너무 추움 이벤트를 받음(전이가 주어짐)
  • 다시 시작 시간이 5분 바로 아래인 경우 대기 상태가 너무 추움 이벤트를 받음(전이가 차단됨)

두 경우 모두에서 테스트 아이디어를 사용하는 테스트는 올바른 상태에 도달했는지 확인해야 합니다.

내부 전이

내부 전이는 외부 전이에서와 마찬가지로 동일한 종류의 아이디어를 테스트 아이디어 목록에 추가합니다. 즉, 다음 상태는 원래 상태와 동일하다는 것입니다. 올바르지 않게 트리거된 경우 상태의 시작 및 종료 조치가 관찰 가능한 영향의 원인이 되는 테스트를 설정하는 것이 바람직합니다.

중첩 상태

테스트를 생성할 때 컴포지트 상태의 항목 및 종료 이벤트가 관찰 가능한 영향을 가지도록 설정하십시오. 이들이 생략된 경우 알 수 있습니다.

동시적 하위 상태

동시성 테스트는 개발자 테스트의 범위 밖에 있습니다.

연기된 이벤트

이벤트가 프로그램이 실제로 수신 상태인 동안 생성되는 대신 연기되어 대기열에 지정되었는지 여부에 따라 이벤트가 서로 다르게 처리되는 것으로 의심되면 이런 두 가지 경우를 테스트할 수 있습니다.

수신 상태의 이벤트에 보호 조건이 있으면 이벤트가 생성된 시간과 수신된 시간 사이에서 조건의 변수에 대한 변경의 세분화를 고려하십시오.

하나 이상의 상태가 연기된 이벤트를 처리할 수 있으면 가능한 각 수신 상태로의 테스트 연기를 고려하십시오. 구현은 "명백한" 상태가 이벤트를 처리하는 것으로 가정할 수 있습니다.

히스토리 상태

히스토리 상태의 예제는 다음과 같습니다.

함께 표시된 텍스트에서 설명되는 다이어그램

그림 2: 히스토리 상태 예제

히스토리 상태로의 전이는 세 가지 실제 전이를 나타내고 또한 세 가지 테스트 아이디어도 나타냅니다.

  • Command 상태의 BackupUp 이벤트는 Collecting 상태를 유도함
  • Command 상태의 BackupUp 이벤트는 Copying 상태를 유도함
  • Command 상태의 BackupUp 이벤트는 CleaningUp 상태를 유도함
체인 상태

체인 상태는 확인해야 하는 조치를 더 많이 알려준다는 점을 제외하면 테스트 디자인에 대해 어떠한 관련도 없는 것처럼 보입니다.

디자인 테스트

앞서의 논의는 구현이 디자인과 일치되는지 여부를 확인하는 데 초점을 맞추었습니다. 그러나 디자인이 잘못되었을 수도 있습니다. 테스트 아이디어를 찾기 위해 디자인을 점검하면서 두 가지 유형의 문제도 확인하십시오.

유실된 이벤트. 상태 차트는 디자이너가 해당 상태에 도달할 수 있다고 예상하는 이벤트에 대한 상태의 응답을 표시합니다. 디자이너가 이벤트를 못보고 지나치는 경우도 있습니다. 예를 들어, 이 상태 차트에서(페이지 맨 위에서 반복됨) 아마 디자이너가 송풍기가 실행 중일 때 뿐만 아니라 냉방의 준비 하위 상태에서도 실패가 발생할 수 있음을 잊은 듯 합니다.

함께 표시된 텍스트에서 설명되는 다이어그램

그림 3: HVAC 상태 차트

이러한 이유로 각 상태에 대해 다른 상태에 적용되는 이벤트가 여기에도 적용되는지를 묻는 것이 좋습니다. 그런 이벤트가 발견되면 디자인을 정정하십시오.

불완전하거나 유실된 보호 조건. 비슷한 경우로 한 전이의 보호 조건에서 다른 전이의 보호 조건이 제안될 수 있습니다. 예를 들어, 위 상태 차트는 난방기가 너무 자주 다시 시작하지 않도록 관리하지만 냉방 시스템에는 그러한 제한은 없습니다. 제한이 있어야 합니까?

하나의 보호 조건에서 사용되는 변수가 다른 보호 조건이 너무 단순함을 암시할 가능성도 있습니다.

테스트 상호 작용

그래프에서 각 연결 화살표를 테스트한다고 해서 테스트가 완료되는 것은 아닙니다. 예를 들어, 시작 상태가 변수를 0으로 초기화하고, 상태 Setter가 이를 5로 설정하고, 상태 Divider가 이를 100 (100/변수)으로 나누었다고 가정해 보십시오. 시작 상태에서 Setter를 통과하지 않는 Divider로의 경로가 있으면 divide-by-zero 예외가 발생합니다. 상태 차트에 많은 상태가 있는 경우 단순하게 각 연결 화살표를 연습하면 경로를 빠뜨릴 수 있습니다.

아주 단순한 상태 차트를 제외하고는 모든 경로를 테스트하는 것은 불가능합니다. 실질적으로는, 보통 유스 케이스 시나리오에 해당하는 복합적인 테스트만으로도 충분합니다. 더 강력한 테스트를 원할 경우, 이를 사용하는 각 상태에 값을 제공하는 데이터를 가지는 각 상태의 경로를 고려하십시오.