1) The use case is clearly expressed without ambiguity

2) Use cases are highly operable.

3) The input and output of the use case are clear. A use case has only one expected result.

4) The maintainability of use cases is good.

5) The coverage rate of use cases to requirements is high,

6) The ability to expose program bugs is strong.

1.1 Test case: unit user registration is successful

Step action :	Expected result :
Go to the registration page, select register	The system displays the registration page
Enter the unit name, unit email, password, confirmation password, organization code, verification code that meet the requirements, and confirm and agree to the "User Registration Agreement", submit the registration information	The system performs the registration operation and sends an activation email. After the registration is successful, jump to the registration success page and prompt the user to activate.
Enter the email address used for registration to activate	Activation successful
Use the registered email address and password to log in	Login is successful, the system displays the welcome page
test method	manual
importance	important
test environment	Chrome，IE
test premise	The system is running normally and the mail server is turned on
functional module	register log in

1.2 Comparison of test cases

Mobile camera test case

Ambiguity Use Cases	Be clear about use cases
Title: Single Shot. (title unclear)	Title: Single Photo
...the use case element "Test Idea" is missing	Test ideas: Check whether the whole process from pressing the shutter button to taking pictures meets the requirements, including the status of the photo indicator light, the display of the screen during the photo storage process, and the correctness check of the photos
Preset conditions: the flash is forced to close, the battery is sufficient	Preset conditions: the flash is forced to close, the battery is sufficient
Steps:....steps are incomplete 1) Point the lens at the subject and press the shutter button. 2) Press the page down key to browse the photos just taken	step: 1) Aim the subject with the camera lens, and when ready, press the shutter button. 2) Pay attention to the sound of pressing the shutter button 3) During the photo saving process, observe the changes displayed on the phone screen 4) Prompt that the photo is saved successfully
Expected output: ...the relative step has no output 1) It can be seen that the photo just taken is normal	Expected output: 1) After pressing the shutter, the set shutter sound will be heard within one second 2) During the photo saving process, the phone screen displays the photo being saved, and the screen returns to the camera mode after the save is completed 3) The photos are what you see and what you get, and the pixels and colors of the photos are the same as the set mode.

2. Benefits of Test Cases

1) Basis for the test executor

2) Make the work repeatable, the basis of automated testing

3) Evaluate Requirements Coverage

4) Reuse of use cases

5) Accumulate test method ideas for subsequent reference

Trouble in use:

The design of test cases is a time-consuming and laborious work, and the time spent on designing test cases is more than the time spent on execution

Solve the following problems:

I don't know if all the functions have been tested more comprehensively

Test coverage cannot be measured

Repeated testing of new versions is difficult to implement

There are a large number of redundant tests that affect test efficiency

3. Use case design method

3.1 Requirements-based design

RBT (Requirements-Based Testing) is a requirements-based testing method that will make testing more effective because it makes testing focus on the root cause of quality problems, that is, requirements.

Requirements-based testing is the most fundamental software testing, focusing on the following two key issues.

1 ) Verify that the requirements are correct, complete, unambiguous, and logically consistent.

2 ) From the perspective of " black box " , design a sufficient and necessary test set to ensure that the design and code can fully meet the requirements

beg.

3.2 Case

1) User needs

Purchase a smartphone, test case:

1. Price range

2. Branding options

3. Smartphone

4. Mobile phone function verification

Make calls, answer calls, send text messages, receive text messages, listen to songs...

2) Software requirements

email event flow

1. If the user has not received the activation email, he can send the activation email again after entering the email and password on the login interface.

2. The activation email sent each time is only valid within 24 hours after sending the email, and the activation email needs to be resent after 24 hours

test case

1-1 . If the email is not received, enter the email and password when logging in, and then send the activation email again

1-2 . The email has been received. After entering the email and password when logging in, no activation email will be sent

2-1 . After receiving the email, activate it within 24 hours

2-2 . After receiving the email, the link will expire after 24 hours for activation.

2-3 . After receiving the email, it has been activated, and the link will expire after 24 hours, click to activate again

page check

1. Receive the activation email

2. The content of the email is correct

3. The activation URL is correct and can be activated

4. Reactivation prompts that it has been activated

5. The expired activation prompt has expired

3.3 Specific design method

equivalence class

Boundary value

causal diagram

Orthogonal arrangement

Scenario Design Method

wrong guess

3.3.1 Equivalence classes

For example, divide the students in a class into several categories: excellent, medium, general

According to the requirements, the input (the output will be considered in special cases) is divided into several equivalence classes, and a test case is selected from the equivalence class. If this test case passes the test, it is considered that the represented equivalence class test is passed. In this way It can achieve as much functional coverage as possible with fewer test cases, which solves the problem that exhaustive testing cannot be performed.

Effective equivalence class: For the specification of the program, it is a set of reasonable and meaningful input data. Use the effective equivalence class to verify whether the program implements the functions and performances specified in the specification.

Invalid equivalence class: According to the requirements specification, the set that does not meet the requirements.

The equivalence class only considers the classification of the input domain, and does not consider the combination of the input domain, which requires other design methods and supplements.

For example:

fruit

Valid equivalence classes: apple, orange, peach

Invalid equivalence classes: vegetables, rice, beverages

Character type AZ, case insensitive:

Valid equivalence classes: AZ,az ,

Invalid equivalence class: ¥, %, @ and other special characters

3.3.2 Boundary values

Boundary value analysis is a black box testing 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 partition method. In this case, the test cases come from the boundary of the equivalence class.

For example:

1) The length of the input box is 1-10, and the boundary values are: 1, 10, 0, 11

2) Athletes’ competitions range from 1 to 4, with boundary values: 0, 1, 2, 3, 4

3) The query page has 999 lines, and every 50 lines is a page. Take the boundary value and output 0 lines, 50 lines, 51 lines, 999 lines

For example:

Software Requirements for Registering Email

The user name requires a length of 6-15 characters, and the boundary value is 5, 6, 15, 16

But in the actual test design, the equivalence class and boundary value will be used in combination, so the use cases we can finally confirm are: 5, 6, 10, 15, 16

3.3.3 Causal Diagram

1) Identity

If the cause is true, then the effect must be true. For example: if there is fruit on this tree, then there must be fruit on this tree

2) with

If there are only two causes, and both are true, then the effect must be true.

3) or

The effect is true when one of the two causes is true.

4) non

The effect is true only if the cause is plus

The steps of designing test cases by causal diagram method are as follows:

1) Analyze all possible inputs and possible outputs.

2) Find out the correspondence between input and output.

3) Draw a cause-and-effect diagram.

4) Convert the causal diagram into a decision table.

5) Correspond the decision table to each test case

Case number one:

Assume that the processing rule of the business document is: " Taobao 618 event, the bill of lading has been submitted, and the total order value is greater than 300 yuan or there is a red envelope, then enter the discount . "

1. For this business rule, first by analyzing all possible inputs and possible outputs, the following results can be obtained:

● Input: The order has been submitted, the amount is greater than 300, and there is a red envelope.

● Output: Preferential, non-preferential.

2. Then, proceed to the second step to find out the correspondence between the input and the output. Through analysis, it can be seen that there are the following correspondences.

1) The order has been submitted, and the order amount is more than 300 yuan, then the discount will be given.

2) The order has been submitted, the order amount is less than or equal to 300 yuan, no red envelope, no discount

3) The order has been submitted, and if there is a red envelope, it will be discounted.

4) The order has been submitted, the order amount is more than 300 yuan, and if there is a red envelope, the discount will be given.

5) The order has not been submitted, no discount

3. In order to facilitate the drawing of the cause-and-effect diagram and the decision table, all inputs and outputs need to be numbered, and the numbers are as follows

1 : The order has been submitted.

2 : The order amount is greater than 300 yuan.

3 : There are red envelopes

21 : Offer

22 : no discount

4. Draw a causal diagram

5. Draw the decision table

There are three conditions, and the output has 2 values, so the number of columns in the table is 2*2*2 = 8

6. The final test case

1 , 2 , 3 , 4 , 5 (including 6 , 7 , 8 ).

case two

Register the requirements for the use case:

Name, email, password, confirmation password, and verification code must all be entered in order to register

How many use cases need to be designed? 2x2x2x2x2 .

Designing test cases by the causal method can help testers clarify the relationship between input and output, but for more complex input and output, it will take a lot of time

3.3.4 Orthogonal arrangement

Use orthogonal permutations when there are too many causal design use cases

The purpose of the orthogonal method is to reduce the number of use cases. Cover pairwise combinations of inputs with as few use cases as possible.

Orthogonal experimental design (Orthogonal experimental design) is a design method for studying multi-factors and multi-levels. According to the orthogonality, some representative points are selected from the combination of all levels of experimental factors for experiments. Analysis of test results Understand the situation of the comprehensive test and find out the optimal level combination.

Orthogonal test design is a high-efficiency, fast and economical test based on orthogonal tables

Factor ( Factor ): In an experiment, the variables to be investigated are called factors (variables)

Level (level) ( Level ): Within the scope of the experiment, the value of the factor being investigated is called the level (the value of the variable)

The composition of the orthogonal table:

Number of rows (Runs) : The number of rows in the orthogonal table, that is, the number of trials , represented by N.

Factors (Factors) : the number of columns in the orthogonal table, represented by C

Levels (Levels) : The maximum number of values that any single factor can obtain. The values contained in the orthogonal table range from 0 to the number " horizontal number -1" or from 1 to " horizontal number" , represented by T

Representation of orthogonal table: L= number of rows ( number of levels * number of factors ) L=N(TC)

Two properties of an orthogonal table:

Each number appears the same number of times in each column.

Each pair of ordinal numbers formed by any two columns appears the same number of times.

Steps to design test cases by orthogonal method:

1. What are the factors (variables)

2. What are the levels of each factor (the value of the variable)

3. Select a suitable orthogonal table

4. Map the value of the variable to the table

5. Take the combination of each factor level in each row as a test case

6. Add combinations of use cases that you think are suspicious and do not appear in the table

case:

Take registration as an example

1. Factors: name, email, password, confirmation password, verification code

2. Level: fill in, not fill in

3. The number of factors in the table =5 ;

Number of levels to each factor number in the table = 2

Take the one with the least number of rows, that is, the one with the least number of trials

L=N(TC)=(2-1)*5+1=6=6(25)

L=6(25)

N number of trials

T level number

Number of C factors

Select the orthogonal table, here L6_2_5 is selected . The orthogonal table is not chosen randomly, but designed

4. Generate test cases

5. Supplementary test cases

Name, email, password, confirmation password, and verification code are not filled in

3.3.5 Scenario Design Method

Almost all current software uses event triggers to control the process. The scene when the event is triggered forms the scene, and the different trigger sequences and processing results of the same event form the event flow. This method can vividly describe the situation when the event is triggered, which is beneficial to the test designer to design the test case, and makes the test case easier to understand and execute.

A typical application is to use business flow to string together isolated functional points to create an overall business sense for testers, so as to avoid the wrong tendency of falling into functional details and ignoring business process points.

case:

Registration example

Designing use cases by imagining registration scenarios is almost the same as designing according to the business flow of requirements. The main thing is to imagine various business flows to design use cases. For example, we can imagine the following scenario:

1. After the user activates, click the email activation link again?

2. Registered users register again?

3.3.6 Error Guessing Method

The wrong guessing method is a testing technique that experienced testers love to use.

Based on experience and intuition, find out the errors that you think may occur in the program, and design test cases in a targeted manner. Experience may come from more tests on a certain business, or from feedback from after-sales users, or sorting out bugs from the fault management library . Sort out where the product was prone to problems in the past. The more problems there are, the more potential bugs there will be.

Registration case

1. How to deal with special characters and spaces in verification ?

2. What is the case in the password verification?

3. Special characters in the name?

4. Whether the password is sent in plain text

4. Validity of test cases

The function corresponding to the test case has been deleted and cannot be operated

Executing a test case did not find a BUG , actually there is a BUG

Executing a test case found a BUG

Executing a test case did not find a BUG , but the actual BUG has been modified

5. Granularity and evaluation of test cases

5.1 Granularity of test cases

A good test case is a person who is not familiar with the business can quickly test according to the use case

Granularity: Refers to the level of detail in which test cases are written.

Test cases can be written very simple or very complex. The simplest test case is the outline of the test, just pointing out what to test,

For example, the test design in exploratory testing only points out which elements of the product need to be tested, the quality goals to be achieved, the test methods to be used, etc. The most complex test case is like the work order card used by aircraft maintenance personnel, which specifies each input data, expected results and inspection methods, specific to the operation steps of interface elements, specified test methods and tools, etc.

(1) Writing too complex or detailed test cases will bring about two problems: one is efficiency and the other is maintenance cost. In addition, if the test case design is too detailed, there is less room for thinking of the test executives, and it is easy to limit the thinking of the testers.

(2) If the test case is written too simply, it may lose the meaning of the test case. Too simple test case design does not actually carry out " design " , but only records the functional modules that need to be tested. Its role is only to serve as a simple test plan during the test process, reminding testers of the main functions of the test. That's all. The essence of the test case design should be to understand the requirements during the design process, verify the requirements, and record the thinking of the testing method of the software system to guide future testing.

Most test teams write test cases with a granularity somewhere in between. How to grasp the granularity is the key to test case design, and will also affect the efficiency and effect of test case design. The granularity of test cases should be designed according to the actual situation of the project and the situation of test resources.

The main considerations can refer to the following:

Product Quality Requirements

Project Requirements for Use Cases

Sufficient time and resources for testing

5.2 Evaluation of test cases

After the test case is designed, how to improve the quality of the test case design? Just as software products need to use various means to ensure quality, the quality assurance of test cases also requires comprehensive use of various means and methods. Reviews are divided into formal and informal reviews

peer review

user check

Project team review

1 ) There are many ways to check test cases, but the most agile one should be ad hoc peer review. Peer reviews, especially ad hoc peer reviews, should evolve into something like pair programming. In order to reflect agile " individuals and interactions are more valuable than processes and tools " , it is necessary to emphasize the collision of ideas among test case designers, and to complete the design of test cases through discussion and collaboration. The reason is very simple. The purpose of test cases is to It is possible to cover the requirements comprehensively, but testers always have some thinking defects, and a person's thinking always has limitations. Hence the need to design test cases together.

2 ) In addition to peer review, we should also try to introduce users to participate in the design of test cases and let users participate in the review, so as to reflect the agile principle of " customer collaboration is more valuable than contract negotiation" . The meaning of customer here is relatively broad, and the key lies in how to define the test. If the test is a criticism of the product, the customer should refer to the end user or customer representative (internally, it can be a marketer or a domain expert); Provide help and support, then the customer is clearly a programmer

3) The meeting will be organized and coordinated by the person in charge of the test, the use case writer will explain the use case, and the participants will raise objections on the spot.

6. Test case

A mobile phone software has the function of exporting data from a TF card, please write down the idea of testing this function point

Consider the direction	checking point	Description of test ideas
Forward	Export data correctness	Export data and verify data correctness
reverse	Validity of exported data	Is the export function correct when there is no data
Boundary capacity	TF card space is insufficient	Can only hold part of the data
Boundary capacity	TF card capacity is full
fault tolerance	TF card write protection
fault tolerance	TF card cannot be recognized
fault tolerance	human interruption	Unplug the TF card when exporting
fault tolerance	Power outage, shutdown, etc. while exporting	After restarting, check whether it can be exported correctly
performance	Export multiple times in a row	Script implementation, massive export, check whether the data is correct
performance	Check export speed
compatibility	Different brands and capacities
compatibility	Different partition formats FAT, FAT32 , NTFS

【Test】Use case test design method

1. Basic elements of a test case

1.1 Test case: unit user registration is successful

1.2 Comparison of test cases

2. Benefits of Test Cases

3. Use case design method

3.1 Requirements-based design

3.2 Case

3.3 Specific design method

3.3.1 Equivalence classes

3.3.2 Boundary values

3.3.3 Causal Diagram

3.3.4 Orthogonal arrangement

3.3.5 Scenario Design Method

3.3.6 Error Guessing Method

4. Validity of test cases

5. Granularity and evaluation of test cases

5.1 Granularity of test cases

5.2 Evaluation of test cases

6. Test case

Guess you like