General functional testing refers to black box testing . The test engineer tests the developed function based on the requirements document. In other words, functional tests are all black box tests based on requirements . The demand is mainly divided into two categories:
- Explicit functional requirements : Refers to the requirements that are clearly specified in the requirements and can be perceived by the user, such as "guest users will jump to the login page when they access the administrator page"
- Non-functional requirements : refers to non-specific functional requirements that users cannot directly experience, but such non-functional requirements will also be involved when doing functional testing, because many non-functional requirements will affect To usability and user experience of features, such as performance testing.
Explicit functional requirements
There are three main solutions that we use the longest for explicit functional requirements:
- Equivalence class division
- Boundary value analysis
- Error inference
Equivalence classification
• In software testing, the exhaustive method is the safest and most secure method, but it is expensive and generally undesirable. We can complete the most efficient test with the least cost through the equivalent class division method.
• Equivalence class division is to divide the program input field into several subsets, and then select a few representative data from the subset for testing. In the subset set, each input data is equivalent to expose the error in the program.
• Equivalence classes are divided into valid equivalence classes and invalid equivalence classes.
• 1.1 effective equivalence class-normal flow
A reasonable and meaningful collection of input data for program specifications, and verify that the program implements the functions and performance in the specification.
• 1.2 Invalid equivalence class-abnormal flow
Unreasonable and meaningless input data collection, verify the ability of the program to handle unexpected data. There should be at least one or more than one.
Criteria for dividing equivalence classes
• 1) complete testing to avoid redundancy;
• 2) division of equivalence classes is important: the division of the set is divided into a set of disjoint subsets, and the subset is the entire set;
• 3) is not The entire set: completeness;
• 4) subsets do not intersect each other: guarantee a form of non-redundancy;
• 5) identify (select) a test case in the same class, often in the same equivalence class, deal with the same, the same Process mapped to the same execution path
Equivalent class division method
Master the general principle that the processing process and processing results of similar data must be completely consistent, and the following division methods can be referred to
• 1) When the input condition specifies the value range or the number of values, one valid equivalence class and two invalid equivalence classes can be determined. If the range of qualified scores is [60,100], the value within the range For valid equivalence classes, <60 and> 100 outside the range are invalid equivalence classes
• 2) In the case where the input condition specifies a set of input values or “what must be”, a valid equivalence class and an invalid equivalence can be determined Class, such as: stipulate that the database type must select oracle, then oracle is a valid equivalence class, otherwise it is an invalid equivalence class
• 3) If the input condition is a boolean, you can determine a valid equivalence class and an invalid Equivalence classes
• 4) When the input conditions stipulate that certain rules must be observed, a valid equivalence class and several invalid equivalence classes can be determined (violating the rules from different perspectives), such as: the input must be a non-zero positive integer , The invalid equivalence class can be divided into null, 0, negative integers, decimals, characters, etc.
• 5) A set of values (assuming N) is specified in the input data, and the program must treat each input value separately Under reasonable circumstances, N valid equivalence classes and one invalid equivalence class can be established. Example: The input conditions indicate that the academic qualifications can be one of four types: junior college, undergraduate, master, and doctorate, and then these four values are taken as four valid equivalence classes, and any academic qualifications other than the four academic qualifications are taken as Invalid equivalence class.
• 6) If it is known that the elements of the divided equivalence classes are processed in different ways by the program in Zhennanguan, the equivalence class should be further divided into smaller equivalence classes
Equivalent Class Table
• After establishing the equivalence class, you can establish an equivalence table to list all the equivalence classes
| Input condition | Effective equivalence class | Invalid equivalence class |
|---|---|---|
| The range of qualified scores is an integer between [60,100] | Integer between [60,100] | Greater than 100; less than 60 decimal places, such as 96.3 strings containing letters; strings containing special characters are empty |
Equivalence class division example 1
• There is a file management system that requires users to enter dates expressed in years and months. Suppose the date is limited to January 1990 to December 2049, and stipulate that the date is composed of 6 numeric characters, the first 4 digits represent the year, and the last 2 digits represent the month. The test case is designed by the equivalent class division method to test the "date checking function" of the program.
Equivalence class division example 1: results
• 1) Divide the equivalence classes and number them, the result of the equivalence class division in the table below
| Enter equivalence class | Effective equivalence class | Invalid equivalence class |
|---|---|---|
| Date type and length | ① 6 digit characters | ② There are non-numeric characters ③ Less than 6 numeric characters ④ More than 6 numeric characters |
| Year range | ⑤ Between 1990 ~ 2049 | ⑥ Less than 1990⑦ Greater than 2049 |
| Month range | ⑧ between 01 ~ 12 | ⑨ equals 00⑩ greater than 12 |
2) Design test cases to cover all valid equivalence classes. Three valid equivalence classes are listed in the table, numbered ①, ⑤, ⑧. The designed test cases are as follows:
the effective coverage of the expected results of the test data, etc. Price category
200211 input valid ①, ⑤, ⑧
3) Design test cases for invalid equivalence class, the design results are as follows:
invalid equivalent class
95June invalid input ②
20036 invalid input ③
2001006 invalid input ④
198912 invalid input ⑥
200401 invalid input ⑦
200100 invalid input ⑨
200113 invalid input ⑩
Examples of testing using equivalence classification (continued)
• Example 2 The procedure for an insurance company to calculate the premium rate
The life insurance premium calculation method for an insurance company is:
Sum insured × insurance premium rate
Among them, the insurance premium rate differs according to the number of points, the insurance premium rate of 10 points and above is 0.6%, and the insurance premium rate of below 10 points is 0.1%; The specific rules are determined by the number of dependents:
The procedure for calculating the premium rate
(1) Analyze the requirements for the input conditions given and implied in the specification of the program, and list the equivalence table (including effective equivalence classes and invalid etc.) Price category).
• Age: one, two or three non-zero integers, the valid range of values is 1 ~ 130
• Gender: an English character, can only take the value 'M' or 'F'
• Marriage: character, can only take Value 'Married' or 'Unmarried'
• Number of dependents: blank or a non-zero integer (1 ~ 9)
• Points: one or two non-zero integers, the value range is 1 ~ 99
(2) According to (1 ) In the equivalence class table, designed to cover all equivalence test cases.
Boundary value analysis method
• 1. Definition: The boundary value analysis method is a black box test method for testing the input or output boundary value. The boundary value analysis method is usually used as a supplement to the equivalence class division method. In this case, the test cases come from the equivalence class boundary.
Past testing experience shows that, due to inaccurate definition of requirements, inadequate design, and mistakes in program writing, the judgment of the boundaries of these data ranges is where the software is extremely prone to errors. A large number of errors often occur on the boundary of the input or output range, so designing test cases for various boundary conditions can detect more errors.
• 2. How to design test cases with boundary value analysis?
1) Boundary value analysis is not to pick a random one from a certain equivalence class as a representative, but to make each boundary of this equivalence class as a test condition. Choose the value that is exactly equal to, just greater than or just less than the boundary as the test data
2) Boundary value analysis not only considers the input conditions, but also considers the test conditions generated by the output space.
3) First determine the boundary conditions. Usually the boundary of the input or output equivalence class is the boundary case that should focus on testing. Therefore, test cases are designed on the boundary of the equivalence class and on both sides.
• 3. Boundary value applicable scenarios
-
The input (output) conditions specify the value range
-
The input (output) conditions specify the number of values
-
The input or output mentioned in the program specification is an ordered collection
-
An internal data structure is used in the program
-
The value of the boundary value should be selected to be exactly equal to, just above the maximum boundary value and just below the minimum boundary value for the most test
Boundary value selection test case principle
• 1) If the input conditions specify a range of values, then the boundary value that has just reached this range and the value that has just exceeded this range should be taken as the test input data. For example, if the specification of the program stipulates: "For mail with a weight in the range of 10 kg to 50 kg, the calculation formula for postage is ...". As test cases, we should take 10 and 50, and also take 10.01, 49.99, 9.99 and 50.01.
• 2) If the input condition specifies the number of values, the maximum number, minimum number, one more than the maximum number and one less than the minimum number are selected as test data.
• For example, an input file should include 1 ~ 255 records, then test cases can take 1 and 255, and should also take 0 and 256.
• For example, the specification of a program requires the calculation of "Monthly Insurance Deduction of 0 to 1165.25 yuan", and its test cases can be 0.00 and 1165.24, and 0.01 and 1165.26.
As another example, a program belongs to an information retrieval system that requires "minimum display of 1 and maximum of 4 intelligence summaries" at a time. At this time, the test cases we should consider include 1 and 4, and 0 and 5 should also be included.
• 5) If the input field is an ordered collection, select the first element and the last element of the collection as test cases
• 6) If the program uses an internal data structure, you should select the boundary value on the internal data structure as the test Use case
• 7) Analyze the specifications and find other possible boundary conditions
Error inference
• The error inference method is generally based on previous test experience and intuition, referring to the errors in the past software system, speculating on various errors that may exist in the program, listing all possible errors and prone to errors in the program, targeted Design test cases.
• The unit test case lists many common errors in the module, errors that have been found in previous product tests, etc.
• For example, the input data and output data are 0; the input form is a space or the input form has only one line. These are all error-prone situations. Various situations are often overlooked in product descriptions, and may also be forgotten by programmers, but often occur in actual use. The tester must stand in the user's perspective and consider the information they want to enter, regardless of whether the information appears to be legitimate input or illegal input.
Causality diagram
• The background of the causality diagram method: the
equivalence class division method and the boundary value analysis method both focus on the input conditions, but do not consider the various combinations of the input conditions and the mutual constraints between the input conditions. In this way, although various input conditions may be wrong, the combination of multiple input conditions may be ignored.
If you must consider various combinations of input conditions during testing, the number of possible combinations will be astronomical, so you must consider a form suitable for describing combinations of multiple conditions and correspondingly generating multiple actions for test cases Design, which requires the use of causality diagrams (logical models)
Introduction to Causality Diagram
• Causality diagram method is based on the idea that the functions of some programs can be expressed in the form of a decision table (or decision table), and the corresponding operations are specified according to the combination of input conditions.
• The definition of the causality diagram method: It is a method of analyzing various combinations of input using a graphical method to design test cases, which is suitable for checking various combinations of input conditions of the program.
• Steps for designing test cases using the cause and effect diagram method:
(1) According to the description of the program specification, analyze and determine the cause (input condition) and effect (output result or program state change), draw a cause and effect diagram.
(2) Convert the resulting causality diagram into a decision table.
(3) Design a test case for the situation represented by each column in the judgment table
Causality diagram
• The basic symbols used in the causality diagram to represent 4 types of causality:
the 4 basic relations in the causality diagram
In the basic symbols of the causality diagram, the left node ci in the figure represents the input state (or cause), and the right node ei represents the output state (or result). The values of ci and ei are 0 or 1, 0 indicates that a certain state does not appear, and 1 indicates that a certain state occurs.
Ø Identity: If c1 is 1, then e1 is also 1, otherwise e1 is 0.
ØNone: If c1 is 1, then e1 is 0, otherwise e1 is 1.
Ø Or: If c1 or c2 or c3 is 1, then e1 is 1, otherwise e1 is 0.
Ø AND: If both c1 and c2 are 1, then e1 is 1, otherwise e1 is 0.
Causality Diagram
• Constraints
in Causality Diagram In actual problems, there may be some dependencies between input states and output states, called "constraints." The constraints on the input conditions are E, I, O, and R, and the constraints on the output conditions are only M.
ØE constraint (different): at most one of a and b may be 1, that is, a and b cannot be 1 at the same time.
ØI constraint (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 constraint (unique): a and b must have one and only one is 1.
ØR constraint (requirement): when a is 1, b must be 1, that is, when a is 1, b cannot be 0.
ØM constraint (mandatory): If the result a is 1, the result b is forced to 0.
Cause and effect diagram
• cause and effect diagram used to represent relationships constraint constraint symbol:
. . . . . .
Decision table
• The final result of the causality diagram method is the decision table.
• Among all the black box test methods, the test based on the decision table (also called decision table) is the most rigorous and logical test method.
• The concept of decision table: The decision table is a tool to analyze and express the situation of performing different operations under multiple logical conditions.
• The advantages of the decision table: it can list all complex problems according to various possible situations, concise and avoid omissions. Therefore, a complete set of test cases can be designed using the decision table.
• In some data processing problems, the implementation of certain operations depends on the combination of multiple logical conditions, that is, for the combined value of different logical conditions, perform different operations separately. The decision table is very suitable for dealing with such problems.
"Reading Guide"
Decision Table Composition of Decision Table
• The decision table usually consists of the following 4 parts:
ØConditional pile—List all the conditions of the
problemØCondition items—List all possible values for the condition given by the condition
pileØAction pile—List the possible provisions of the problem Operation
Ø Action item—Indicate the action
that should be taken when each group of condition items takes values . The specific value of any combination of conditions and the corresponding action to be executed are called a rule. A column that runs through condition items and action items in the decision table is a rule.
Decision table generation
• 5 steps to construct a decision table:
(1) Determine the number of rules.
Ø A decision table with n conditions has 2n rules (each condition takes true and false values).
(2) List all condition piles and action piles.
(3) Fill in the condition items.
(4) Fill in the action items to get the initial decision table.
(5) Simplify the decision table and merge similar rules.
Ø If there are more than two rules in the table with the same action, and there is a very similar relationship between the condition items, they can be merged.
The combined condition item is represented by the symbol "-", indicating that the action performed has nothing to do with the value of the condition, which is called an irrelevant condition
Selection of test methods
• Generally, when determining the test method, the following principles should be followed:
Ø Determine the test level and test focus according to the importance of the procedure and the loss that will occur if a failure occurs.
ØChoose the testing strategy carefully so that as few test cases as possible can be used to find as many program errors as possible.
• Usually, when determining the test strategy, there are the following 5 reference principles:
(1) In any case, the boundary value analysis method must be used. The test cases designed by this method have the strongest ability to find program errors.
(2) When necessary, supplement the test cases with the equivalent class division method.
(3) Use the error inference method to add test cases.
(4) Check the logic coverage of the designed test cases against the program logic. If the required coverage standard is not met, more test cases should be added.
(5) If the function description of the program contains a combination of input conditions, the causality diagram method should be selected from the beginning.
Non-functional requirements
After the test engineer tests the display functional requirements, the non-functional requirements of the system must also be considered. This requirement may be explicitly mentioned in the document, or may not be clearly stated. But our test engineers must pay attention when testing.
2.1 Compatibility test
Compatibility refers to whether the developed software can be used on various platforms. For example, if we develop a website, our users may use various browsers to access our website. In this way, when testing, we can not only consider a certain browser. We need to consider the compatibility of multiple browsers.
Compatibility testing may involve:
- Browsers of different manufacturers and browsers of the same manufacturer and different versions.
- Different device terminals and operating systems
- Different screen resolutions
- Different user software environments (such as whether cookies are disabled, whether they can connect to the Internet, etc.)
2.2 Security testing
Our testers also need to pay attention to the security of the developed software. This involves:
-
Whether user privacy information is encrypted
-
Is there any risk that resources requiring permissions can be obtained without permissions?
-
Will it be attacked by cross-site scripting
-
Will it be attacked by SQL injection, etc.
2.3 Stress test
Testers also need to consider whether the software can bear the pressure required by their needs, for example:
-
Whether the software can respond to user behavior within a reasonable time
-
Is the software likely to carry enough requests
-
Will the software lock up resources when processing large amounts of data?
to sum up
User login interface test case design:
• 1. Login with correct user name and password
• 2. Submit directly to the default page
• 3. Detection of incorrect user name and password
• 4. Detection of non-existent user name
• 5. Detection of TAB key
• 6. Detection of Enter key
• 7. Can the deleted user name log in
? 8. Can the prohibited user name log in
? 9. Repeated user login
• 10. Sensitive detection of user name case
• 11. User name and password are sensitive to copy and paste content Testing
