Maybe you will say, "user login" object of this test is a bit too simple, too, I want to find a user, let him on the interface of input the user name and password, then click the "confirm" button, verify whether it is ok to login successfully, indeed, this constitutes one of the most basic, the most typical test cases, and this is the end user when using the system the most typical Happy Pass scene,

But as a test engineer, your goal is to ensure that the function of the system under various scenarios is in conformity with the design requirements, so you need to consider the test cases will need more and more comprehensive, so you may according to the requirements of "user login" function description, combining with the equivalence class partition and boundary value analysis method to design a series of test cases,



What is equivalence class division and boundary value analysis method? First of all, both belonging to the most commonly used, the most typical, which is the most important method of black box testing,

Equivalence class partition method, it is all possible input data is divided into several subsets, in each subset, if any one of the input data to reveal potential errors in the program have the same effect, so it forms a subset of the equivalence class, later as long as freely choose a value from each equivalence class testing, you can use a small amount of the typical test inputs to obtain a better test coverage as a result,
Boundary value analysis method, is to choose the input and output of the boundary value testing, because a large number of software errors usually occur in the boundary of the input or output range, so it is necessary to focus on boundary value testing, usually choose exactly equal to the just just less than or greater than the boundary value as the test data,
Can see from the methodology, boundary value analysis is the equivalence class partition is added, so the two combined test method often used,

Now, in view of the "user login" function, based on the equivalence class division and boundary value analysis method, we design test cases include:

Enter the registered user name and password correctly, verify the login success;
Enter the registered user name and not the correct password, verify login failed, and prompt information correct;
Input not arbitrary registered user name and password, verify login failed, and prompt information correct;
Both the user name and password is empty, verify login failed, and prompt information correct;
One of both the user name and password is empty, verify the login fails, correct and prompt information;
If the login function to enable the function of authentication code, under the premise of the user name and password is correct, enter the correct verification code, verify the login success;
If the login function to enable the function of authentication code, under the premise of the user name and password is correct, the input the wrong verification code, verify login failed, correct and prompt information,
List after these test cases, you may have already feel satisfied, because you feel has put its test in the design of knowledge used in these cases, indeed, the above test suite has covered the main functional test scenarios, but in the eyes of a good test engineer, these cases can only be reached the standard of barely passing,

What? Just to pass the exam? If you have this idea, then I suggest you continue to see the following content before, think carefully, really need to expand these test cases,



Now, I share with you the experienced test engineer will add test cases:

The user name and password is case sensitive;
Whether the password box on the page encryption display;
Backend system to create the user login successfully for the first time, whether or not prompted to change password.
Forget the user name and password of the function is available;
The front page is according to the design requirements, user name and password length;
If the login function need verification code, click on the verification code picture whether can change the verification code, change after verification code is available;
Refresh the page will refresh verification code;
If the authentication code has timeliness, need we validate and limitation of the validity of the verification code in aging;
The user login successfully but session timeout, whether to continue operating will be redirected to the user login interface;
Different levels of users, the administrator users and ordinary users, for example, after login system permissions are correct;
Whether the page is the default focus location in the user name input box;
The shortcut Tab and Enter, whether can be normal use,


Watching these use cases, you might say: "wow, originally a simple login there was so much need to test point", but, you don't be fooled, "user login" function test doesn't end,

Although the improved compared to a set of test cases before the test coverage is indeed have improved a lot, but standing in the point of view of senior tester, there are many cases need to design,
By what I said, you may have found that all the above test case design are built around the explicit functional requirements validation, in other words, these cases are aimed directly at "user login" function of functional verification and testing, however, a quality of the software system, in addition to the explicit functional requirements, other non-functional requirements that implicit functional requirements is extremely critical,

Explicit Functional requirements (Functional requirement) from the literal meaning can understand well, refers to the software itself need to implement specific functions, such as "normal user use the right user name and password can be a successful login", "non registered users cannot login" and so on, this all belongs to the typical explicit Functional requirements description,



What are the functional requirements (Non - functional requirement)? From the perspective of the dimensions of software testing, non-functional requirements mainly relates to safety, performance and compatibility with the three aspects, in all the test case design above, we didn't consider completely to test the non-functional requirements, but these tend to be key factors in determining the quality of software,

Understand the importance of non-functional requirements test, you can think about what needs to be designed test cases, and then take a look at what use case, I'll give believe this way will be more for your help,



Security test cases include:

If the user password backend storage encryption;
The user password is encrypted in the process of network transmission;
Password is valid, the password validity expires, whether tip need to modify the password;
Not logged in, in the browser to directly enter the URL address after logging in, verify will be redirected to the user login interface;
If the password input box does not support copy and paste;
Password input box input password whether can be viewed in the page source mode;
The user name and password input box input respectively the typical "SQL injection attacks" string, authentication system return to the page;
The user name and password input box input respectively the typical "XSS cross-site scripting attacks" string, verify whether the system behavior been tampered with;
Login failed cases many times continuously, the system will prevent subsequent attempts to cope with brute force;
The same user login multiple browsers, in the same terminal on the function of mutual exclusivity is in line with the design expectations;
Same user has on more than one terminal browser login, verify whether the login is mutually exclusive,
Performance pressure test cases include:

A single user login response time is less than 3 seconds;
Single user logs in, the background request quantity is too much;
High concurrency scenarios user login response time is less than 5 seconds;
Whether high concurrency scenarios server monitoring indicators in line with expectations;
Collection points higher concurrency scenarios, whether there is a deadlock and unreasonable resources.
Long time continuous login and logout, a large number of users on the server side if there is a memory leak,


Compatibility test cases include:

Different browsers, validating the login page display and function;
Under different versions of the same browser, validating the login page display and function;
Different mobile terminals under different browsers, validating the login page display and function;
The interface of different resolution, validating the login page display and function,
Here, you will find "user login" function test is very simple, isn't worth mentioning? A seemingly simple functional testing, incredibly covers so many test cases, in addition to covering specific functional requirements, also need to consider many other non-functional requirements,