Test case design is a common topic for us testers, but it is also a basic skill that we need to practice all the time. It is also an important means for each role in the team to align their requirements awareness for the second time. Let’s just imagine, if there are no test cases, What kind of scene would it be? After the requirements review is completed, our job is to design a test plan for larger requirements. For smaller requirements, we may skip the test plan step and just wait for the test to be proposed and tested. What will happen after the formal intervention in testing? What about the scene? If you look at the requirements document for testing, you can test wherever you want. If you test without a charter, what will be the consequences? With a high probability, it should only ensure the normal process, and miss out on abnormal scenarios and regression scenarios.
Therefore, the correct testing process should be requirements review –> test case design –> test plan design –> preparation of test data according to the plan planning –> test according to the use cases and plan after the test is proposed, and any missed scenarios should be supplemented in a timely manner.
This time I will summarize how I design test cases in my daily work, and the specific manifestations of use cases for offline store business.
Use case design tools
In theory, we can start from the following points when designing test cases:
01 Carefully study the requirements document
Requirements documents are the basis for us to design use cases. Controlling the quality of requirements also controls the quality of our test cases in disguise. Therefore we need to do the following:
- Analyze the rationality of requirements
- Clarify the scope and details of the requirements
- Uncover hidden needs
02 Combine with technical documents to determine the modification interface
For each functional data, it is necessary to clarify the data source, whether it is controlled by the front end or the back end. The technical document is a document for us to understand the functional logic implementation. Through the technical document, we understand the interface and determine whether the data source of the function point is back-end processing. Understand the logical processing from the inside, determine the core interface, design interface use cases, and ensure the correctness, exception handling, and idempotent processing of the core interface.
03 Apply testing theory
When designing test cases, it is easy to follow the design ideas of the product requirements document, resulting in our testing theory not being used, the coverage of use cases is low, and the use cases will appear relatively thin. When designing use cases, we must always keep our testing theory in mind and apply the theory into practice. The following are commonly used test case methods.
Well-known design use case methods include:
- Equivalence classes, boundary values
- Cause and effect diagram, flow chart
- Scenario method, etc.
04 Combined with software quality model
On the basis of the above, we also need to use the software quality model to assist in the design of use cases from the perspective of software quality, and the use cases will be more comprehensive. Generally, the following aspects can be considered:
Function: Whether the expected functions of the product are realized, whether the functions are complete, and whether it is easy to use;
Performance: whether it will cause a large amount of resource consumption to the system and whether it will affect the system response time; whether multiple threads request at the same time, whether the system performs normally;
security : Whether the user's information will be leaked;
Compatibility: whether it can be compatible with different network environments and devices, such as whether the mini program is displayed correctly in Android and iOS systems, whether the click button is valid, and whether the return button is normal; Ease of use: whether the
user Easy to understand and use; whether the prompts are friendly; whether exception prompts are given.
Specific manifestations of offline store business use cases
01 Offline store business
As the name suggests, offline stores have physical stores, and the specific business mainly includes recycling and retail. That is to say, users can be served by clerks in the store and conduct recycling and retail transactions, forming a good closed loop. Offline stores are a relatively new business line. They have been established for more than two years so far. The business is in the process of rapid expansion and steady infrastructure construction. The rapid expansion is reflected in the fact that we are expanding stores and the number of stores is gradually growing. The steady infrastructure construction is reflected in our While expanding, we pay attention to the stability of basic functions and continuously improve basic functions to solve the pain points of store business that can only be determined one by one in the past, free up manpower, and connect to the listening system to accept improvement feedback and suggestions from store staff to help stores Make steady progress.
02 How to design test cases for offline stores
According to the characteristics of the rapid expansion of offline store business, the demand characteristics of stores are mainly reflected in the demand for new functional modules to contribute to the store business; the rapid expansion of business requires data to support decision-making, and store clerks also need to see their own business more intuitively. For work performance data, store needs will also include some statistical needs; with the continuous expansion of offline store business scale, the acceleration of city openings, store openings, and personnel recruitment, there will be some system reconstruction needs, because stores accept clerks. feedback suggestions, so we still have some iteration requirements for existing functions. The following is a brief introduction to how I design use cases based on the demand characteristics of the store business.
New function module
For new functional modules, interface use case + functional use case design can be adopted, which can be mainly implemented from the following points:
(1) Determine the core interface of the new function based on the technical documentation and design the corresponding interface use cases. The interface use cases should be designed as complete as possible and the granularity should be more refined.
Input parameter verification: required field verification, input parameter length, special characters, boundary value design exception use case Output parameter
verification: business logic processing, database table field data, abnormal process processing, whether important user information is desensitized , whether the returned error message involves SQL information and whether it contains project sensitive information.
Idempotence verification: involving state transfer, repeated request writing, and deletion of database data
(2) Functional use cases are mostly designed with page functions and process use cases.
Page function: When designing use cases, the idea of separation of front and back ends is adopted. For the function points already involved in the interface use cases, whether the front end makes corresponding displays based on the returns; whether the front end gives corresponding processing flow use cases based on the user's current operation: if
required When it comes to processes, the execution process can be written in the use case to ensure the readability and executability of the use case during development and self-testing.
Existing function module iteration
To meet the demand for optimizing existing functions, when designing use cases, we first determine whether the interface is new based on technical documents. If it is new, we can design interface use cases for core interfaces, and functional use cases for non-core interfaces; if it is not new, Addition is a change made to the original interface. We need to further clarify the scope of influence of the interface and reflect it in the use case as a regression use case.
technology refactoring
The rapid development of the store has put great challenges on the existing system, and the management roles have become more and more clearly differentiated, so the permission system upgrade has been launched. The functional requirements are consistent with those online, but the menus, operations and data owned by different permissions are Permissions are inconsistent, so all existing functions need to be returned, which is a typical regression requirement. How to design test cases?
Divide into roles
and modules.
Since the function points under each role are quite different, each module will have customized operation functions. When designing use cases, list the differences under different roles in each module. When testing, test according to the role. It can be accurately verified whether the role has this menu, operation or data permission. Some roles are consistent with other roles in terms of menus, operations, and data permissions. In order to maximize the effectiveness and efficiency of use cases, the copy and paste of use cases is simplified and replaced with "same ***".
Statistical requirements
This type of demand is basically based on query, and the page content is relatively large. When designing use cases, we can focus on the following points:
- Scope of data: For example, when is the maximum statistical range, use cases should consider boundary values; stores involve multiple roles, and the data range under different roles must be clear.
- Correctness of data: For example, if the function point is to count the number of goods to be stored and stored in the store and display the details, the use case must not only independently state the existence of this statistical function, but also clarify how the quantity details are counted and mark them. Correctness of quantities and corresponding details
- Abnormal statistics scenarios: For example, if a store clerk leaves or is promoted, or if a store clerk changes stores, do you still need to count this person when counting data in the store dimension?
Summarize
The above are some of my insights on test case design in store business. Finally, I have summarized and sorted out the common daily demand characteristics of stores and how to design use cases for common function points. I hope that we can all design more perfect use cases. Effective use cases ~
Finally, I would like to thank everyone who reads my article carefully. Reciprocity is always necessary. Although it is not a very valuable thing, if you can use it, you can take it directly:
This information should be the most comprehensive and complete preparation warehouse for [software testing] friends. This warehouse has also accompanied tens of thousands of test engineers through the most difficult journey. I hope it can also help you!