This sentence is discussing the application of multiple defect assumptions and boundary value analysis in software testing.
The multiple-flaw assumption refers to the fact that when multiple variables take on certain values at the same time, a flaw or error may occur. In a software system, the interaction between various variables (such as input parameters, configuration options, etc.) can lead to errors or abnormal behavior. Therefore, in order to identify and verify these potential problems, we need to pay attention to the situation when multiple variables take certain values at the same time.
Boundary value analysis is a testing technique that aims to identify boundary cases and extreme values of variables and use these values as test cases. Typically, boundary value analysis use cases are designed with multiple defects assumptions. Specifically, boundary value analysis will focus on the situation where multiple variables take boundary values at the same time, and generate corresponding test cases.
The "cartesian product of each variable" mentioned in this sentence refers to a common method of boundary value analysis. Cartesian product refers to the combination of elements in multiple sets to generate all possible combinations. In boundary value analysis, the boundary cases and extreme values of each variable are combined to generate test cases that cover multiple variables taking specific boundary values at the same time.
By applying multiple defect assumptions and boundary value analysis, testers can more fully explore potential problems that may exist in a software system. The test case of boundary value analysis can cover the situation that multiple variables take boundary value at the same time, so as to verify the behavior and processing ability of the system in these situations.
To sum up, this sentence means that in software testing, based on the assumption of multiple defects, boundary value analysis usually generates test cases that contain multiple variables that take boundary values at the same time to cover situations that may cause defects.
The Cartesian product set here means that these, such as x, y, and z, are set as boundary values, and they are combined together
Valid equivalence class & non-putting equivalence class
Valid equivalence class
is meaningful to the specification of the program, and a set
of reasonable input data
Invalid equivalence class
is meaningless or unreasonable to the specification of the program
The set of input data
Decision Table and Decision Tree are two commonly used tools for representing decision logic in software testing and rule engines. There are some similarities between them, but there are also some differences.
A decision table is a decision representation method in the form of a table, which is used to describe the actions or results that a decision needs to take under different conditions. It usually consists of a condition column and an action column. The Condition column lists the different conditions or events in the decision logic, while the Action column lists the corresponding actions or outcomes based on the conditions. Decision tables use logical operators (such as AND, OR) to represent the relationship between conditions in order to determine the final decision result.
A decision table is a tree-structured decision representation method, which expresses decision logic in the form of branches and nodes. In a decision tree, each node represents a condition or event, and each branch represents a possible outcome or next step in the decision. According to the given input condition, starting from the root node, according to the value of the condition, it goes down the corresponding branch step by step until it reaches the leaf node, and finally obtains the final decision result.
The relationship between the decision table and the decision table is that they can be used to express decision logic, and make corresponding decisions according to given conditions. They are all tools that help testers or rule engines design and verify decision logic.
Specifically, decision tables are generally more suitable for complex decision logic, where the relationship between conditions and actions is complex. The advantage of the decision table is that it can clearly list all possible combinations of conditions and visually display the decision results in the table. The decision table is suitable for the design of test cases and the rule description of the rule engine.
The decision table is more suitable for situations where the decision logic is relatively simple and there are few branches. The advantage of the decision table is that it can display the decision logic in a tree structure, which is easy to understand and visualize. Decision tables are suitable for the execution of rule engines and the construction of decision trees.
In short, decision tables and decision tables are commonly used decision representation methods, they can make decisions according to given conditions, and have different applicable scenarios and advantages. The choice of which method to use depends on the complexity of the decision logic and the needs of the test/rules engine.
Chapter Four
chapter Five
Chapter Eleven
In software testing, FP (Function Point) is a measurement unit for measuring software scale, which is used to evaluate software development workload and number of function points. FP can be calculated according to the functional requirements of the software, input and output, and user interface.
In the given sentence, "every function point must have test cases, average >4/FP" means that for each function point (FP), at least 4 more test cases need to be written to cover the function point. This is a requirement to measure test case coverage.
Test case coverage refers to the degree to which the functional requirements and characteristics of the software are covered by test case execution. In order to effectively test each function point of the software, at least a certain number of test cases need to be written. In this case, an average of at least 4 test cases per function point is required.
By writing multiple test cases, you can ensure thorough testing of the function points. Different test cases can cover different scenarios, combinations of inputs, and expected results to discover potential bugs, edge cases, and anomalies.
Please note that the average value means that the average number of test cases for each function point should be greater than 4 within the scope of the entire software project. The exact number of test cases may vary depending on the size, complexity, and testing strategy of the project.
In short, this sentence means that in software testing, for each function point (FP), at least 4 test cases need to be written to cover the function point in order to achieve a high test coverage rate.
Chapter Thirteen
