With the exposure of software defects, we need to find software vulnerabilities through various software testing methods, write test cases, and modify bugs in time.
In the following article, we will talk about eight typical black box testing methods, let s learn together
1. Equivalence class division method
A program can have multiple inputs. The equivalence class division is to classify these input data according to the input requirements, and divide them into several subsets. These subsets are the equivalence classes ( subsets of a certain input field ). Select representative data to design test cases in each equivalence class .
For example :
This method is similar to the students standing in teams, the boys stand on the left, the girls stand on the right, and the teacher stands in the middle. This divides the entire group of teachers and students into three equivalent classes .
2. Steps of the equivalence class division method
(1) First find out each input condition from the program specification ; (2) Divide equivalence classes for each input condition to form a number of disjoint subsets ; (3) List the equivalence table
|Input condition||Effective equivalence class||Invalid equivalence class|
3. Steps to design test cases
The equivalence class division method designing test cases requires two steps: dividing equivalence classes (listing the equivalence class table) and selecting test cases .
(1) Divide equivalence classes
Equivalence class refers to a subset of an input field. In this subset, each input data is equivalent for exposing errors in the program . The test representative value is equivalent to the test of other values of this type.
When dividing equivalence classes, there will be valid equivalence classes and invalid equivalence classes. How do we need to judge this time?
Effective equivalence classes are a collection of effective values, which are reasonable and meaningful input data that meet the requirements of the program.
Invalid equivalence classes are sets of invalid values, which are input data that does not meet the requirements of the program, is unreasonable or meaningless.
Therefore, when designing test cases, it is necessary to consider the design of valid and invalid equivalence classes at the same time .
At the same time, when dividing equivalence classes, certain division principles need to be followed:
Principles of equivalence classification :
Principle 1 : If the input conditions specify the value range or the number of values , one valid equivalence class and two invalid equivalence classes can be determined.
Principle 2 : If the input condition stipulates the set of input values or stipulates the condition of "how it must be" , a valid equivalence class and an invalid equivalence class can be established.
Principle 3 : If the input condition is a Boolean quantity , a valid equivalence class and an invalid equivalence class can be determined.
Principle 4 : If a set of values (assuming n) of input data is specified , and the program needs to process each input value separately, n valid equivalence classes and one invalid equivalence class can be determined.
Principle 5 : If the rules that the input data must comply with are specified, one valid equivalence class (conforming to the rule) and several invalid equivalence classes (violating the rule from different perspectives) can be determined.
Principle 6 : When it is known that in the equivalence class that has been divided, the ways in which each element is processed in the program are different, the equivalence class should be further divided into smaller equivalence classes.
The data in the same equivalence class has the same ability to detect program defects. If one of the data in the equivalence class cannot be used to capture the defect, then the other data in the equivalence class cannot be used to capture the defect; similarly, if the equivalence class is used One of the data in the class can capture the defect, then the other data in the equivalence class can also capture the defect, that is, all the input data in the equivalence class are equivalent .
(2) Design test cases
- After the equivalence class is established, a list of equivalence classes is established to list all the equivalence classes that have been divided.
- Specify a unique number for each equivalence class .
- Design a new test case to cover as many effective equivalence classes as possible that have not yet been covered. Repeat this step until all valid equivalence classes are covered.
- Design a new test case to cover only an invalid equivalence class that has not been covered. Repeat this step until all invalid equivalence classes are covered.
4. Case: Elective courses for students
Seeing this, might as well do the next case analysis.
Case 1 : Each student can choose 1~3 courses, and it is required to design test cases with equivalent classes.
Problem-solving ideas : first analyze the effective equivalence class and the invalid equivalence class, and then establish the equivalence class table.
(1) Analyze the effective and invalid equivalence classes according to the question stem:
Effective equivalence class : Elective course 1-3
Invalid equivalence class : no elective, elective course 3 or more
(2) Establish an equivalent class table based on the analysis:
(3) Design test cases according to the equivalence class table to cover the effective equivalence class and the invalid equivalence class:
Case 2 : A hotel chain group implements a point reward program. Members can earn certain points every time they stay at the group's hotels. The points are composed of welcome points plus consumption points. The welcome points are related to the hotel level. The specific criteria are shown in Table 1-1; the consumption points are related to the amount of consumption per stay. The specific criteria are 2 points for every RMB 1 spent (no points will be awarded for the part less than RMB 1). In addition, group members are divided into three levels: priority member, gold member, and platinum member. Gold members and platinum members can get extra rewards for consumption points when they stay in hotels. The reward rules are shown in Table 1-2.
Table 1-1 Welcome points standards of different grade hotels of the group
Table 1-2 Extra points reward rules
The hotel group has developed a program to calculate the points accumulated by members after each stay. The input of the program includes membership level L, hotel level C and consumption amount A (unit: yuan), and the output of the program is the point S. Among them, L is a single letter and is case-insensitive, C is an integer ranging from 1 to 6, A is a positive floating point number with a maximum of two decimal places, and S is an integer.
[ Question 1 ] Use the equivalence class division method to test the program. The equivalence class table is shown in Table 1-3. Please supplement the blanks (1)-(7) in the table.
[ Question 2 ] The test example designed according to the above equivalent class table is shown in the following table, please supplement the hollows (1)-(13) in Table 2-4.
2. Boundary value analysis method
1. Overview of boundary value analysis method
( 1 ) The boundary value analysis method is a method of testing the input or output boundary of the software, and it is usually used as a supplementary test of the equivalence class division method.
( 2 ) In the equivalence class division method, whether it is an input equivalence class or an output equivalence class, there will be multiple boundaries , and the boundary value analysis method is to find certain points near these boundaries as test data, instead of The test data is selected internally in the equivalence class.
2. Design test cases
Steps to design test cases :
( 1 ) First divide the equivalence class , and determine the boundary conditions according to the equivalence class division .
( 2 ) Select the value that is exactly equal to , just greater than , and just less than the boundary as the test data, instead of selecting the typical value or any value in the equivalence class.
3. Boundary value design principles
Principle 1 : If the input condition specifies the value range , the value that has just reached the boundary of this range and the value that has just exceeded the boundary of this range should be used as the test input data
Principle 2 : If the input condition specifies the number of values , use the maximum number, minimum number, less than the minimum number, and 1 more than the maximum number as the test data
Principle 3 : Use the previous principle 1 according to each output condition stated in the specification.
Principle 4 : According to each output condition stated in the specification, use the previous principle 2.
Principle 5 : If the input field or output field given by the program specification is an ordered set , the first element and the last element of the set should be selected as test cases.
Principle 6 : If an internal data structure is used in the program, the value on the boundary of this internal data structure should be selected as the test case.
Principle 7 : Analyze specifications and find other possible boundary conditions .
3. the wrong speculation method
1. Overview of Wrong Speculation
Error speculation is that people can use experience and intuition to speculate on the various errors that may exist in the program, so as to write and check examples of these errors in a targeted manner.
2. The basic idea of the wrong speculation method
(1) List all possible errors in the program and special situations that are prone to errors (for example, the program can only enter numbers, and letters can be entered for testing during testing). (2) Choose test cases based on them.
4. the causality diagram design method
1. An overview of the causality diagram design method
If various combinations of input conditions and various output conditions must be considered when testing , then a form suitable for describing a combination of multiple conditions and correspondingly generating multiple actions can be used to design test cases, which requires the use of causality Figure.
2. Causality diagram representation
The cause and effect diagram uses some simple logic symbols and straight lines to connect the cause (input) and the effect (output) of the program. The general cause is represented by ci, and the result is represented by ei. Each node represents the state , and can take the value "0" or " 1", where "0" indicates that the state does not appear, and "1" indicates that the state appears.
As shown below:
There are 4 relationships between ci and ei: identity, not (~), or ( ), and ( ):
Identity : In the identity relationship, the program is required to have one input and one output, and the output is consistent with the input. If c1 is 1, e1 is also 1, and if c1 is 0, e1 is also 0.
Not : Not using the symbol "~" to indicate that in this relationship, the program is required to have one input and one output, and the output is the inverse of the input. If c1 is 1, then e1 is 0, if c1 is 0, then e1 is 1.
Or : Use the symbol " " to indicate that the OR relationship can have any number of inputs. As long as one of these inputs is 1, the output is 1, otherwise the output is 0.
And : Use the symbol " " to indicate that the AND relationship can also have any number of inputs, but only if these inputs are all 1, the output can be 1, otherwise the output is 0.
Here is a picture to show these 4 relationships:
- In software testing, if the program has multiple inputs, in addition to the relationship between input and output, there are often some dependencies between these inputs, and certain input conditions themselves cannot appear at the same time. Input may affect other inputs.
- For example, a certain software is used to count medical examination information. When entering personal information, gender can only be entered as male or female. These two inputs cannot exist at the same time, and if the entered gender is female, then the physical examination items will be restricted.
To represent between the same reasons , between cause and effect constraints may exist, in the figures may additionally cause some signs constraints.
(1) The constraint categories of input conditions can be divided into four types:
E (Exclusive, these dependencies are called "constraints" in software testing, different), I (at least one, or), O (one and only one, unique), R (Requires), in the cause and effect diagram , And use specific symbols to indicate these constraints.
- E (different): At most one of a and b can be 1, that is, a and b cannot be 1 at the same time.
- I (or): At least one of a, b, and c must be 1, that is, a, b, and c cannot be 0 at the same time.
- O (Unique): There is one and only one of a and b is 1.
- R (required): a and b must be consistent, that is, when a is 1, b must also be 1, and when a is 0, b must also be 0.
(2) There is only one type of constraint for output conditions:
- In addition to the input conditions, the output conditions will also restrict each other. There is only one type of M (Mask, mandatory) for the output conditions , which is a mandatory constraint relationship. If the result a is 1, then the result b is forced to 0.
4. Design test cases
(1) Causality diagram design test case idea:
From the description of the program specification , find out the cause (input condition) and effect (output result or change of program state);
Convert the cause and effect diagram into a judgment table ;
Design a test case for each column in the decision table ;
(2) Steps to design test cases using causality diagrams:
Analyze the description of the program specification and determine the input and output of the program, that is, determine the "cause" and "result".
Analysis of results between the input and the input , between the input and output correspondence relationship, the relationship between the input and output using the causal FIG represented.
Due to the limitations of syntax and environment, some combinations between input and input and between input and output are impossible. For this situation, use symbols to mark the restriction or constraint relationship between them.
Convert the cause and effect diagram into a decision table , and design test cases based on the decision table. (The decision table will be mentioned in Title 5 Decision Table Driven Method)
Advantages of causality diagram:
Taking into account the various combinations of input conditions and the mutual constraints between the various input conditions .
The constraint relationship of the causality diagram can effectively simplify the decision table and help testers develop test cases efficiently.
The causality diagram method is a strict method of transforming natural language specifications into formal language specifications, which can point out the incompleteness and ambiguity of the specifications .
6. Thinking questions
The specification requirements of the program: the first character entered must be # or *, and the second character must be a number. In this case, the file is modified; if the first character is not # or *, information is given N, if the second character is not a number, the message M is given. The causality diagram method is used to design test cases of the software.
The specific analysis is as follows:
(1) Analyze the reasons and results in the program specification:
the reason result C1: The first character is # e1: give information N C2: The first character is * e2: modify the file C3: The second character is a number e3: give information M
(2) Draw a cause and effect diagram:
Note : 10 is the intermediate reason for exporting the result
(3) Convert the cause-effect diagram into a judgment table, the 3 conditions can generally have 2 combinations
1 2 3 4 5 6 7 8 the reason c1 1 1 1 1 0 0 0 0 c2 1 1 0 0 1 1 0 0 c3 1 0 1 0 1 0 1 0 result e1 e2 e3
(4) Simplify the judgment table, merge the 7th and 8th columns
1 2 3 4 5 6 7 the reason c1 1 1 1 1 0 0 0 c2 1 1 0 0 1 1 0 c3 1 0 1 0 1 0 - result e1 e2 e3
(5) Generate test cases according to the judgment table
Test case ID Input data Output result 1 #3 Modify file 2 #M Give information M 3 *5 Modify file 4 *A Give information M 5 MM Give information N
5. decision table-driven method
1. An overview of the decision table-driven method
The decision table is also called a decision table , and its essence is a logical table . In the early stage of the development of program design, the decision table has been used as an auxiliary tool for program development to help developers organize the development model and process, because it can express the complex logical relationship and the combination of multiple conditions in a specific and clear way. , Use the decision table to design a complete set of test cases.
2. Judgment-driven method-examples
In order to let everyone understand what is
(1) There may be three situations in the process of book reading:
- Are you tired?
- Are you interested in the content.
- Are you confused about the content of the book?
If the answer is yes, use the "Y" mark;
If the answer is negative, use the "N" mark.
Then there can be 2 =8 combinations in these 3 situations , for these 8 combinations.
(2) The reading guide provides readers with 4 suggestions:
- Go back to the beginning of this chapter and reread.
- Keep reading.
- Skip to the next chapter to read.
- Stop reading and rest.
( 3 ) Based on the above analysis, the following book reading guide judgment table is obtained .
|Questions and suggestions||1||2||3||4||5||6||7||8|
|Are you interested in the content||Y||Y||N||N||N||Y||Y||N|
|Are you confused about the content of the book||Y||N||N||Y||Y||Y||N||N|
|Suggest||Go back to the beginning of this chapter and reread|
|Skip to the next chapter to read|
|Stop reading and rest|
( 4 ) In practical tests, the condition often many piles, and the piles are each condition genuine two Condition, n-condition determination table pile will have 2 n kinds of conditional rules, each rule if the design A test case is not only a heavy workload, but some of the workload may be repetitive and meaningless. For example, in the "Book Reading Guide", the first and second rules, the first rule takes the value: Y, Y, Y, the execution result is "stop reading and rest"; the second rule takes the value: Y, Y, N, the execution result is also "stop reading and rest"; for these two rules, the values of the first two questions are the same, and the execution result is the same.
These problems that do not affect the value of the result are called irrelevant condition items and are represented by "-". Ignoring irrelevant condition items, you can merge the two rules.
The merging rules need to meet the following two conditions : The actions taken by the two rules are the same; The condition items of the two rules have similar values.
(5) According to the merger rules, the "Book Reading Guide" decision table can be merged.
|Questions and suggestions||1||2||3||4||5|
|Are you interested in the content||Y||N||N||Y||Y|
|Are you confused about the content of the book||-||-||-||Y||N|
|Suggest||Go back to the beginning of this chapter and reread|
|Skip to the next chapter to read|
|Stop reading and rest|
3. Judgment table structure
The judgment table is a table formed by listing all the various combination values of inputs as conditions and the corresponding output values . The judgment table is composed of 4 parts . The structure of the judgment table is as follows:
|Condition stub||Condition item|
|Action pile||Action item|
Each of these columns is called a rule. The 4 parts of the decision table are:
- Condition stub : List all the conditions of the problem. Except for some questions that require the order of the conditions, the order of the conditions listed in the decision table is usually irrelevant.
- Condition items : Condition items are all possible values of condition stubs.
- Action stub : Action stubs are the actions that may be taken for the problem, and these actions are generally in no order.
- Action item : Point out the action that should be taken in the case of each group of condition items.
In the judgment table, the specific value of any combination of conditions and the corresponding operation to be performed is called a rule , that is, each column in the judgment table is a rule, and a test case can be designed for each column, and the test can be designed according to the judgment table. There will be no omissions in the use cases.
4. Steps for establishing the judgment table
- Determine the number of rules (2 rules corresponding to n conditions).
- List all condition piles and action piles .
- Fill in the condition items.
- Fill in the action items and formulate the initial judgment table.
- Simplify, merge similar rules or the same actions.
5. Use the decision table to design the conditions of test cases
- The specifications are given in the form of a judgment table, or can be easily converted into a judgment table.
- The order of the conditions does not affect which operations are performed.
- The order of the rules does not affect which operations are performed.
- When the conditions of a certain rule have been met and the operation to be performed is determined, there is no need to check other rules.
- If a rule needs to perform multiple operations, the order in which these operations are performed does not matter.
6. Case: Salary payment
The salary management system of a company is as follows: employee wages are divided into two types: annual salary system and monthly salary system. The wrong positioning of employees includes two kinds of common mistakes and serious mistakes. If they are employees of the annual salary system, they will deduct 2% of common mistakes and commit serious mistakes. 4% for wrongful deductions; 4% for common mistakes and 8% for serious mistakes if they are employees of monthly salary system. The company has written a piece of software for employee salary calculation and distribution, and it is now being tested.
Analyzing the company's employee salary management, it can be concluded that the employee's salary is determined by 4 factors: annual salary, monthly salary, common errors, and serious errors. Among them, annual salary and monthly salary cannot coexist at the same time, but common mistakes and serious mistakes can coexist.
There are 7 final deduction results for employees: no deduction, 2% deduction, 4% deduction, 6% deduction (2%+4%), 4% deduction, 8% deduction, 12% deduction ( 4%+8%).
The decision table-driven method is adopted to design the test cases of the software.
The specific analysis is as follows:
( 1) Analyze the causes and results of employee wages:
( 2 ) There are 4 reasons, each of which has two values of "Y" and "N". In theory, 2 4 = 16 rules can be formed , but c1 and c2 cannot coexist at the same time, so there are 2 3 = 8 types rule. The employee salary determination table is as follows:
( 3) Finally, the employee salary test case table is obtained:
6. Orthogonal experimental design method
1. Overview of the orthogonal experiment design method
Orthogonal experimental design method (Orthogonal experimental design) refers to choose from a large number of experimental points in the right amount , a representative point, Export "orthogonal" according to Glois theory, so an experimental design methods Reasonable arrangements experiment .
2. 3.key factors of orthogonal experiment design method
- Indicators : Standards for judging the pros and cons of experimental results.
- Factors : Factors are also called factors, which refer to all conditions that affect experimental indicators.
- The status of the factor: The status of the factor is also called the level of the factor, which refers to the value of the factor variable.
3. Steps to design test cases using orthogonal experiment method
- Extract factors, construct factor status table
- Weighted screening, simplified factor status table
- Construct orthogonal table and design test cases
Next, analyze these three steps one by one.
(1) Give a chestnut (step one):
Extract factors and construct a factor status table that is, analyze the specifications of the software and explain the factors that affect the function of the software. Determine what values the factors can have, that is, determine the status of the factors.
For example, running a software affected by the operating system and database, thus affecting whether its running success factor has two operating systems and databases, and operating systems are Windows, Linux, Mac three values, there is a database MySQL, MongoDB , Oracle has three values, so the factor status of the operating system is 3, and the database factor status is 3. Get the following factor-state table:
(2) Give a chestnut (step two):
Weighted screening, simplified factor status table -In actual software testing, there will be many factors and status of the software, and each factor and its status will have a very different effect on the software. If you divide these factors and statuses into In the factor-state table , the final generated test cases will be quite large, which will affect the efficiency of software testing. Therefore, it is necessary to perform weighted screening according to the importance of factors and states, select important factors and states, and simplify the factor-state table.
(3) Give a chestnut (step three):
Construct the orthogonal table and design the test case -the representation of the orthogonal table is L n (t c ) .
- L stands for orthogonal table.
- n is the number of rows of the orthogonal table, and each row of the orthogonal table can design a test case, so the number of rows n also represents the number of test cases that can be designed.
- c represents the number of factors in the orthogonal experiment, that is, the number of columns in the orthogonal table, so the orthogonal table is a table with n rows and c columns.
- t is called the level number, which represents the maximum value that each factor can achieve, that is, how many states the factor has.
- In an orthogonal table with the number of rows n (n is a positive integer), the number of rows n (the number of trials) = (the number of levels in each column t-1)+1 . For example: L 8 (2 7 ) , n=7 (2-1)+1=8; L 4 (2 3 ) , n=3 (2-1)+1=4.
Here are two examples to aid understanding: Example 1: L 4 (2 3 ) is the simplest orthogonal table, it means that the experiment has 3 factors, each factor has two states, you can do 4 experiments, if Using 0 and 1 to represent the two states of each factor, the orthogonal table is a table with 4 rows and 3 columns. The orthogonal table is shown in the following figure: Example 2: In the actual software test, in most cases, the software has multiple factors, and the number of states of each factor is different, that is, the number of levels in each column is not equal. The intersection table is called a hybrid orthogonal table , such as L 8 (2 4 + 4 1 ) , this orthogonal table indicates that there are 4 factors with 2 states, and 1 factor with 4 states. Then the number of rows in the orthogonal table is
4. The characteristics of orthogonal table
The biggest feature of the orthogonal table is that the points are evenly distributed , neat and comparable . Each number in each column has the same number of times, that is, the number of values for each state is the same.
Written here, make a summary of the orthogonal experimental design method:
- In the orthogonal table, each level of each factor "interacts" once with each level of another factor. This is orthogonality, which ensures that the experimental points are evenly dispersed in the combination of factors and levels, so it has Strong representation.
- For software affected by multiple factors and levels , the orthogonal experiment method can generate test cases efficiently and appropriately , reducing the test workload, and the test cases obtained by the orthogonal experiment method have a certain degree of coverage, and the error detection rate can reach 50% Above .
- Although the orthogonal experiment method is easy to use, when choosing an orthogonal table, you must first determine the experimental factors , states and their interactions , choose a suitable orthogonal table, and also consider the accuracy requirements, cost, and cost of the experiment. Factors such as duration.
6. Case: Orthogonal Experimental Design of WeChat Web Page Operating Environment
WeChat is a mobile app, but it also has a web version of WeChat to log in. If you want to test the operating environment of the WeChat web page, you need to consider many factors. Among the many factors, we can select several factors that have a greater impact. Such as servers, operating systems, plug-ins and browsers. Design the test cases of the software by using the orthogonal experiment design method .
The specific analysis is as follows: (1) Extract factors and construct the factor status table
For the selected four influencing factors, each factor has a different value. Similarly, among the multiple values of each factor, several more important values can be selected. Such as:
Server: IIS, Apache, Jetty;
Operating system: Windows7, Windows10, Mac;
Plug-in: none, small program, WeChat plug-in;
Browser: IE11, Chrome, FireFox;
The constructed factor state table is as follows:
factor Factor status operating system IIS Apache Jetty database Windows7 Windows10 Mac Plug-in no Applets WeChat plugin Browser IE11 Chrome FireFox
(2) Weighted screening, simplified factor status table
- There are 4 factors in the orthogonal experiment of the operating environment of WeChat web version: server, operating system, plug-in, and browser. Each factor has 3 levels, so the orthogonal table is a 4-factor 3-level orthogonal table.
- So the number of rows in the orthogonal table is `n = (the number of levels in each column t-1) + 1 = (3-1) 4 + 1 =
9`, so the representation of the orthogonal table is L 9 (3 4 ) .
- After getting n=9, look up the table to get, the simplified factor state table is as follows:
(3) Construct an orthogonal table and design test cases
- Mapping factors and states to an orthogonal table can generate specific test cases, as shown in the following table:
7. scene method
1. Design ideas
Almost all softwares nowadays are triggered by events. Event triggers form a scene , and different trigger sequences and processing results of the same event form an event stream .
2. Elements of the scene
The scene can be seen as
(1) Elementary flow
The basic event flow is a business process that starts from an initial state of the system and reaches the final state after a series of states. It is the most important and basic business process ( without any errors, the program runs directly from the beginning to the end of execution ) .
(2) Scene flow
The alternative event flow is based on the basic flow, and other event flows caused by meeting different trigger conditions at each judgment node that the basic flow passes through.
3. Scenario description of basic flow and alternative flow
First use a diagram to describe the flow of the basic flow and the alternative flow.
As can be seen from the above figure, each path through the use case in the figure is represented by a basic flow and an alternative flow .
Basic flow: It is represented by a straight black line and is the easiest path through the use case .
Alternative flow: expressed in different colors , an alternative flow may start from the basic flow, execute under certain conditions, and then rejoin the basic flow (for example, alternative flows 1 and 3); it may also originate from another backup flow. Select flow (such as alternative flow 2), or terminate the use case without rejoining a certain flow (such as alternative flow 2 and 4).
The maps every possible path through, from the beginning of the elementary stream, then through the integrated elementary stream, stream alternatively, can determine a different use case scenarios as follows : Based on the above example, we can draw the following conclusions : only one elementary stream, The number of candidate flows depends on the number of decision nodes on the basic flow and the granularity of transaction analysis. The finer the granularity and the more thorough consideration, the greater the number of candidate flows and the greater the corresponding test workload. .
4. Design test cases
The basic steps of scenario method design test case are as follows:
(1) According to the requirements specification, describe the basic flow of the program and various alternative flows.
(2) Different scenarios are generated based on the basic flow and various alternative flows.
(3) Generate corresponding test cases for each scenario.
(4) Re-examine all generated test cases and remove redundant test cases. After the test case is determined, the test data value is determined for each test case.
Written here, make a summary of the scene method:
- The scenario method takes event flows and scenarios as the core , and is also called the business process testing method . Testers are required to use the scenario method to design test cases as end users , and to simulate the user's operating conditions when using the software as realistically as possible.
- In the testing process, testers need to simulate two aspects of the business: the correct operation process and possible wrong operations .
- It is suitable for the testing of more complex software systems in the business.
6. Case: Online shopping case
There is an example of online shopping: a user enters an online shopping website to make purchases, and after purchasing items, he makes online purchases. At this time, he needs to log in with his account; after the login is successful, a payment transaction is made; after the transaction is successful, an order form is generated; complete The whole shopping process. Please use the scenario method to design test cases.
The case analysis is as follows:
(1) Determine the basic flow and alternative flow
- Basic flow: Log in to the online shopping site, select items, log in to your account, pay for transactions, and generate purchase orders.
- Alternative flow 1: The account does not exist.
- Alternative flow 2: Incorrect password.
- Alternative flow 3: Insufficient inventory of goods.
- Alternative flow 4: Insufficient account balance.
(2) Determine the scene according to the basic flow and the alternative flow, as shown in the following table:
Table Shopping system scene table
Scenario 1: Successful shopping Elementary flow Scenario 2: The account does not exist Alternate flow 1 Scenario 3: Incorrect password Alternate flow 2 Scenario 4: Insufficient inventory of goods Alternate flow 3 Scenario 5: Insufficient user account balance Alternate flow 4
(3) According to each scenario, design the required test cases
A matrix or decision table can be used to determine and manage test cases. The following describes a general format, where each row represents each test case, and each column represents information about the test case. In the matrix,
- V (valid) is used to indicate that this condition must be VALID (valid) to execute the basic flow;
- I (invalid) is used to indicate that the required alternative flow will be activated under this condition;
- N/A (not applicable) indicates that this condition does not apply to the test case.
The shopping system scene matrix is shown in the following table:
Table Shopping system scene matrix
Test case ID Scenes account number password Quantity of goods purchased Commodity inventory quantity User account balance expected outcome 1 Scenario 1: Successful shopping V V V V V Successful shopping 2 Scenario 2: The account does not exist I N/A N/A N/A N/A Prompt that the account does not exist 3 Scenario 3: Incorrect password V I N/A N/A N/A Prompt that the password is entered incorrectly 4 Scenario 4: Insufficient inventory of purchased goods V V V I N/A Prompt insufficient inventory 5 Scenario 5: Insufficient user account balance V V V V I Prompt that the account balance is insufficient
(4) Design specific test case data (assuming the unit price of the purchased product is 30 yuan)
Table specific test cases of shopping system
Scenes Test case ID account number password Quantity of goods purchased Commodity inventory quantity User account balance expected outcome Scenario 1: Successful shopping 1 admin123 test123 10 50 pieces 2000 dollars Successful shopping Scenario 2: The account does not exist 2 admin N/A N/A N/A N/A Prompt that the account does not exist Scenario 3: Incorrect password 3 admin123 test N/A N/A N/A Prompt that the password is entered incorrectly Scenario 4: Insufficient inventory of purchased goods 4 admin123 test123 60 pieces 50 pieces N/A Prompt insufficient inventory Scenario 5: Insufficient user account balance 5 admin123 test123 10 50 pieces 200 yuan Prompt that the account balance is insufficient
8. Function map method
The function chart method is currently used less frequently, so I won t go into details here...
9. black box testing method strategy summary
Written here, make a summary of the above eight black box test methods.
1. Comprehensive strategy for the selection of various test methods
(1) 1. divide the equivalence class , including the equivalence division of input conditions and output conditions, and turn infinite tests into finite tests. This is the most effective way to reduce workload and improve test efficiency.
(2) The boundary value analysis method must be used in any case . Experience has shown that the test cases designed by this method have the strongest ability to find program errors.
(3) Some test cases can be added by error speculation , which requires the wisdom and experience of test engineers.
(4) Check the logic coverage of the designed test cases against the program logic . If the required coverage standard is not reached, sufficient test cases should be added.
(5) If the function description of the program contains a combination of input conditions, the causality diagram and judgment table can be selected from the beginning .
(6) For the parameter configuration software, the orthogonal experiment method should be used to select fewer combinations to achieve the best results.
(7) For software with clear business flow, scenarios can be used throughout the test, and then various test methods can be used comprehensively.
2. The advantages and disadvantages of black box testing
(1) Advantages : For larger code units , black box testing is more efficient than white box testing, and testers do not need to understand the implementation details, including specific programming languages; testers and programmers are independent of each other Yes, testing from the user s perspective is easy to accept and understand, and helps to expose any inconsistencies or discrepancies with the specifications. Test cases can be performed immediately after the specifications are completed.
(2) Disadvantages : It is not possible to test specific parts of the program, such as the unexecuted code of the program. If these codes cannot be tested, errors cannot be found. Without clear and concise specifications, test cases are difficult to design and adequacy testing is difficult.
10. Write at the end
Black box testing is relatively simple compared to white box testing. It does not need to understand the code inside the program and has nothing to do with the internal implementation of the software. From the perspective of the user, it is easy to know which functions the user will use and which will be encountered Problem; and it is based on the related test of the software development document, which can clearly understand which functions in the document are realized by the software.
The explanation of the eight typical black box testing methods is over here! If you don t understand or make mistakes, welcome to the comment area or private chat with me~
The next article will explain white box testing.
If you want to view previous articles, you can also directly click to enter the software test section .
- No public concern Monday lab , dry from time to time to share learning, learning does not get lost on the way -
- If this article is useful to you, remember to like and pay attention before leaving~