State-transition-based testing

Everything in the world, the origin of the death, every day is experiencing a variety of state transitions.
As a tester, in the process of working, often encounter the software things have multiple states, each State in satisfying certain conditions, the realization of the State transformation.
　　  In software, the transformation between the state of things can be divided into two categories: A class is the transition between the various states have a certain sequence of relations, such as workflow, must first occur a state, to the B state, the state A and B have a sequential order; one is that each state is a side-by-side relationship, and each state can be transformed between can be converted from C to D, or from D to C. Both types of state transitions require attention to user role permissions. 
The so-called state Transition test, refers to in the test process for the software in the state of the transition, we need to simulate the state to transform the various user operating scenarios, and through some abnormal means to verify the state flow is not allowed to occur. Basically testing for state transitions, the use cases we design need to cover allowed state transitions and disallowed state transitions, as well as validation of user role permissions. 
For those with only 2 state transitions, it is often possible to add state checksums in use cases based on the main process or alternative processes, and for those with complex flow or multiple states, it is easy to omit the transition relationship of the state by the State check item added in the use case. The transformation of the more major states is split into the use cases of the various functional modules, very fragmented, if you want a regression for the state transition, filtering the use case will be a very troublesome thing, and the non-existent state transition check is not reflected, so we need to specifically for the state of the flow to do a test design. 
Whether it is a sequence relationship or a side-by-side relationship state transition, we can get the flow information of the State from the Requirement specification (PRD), in order to describe this state flow more clearly, we can express it through the state diagram. With the state diagram, we can from the user's point of view, combined with the actual needs of users to consider whether the flow of these states in line with the user's operating habits, check whether there is redundancy or missing state; whether the implementation of the program can make the user's operation as easy as possible; is the state flow path end Node A state of finalization, Whether there is a reverse state flow in the final state. 
The following are examples of these two types of illustration. 
State transitions for sequence relationships: conversion of SPU Edit state. 
SPU edit state conversion, is an orderly process, in a life cycle, in a certain state, to meet the requirements will flow to the next state, most of the state of the flow is one-way, any of the state flow branches from the initial state, to the end of the state.

State transition of a parallel relationship: the transformation of a commodity's state.
The transformation between the various states of the commodity, also has the starting state and the terminating state, differs from the sequence state, almost each state and many states exist in the transformation relationship, and the transitions between states are mutual, like a spider's web, in the face of such a network of state diagrams, the test requires special attention to the existence of the transition between States not allowed.

from two instances, according to the state diagram, we can see what we need to focus on:
Status: Each state in the state diagram must be tested, verified in that state, Whether transitions to other states are consistent as shown in the state diagram.
allowed conversions between states: the same data, different operations cause different conversions, different data (preconditions not the same), different conversions due to the same operation, different data, different conversions caused by different operations. Validate each allowed state transition, set the preconditions for state transitions, operate the function that transforms the state, verify that the operation is normal, and that the state is changing as expected. For very high-frequency, or particularly error-prone conversions, and the most infrequently used conversions, you need to construct more test data and do as much coverage as possible.  
Disallowed transitions between states: conversion tests that are not allowed between States, concerns about whether the system returns error messages and status values are changed, does not need to be validated against all the impossible, and should be tested for those that are particularly prone to change.  
Role permissions for state transitions: transitions between states are required by a user role, and we need to verify not only that the roles that have permissions are operational, but also that the roles that do not have permissions are operational, that for roles that do not have permissions, and where it is not possible to validate all It is also a selection of relatively error-prone operations.   The transformation of the
State is very common in software, and it can be used to ensure the correctness of the transition of the software state by combing the state diagram to comb the relationship of the state transitions and testing the design according to the coverage principle of State and state transition on the basis of state diagram. During the test, a random state transition test can also be performed.

This article was selected from: http://www.spasvo.com/news/html/20141216133723.html

?

?

State-transition-based testing