In this article, we mainly talk about the most common and fundamental skill of a test engineer, the ability to design test cases.
test case
A test case is a document designed to focus on how to produce specific results by using the test technology determined in the test plan to refine and refine the determined test conditions step by step.
In layman's terms, it is to turn the actions you want to test into under what circumstances, what actions to do, what data methods to use, and what kind of results you want to get at the end into a test case. Therefore, each test case should have its preconditions, its events and corresponding parameters, and finally the expected results. This is a qualified test case.
For example, the login function, now basically every website, app, etc. has a login function, and it is also asked a lot in the interview. Find an existing user, enter the correct user name and password on the interface, click the login button, and see Have you logged in successfully. This is the simplest operation and constitutes our first and most normal test case. It also includes several elements mentioned above:
Precondition : an existing user
Actions and parameters: Enter the correct user name and password, and click Login
· Expected result: successful login
This is of course a complete test case, but of course not enough for a login module, this is just one of the qualified test cases in this module. So how to write more test cases? Now it's time to look at our verb: design. Design actually corresponds to a set of methods. Only with the correct method can we design qualified test cases.
use case design
More common test case design methods
· Equivalence class division method
· Boundary value method
· Cause-effect diagram design method
· Decision table design method
· Orthogonal experimental method
· Miscalculation
· Scene method
As for the principles, principles, and how to use it, there are a lot of information on the Internet, so I won’t talk about it here. There are so many methods, so how to choose when designing. Here is a joke that is circulating on the Internet
Choose equivalence for input classification, add boundaries for a given range, combine conditions to determine cause and effect, determine if conditions are isolated, use orthogonality for infinite exhaustion, use complex business scenario method, rely on experience for error guessing, and fully cover the test.
Can all these methods be used? The answer is no. In my test cognition, the most used methods are boundary value, equivalence class, scenario method and error guessing. So to sum up, our design ideas in real work are probably:
· Use the equivalence class division method to divide most of the scenario design test cases
In any case, the boundary value analysis method must be used. Experience shows that the test cases designed with this method have the strongest ability to find program errors
· The business complexity of the program is relatively high, so use the scenario method to supplement part of the test cases
· If you are very familiar with the business, you can add some test cases based on your experience where errors are prone to occur
Based on this design method, which is still the original login interface, we can roughly design the following test cases:
1. For an existing user, enter the correct user name and password, click Login, and verify whether the login is successful;
2. Do not enter any content, click Login directly, verify whether the login fails, and the prompt information is correct;
3. For an existing user, enter the correct user name and wrong password, click Login, verify whether the login fails, and the prompt information is correct;
4. Existing users A and B, enter A’s user name and B’s password, click Login, verify whether the login fails, and the prompt information is correct; enter a non-existing user name and any password, click Login, verify whether the login fails, and prompt information correct;
5. For users who already exist but have abnormal status (such as deactivated, frozen, locked), enter the correct user name and password, click Login, verify whether the login fails, and the prompt information is correct;
6. For an existing user, the user name is in lowercase, enter the uppercase user name and the correct password, click Login, and verify whether the login fails;
7. For an existing user, the password is in lowercase, enter the correct user name and uppercase password, click Login, and verify whether the login fails;
8. Whether the password is automatically encrypted and displayed or contains hidden/displayed functions, and verify whether it can be used normally;
9. Whether the user rights are distinguished, and whether the administrator and ordinary user log in successfully and jump correctly;
10. Whether the user name and password input box has a length limit, and whether it is consistent with the length requirement during registration;
11. Whether the verification code will be displayed automatically if the login failure reaches a certain number of times;
12. If there is a verification code, enter the correct username and password and the correct verification code to verify whether the login is successful;
13. If there is a verification code, enter the correct username and password and the wrong verification code to verify whether the login fails;
14. When there is a verification code, click the verification code picture (or change a button) to change the verification code, and whether the replaced verification code is available;
15. If there is a verification code, click the verification code picture (or change a button) to replace the verification code, log in with the verification code before the replacement, and verify whether the login fails;
16. Whether the verification code of the refresh page follows the refresh;
17. If the verification code has expired, enter the current verification code to verify whether the login fails;
18. After the login fails, whether the user name is saved and the password is empty;
19. Whether there is a function of remembering the user name and remembering the password, and whether it is available;
20. Whether the shortcut key is available, and whether the password cannot be pasted;
21. Whether TAB and ENTER can automatically jump to the control and automatically submit;
22. Whether it supports third-party login (WeChat, Alipay, QQ, Weibo, etc.), and whether the login verification is correct;
23. Whether it supports mobile phone verification code login, whether the mobile phone can receive text messages, and whether the login can be successful;
24. The verification code on the mobile phone has timed out. If you use the timed-out verification code to log in, can you log in successfully?
25. Whether to redirect to the login page after the user session expires;
26. After the user logs out, whether the operation can be continued through the back button;
27. Whether it has the function of forgetting the password and whether it is available.
OK, just listed a few, but if I were to rate this set of use cases at this point, I would rate it 80. There must be friends who want to diss me by real name, already so comprehensive, what more do you need? Why only 80 points? This involves the third dimension of our discussion topic today, the adjective "excellent".
Talk about excellent test cases
For a set of test cases, only complete, repeatable, verifiable, and comprehensive test cases are the best test cases.
Data log test
The so-called data log test mainly includes test items that we cannot see on the front end, page or APP. Let me give a few examples:
· Whether the database password field is encrypted or not
Whether the number of login failures is recorded in the database and cache, and whether the logic is correct
· Whether the status of the database is correctly modified in scenarios such as login failure and freezing
Whether the error log is complete and easy to troubleshoot
Whether the object is easy to locate and easy to automate
Whether there is an increase in buried points for user behavior analysis
Interface UI testing
For daily testing, the testing of the interface and user experience is also very necessary. The use of TAB and ENTER is actually a kind of user experience, so if you want to test more comprehensively, you must also consider the interface test.
Whether the layout is reasonable and aligned
Whether the interface design is consistent with the requirements and UI design documents
· Whether there are typos or punctuation errors
· Is the page color matching appropriate?
· Whether the error text is clear and easy to understand
Whether the visual effect of the interface is appropriate, and whether the animation display of the interface is smooth
compatibility test
Whether it is compatible under different operating systems (Windows, MAC OS, LINUX)
· Under different versions of the same operating system, whether it can be displayed normally and the function is correct
Whether it is compatible under different browsers (Chrome, IE, FireFox, etc.)
Whether different versions of the same browser are compatible
· Whether the mobile terminal is compatible
Whether it is compatible to display when zooming in and out of the interface
Whether the interface display is correct in different languages
Whether it has a high-contrast reading mode (prepared for people with poor eyesight)
Performance Testing
Performance testing can be divided into server-side performance and front-end performance, which also need to be considered comprehensively. At the same time, performance indicators and scenarios also vary with different modules, different companies, and different needs. I will briefly give a few comparisons here. Generic example:
· Maximum concurrent user login interface (response time within 3s)
· Performance metrics for servers under specific load tests
Stability and performance indicators of services during stress testing
· Service distributed processing logic, load balancing logic, cache and queue usage
· The maximum concurrency of the interface that can be supported
GC processing, whether there is memory overflow, etc.
Whether the database has slow [url=]SQL[/url] and deadlock under high concurrency
· Page loading speed
· Page resource size, whether to apply Sprite
· YSLOW analysis, static performance
Safety test
Last but not least is our most overlooked security test. In many cases, we tend to ignore the threats brought by security, but in fact, once a security problem occurs, the loss will be far greater than the impact of a certain bug. Let's first briefly introduce the security testing measures that should be taken on the login interface, and then we will talk about all aspects of security testing in detail later.
Verify whether critical data is transmitted over HTTP or HTTPS
Whether to include weak passwords
Whether it is easy to be cracked by brute force
Whether to use multi-factor authentication
Whether to use mutual exclusion authentication for login
· Generated session token (sessionID) strength
Whether there is a session token leak in the transmission
· Whether it contains unauthorized loopholes
· Whether you can log in successfully using the universal password
Whether it is possible to perform SQL blind injection
· Password storage encryption security
Whether it has XSS (cross-site scripting) attack defense
Whether it contains CSRF attack vulnerability
· Prevent man-in-the-middle attacks during Token or password transmission
Written at the end, the execution of test cases should also be linked to the urgency of the actual project. Obviously, the project is very urgent and needs to be launched. Is it possible to execute all the above use cases? Then nothing can be achieved, so the priority of test cases should be clear. Execute relatively appropriate priority use cases at the appropriate time to ensure product quality.
Finally, I would like to thank everyone who has read my article carefully. Reciprocity is always necessary. Although it is not a very valuable thing, you can take it away if you need it:
These materials 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, and I hope it can help you! Partners can click the small card below to receive