With 3 years of testing experience, the use case design doesn't even know the state transition method?

1. Concept

The state transition method mainly focuses on testing the correctness of state transitions. For a finite state machine, it is tested to verify whether it can produce the required state changes within the given conditions, whether there are unreachable states and illegal states, whether illegal state transitions may occur, etc. Test transitions between states by constructing events that cause state transitions.

2. Application scope

The idea of ​​the state transition method is to provide an idea to string together the transitions of multiple states for testing. This method is suitable for the situation where there are many states of the function, and it is necessary to test the transition of various states, and the test of these state transitions is easy to be missed in actual work. Such as players, remote control buttons, etc.

3. Steps of state transition method

  1. Analyze requirements and sort out all states;

  2. Draw a state transition diagram;

  3. list state-event table;

  4. Get the state transition tree (test path);

  5. Get test cases according to the state transition tree

4. Case:

Requirements: Through a certain ticketing system, customers can purchase train tickets in advance to go to a certain place.

  1. The user logs in to the ticketing system, selects the place of departure, destination, and date of departure, selects a certain train number and clicks "Book", fills in the information of the orderer, and clicks to submit the order; the current order status is "Unpaid";

    The user manually cancels the order, and the ticket status is updated to "Cancelled";

    If payment is not made within 45 minutes, the order will be automatically canceled and the ticket status will be "Cancelled";

  2. The user pays the ticket, and the ticket status changes to "Paid";

  3. When the user arrives at the station and picks up the ticket through the automatic ticket machine or the ticket window, the status of the ticket is "issued";

  4. Half an hour before driving, you can change the ticket. If the change is successful, the ticket status will be "Successful change";

  5. After the ticket has been issued/rebooked and boarded the train, the status of the ticket will change to "Used";

  6. Half an hour before driving, the ticket can be refunded. If the refund is successful, the ticket status will be "refunded successfully".

If you want to learn automated testing, here I recommend a set of videos for you. This video can be said to be the first interface automation testing tutorial on the entire network at station B. At the same time, the number of online users has reached 1,000, and there are notes to collect and various Lu Dashen Technical Exchange: 798478386     

 

[Updated] The most detailed collection of practical tutorials for automated testing of Python interfaces taught by station B (the latest version of actual combat)_哔哩哔哩_bilibili [Updated] The most detailed collection of practical tutorials for automated testing of Python interfaces taught by station B (actual combat) The latest version) has a total of 200 videos, including: 1. [Interface Automation] The current market situation of software testing and the ability standards of testers. , 2. [Interface Automation] Fully skilled in the Requests library and the underlying method call logic, 3. [Interface Automation] interface automation combat and the application of regular expressions and JsonPath extractors, etc. For more exciting videos, please pay attention to the UP account. https://www.bilibili.com/video/BV17p4y1B77x/?spm_id_from=333.337&vd_source=488d25e59e6c5b111f7a1a1a16ecbe9a

a. Organize all the states of the ticket order:

Unpaid, Canceled, Paid, Ticket issued, Refunded, Rebooked, Used

b. Draw a state transition diagram:

picture

picture

c. List the state-event table:

This item is not mandatory, you can skip this step according to the actual situation, and directly get the state transition tree;

picture

picture

d. Obtain the state transition tree (test path):

picture

picture

Get the test path through the above:

  1. Unpaid --> Canceled

  2. Unpaid --> Paid --> Ticket issued --> Rebooked successfully --> Refunded successfully

  3. Unpaid --> Paid --> Ticket issued --> Rebooked successfully --> Used

  4. Unpaid --> Paid --> Ticket issued --> Refund successful

  5. Unpaid --> Paid --> Ticketed --> Used

  6. Unpaid --> Paid --> Rebooked successfully --> Refunded successfully

  7. Unpaid --> Paid --> Successfully rebooked --> Used

  8. Not paid --> paid --> successful refund

  9. Unpaid --> Paid --> Used

e. Obtain test cases according to the state transition tree

Each of the above test paths is a test case, and each path can be covered by the test. For state transitions, there are multiple event triggers and operations covering multiple events, such as the test path "unpaid --> cancelled", need to test 2 situations: 1) The user manually cancels the ticket order 2) More than 45 minutes If the user fails to pay, the ticket order will be automatically canceled

5. Summary

In actual work, for products with complex business processes, when the use case design cannot be done well through the method of scene coverage, the idea of ​​​​the state transition method can be applied, starting from various states of the business, and passing the switching conditions between these states Connect them together for test coverage to ensure high coverage of use cases.

Guess you like

Origin blog.csdn.net/caixiangting/article/details/132212479