As a test, the number of defects found and the severity of the defects can be used as an important indicator to measure its ability. Then how can we find as many permissions as possible, and how can we find defects with high severity earlier? My understanding is to rely on test case design.
As a test, one of the most common daily tasks is to design test cases. What kind of test cases are good test cases? My understanding is that the fewer use cases and the more defects found are good use cases. Good use cases are designed and are a collection of testers’ ideas and methods, not a list of test logic and requirements.
So the question is, how can we design good test cases?
1. Several guidelines for test case design 1. Use case design = ideas. Emphasize the test scenarios and test methods.
2. Step-by-step testing. The test steps mentioned here do not mean that each test case must specify the test steps, but refers to the areas where defects will appear through the adjustment of the test steps, and the test steps need to be focused on, such as adding operations. Simply adding functions is OK. Yes, but first delete a piece of data, and it fails after adding the same data. This involves operating steps.
3. Use case flow. This process relies on a complete business flow chart. Each branch is a tributary. Requests initiated by the business end will eventually flow to a branch. The process is to sort these branches into test scenarios and cover the business logic by covering the test scenarios. .
Second, the steps of test case design:
1. Identify the original requirements.
The original requirement is the requirement of the user (customer) of the software. Only when the requirement document foundation + essential understanding can really understand what the requirement is to achieve, and use this as a starting point to not deviate from the essence of the requirement;
2. Split the original requirement.
In the requirements testing phase, if you sort out the requirements according to the requirements testing strategy, you should have a clear idea of all the requirements points. List the requirements points in this part and you can use them as rough requirements test points;
3. Sort out the business logic.
Nowadays, more front-end services are derived from the data returned by the interface. The most front-end is to display and calculate some responses based on the returned data. Therefore, if you design test cases for the page, you need to pay attention to the integrity and correctness of the interface data. The impact of gender on the page, and the test of the interface itself must be summarized in the interface test case design link.
(1). How to deal with the page when the interface does not return data;
(2). The parameters returned by the interface are incomplete, for example, the return package has a list structure, which is used as the basis for displaying the list data in the foreground, but the list is empty;
(3). The interface returns the parameter name that is not required in the package
There is a principle in this place that needs to be paid attention to, namely the separation of front and back ends and the collection of front and back ends.
(1) The front and back ends are separated, and there are dedicated interface testers to ensure the correctness of the interface functions. At this time, as a front-end tester, you only need to ensure that the page is displayed correctly when the data returned by the interface is correct; when the data returned by the interface is abnormal, the page is displayed correctly; the data of the calling interface is correct;
(2) The front and back ends are semi-separated, and the interface is also done. Testing, but using automated tools to ensure the correctness and patency of the basic parameters, and the logic of the interface needs to be tested in the previous stage. At this time, as a front-end tester, you need to understand the implementation logic of the interface, such as data processing logic, storage structure, etc. Based on this, the front-end test cases are designed, and if necessary, the front-end must be bypassed and the interface is directly called to simulate the front-end test.
To sum up, the degree of understanding of business logic depends on the structure of the business. After understanding the business logic, supplement the business logic test points corresponding to the demand point.
4. Distinguish between page tests and business logic tests
4.1. Page level tests follow the following methods:
(1). Overall interface test: to verify whether the overall interface is consistent with the design drawing;
(2). Interface element test:
( 3). Control operation verification: such as verification of whether the control can be operated and whether the operation is normal;
4.2. The test of business logic (function) level follows the following methods:
(1). Boundary analysis method must be used in any case, and there is a problem The most is in the boundary value;
(2). If necessary, use equivalence class division method to supplement some test cases;
(3). Use error speculation to add some test cases;
(4). Check that the program logic has been designed If the logic coverage of the test cases does not meet the required coverage standard, enough test cases should be added.
Now software almost always uses event triggering to control the process. The scene when the event is triggered forms a scene, and the same event Different trigger sequences and processing results form a stream of events.
Software testing exchange group: 785128166
WeChat public account: Programmer Erhei; After paying attention, you can receive a set of video resources for free; explain in detail: python automated testing, web automation, interface automation, mobile terminal automation, interview experience and other related content, the value of learning resources depends on you Action, don’t be a "collector"
Here is a collection of selected dry goods articles for functional testing: