A few days ago when I saw a good article online now record it.
Material from the Internet, if infringement, please contact deleted.
Log in patients with functional design
About test case design, according to different business, different abilities, different design test cases.
Requirements: As a user, I want to enter the account number, password and a verification code, so that I can log in normally
According to the above requirements, different testers may test cases designed to test different login feature.
I think this is 60 minutes of test cases
Example design of registration points -60
- Enter the registered user name and the correct password, verify that the login is successful
- Enter the registered user name and password is incorrect, verify that the login fails, correct and prompt information
- Enter an unregistered user name and any password, verify that the login fails, correct and prompt information
- Both the user name and password are empty, verify that the login fails, correct and prompt information
- One user name and password are both blank, verify that the login fails, correct and prompt information
- If the login feature is enabled verification code function, under the premise of the correct user name and password, enter the correct verification code to verify that the login is successful
- If the login feature is enabled verification code function, under the premise of the correct user name and password, enter an incorrect code, verify the login fails, correct and prompt information
- Whether to support third-party login
Base case of 60 points on, add the following case, which I think 70 minutes of test cases
Example design of registration points -70
- User name, password, authentication code is case sensitive
- Whether encryption password box on the page display
- Input box default focus
- The first time a user's back-end system to create a successful login, if prompted to change your password
- Forgot your username and password forget feature is available
- Front page whether to limit a user name and password length according to design requirements
- Click on the picture verification code if you can replace the verification code, the replacement code is available
- Refresh the page whether to refresh code
- If the codes are timely, respectively, need to verify the validity of the limitation and the outer limitation of the codes
- After users of different levels, login system permissions are correct
- Whether the user login times out, continue operation will be redirected to the user login interface
- The default page if the focus is positioned in the user name input box
- Switching between the network environment, log on to verify proper function
- Shortcuts Tab and Enter, etc., can normally use
- Different input methods can not properly input
- English input method can not normally enter
- Can I use the packet capture tool caught request directly log
- In addition to verify the format and length of the front end, back-end whether the check?
- The user has logged on, after killing the process APP, APP remains open whether the state is logged again
- After a successful login, session timeliness settings
On the basis of 70 points on the use case, add the following case, which I think 80 minutes of test cases
Login use case design -80 points
Performance test design points:
- Single user login response time is less than 3 seconds
- Single-user logs on, the background whether the excessive number of requests
- Highly concurrent scenario, the user response time is less than 5 seconds log
- High concurrency scenarios, monitoring indicators server meets expectations
- Rendezvous at high concurrency scenarios, whether there is a resource deadlocks and unreasonable wait resources
- Long continuous large number of users to log in and log out, the server memory leaks
Safety Test Test points:
- User password is encrypted back-end storage
- User password is encrypted network transfer
- Is there a password expiration date, after the expiration, if prompted to change the password
- Without login, enter the URL address after login directly in your browser, to verify whether the user is redirected to the login screen
- Password input box supports copy and paste
- User name and password input boxes are typical SQL injection attack strings, verify system behavior has been tampered with
- Login failed repeatedly case, whether the system will prevent subsequent attempts to deal with brute force
- The same user on multiple browsers the same terminal login, login verification function mutually exclusive with the design expectations
- The same user has to log in on the browser multiple terminals to verify whether the login mutually exclusive
- Remote login check, replacement of equipment check, whether considered abnormal login account frozen
Base case of 80 points on, add the following case, which I think 90 minutes of test cases
Login use case design -90 points
Compatibility test:
- Different platforms, and display function to verify the correctness of the login page
- Under different devices, and display function to verify the correctness of the login page
- Different browsers, and display function to verify the correctness of the login page
- Different resolutions, to verify the login page display and functionality of correctness
- The same browser, different versions, verify that the login page is displayed and functional correctness
A student asked me, why not 100 test cases. The answer of course is no, the software testing theory and which is impossible to do exhaustive testing contrary.
At any time, when you receive a demand for a function, in addition to considering the needs of covering functional test points outside, but also need to consider non-functional test point design, so as to better ensure the integrity of the function.
The above information conveys a design idea, of course, there will be more for the login function of test points, this would need to project development process, test time and economic costs, risk-driven pattern-based, have focused to select the test range and test cases, defects in order to strike a balance between risk and development costs.
Note: All information reference RU teacher (RU Bing Sheng) geek time in the "software testing 52 stresses"
