⏳ preface
With the exposure of software defects, we need to find out software vulnerabilities through various software testing methods, write test cases, and timely modify the bug.
In the following article, we will talk about eight typical black box testing methods to learn together (⑧💡)
Equivalence class division method
1, define,
A program can have multiple inputs. Equivalence class partitioning is to classify these input data according to input requirements and divide them into several subsets, which are equivalence classes (subsets of an input field). Representative data are selected from each equivalence class to design test cases.
Here’s an example:
This method is similar to students standing in line, boys stand on the left, girls stand on the right, teachers stand in the middle, so that the whole group of teachers and students intoThree equivalence classes.
2. Steps of 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 several disjoint subsets; (3) List the equivalence table
| The input conditions | Valid equivalence class | Invalid equivalence class |
|---|---|---|
| … | … | … |
3. Design test case steps
The design of test cases should go through two steps: dividing equivalence classes (listing equivalence class table) and selecting test cases.
(1) Divide equivalence classes
An equivalence class is a subset of an input field. In this subset, each input data is equivalent to exposing errors in the program. Test representative values are equivalent to tests of other values in this class.
Then, when dividing equivalence classes, there will be valid equivalence classes and invalid equivalence classes. At this time, how should we judge?
A valid equivalence class is a set of valid values, which are reasonable and meaningful input data conforming to program requirements.
An invalid equivalence class is a collection of invalid values, which are input data that does not conform to program requirements, is unreasonable, or is meaningless.
Therefore, when designing test cases, the design of valid equivalence classes and invalid equivalence classes should be considered simultaneously.
At the same time, certain classification principles should be followed when dividing equivalence classes:
Equivalence class classification principle:
Principle 1: One valid equivalence class and two invalid equivalence classes can be determined if the input conditions specify a range of values or the number of values.
Principle 2: A valid equivalence class and an invalid equivalence class can be established if the input conditions specify a set of input values or a “must be” condition.
Principle 3: If the input condition is a Boolean, we can determine a valid equivalence class and an invalid equivalence class.
Principle 4: N valid equivalence classes and one invalid equivalence class can be determined if a set of values (assumed to be N) for input data is specified and the program treats each input value separately.
Principle 5: If you specify rules that input data must follow, you can determine one valid equivalence class (conforming to the rule) and several invalid equivalence classes (violating the rule from different angles).
Principle 6: The equivalence class should be further divided into smaller equivalence classes if it is known that each element is treated differently in the program.
Data in the same equivalence class has the same ability to discover program defects. If one data in the equivalence class cannot capture defects, then other data in the equivalence class cannot capture defects. Similarly, if one of the data in the equivalence class can catch defects, then the other data in that equivalence class can also catch defects, that is, all the input data in the equivalence class is equivalent.
(2) Design test cases
- After the equivalence classes are established, a list of equivalence classes is established to list all the divided equivalence classes.
- Assign a unique number to each equivalence class.
- Design a new test case that covers as many valid 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 that covers only one invalid equivalence class that has not yet been covered. Repeat this step until all invalid equivalence classes are covered.
4. Case: Students take elective courses
See here, might as well do next case analysis.
Case 1: Each student can take 1 to 3 courses and is required to design test cases using equivalence classes.
Firstly, the effective equivalence class and invalid equivalence class are analyzed, and then the equivalence class table is established.
“Resolution”
(1) Analyze valid equivalence classes and invalid equivalence classes according to the question:
Valid equivalents: take 1~3 courses
Invalid equivalence: no electives, electives more than 3 courses
(2) Establish equivalence class table based on analysis:
(3) Design test cases to cover valid equivalence classes and invalid equivalence classes according to equivalence class table:
Case 2: A hotel chain group implements a bonus point program, in which members can get certain points every time they stay in the group’s hotels, which consists of welcome points plus consumption points. Welcome points are related to the hotel level, and the specific standards are shown in Table 1-1. Consumption points are related to the consumption amount of each check-in, and the specific standard is 2 points for each consumption of 1 yuan (less than 1 yuan will not be given points). In addition, the group members are divided into three levels: Priority member, Gold member and Platinum member. Gold member and platinum member can get extra rewards of consumption points when checking in to the hotel. The reward rules are shown in Table 1-2.
Table 1-1 Welcome points standards for different grades of hotels in the Group
Table 1-2 Bonus points award rules
The hotel group developed A program to calculate the points accumulated by members after each stay. The input of the program includes member level L, hotel level C and consumption amount A (unit: yuan), and the output of the program is the points S. In the preceding command, L is A single letter and case insensitive, C is an integer ranging from 1 to 6, A is A positive floating point number with A maximum of two decimal digits, and S is an integer.
【Problem aThe program is tested by using equivalence class division method. The equivalence class table is shown in Table 1-3. Please add hollow (1) – (7) in the table.
[Question 2] The test designed according to the above equivalence class table is as shown in the following table. Please supplement hollow (1) – (13) in Table 2-4.
2. Boundary value analysis
1. Overview of boundary value analysis
(1) Boundary value analysis method is a method to test the input or output boundary of software, which is usually used as a supplementary test to equivalence class partitioning method.
(2) In the equivalence class partition method, there are multiple boundaries in both the input equivalence class and the output equivalence class, while the boundary value analysis method is to find some points near these boundaries as test data, rather than select test data within the equivalence class.
2. Design test cases
Test case Design steps:
(1) First divide the equivalence class, and determine the boundary case according to the equivalence class division.
(2) Select the value exactly equal to, just greater than or just less than the boundary as test data, rather than select the typical value or any value in the equivalence class.
3. Boundary value design principle
Principle 1: If the input criteria specify a range of values, the test input data should be values that have just reached the boundary of the range, and values that have just passed the boundary of the range
Rule 2: If the input criteria specify the number of values, use the maximum, minimum, number 1 less than the minimum, and number 1 more than the maximum as the test data
Principle 3: For each output condition of the specification, use principle 1 above.
Principle 4: For each output condition of the specification, use principle 2 above.
Principle 5: If the program specification gives an ordered set of input or output fields, the first and last elements of the set should be selected as test cases.
Principle 6: If an internal data structure is used in the program, the values on the boundaries of the internal data structure should be selected as test cases.
Principle 7: Analyze the specification to find other possible boundary conditions.
Third, false speculation
1. Overview of false speculation
Error prediction is an example of how people can rely on experience and intuition to predict the possible errors in a program, so as to write a targeted check for these errors.
2. Basic idea of error conjecture
(1) List all possible errors in the program and special cases prone to errors (for example, the program can only enter numbers, the test can enter letters for testing). (2) Select test cases based on them.
4. Causal diagram design method
1. Overview of causality diagram design
If various combinations of input conditions as well as various output conditions must be considered during testing, test cases can be designed in a form suitable for describing multiple actions for multiple combinations of conditions, which requires the use of causal diagrams.
2. Causal diagram representation
Causality diagram uses some simple logical symbols and straight lines to connect the cause (input) and effect (output) of the program. The general cause is represented by CI, and the result is represented by EI. Each node represents the state, which can be evaluated as “0” or “1”, where “0” means that the state does not appear, and “1” means that the state appears.
As shown below:
There are identity, non (~), or (∨), and (∧) relations between CI and EI, respectively:
Identity: In identity relations, the program is required to have one input and one output, with the output consistent with the input. If C1 is 1, E1 is also 1, and if C1 is 0, E1 is also 0.
Not: Not is indicated by the symbol “~”. In this relationship, the program is required to have an input and an output, and the output is the inverse of the input. If C1 is 1, E1 is 0, and if C1 is 0, E1 is 1.
Or: using the symbol ∨, or the relationship can have any input, so long as one of these inputs is 1, the output is 1, otherwise the output is 0.
And: is represented by the symbol “∧”. The and relation can also have any input, but the output can be 1 only if these inputs are all 1, otherwise the output is 0.
Here is a graph showing the four relationships:
Conclusion:
- In software testing, if the program has more than one input, in addition to the relationship between the input and output, there will often be some dependence between these inputs, some input conditions themselves can not appear at the same time, one input may affect other inputs.
- For example, when a software is used to count information about a medical examination, the entry of a person’s gender can only be male or female. The two inputs cannot exist at the same time, and if the entry is female, the examination items are limited.
3. Constraints
In order to show the possible constraints between causes and effects, some symbols for constraints can be attached to cause-and-effect diagrams.
(1) Constraint types of input conditions can be divided into four categories:
E (Exclusive, these dependencies are called “constraints” in software testing), I (at least one, or), O (one and only one), and R (Requires, Requires). These constraints are denoted by specific symbols in cause-and-effect diagrams.
- E (different) : At most one of a and B can be 1. That is, both 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) : one and only one of a and B is 1.
- R (Requirement) : A and B must be the same, 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 constraint category of output conditions:
- In addition to input conditions, output conditions also constrain each other. There is only one M (Mask, mandatory), mandatory constraint relation of output conditions. If a is 1, then b is forced to be 0.
4. Design test cases
(1) Idea of test case design of causality diagram:
-
Identify causes (input conditions) and effects (output results or changes in program state) from the description of the program specification;
-
Transform the causal diagram into a decision table;
-
Design a test case for each column in the decision table;
(2) Steps to design test cases using causality diagrams:
-
Analyze program specification description to determine program input and output, that is, determine “cause” and “effect”.
-
Analyze the corresponding relations between input and input, between input and output, the relationship between these inputs and output using causality diagram.
-
Some combinations of inputs and outputs are impossible due to syntax and environment constraints. In such cases, symbols are used to mark the restrictions or constraints between them.
-
Transform the causal diagram into a decision table, and design test cases based on the decision table. (Decision tables will be mentioned in heading 5 decision Table Driven methods.)
5, strengths,
Advantages of causal graph method:
-
The various combinations of input cases and the restrictive relationship between each input case are considered.
-
The constraint relation of causality diagram can simplify decision table effectively and help testers to develop test cases efficiently.
-
Causality diagram is a strict method to transform natural language specifications into formal language specifications, which can point out the incompleteness and ambiguity of specifications.
6. Think about questions
Program specifications require: the first character of the input must be # or *, and the second character must be a number, in which case the file is modified; If the first character is not # or *, information N is given, and if the second character is not a number, information M is given. The test case of the software is designed by using causal graph method.
Specific analysis is as follows:
(1) Analyze the causes and results in the program specifications:
why The results of C1: The first character is # E1: indicates the information N C2: The first character is * E2: Modifies the file C3: The second character is a number E3: gives information M (2) Draw a causal diagram:
note: 10 is the intermediate cause of the derived result
(3) Convert the causality diagram into a decision table. Generally, there are 2³ combinations of the 3 conditions
1 2 3 4 5 6 7 8 why 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 The results of e1 ✔ ✔ e2 ✔ ✔ e3 ✔ ✔ (4) Simplified decision table, column 7 and 8 are combined
1 2 3 4 5 6 7 why c1 1 1 1 1 0 0 0 c2 1 1 0 0 1 1 0 c3 1 0 1 0 1 0 – The results of e1 ✔ e2 ✔ ✔ e3 ✔ ✔ (5) Generate test cases according to the decision table
Test case ID The input data The output 1 # 3 Modify the file 2 #M Give information M 3 * 5 Modify the file 4 *A Give information M 5 MM Give information N
note: 10 is the intermediate cause of the derived resultFive, determine the table drive method
1. Overview of decision table driving method
Decision table is also called decision table, its essence is a logical table. In the early stage of program design, decision table has been used as an auxiliary tool for program development, helping developers to sort out the development mode and process, because it can express the complex logical relationship and a variety of conditions combination both specific and clear, using decision table can design a complete set of test cases.
2, decision driven method — citation
In order to let everyone understand what is the judgment table, the following through a “book reading guide” to make a judgment table, book reading guide indicates the process of reading books may appear, as well as for various situations to the reader’s advice.
(1) There may be three situations in the process of book reading:
- Are you tired?
- Are you interested in the content?
- Are you confused by the contents of the book?
If the answer is yes, use the “Y” flag;
If the answer is negative, the “N” flag is used.
So there could be 8 combinations of 2 cubed equals 8 combinations of these 3 cases.
(2) The reading guide provides readers with four suggestions:
- Go back to the beginning of the chapter and re-read it.
- Read on.
- Skip to the next chapter.
- Stop reading and rest.
(3) In view of the above analysis, the following book reading guide judgment table is obtained.
| Questions and Suggestions | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | |
|---|---|---|---|---|---|---|---|---|---|
| The problem | If tired | Y | Y | Y | Y | N | N | N | N |
| Are you interested in the content | Y | Y | N | N | N | Y | Y | N | |
| Are you confused by the contents of the book | Y | N | N | Y | Y | Y | N | N | |
| advice | Go back to the beginning of the chapter and re-read it | ✔ | |||||||
| Read on | ✔ | ||||||||
| Skip to the next chapter | ✔ | ✔ | |||||||
| Stop reading and rest | ✔ | ✔ | ✔ | ✔ |
(4) In the actual test, there are often many conditional piles, and each conditional pile has two conditions: true and false. There will be 2N kinds of conditional rules in the judgment table of N conditional piles. If each rule designs a test case, not only the workload is heavy, but also some of the workload may be repetitive and meaningless. For example, rule 1 and Rule 2 are displayed in the Book Reading Guide. The value of rule 1 is Y, Y, Y, and the execution result is Stop reading and rest. The value of rule 2 can be Y, Y, or N, and the result is Stop reading and rest. For the two rules, the values of the first two questions are the same and the execution results are the same.
These problems that do not affect the value of the result are called irrelevant conditions and are represented by “-“. Two rules can be merged by ignoring irrelevant condition items.
Merge rules must meet the following two conditions: (1) The actions taken by the two rules are the same. ② The conditions of the two rules are similar.
(5) According to the merger rules, the “Book reading Guide” judgment table can be merged.
| Questions and Suggestions | 1 | 2 | 3 | 4 | 5 | |
|---|---|---|---|---|---|---|
| The problem | If tired | Y | Y | N | N | N |
| Are you interested in the content | Y | N | N | Y | Y | |
| Are you confused by the contents of the book | – | – | – | Y | N | |
| advice | Go back to the beginning of the chapter and re-read it | ✔ | ||||
| Read on | ✔ | |||||
| Skip to the next chapter | ✔ | |||||
| Stop reading and rest | ✔ | ✔ |
3, determine the structure of the table
The decision table is a table that lists all the combined values of input and corresponding output values as conditions. The decision table consists of four parts. The structure of the decision table is as follows:
| Conditions of the pile | Item condition |
|---|---|
| The action of pile | Action item |
Each of these columns is called a rule. The four parts of the decision table are as follows:
- Condition pile: Lists all the conditions of the problem. Usually the order of the conditions listed in the decision table does not matter, except that some problems require the order of the conditions.
- Condition term: The condition term is all possible values of the conditional pile.
- Action pile: Action pile is the operation that the problem may take, and these operations are generally not in any order.
- Action item: indicates the action to be taken in the case of each group of conditions.
In the decision 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 decision table is a rule, each column can design a test case, according to the decision table design test cases will not be omitted.
4, the establishment of the decision table steps
- Determine the number of rules (n conditions have 2 or n rules).
- List all conditional piles and action piles.
- Fill in the conditions.
- Fill in the action items and make the initial decision table.
- Simplify, combine similar rules or same actions.
5. Use decision tables to design test case conditions
- Specifications are given in the form of decision tables, or can be easily converted into decision tables.
- The order of the conditions does not affect which operations are performed.
- The order of the rules does not affect which actions are performed.
- When the conditions of one rule are met and the action to be performed is determined, there is no need to verify other rules.
- If a rule performs multiple operations, the order in which those operations are performed is irrelevant.
6. Case: Salary payment
The salary management system of a company is as follows: the salary of employees is divided into two kinds of annual salary system and monthly salary system. The error positioning of employees includes two kinds of ordinary mistakes and serious mistakes. If it is the annual salary system, the ordinary mistakes will be deducted 2%, and the serious mistakes will be deducted 4%. For employees on a monthly salary, 4% will be deducted for common mistakes and 8% for serious ones. The company is testing a piece of software it has written to calculate its employees’ salaries.
Through the analysis of employee salary management, it can be concluded that employee salary is determined by four factors: annual salary, monthly salary, common error and serious error. 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 of employees: no deduction, deduction 2%, deduction 4%, deduction 6% (2%+4%), deduction 4%, deduction 8%, deduction 12% (4%+8%).
The test case of the software is designed by decision table driving method.
Specific analysis is as follows:
(1) Analyze the causes and results of employees’ salaries:
(2) there are four causes, each of which has two values of Y and N24= 16Rule, but c1 and C2 cannot coexist, so there are23= 8 kinds ofThe rules. conclusionEmployee wage determination formAs follows:
(3) The final salary test case table of employees:
Orthogonal experimental design method
1. Overview of orthogonal experimental design method
Orthogonal experimental design (Orthogonal experimental design) refers to a method of experimental design that selects appropriate and representative points from a large number of experimental points and derives “Orthogonal table” according to Glois theory so as to arrange experiments reasonably.
2. Three key factors of orthogonal experimental design method
- Index: a criterion for judging the merits and demerits of experimental results.
- Factor: Factor, also known as factor, refers to all the conditions that affect the experimental index.
- Factor state: The state of a factor, also known as the factor level, refers to the value of a factor variable.
3. Steps of designing test cases by using orthogonal experiment method
- Factor is extracted and factor state table is constructed
- Weighted screening, simplifying factor status table
- Build orthogonal tables and design test cases
The next three steps are analyzed one by one.
(1) For example (Step 1) :
Extract factors and construct factor state table — that is, analyze the specifications and requirements of software to obtain factors affecting software functions and determine what values can be taken for factors, that is, determine the state of factors.
For example, the operation of a certain software is affected by the operating system and the database. Therefore, the factors affecting the successful operation of the software include the operating system and the database. The operating system has Windows, Linux, and Mac values, and the database has MySQL, MongoDB, and Oracle values. Therefore, the operating system factor state is 3, and the database factor state is 3. The following factor-state table is obtained:
| factor | State of factor | ||
|---|---|---|---|
| The operating system | Windows | Linux | Mac |
| The database | MySQL | MongoDB | Oracle |
(2) For example (Step 2) :
Weighted filter, simplify factor status table, in the actual software testing, software there will be a lot of factor and factor of the status of each factor and its effect on the state of the software is very different, if all these factors and status into factor – state in the table, the last generation of test cases is quite large, which affects the efficiency of software testing. Therefore, it is necessary to carry out weighted screening according to the importance of factors and states, select important factors and states, and simplify the factor-state table.
(3) For example (Step 3) :
Construct an orthogonal table and design test cases — the representation of the orthogonal table is Ln(TC).
- L stands for orthogonal table.
- N is the number of rows in the orthogonal table, and each row of the orthogonal table can design one test case. Therefore, the number of rows n also represents the number of test cases that can be designed.
- C represents the number of factors of 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, called the horizontal number, represents the maximum that each factor can achieve, that is, how many states the factor has.
- In an orthogonal table with n rows (n is a positive integer), the number of rows (n trials) =∑ (horizontal number t-1 per column) +1. ①L8(27), n=7×(2-1)+1=8; (2) L4 (23), n = 3 x (2 -) 1 + 1 = 4.
Here are two examples to help you understand: Case 1: L4(23)Is the simplest orthogonal table, it means that the experiment has three factors, each factor has two states, can do four experiments, if 0 and 1 represent the two states of each factor, then the orthogonal table is a table with four rows and three columns.The orthogonal table is shown in the figure below: 
N = ∑ (t-1 for each column) + 1 = (2-1)×4 + (4-1)×1 + 1 = 8This n calculation is often difficult to calculate if it occurs on large projects. Therefore, mixed orthogonal tables are often difficult to determine the number of test cases, that is, the value of n. So, in this case, you can go to some of the most reputable websites for orthogonal tables, and look up n, and here’s oneOrthogonal table query siteHere, n values of orthogonal tables with different number of factors and levels can be queried.Finally, the mixed orthogonal table is shown as the figure below:
4, the characteristics of orthogonal table
The biggest characteristic of orthogonal table is that the points are uniformly dispersed and uniformly comparable, and the number of each number in each column is equal, that is, the number of values in each state is equal.
5, summary
Here is a summary of the orthogonal experimental design:
- In an orthogonal table, each level of each factor “interacts” with each level of another factor once, which is orthogonality. It ensures that experimental points are evenly dispersed in the combination of factors and levels, so it has strong representativeness.
- For the software affected by multiple factors and levels, the orthogonal experiment method can efficiently generate appropriate test cases and reduce the testing workload. Moreover, the test cases obtained by the orthogonal experiment method have a certain coverage, and the error detection rate can reach more than 50%.
- Although the orthogonal experiment method is easy to use, attention should be paid to determining the experimental factor, state and interaction between them when choosing the orthogonal table, choosing the appropriate orthogonal table, and considering the accuracy requirements of the experiment, cost, time and other factors.
6. Case: Orthogonal experimental design of wechat Web page running environment
Wechat is a mobile phone App, but it also has a web version of wechat to log in. If we want to test the running environment of wechat Web page, we need to consider a variety of factors. Among many factors, we can select several factors that have a greater impact, such as server, operating system, plug-in and browser. The test case of the software is designed by orthogonal experimental design method.
The specific analysis is as follows: (1) Extract factors and construct factor status table
For the four selected influencing factors, each factor has different values. Similarly, several important values can be selected from multiple values of each factor. Such as:
Server: IIS, Apache, Jetty;
Operating system: Windows7, Windows10, Mac;
Plug-ins: none, small program, wechat plug-in;
Browsers: IE11, Chrome, FireFox;
The constructed factor state table is as follows:
factor State of factor The operating system IIS Apache Jetty The database Windows7 Windows10 Mac The plug-in There is no Small program WeChat plug-in The browser IE11 Chrome FireFox (2) Weighted screening, simplifying the factor state table
- There are four factors in the orthogonal experiment of wechat Web edition operating environment: server, operating system, plug-in and browser, and each factor has three levels. Therefore, this orthogonal table is a 4-factor and 3-level orthogonal table.
- So the number of rows in an orthogonal table is n= ∑ (horizontal number t-1 per column) + 1 = (3-1)×4 + 1 =
9 ‘, so the representation of the orthogonal table is L9(34).
- When n=9 is obtained, the simplified factor state table is as follows:
(3) Construct orthogonal tables and design test cases
- By mapping factors and states to orthogonal tables, specific test cases can be generated, as shown in the following table:
(3) Construct orthogonal tables and design test cases
7. Scene method
1. Design idea
Nowadays, almost all software is triggered by events, which form scenes, and different triggering sequences and processing results of the same event form event flow.
2. Elements of the scene
A scenario can be thought of as a collection of basic and alternative flows. The use case scenario describes the path that flows through the use case, traversing all the base and alternate flows along the path from the beginning to the end of the use case.
(1) Basic flow
Basic event flow is a business process that starts from an initial state of the system, goes through a series of states, and reaches the final state. It is the most important and basic business process (without any error, the program starts from the beginning to the end of execution).
(2) Scene flow
Alternative event flows, based on the base flow, resulting in other event flows at each decision node through which the base flow meets different triggering conditions.
3. Scenario description of base flow and alternative flow
Start with a diagram that describes the flow of the base and alternative flows.
As you can see from the figure above, each path through the use case in the figure is represented by a base flow and an alternate flow.
Basic flow: Represented by a straight black line, is the simplest path through the use case.
Alternate flows: Represented in different colors, an alternate flow might start with a base flow, perform under a specific condition, and then rejoin the base flow (e.g., alternate flows 1 and 3); It may also originate from another alternative flow (such as alternative flow 2), or terminate the use case without rejoining a flow (such as alternative flows 2 and 4).
Based on each possible path in the diagram, starting with the basic flow and then going through the combination of the basic flow and alternative flow, yesIdentify the different use case scenarios, as follows:
4. Design test cases
The basic steps of scenario test case design are as follows:
(1) Describe the basic flow and alternative flow of the program according to the requirements specification.
(2) Generate different scenarios based on the basic flow and various alternative flows.
(3) Generate corresponding test cases for each scenario.
(4) Re-review all generated test cases and remove redundant test cases. After the test cases are determined, the test data values are determined for each test case.
5, summary
Here’s a summary of the scene method:
- Scenario method takes event flow and scenario as its core, which is also known as business process testing method. It requires testers to regard themselves as end users when designing test cases using scenario method, and simulate the operation situation of users when using the software as realistically as possible.
- During testing, testers need to simulate two aspects of the business: the correct operational process and the possibility of wrong operations.
- It is suitable for software system testing with complex business.
6. Case: Online shopping case
There is an example of online shopping: a user enters an online shopping website for shopping. After purchasing items, he or she needs to log in using an account. After successful login, pay transaction; After the transaction is successful, the purchase order will be generated. Complete the shopping process. Use the scenario approach to design test cases.
Case analysis is as follows:
(1) Determine the basic flow and alternative flow
- Basic flow: Log in to an online shopping site, select items, log in to an account, pay for transactions, and generate a purchase order.
- Alternative flow 1: The account does not exist.
- Alternate flow 2: password error.
- Alternative flow 3: Low inventory of goods.
- Alternative flow 4: Insufficient account balance.
(2) Scenarios are determined according to basic flows and alternative flows, as shown in the following table:
Table Shopping system scenario table
Scenario 1: Successful shopping The basic flow Scenario 2: The account does not exist Alternative flow 1 Scenario 3: Incorrect passwords Alternative flow 2 Scenario 4: Insufficient inventory Alternate flow 3 Scenario 5: The account balance is insufficient Alternate flow 4 (3) Design required test cases according to each scenario
“Resolution”
You can use matrices or decision tables to identify and manage test cases, and the following is a common format where the rows represent individual test cases and the columns represent test case information. In the matrix,
- V (VALID) is used to indicate that the condition must be VALID for the base flow to be executed;
- I (invalid) is used to indicate that the desired alternative flow will be activated under this condition;
- N/A(not applicable) indicates that this condition does not apply to the test case.
The scene matrix of the shopping system is shown in the following table:
Table shopping system scene matrix
Test case ID scenario account password Quantity of goods purchased Commodity inventory quantity Balance of User account The expected results 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 The account does not exist 3 Scenario 3: Incorrect passwords V I N/A N/A N/A Incorrect password is displayed 4 Scenario 4: Insufficient inventory of purchased goods V V V I N/A Prompt stock shortage 5 Scenario 5: The account balance is insufficient V V V V I The account balance is insufficient (4) Design specific test case data (assuming the unit price of the purchased item is 30 yuan)
Table shopping system specific test cases
scenario Test case ID account password Quantity of goods purchased Commodity inventory quantity Balance of User account The expected results Scenario 1: Successful shopping 1 admin123 test123 10 things 50 2000 yuan Successful shopping Scenario 2: The account does not exist 2 admin N/A N/A N/A N/A The account does not exist Scenario 3: Incorrect passwords 3 admin123 test N/A N/A N/A Incorrect password is displayed Scenario 4: Insufficient inventory of purchased goods 4 admin123 test123 60 50 N/A Prompt stock shortage Scenario 5: The account balance is insufficient 5 admin123 test123 10 things 50 200 yuan The account balance is insufficient
8. Function diagram method
Function mapping is currently used infrequently, so I won’t go into details here…
Summary of black box test method strategy
Write here, make a summary of the above eight black box test methods.
1. Comprehensive strategies for various test methods
(1) First, divide the equivalence classes, including the equivalence division of input conditions and output conditions, and change the infinite test into the finite test, which is the most effective method to reduce workload and improve test efficiency.
(2) The boundary value analysis method must be used in all cases. Experience has shown that test cases designed in this way are the most capable of detecting program errors.
(3) Some additional test cases can be added by error conjecture, which depends on the wisdom and experience of test engineers.
(4) Check the logical coverage of the designed test cases against the program logic. If the required coverage criteria are not met, adequate test cases should be added.
(5) If the function description of the program contains a combination of input conditions, the causal diagram and decision table can be used at the beginning.
(6) For the software of parameter configuration, the orthogonal test method should be used to select fewer combination methods to achieve the best effect.
(7) For software with clear business flow, scenarios can be used throughout the test, and then various test methods can be used comprehensively.
2. Advantages and disadvantages of black box testing
(1) Advantages: (1) For large code units, black box testing is more efficient than white box testing, testers do not need to know implementation details, including specific programming language; (2) Testers and programmers are independent of each other, and testing from the user’s point of view is easily accepted and understood, helping to expose any inconsistencies or differences with the specification. Test cases can be carried out immediately after the specification is completed.
(2) Disadvantages: can not test specific parts of the program, such as the code of the program is not executed, these codes can not be tested, can not find errors. Without clear and concise specifications, test cases are difficult to design and conduct adequate testing.
Write at the end
Black box testing is relatively simple compared with white box testing. It does not need to understand the internal code of the program and has nothing to do with the internal implementation of the software. From the user’s point of view, it is easy to know what functions users will use and what problems they will encounter. And is based on the software development documents to do the relevant test, can clearly understand the software to achieve what functions in the document.
This is the end of eight typical black box test methods! If you do not understand or wrong place welcome to comment or private chat I exchange ~
The next article will cover white-box testing.
If you want to view previous articles, you can also directly click into the software testing section.
- Concern about the public number Monday laboratory, do not regularly share learning dry goods, learning on the way not lost ~
- If this article is useful to you, be sure to like it and follow it