Thinking analysis of test cases

As a beginner, the most worrying problem for many students is that they don’t know how to start writing test cases . They are worried that the test cases are incomplete and incomplete. For fear of missing a certain point, it is very important that they will cause their next test work. There are hidden dangers in;

But if you are too late to write test cases by hand, you are worried that your overall test plan will be affected by your own delays. This mentality of fearing wolves and tigers before and after, I believe all people who have just started testing have had it.

Let me give you a few comments. First of all, for the writing of test cases, no matter what you can think of, write it first . No matter what you think , the test cases are written .

Secondly, don’t worry about whether your use cases are good or bad , because before the test cases are executed, whether they are newly hired employees or old employees, they need to participate in the use case review process. During this process, problems in the test cases are discovered, and at the same time Everyone will be given suggestions for revisions. Therefore, everyone should settle down to write the test cases that they think of, so as to help find the problem and solve it better.

What's more, whether old employees or newcomers, you need to use case review , that is to say, everyone’s test cases cannot be said to be perfect and comprehensive. They are trying to be as comprehensive as possible during the continuous review process, and the coverage rate is Taller. However, veteran employees have more experience and experience than Xiaobai, so in the process of writing test cases, there must be a set of suitable methods.

 

 

Next, I will share the dry goods with you with a specific scenario analysis method, so that all the "smart women" tested have rice to cook.

 

Original requirements for login scenarios:

• Ordinary login page, there are two text input boxes on the page, one for the account name;

• An input password (the account number box displays the entered account number, and the password box is displayed with black dots).

• There are two buttons below the two text boxes, one is the "Login" button.

• Enter a successfully registered account name + password combination, click the login button, and after successful login, you will be redirected to the personal information page.

• The other is the change password button. After clicking it, it will jump to the change password page. After the change, you need to log in with the new password. The original password login prompts incorrect. (By default, an account has been registered successfully, use that account to log in; at the same time, prepare a logged-out account for testing)

demand analysis:

(1) As a function point of the original requirement, this module is relatively simple. First of all, this is a single module and there is no test point for functional interaction. Secondly, the page UI is relatively simple, and there is no special specification, it is only necessary to display the page normally when viewing it .

(2) Since there are relatively few tests for a single module, our focus should be on the input boxes, buttons, and the input of account numbers and passwords on the page.

Stop for a moment, think about what you can think of?

 

• Can I log in successfully if my account name and password are entered incorrectly?

• Can I log in successfully if I entered the wrong account name or password?

• Is the Chinese or English name of the account okay?

I believe everyone can think of the above, but these are far from enough , so next, the container for the rice will be served first. I am used to dividing the test points in the scene into three scenes.

1. Conventional scene

It is just like the few test cases that you can write according to business processes (described in the requirements document) or life experience. I define it as a regular scenario.

2. Occasional scenes

I divided the accidental scenes into two types, one is called the occasional scene, and the other is called the provocative scene.

• Occasional scene

      It refers to the scene that can be seen in life experience, but the frequency of use is very low, or even not used, but after the review process, it is a scene that can be considered and can be written independently

• Thorny scene

      Contrary to the operation required by the function point or simply runs counter to it, it is a bit like a scene of "picking bones in an egg".

3. Professional scene

Need to consider professionalism, including programming ideas, and database expertise as a support to master test case scenarios.

 

OK, let's start watching the rice next!

     Based on the analysis of the original requirements, the common scenarios in the login scenario summarize the following:

1. Enter the account name and password, the account name is correct, the password is wrong, click login, login fails;

2. Enter the account name and password, the account name is wrong, the password is wrong, click login, login fails;

3. Enter the account name and password, the account name is correct, the password is correct, click login, login fails;

4. Enter the account name and password, the account name is correct, the password is correct, click login, login is successful;

5. Enter the account name and password, enter the account name or password in Chinese, and click login to log in;

6. Enter the account name and password, enter the upper and lower case of the English name, click login, and log in.

 

   2. Accidental scene

(1). Occasional scenes

   a. Open the login page and check whether the login page is displayed normally and whether there are garbled characters;

   b. After clicking login, jump to the personal information page to check whether the personal information is consistent with the page display;

   c. After the account has changed the password, enter the new password to log in and log in;

   d. After the account has changed the password, enter the old password to log in and log in.

 

(2). Stabbing scene

   a. Without entering the account name and password, click the login button to check the login status;

   b. Without entering the account name or password, click the login button to check the login status;

   c. Enter a special symbol in the text input box and click Login to check the login status.

 

   3. Professional scene

(1). Enter a long account name or password;

      If you select a fixed number of digits to pass the parameters in the text box, there may be login failures. If your user name is eight digits, and you enter ten digits; at this time, if only the first eight digits are taken in the process of obtaining the user name in the text box, then you can log in successfully, but if you get ten digits, you may be Report an error.

 

(2). Account name and password input "'or 1 = 1--";

     The bug that occurred in the Oracle database is a universal account, so it is necessary to develop a check method to avoid this problem.

 

(3). Enter a log-out account name and password combination, click login to view the login status.

     If the account is cancelled, his status in the database is different from that of the normal account. After clicking login, the system will give a corresponding prompt.

 

For the analysis of the above scenes, especially the professional scenes, it must be difficult to understand, so you are required to sort it out after you see it. The rest of the scene analysis hopes to bring you some help in the future.

 

　1. According to the requirements document, completely follow the requirements document framework/function description, and organize them into use cases according to their own understanding. Simply put, it is to edit the content described in the requirements document again according to the format of the use case, and add all the possibilities that can be thought of.

　　2. Search for the same type of functional use cases written by other testers, first understand, and then add/delete/modify according to the small differences in the actual needs of the project to form a use case group that meets the needs.

　　There are actually no tricks to quickly grasping use cases. There is only more reading, thinking, writing, and reviewing.

This article uses the most common test scenarios to discuss how to design more efficient and more comprehensive test cases.

 

Before discussing, let us first understand the design methods of several test cases commonly used in the industry. The current mainstream test case design methods are as follows

1 Common design methods for test cases

1.1 Equivalence class division method

This design method is considered to be the most used one in black box testing, and this method is often used with other methods to design test cases. The commonly used combination is the boundary value division method;

 

Definition: The equivalence class division method divides all possible input data into several parts, and then selects a few representative data from each part as test cases.

 

Criteria for the classification:

1. Completeness, that is, the divided parts of test data together constitute all possible input data.

2. Exclusivity, that is, in principle, the test data of each part should not have overlapping parts.

 

Division method:

1. When the input condition specifies the value range or the number of values, it can be divided into one valid equivalence class and two invalid equivalence classes

2. Under the condition that the input condition stipulates the set of input values ​​or stipulates how it must be, it can be divided into a valid equivalence class and an invalid equivalence class

3. When the input condition is a boolean quantity, it can be divided into a valid equivalence class and an invalid equivalence class

4. In the case of stipulating the rules that the input data must comply with, it can be divided into a valid equivalence class and several invalid equivalence classes (violating the rules from different perspectives)

5. When the input data is specified as a set of values, and each value handles different situations separately, then n valid equivalence classes and one invalid equivalence class can be determined

6. If it has been confirmed that each element in the equivalence class that has been divided is different in the way the program is processed, the equivalence class needs to be further divided into smaller equivalence classes

 

1.2 Boundary value analysis method

        This method is based on a particularly commonly used design method. Students who have written code or have extensive testing experience should know that there are many judgment logics in the code. The more complex the business process, the more judgment logic. Even developers with rich experience will be negligent when judging the logic code, especially those students who lack development experience, it is easier to ignore certain boundary issues.

 

       Definition: The boundary value analysis method is a black box test method for testing the boundary value of input or output. Usually the boundary value analysis method is used as a supplement to the equivalence class division method. In this case, the test cases come from the equivalence class boundary.

 

      Analysis: A large number of errors occur on the boundary of the input or output range, rather than inside the input and output range. Therefore, by designing test cases for various boundary conditions, more errors can be detected. To design test cases using boundary value analysis methods, first determine the boundary conditions. Usually the boundary of the input and output equivalence classes is the boundary case that should be tested. The value that is exactly equal to, just greater than or just less than the boundary should be selected as the test data, rather than the typical value or any value in the equivalence class as the test data.

 

1.3 Scenario analysis method (flow chart method)

        With more and more system functions and more and more complex business, at this time, in order to better test and ensure that all business processes can be covered and tested, it is very necessary to introduce scenario analysis at this time.

 

       Definition: Almost all software now uses event triggering to control the process. The scene when the event is triggered forms a scene, and different trigger sequences and processing results of the same event form an event flow.

 

1.4 Empirical inference

        As testers become more familiar with the system, deepen their understanding of the business, and continue to understand the programmers, sometimes they can be targeted to verify whether a certain problem exists.

 

1.5 Causality Diagram

        The equivalence class division method and the boundary value analysis method both focus on the input conditions, but do not consider the various combinations of the input conditions and the mutual constraints between the input conditions. In this way, although various input conditions may be wrong have been tested, but the combination of multiple input conditions may be wrong has been ignored.

If various combinations of input conditions must be considered during the test, the number of possible combinations will be astronomical. Therefore, a form suitable for describing a combination of multiple conditions and correspondingly generating multiple actions must be considered for the test case. Design, which requires the use of cause and effect diagrams (logical models).

Definition: The causality diagram method is a method of analyzing various combinations of input by using a graphical method to design test cases. It is suitable for checking various combinations of program input conditions.

Several other methods are not commonly used, so I won’t introduce them. If necessary, learn more about them.

2 Overview of design ideas

Above, we have roughly understood the design methods of each test case, and then we will use practical examples to illustrate how to design test cases more efficiently.

2.1 Test of web login page

         Analysis: First, we can analyze which elements of the interface, what rules and requirements each element has, whether there are other special requirements, such as caching, encryption, etc.; after the analysis, we can go according to what we know Choose a suitable test case design method, and write a use case for this page.

demand:

1. Support work ID password and APP scan login

2. Support caching account and password information, no need to enter login next time

3. The password needs to be encrypted whether it is in the front-end or in the cache or in the transmission process.

4. Support verification code image click to replace

5. Support login interface display in different languages, and have the function of remembering the last change

6. Other requirements are as shown

 

After getting the above requirements and prototype diagrams, we can begin to analyze and then design test cases.

 

2.1.0 UI interface test

       First of all, for users, the evaluation of a system is first judged from the visual aspect of the interface. It is like the first meeting between a man and a woman. Well, you are right, it is a blind date. The first impression is basically from the personal From looks and mental outlook, we all know that the first impression is very important, especially in today's fast-paced society;

       For a user, the interface style, human-computer interaction, easy to understand, easy to operate, etc. will directly impress the user’s first user experience. If the first user experience is not good, if the product is not irreplaceable If the product is a sexual product, users are likely to be lost. If the system is paid by the user, although the page is not good-looking, the page is difficult to operate, the page that is difficult to understand will not immediately cause the customer to return the product, but at least it will cause the The user feels unprofessional at all, and then the user is likely to operate with an unpleasant mood, which is likely to cause all kinds of tricks, and ultimately lead to a complete loss of interest in the product. Either call back and ask for re-adjustment, or return a refund.

      In most product development processes, this aspect will be discussed and researched during the preliminary requirements determination and review process. Therefore, it is recommended that the test students should be involved in the requirements phase, from the interface style, human-computer interaction, easy to understand, and easy Several aspects such as operability are reviewed, and good suggestions are given.

      Then the next step is to test the business functions of the system. After business analysis, it is a login function and two login modes. Among them, there are three input boxes on the login page of the account number, a drop-down box, a picture button, and a text button. , A login button; scan the login page and there is a QR code on it.

       According to the general test routine, we first carry out basic functional tests. Only when the basic functions are realized can we make sense to carry out other tests.

Note: Scan the login page because it is too simple, so I won’t explain it here.

2.1.1 Function test

        Combining our knowledge of the relevant requirements of the page and the hidden requirements we expanded to later (preferably put forward in the requirements phase), extract the test points we need, and then combine the test case design we have mastered Method to write test cases.

The following are the extracted test points:

1. Login with empty value in the input box

2. The space test of the input box

•  a. Are there any spaces between the front and back of the account and password input box?

3. Login with valid account password and other information

4. Login with invalid account and password information

• a. Correct account number, wrong password
• b. Non-existent account, password of account A
• c. A account, B account password

5. Password special requirement test 

• a. Whether the ciphertext is displayed in the input box
• b. Whether it can be copied to the input box from outside
• c. Is it possible to copy the password from the password input box?
• d. Password anti-cracking mechanism verification
• e. Whether the password is encrypted during transmission and in the log information
•  f. Whether the password is stored in encrypted form in the database table
• g. Will the password information be remembered and saved by the browser?    

 6. Verification code test

• a. Enter the correct verification code to log in
• b. Leave the verification code input box blank to log in
• c. Enter the wrong verification code to log in
• e. Enter the outdated verification code to log in
• f. Is the picture refresh mechanism reasonable?

 7. Account and password memory preservation test

• a. The correct account and password will be saved in memory after successful login
• b. Whether to save only account information after login failure with correct account and wrong password
• c. Wrong account login, wrong password, login failure, will it be saved?
• d. With the correct account number and leave the password blank to log in, will the account information be saved?
• f. Verification of effective memory storage time
• g. Manually clear the cache whether the login information is still retained

 8. Simultaneous login test

• a. Can an account be logged in at the same time on the same browser?
•  b. Can an account be logged in at the same time with different browsers on the same machine?
• c. Can an account be logged in at the same time on different machines?
• d. Can an account be logged in at the same time on the web and mobile apps?
• e. Can two accounts be logged in at the same time on the same browser
• f. Can two accounts log in at the same time with different browsers on the same machine?

  9. Memory test of the default language

• a. Modify the interface language options, after successful login, whether the last saved language will be remembered next time you log in
• b. Modify the interface language option, after the login fails, whether the current page will save the modified language
• c. Modify the interface language option, after the login fails, close the browser, and whether to save the last language option when you open the login next time

10. The input box length limit test

11. The input box can enter the type test

 

2.1.2 Friendly and easy to operate test

     1. Can you use windows commonly used shortcut keys in the input box, such as copy and paste, tab switching, enter, etc.

     2. Can you switch between upper and lower case, input method in the input box, and whether there is a corresponding prompt after switching

     3. When the network is abnormal, is there a friendly loading page prompt?

     4. Whether the prompts under various login failures are friendly, clear and easy to understand.

 

2.1.3 Robustness test

      1. Kill the browser program process and reopen the browser, whether the entered login information is still there

      2. Switch between the login page and other page tabs and shrink to the background, whether the entered login information is still there

      3. If you click the login button multiple times quickly, whether the interface still displays normally and prompts

      4. If you perform multiple refresh operations quickly, is the interface still displayed?

 

2.1.4 Safety test

      1. Does the account password box block SQL injection attacks?

      2. Whether the account password input box prohibits script input (to avoid XSS attacks)

      3. Is there an anti-cracking mechanism for login?

      4. Is the password cached information stored in cookies or in session?

      5. Is the password displayed in encrypted form in any place?

 

2.1.5 Performance test

      1. Whether the time spent opening the login page meets the requirements

      2. Click the login button to enter the page after the login is successful, whether the time it takes to meet the requirements

      3. Support how many people can open normally at the same time and log in normally at the same time

 

2.1.6 Compatibility test

      1. Are the mainstream browsers and versions compatible with this page?

      2. Whether different operating platforms and versions are used normally

      3. Whether the allocation rate of different screens is reasonable to display the page

     4. Whether the interface display is normal under zoom in and zoom out state

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"

Next update: How to write test case templates?

Here is a collection of selected dry goods articles for functional testing:

Dry goods sharing | Featured article collection of functional tests (Are you afraid that you can't find the article you need?)