state transition testing technique
상태 전이 테스트 란 무엇이며 상태 전이 다이어그램을 사용하는 방법을 알아보십시오.
지난 기사에서 ' 원인 및 결과 그래프 '테스트 케이스 작성 기법. 오늘은 다음 동적 테스트 케이스 작성 방법 인 상태 전환 기술로 이동하겠습니다.
이 문서에서는이 테스트 개념을 전체적으로 FSM이 아니지만 일부 구성 요소 인 더 큰 응용 프로그램으로 확장하여 '상태 저장'이라는 고유 한 기능과 전환 규칙을 채택하여 많은 이점을 얻을 수있는 방법을 살펴 봅니다.
상태 전이 테스트
상태 전환 테스트는 블랙 박스 테스트 기술 , '유한 상태 머신'테스트에 적용 할 수 있습니다.
'유한 상태 머신 (FSM)'은 입력 또는 자극에 따라 서로 다른 개별 상태 (예 : '준비', '준비 안 됨', '개방', '닫힘',…)에있는 시스템입니다.
이산 상태는 시스템 전환 규칙에 따라 시스템이 끝나는 상태입니다. 즉, 시스템이 이전 상태에 따라 동일한 입력에 대해 다른 출력을 제공하면 유한 상태 시스템입니다.
또한 모든 트랜잭션이 시스템에서 테스트되는 경우이를 '0-switch'커버리지라고합니다. 테스트가 2 쌍의 유효한 트랜잭션을 포함하는 경우 '1- 스위치'적용 범위입니다.
학습 내용 :
상태 전이 테스트 기법이란 무엇입니까?
상태 전이 기술은 시스템이 유한 수의 상태로 정의되고 상태 간의 전이가 시스템의 규칙에 의해 제어 될 때 사용되는 동적 테스트 기술입니다.
즉,이 기술은 시스템의 특징이 서로 변환되는 상태로 표현 될 때 사용됩니다. 변환은 소프트웨어의 규칙에 따라 결정됩니다. 그림 표현은 다음과 같이 표시 될 수 있습니다.
여기에서 엔티티가 전환 일부 때문에 상태 1에서 상태 2로 입력 조건으로 이어지는 행사 결과 동작 그리고 마지막으로 산출 .
예를 들어 설명하려면 :
ATM을 방문하여 $ 1000를 인출합니다. 현금을받습니다. 이제 잔액이 부족하여 $ 1000를 인출하는 것과 똑같은 요청을합니다. 이번에는 ATM이 잔액이 부족하여 돈을주지 않습니다. 그래서 여기 전이 , 원인 상태의 변화 이전 인출입니다
상태 전이 테스트 정의
상태 전환이 무엇인지 이해 했으므로 이제 상태 전환 테스트에 대한보다 의미있는 정의에 도달 할 수 있습니다. 따라서 테스터가 시퀀스에 주어진 다양한 입력 조건에 대해 AUT (Application Under Test)의 동작을 검사해야하는 일종의 블랙 박스 테스트입니다.
시스템의 동작은 양성 및 음성 테스트 값 모두에 대해 기록됩니다.
상태 전이 테스트를 언제 사용합니까?
상태 전이 테스트는 다음 상황에서 사용할 수 있습니다.
오라클 PL SQL 고급 인터뷰 질문
- 테스트중인 애플리케이션이 다양한 상태와 전환이 포함 된 실시간 시스템 인 경우.
- 애플리케이션이 과거의 이벤트 / 가치 / 조건에 의존하는 경우.
- 이벤트 순서를 테스트해야하는 경우.
- 유한 한 입력 값 세트에 대해 애플리케이션을 테스트해야하는 경우.
상태 전환 테스트를 사용하지 않는 경우
다음 상황에서 상태 전환 테스트에 의존해서는 안됩니다.
- 순차 입력 조합에 대해 테스트가 필요하지 않은 경우.
- 애플리케이션의 다양한 기능을 테스트해야하는 경우 (탐색 테스트와 유사).
소프트웨어 테스트의 상태 전환 테스트 예
실제 시나리오에서 테스터는 일반적으로 State Transition 다이어그램을 제공하며이를 해석해야합니다.
이러한 다이어그램은 비즈니스 분석가 또는 이해 관계자가 제공하며이 다이어그램을 사용하여 테스트 사례를 결정합니다.
아래 상황을 고려해 보겠습니다.
소프트웨어 이름 – Manage_display_changes
사양 – 소프트웨어는 시간 표시 장치의 표시 모드를 변경하기위한 입력 요청에 응답합니다.
디스플레이 모드는 다음 네 가지 값 중 하나로 설정할 수 있습니다.
- 시간 또는 날짜 표시에 해당하는 2 개.
- 다른 두 개는 시간이나 날짜를 변경할 때입니다.
다른 상태는 다음과 같습니다.
- 변경 모드 (CM) : 이를 활성화하면 표시 모드가 '표시 시간 (T)'과 '표시 날짜 (D)'사이에서 이동합니다.
- 재설정 (R) : 디스플레이 모드가 T 또는 D로 설정된 경우 '재설정'으로 인해 디스플레이 모드가 '시간 변경 (AT)'또는 '날짜 변경 (AD)'모드로 설정됩니다.
- 시간 설정 (TS) : 이를 활성화하면 디스플레이 모드가 AT에서 T로 돌아갑니다.
- 날짜 세트 (DS) : 이를 활성화하면 디스플레이 모드가 AD에서 D로 돌아갑니다.
상태 전이 다이어그램
이제 해석을 시작하겠습니다.
여기:
# 1) 다양한 상태는 다음과 같습니다.
- 표시 시간 (S1),
- 시간 변경 (S3),
- 날짜 표시 (S2) 및
- 날짜 변경 (S4).
# 2) 다양한 입력은 다음과 같습니다.
- 모드 변경 (CM),
- 리셋 (R),
- 시간 설정 (TS),
- 날짜 설정 (DS).
# 3) 다양한 출력은 다음과 같습니다.
- 시간 변경 (AT),
- 표시 시간 (T),
- 날짜 표시 (D),
- 날짜 변경 (AD).
# 4) 변경된 상태는 다음과 같습니다.
- 표시 시간 (S1),
- 시간 변경 (S3),
- 날짜 표시 (S2) 및
- 날짜 변경 (S4).
1 단계: 모든 시작 상태를 작성하십시오. 이를 위해 한 번에 하나의 상태를 가져 와서 얼마나 많은 화살표가 나오는지 확인하십시오.
- State S1에는 두 개의 화살표가 있습니다. 하나의 화살표는 S3 상태로 가고 다른 화살표는 S2 상태로 이동합니다.
- State S2의 경우 – 2 개의 화살표가 있습니다. 하나는 S1 상태로 가고 다른 하나는 S4로 이동합니다.
- 상태 S3의 경우 – 하나의 화살표 만 나와 S1 상태로 이동합니다.
- 상태 S4의 경우 – 하나의 화살표 만 나와 S2 상태로 이동합니다.
이걸 우리 테이블에 올려 보자.
상태 S1과 S2의 경우 두 개의 화살표가 나오므로 두 번 작성했습니다.
2 단계: 각 상태에 대해 최종 전환 상태를 기록합니다.
- 상태 S1의 경우 – 최종 상태는 S2 및 S3입니다.
- 상태 S2의 경우 – 최종 상태는 S1 및 S4입니다.
- 상태 S3의 경우 – 최종 상태는 S1입니다.
- 상태 S4의 경우 – 최종 상태는 S2입니다.
이것을 출력 / 결과 상태로 테이블에 놓습니다.
3 단계 : 각 시작 상태 및 해당 종료 상태에 대해 입력 및 출력 조건을 기록합니다.
– 상태 S1이 상태 S2로 이동하는 경우 입력은 변경 모드 (CM)이고 출력은 아래 표시된 날짜 표시 (D)입니다.
비슷한 방법으로 다음과 같이 모든 상태에 대한 입력 조건과 출력을 기록합니다.
4 단계 :
이제 아래 표시된 각 테스트에 대한 테스트 케이스 ID를 추가하십시오.
이제 공식 테스트 케이스로 변환 해 보겠습니다.
이러한 방식으로 나머지 모든 테스트 케이스를 도출 할 수 있습니다. 나는 다른 것을 가정 테스트 케이스의 속성 전제 조건, 심각도, 우선 순위, 환경, 빌드 등도 테스트 케이스에 포함됩니다.
단계를 다시 요약하면 :
- 초기 상태에서 나오는 선 / 화살표를 기반으로 초기 상태와 최종 상태를 식별합니다.
- 각 초기 상태에 대해 입력 조건 및 출력 결과를 찾습니다.
- 각 세트를 별도의 테스트 케이스로 표시하십시오.
상태 전환 기법의 더 많은 예
다음은 더 큰 소프트웨어 응용 프로그램에서 상태 전이 테스트 기술의 또 다른 예입니다.
기술:
' 상태 저장 기능 테스트 ' FSM (Finite State Machine)의 특성으로 응용 프로그램의 특정 부분이나 구성 요소를 테스트하는 데 접근 방식을 사용할 수 있습니다.
구현 단계 :
자바에서 배열을 반환 할 수 있습니까?
#1) '상태 기반 기능 테스트'구현의 첫 번째 단계는 FSM으로 분류 할 수있는 애플리케이션의 여러 구성 요소 / 부분을 식별하는 것입니다. 입력, 상태 및 출력은 이러한 각 FSM에 대해 신중하게 추적됩니다.
#두) 다음 단계는 전환 규칙, 입력, 출력 및 전환 상태를 기반으로 이러한 FSM에 대한 테스트 케이스를 개발하는 것입니다.
#삼) 세 번째 단계는 이러한 구성 요소의 테스트를 다른 인터페이스 구성 요소와 통합하여 애플리케이션의 종단 간 유효성을 검사하는 것입니다.
이는 주택 건축 승인, 부지 및 주택 등록, 건축 계약자 선정과 같은 다양한 응용 구성 요소를 사용하여 주택 건설을 추적하는 'House Project'라는 응용 프로그램의 예를 통해 설명 할 수 있습니다. , 주택 대출 승인 등
예를 들어
“하우스 프로젝트”애플리케이션의 하나의 FSM 구성 요소 인 주택 융자 승인을 테스트하는 것을 고려할 것입니다.
주택 융자 승인 신청서 (HLA)
HLA 신청은 대출 신청을 처리하는 독립적 인 대출 처리 사용자에 의해 실행됩니다. 신청서 처리의 여러 단계는 다음과 같습니다.
1.1.1 1 단계 : 문서 수집
첫 번째 단계는 아래 표에 언급 된 대출 신청을위한 관련 문서를 수집하는 것입니다. 이는 성공적인 지원을위한 '조건'입니다. 신청자는 필요한 서류를 수집하여 주택 융자에 적용합니다.
대출 처리 사용자는 문서 수신을 확인하고 대출 신청 상태 (즉, HLA 신청 구성 요소의 상태)를 '적용됨'상태로 전환합니다.
표 1 : 문서 목록
1.1.2 2 단계 : 대출 평가
이 단계에서 대출 기관은 대출 신청이 자신의 신용 요건을 충족하는지 확인하기 위해 대출 신청서를 평가합니다. 이때 지원 문서가 확인됩니다.
표 2 : 문서의 중요도
평가에 필요한 문서, 즉이 단계에서 확인해야하는 '조건'이 확인됩니다. 각 조건에는 중요도가 첨부되어 있습니다 (위 표에서 'Y'로 언급 됨). 모든 필수 위험 조건이 충족되면 애플리케이션이 '확인 됨'상태로 이동합니다. 즉, HLA 애플리케이션 구성 요소가 '확인 됨'상태에 있습니다.
참고 사항 :
#1) 이 원칙은 시스템의 테스트 조건 및 '상태'정의에 구조와 객관성을 가져옵니다. .
또한 시스템 유효성 검사를위한 모든 '조건'이이 '확인'상태에 도달하는 데 중요한 것은 아닙니다. 위의 표에서 응용 프로그램이 '확인'상태에 도달하려면 4 가지 조건이 '중요하지 않음'으로 표시됩니다.
#두) 유효성 검사 횟수는 각 상태에 필요한 규칙의 위험 또는 중요도에 따라 최적으로 줄일 수 있습니다. 이렇게하면 테스트 실행에 필요한 시간이 크게 줄어들고 동시에 테스트 품질이 저하되지 않습니다.
#삼) 이는 개별 구성 요소를 테스트하는 데 유용 할뿐만 아니라 시스템 전체를 테스트하는 데에도 유용합니다.
# 4) 또한 회귀 테스트 스위트를 만드는 동안 매우 유용합니다.
따라서이 단계에서는 0 스위치 유형의 테스트입니다. 그러나 이후 승인 단계는 해당 단계에 대한 1- 스위치 또는 2- 스위치 유형의 유효성 검사가 될 수 있습니다.
예를 들어 이 단계에서는“결혼 증명서”가 그다지 적절하지 않을 수 있지만 신청자가 EMI를 지불 할 위험을 고려할 때 승인의 후반 단계에서 결혼 증명서가 적절해질 수 있습니다. 즉, 배우자가 고용 된 경우 , 그것은 위험을 감소시키고, 고용되지 않으면 위험을 증가시킵니다.
# 5) 위의 원칙은 해당 단계에서 구성 요소의 요구 사항에 따라 테스트 조건을 확장하는 데 사용할 수 있습니다.
1.1.3 3 단계 : 조건부 승인
응용 프로그램의 현재 상태는 '확인 됨'입니다. 대출 기관은 대출 절차를 진행하기 위해 '조건부 승인'을 제공합니다. HLA 신청을 '승인 됨'상태로 이동하려면 추가 검증이 필요합니다.
1.1.4 4 단계 : 승인
이 단계에서 중요한 검증이 수행됩니다.
- LMI (Lenders Mortgage Insurance)의 평가 : 여기에는 부동산의 진위 여부에 대한 2- 스위치 이상의 검증이 포함됩니다.
- 대출 기관은 '확인'단계에서 제공되지 않은 정보를 요구할 수 있습니다.
위의 조건이 충족되면 애플리케이션이 '승인 됨'상태로 이동합니다. 승인 절차의 최종 권한은 자세한 내용을 요청하여 대출 신청자의 신용을 교차 확인하거나 신청자의 다른 문서가 결정적인지 묻지 않을 수 있습니다. 즉, 타당성을 증명하려면 기본 응용 프로그램의 다른 구성 요소에서 더 많은 입력이 필요합니다. .
# 6) 즉, 응용 프로그램의 다른 구성 요소에서 구성 요소에 대한 입력 조건에 따라 다른 상태로 전환하기 위해 더 많은 유효성 검사가 필요하거나 줄어들 수 있습니다.
아래 다이어그램은 승인 프로세스를 보여줍니다.
그림 1 : 대출 승인 프로세스
위험과 도전
- 대규모 응용 프로그램의 경우 FSM 및 일반 구성 요소로 분류 할 수 있도록 응용 프로그램을 여러 논리적 구성 요소로 나누려면 깊은 응용 프로그램 지식이 필요합니다. 이를 위해서는 SME에서 비용이 많이 드는 시간이 필요할 수 있습니다.
- 모든 애플리케이션이 이러한 종류의 FSM 분류를 실현할 수있는 것은 아닙니다.
- FSM 구성 요소는 응용 프로그램의 일반 구성 요소와 상호 작용하므로 다른 구성 요소에서 FSM에 대한 입력은 신중한 계획과 실행이 필요합니다.
상태 전이 테스트의 장점
- 이 기술에서 테스터는 시스템 동작의 그림 또는 표 형식 표현을 사용하여 애플리케이션 설계에 익숙해지고 테스트를 효과적이고 효율적으로 다루고 설계하기가 쉽습니다.
- 계획되지 않았거나 잘못된 시스템 상태도이 기술을 사용하여 다룹니다.
- 상태 전환 다이어그램을 사용하면 모든 조건이 적용되는지 쉽게 확인할 수 있습니다.
상태 전환 테스트의 단점
- 이 기술은 비유 한 상태 시스템에 사용할 수 없습니다.
- 크고 복잡한 시스템에 대해 가능한 모든 상태를 정의하는 것은 매우 번거로운 작업입니다.
결론
상태 전환 테스트는 유한 상태 시스템에 대해 다양한 시스템 전환을 테스트해야 할 때 유용한 접근 방식입니다.
'상태 저장 기능 테스트'개념으로 응용 프로그램을 테스트하면 복잡한 응용 프로그램을 테스트하기위한 고유 한 테스트 접근 방식을 테스트 조직에 제공하여 테스트 범위를 손상시키지 않고 테스트 실행 생산성을 높일 수 있습니다.
상태 전환 테스트는 복잡한 응용 프로그램을 테스트하기위한 고유 한 테스트 접근 방식으로, 테스트 범위를 손상시키지 않으면 서 테스트 실행 생산성을 높일 수 있습니다.
이 기술의 한계는 테스트중인 시스템이 유한 상태 만 가질 때까지 사용할 수 없다는 것입니다.