The interview encountered the login function test case design, did you answer correctly?

Give you a login function, how to design test cases

Even if it is the most commonly used and smallest login function, there are actually a lot of test cases involved. This topic usually uses interviews to examine the comprehensive ability of job applicants, especially the design thinking of test cases, because you A test case design method, such as equivalence class, boundary value, decision table, etc., in actual work, it is impossible to design strictly according to this standard. In most cases, due to limited time cost and economic cost, it is It is impossible to exhaust all possible combinations, but to integrate these design methods, cover more scenarios and functions with as few use cases as possible, and select the test scope and design test cases in a targeted manner to minimize the risk of defects and R&D costs. balance between.

Assuming there is a login box with account number, password input box, remember password function, and login button, please design as many test cases as possible.

insert image description here

1. Functional test

  • Enter the registered user name and correct password to verify that the login is successful.

  • Enter the registered user name and incorrect password, and the verification login fails and the prompt information is correct.

  • Enter an unregistered user name and any password, and verify that the login fails and the prompt information is correct.

  • When verifying that the user name and password are empty, the login fails and the prompt information is correct.

  • When verifying that the user name or password is empty, the login fails and the prompt information is correct.

  • If the verification code function is enabled, enter the correct verification code under the premise of correct user name and password to verify that the login is successful.

  • If the verification code function is enabled, and the wrong verification code is entered under the premise of correct user name and password, the verification login fails and the prompt information is correct.

  • Whether username and password are case sensitive.

  • Whether the password box on the page is displayed encrypted.

  • Whether to prompt to change the password when the user created by the background system successfully logs in for the first time.

  • Whether the functions of forgotten username and forgotten password are available.

  • Whether the front-end page limits the length of user names and passwords according to design requirements.

  • If the login function requires a verification code, click the verification code picture to see if the verification code can be replaced, and whether the new verification code is available.

  • Whether refreshing the page will refresh the captcha.

  • Verify the validity of time-sensitive verification codes, including verification codes within and outside the time limit.

  • After the user logs in successfully but the session times out, whether to continue the operation will be redirected to the user login interface.

  • Whether the permissions of different levels of users (such as administrators and ordinary users) after logging in to the system are correct.

  • Whether the default focus of the page is located in the input box of the user name.

  • Whether the shortcut keys Tab and Enter can be used normally.

2. UI testing

  • Verify that the layout is sound and that the input boxes and buttons are aligned.
  • Verify that the interface design style is consistent with the UI design style.
  • Verify that the text on the interface is concise and easy to understand, and that there are no typos.

3. Performance test

  • Verify that the response time for a single user login is less than 3 seconds.
  • Verify that the number of background requests is not excessive for a single user login.
  • Verify that the response time for user login in a high-concurrency scenario is less than 5 seconds.
  • Verify whether the monitoring indicators of the server meet expectations in high concurrency scenarios.
  • Verify whether there are resource deadlocks and unreasonable resource waiting in high concurrency scenarios.
  • Verify that there is no memory leak on the server side when a large number of users log in and out continuously for a long time.

4. Safety test

  • Verify that user passwords are encrypted when stored in the background.

  • Verify that user passwords are encrypted during network transmission.

  • Verify that the password has an expiration date, and prompt to change the password after expiration.

  • Verify that if you are not logged in, directly entering the URL address after login in the browser will redirect you to the user login interface.

  • Verify that the password input box does not support copy and paste operations.

  • Verify whether the password entered in the password input box can be viewed in the page source code mode.

  • Verify the return page of the system after entering typical "SQL injection attack" strings in the user name and password input boxes respectively.

  • Verify whether the system behavior has been tampered with after entering typical "XSS cross-site scripting attack" strings in the user name and password input boxes.

  • Verify that in the case of multiple consecutive login failures, the system blocks subsequent attempts to deal with brute force attacks.

  • Verify that when the same user logs in on multiple browsers on the same terminal, whether the mutual exclusion of the login function meets design expectations.

  • Verify that when the same user logs in on the browsers of multiple terminals successively, the logins are mutually exclusive.

5. Compatibility test

  • Under different browsers, verify the display and function correctness of the login page;

  • Under different versions of the same browser, verify the display and function correctness of the login page;

  • Under different browsers of different mobile device terminals, verify the display and function correctness of the login page;

  • Under different resolution interfaces, verify the display and function correctness of the login page.

6. Network related

  • Verify whether you can log in normally in the case of network delay, weak network, switched network or disconnected network.
  • Verify that when logging in in no-network mode, the "network is not connected" or "network abnormal" prompt is correctly given.
  • Verify that after the first login request times out (the server went down and then recovered), a second login request succeeds.
  • After verifying that the login failed the first time without the network, connect to the network and log in again.
  • Verify whether you can log in normally when you encounter a network switch (such as switching from 4G to WiFi environment) during the login process.

We have seen that when designing use cases, we should not only consider functions, but also consider performance, security, and compatibility issues, and these non-functional requirements are the key to product stability and security.

Seeing the design ideas of the above test cases, which ones did you think of, and which angles did you ignore? I think many people should, there are always some points that have not been covered, but we should try our best to train ourselves this kind of global and multi-dimensional thinking.

If you want to be an excellent test engineer, you must have a wide range of knowledge in order to design very complete test cases and improve test coverage.

Guess you like

Origin blog.csdn.net/XingLongSKY/article/details/131489408