Hello everyone, I am Yifei, today we will talk about the design of software test cases.
1. Understand the original requirements of the software (test purpose)
When writing a test case for a software or module, you must understand the original requirements of the function, that is, the requirements of the users (customers) of the software. After understanding the original requirements, the written test cases are more purposeful.
2. Familiar with the functional requirements of the software (test points)
This functional requirement refers to the detailed requirement point of the software, which is generally reflected in the requirement document. What we need to do here is to refine the "rough" needs into small demand points. After you are familiar with the functional requirements, you need to know how the software is used so that various operations can be covered.
In short, the test cases must cover all the requirements, this is the most basic point.
3. Familiar with the realization principle of the software (test point)
After understanding the original requirements and the functional requirements of the software, test cases written according to the requirements can basically be covered more comprehensively.
On this basis, be familiar with the realization principle of the software and understand the internal processing of the software.
(1) The process of familiarizing with the principle is the process of further familiarizing with the software. If only cover the case from the demand point, the test case can only cover the "surface" layer. Some internal processing procedures may not be covered, and these uncovered codes are likely to be a risk point.
(2) After being familiar with the principle of modules, another point is that it is easy to analyze the relevance of software modules. A large-scale software is a combination of some small modules. The larger the software, the greater the coupling and the more "interactions" will be. If the design use case is only considered from the module itself, it is likely to cause risks to other modules.
4. User scenarios and online issues
Considering the user's usage scenarios, this is more important in some network equipment, such as the later use of software in some real use environments.
It is also summarized from some online problems, those areas are prone to errors, and need to be taken into account when designing the case.
5. The framework of the test case
The framework of a test case reflects a tester's overall idea of designing test cases. The framework is also divided from large to small, which can be:
UI interface, function, fault tolerance, compatibility, performance and other categories, each category is divided into small categories according to the logic of the software, and finally subdivided into test points.
6. Test procedure (test technique method)
The first 4 points are considered from the point of view of test points. After the test cases are completed at the test point, the next step is the test steps and test results.
Test cases can be written in detail, or they can be written relatively simple. It depends on the company's requirements. Some companies require very detailed test steps, including one-to-one correspondence between test results and test steps.
Companies that require very detailed test procedures are generally afraid that the execution of the executives will not be in place, leading to failure to understand the purpose of the case and leading to missed tests. It usually occurs when new employees are unfamiliar with the software system.
If the test steps are written in detail, it will be time-consuming, and too detailed will limit the thinking of the executive. I personally think that the focus of test cases is on test points.
7. Some ideas for test cases
In designing test cases, boundary values, equivalence classes, pass and fail tests are usually used more often. Consider the following from a single module or a single function point: (combined with the views of some online articles)
1. UI interface: ease of use, prompt information, overall layout, button icons, colors, Chinese and English punctuation typos.
2. Data diversity: valid data, legal invalid data (boundary value), illegal abnormal data, legal data combination that produces error output and other data combinations.
3. Operation diversity: add delete edit query, multi-user operation.
4. Capacity test
5. User authority: use authority, authority for various operations.
(6) Upgrade installation and uninstallation: smooth upgrade
(7) Log related (including debug log)
(8) Logical division of software functions: code logic that cannot be covered by functional division, white box gray box use cases can be added.
(9) Reliability and fault tolerance
(10) Compatibility: browser, system, supporting software.
(11) Security
(12) Performance (the performance here refers to the performance of a single module or subsystem)
In short, test cases must first cover all functional requirements, and then understand the software processing logic. You can look at the test cases together with developers, and add the corresponding use cases for the code flow that is not covered. So far, the basic functions of the use cases will basically not appear. .
On this basis, some use cases such as reliability, fault tolerance, and compatibility can be designed to test the stability of the software.
I recommend a software testing exchange group, QQ: 642830685. The group will share software resources, test interview questions, and industry information from time to time. You can actively exchange technology in the group, and there are big guys to answer your questions.
