Common rules and methods for functional testing (black box testing)

　 Black box testing(Black-box Testing, Also known Function TestingOr data-driven testing) is to regard the test object as a black box. When using the black box Testing Method for Dynamic Testing, You need to test the functions of the software product without testing the internal structure and processing process of the software product.

Black box technology is used to design test cases in the following ways: equivalence classification, Boundary Value Analysis, Error Prediction, cause and effect, and comprehensive strategies.

Black box testing focuses on functional requirements of testing software, that is, black box testing enables software engineers to derive input conditions for all functional requirements of the execution program. Black box testing is notWhite box testingInstead, it is used to assist white box test discovery.OthersType error.

Black box testing tries to find the following types of errors:

1) function errors or omissions;

2) interface error;

3) data structure or externalDatabaseAccess error;

4) performance error;

5) initialization and termination errors.

　　I. Black box testing Test Case Design Method

· Division of equivalence classes

· Boundary Value Analysis Method

· Incorrect estimation method

· Causal Method

· Table-Driven Analysis Method

· Orthogonal Experiment Design Method

· Function diagram Analysis Method

　　Division of equivalence classes:

All possible input data, that is, the input field of the program, is divided into several parts (subsets), and then a few representative data from each subset is selected as the test case. This method is an important and common black box test case design method.

1) Division equivalence class: an equivalence class refers to a subset of an input field. In this subset, each input data is equivalent to exposing errors in the program. It is reasonably assumed that the representative value of an equivalence class is equalOthersValue test. Therefore, we can reasonably divide all input data into several equivalence classes, and take a data in each equivalence class as the input condition for testing. Then we can use a small number of representative test data. Obtain good test results. There are two differences between equivalence classes: Valid equivalence classes and invalid equivalence classes.

Valid equivalence class: a set of meaningful input data that is reasonable for the program specification description. Effective equivalence classes can be used to check whether the program has implemented the functions and performance specified in the Specification Description.

Invalid equivalence class: It is opposite to the definition of valid equivalence class.

When designing test cases, consider both equivalence classes. Because, software must not only receive reasonable data, but also be able to withstand unexpected tests. This test ensures higher software reliability.

2) Division of equivalence classes: The following describes six principles for determining equivalence classes.

① When the input conditions specify the value range or number of values, a valid equivalence class and two invalid equivalence classes can be established.

② An effective equivalence class and an invalid equivalence class can be established when the input condition specifies the set of input values or the condition that specifies "what must be done.

③ When the input condition is a Boolean value, a valid equivalence class and an invalid equivalence class can be determined.

④ N valid equivalence classes and an invalid equivalence class can be established when a set of values (n) of input data are specified and each input value is processed by the program separately.

⑤ A valid equivalence class (compliant with the rules) and several invalid equivalence classes (violation of rules from different perspectives) can be established when rules are required for the input data ).

⑥ When we know that each element in a divided equivalence class has different methods in program processing, we should further divide the element into smaller equivalence classes.

3) design test cases: After an equivalence class is established, an equivalence class table can be created to list all the divided equivalence classes:

The valid equivalence class of the input condition is invalid.

Then, the test cases are designed based on the following three principles from the divided equivalence classes:

① Specify a unique number for each equivalence class.

② Design a new test case to cover as many effective equivalence classes as possible, and repeat this step. Until all valid equivalence classes are overwritten.

③ Design a new test case so that it only overwrites an unoverwritten invalid equivalence class. Repeat this step. Until all invalid equivalence classes are overwritten.

　　Boundary Value Analysis

The boundary value analysis method is complementary to the equivalence classification method.

(1) Considerations of the Boundary Value Analysis Method:

Long-term TestingWorkExperience tells us that a large number of errors occur on the boundary of the input or output range, rather than within the input and output range. Therefore, you can design test cases for various boundary conditions to identify more errors.

When using the Boundary Value Analysis Method to Design test cases, the boundary condition should be determined first. Generally, the boundary of the input and output equivalence classes is the boundary that should be tested. Select a value equal to or less than the boundary value as the test data, instead of a typical value or any value in the equivalence class as the test data.

(2) principles for selecting test cases based on the Boundary Value Analysis Method:

1) if the input condition specifies the value range, take the value that has just reached the boundary of this range and the value that has just exceeded the boundary of this range as the test input data.

2) If the input condition specifies the number of values, use the maximum and minimum numbers, one less than the minimum number, and one more than the maximum number as the test data.

3) use the previous Principle 1 according to each output condition in the Specification Description ).

4) according to each output condition in the Specification Description, apply the preceding principle 2 ).

5) if the input or output fields provided in the program specification are ordered sets, the first and last elements of the set should be selected as the test case.

6) if an internal data structure is used in the program, select the value at the boundary of the internal data structure as the test case.

7) analyze the specifications to find other possible boundary conditions.

　　Error Prediction Method

Error inference: This method is used to design test cases based on experience and intuition.

The basic idea of the error inference method is to list all possible errors and special circumstances that are prone to errors in the program and select test cases based on them. For exampleUnit TestMany common errors listed in the module. Errors found in previous product tests are a summary of experience. In addition, when the input and output data are 0. Enter a space in the table or only one row in the table. These are prone to errors. You can select an example in these cases as a test case.

　　Causal Method

The equivalence classification method and Boundary Value Analysis method described above both focus on the input conditions, but do not consider the Association and Combination between the input conditions. Considering the combination of input conditions, there may be some new situations. However, it is not easy to check the combination of input conditions. Even if all input conditions are divided into equivalence classes, there are many combinations between them. Therefore, we must consider using a combination suitable for describing multiple conditions and generating multiple actions to consider designing test cases. This requires the use of the logical model ).

The Cause-to-cause method generates a decision table. It is suitable for checking various combinations of program input conditions.

Follow these steps to generate a test case by using the reason:

(1) The reason (that is, the equivalence class of the input condition or the input condition) and the result (that is, the output condition) in the description of the Analysis Software specification ), and assign an identifier to each reason and result.

(2) analyze the semantics in the description of the Software specification. Find out the relationship between the cause and the result. Based on these relationships, draw the causal coefficient.

(3) due to syntax or environmental restrictions, the combination between the cause and the result cannot occur between some reasons and causes. In order to indicate these special circumstances, use some marks to indicate the constraints or restrictions on the condition.

(4) convert the causal table into a discriminant table.

(5) use each column in the decision table as a basis to design test cases.

The test cases generated from the reason (partial, under the combination relationship) include the true and false values for all input data. The number of test cases is the minimum, the number of test cases increases linearly as the number of input data increases.

The discriminant table has been used in the previous causal table method. A describe table is a tool used to analyze and express different operations under multiple logical conditions. In the early stages of programming, the discriminant table has been used as an auxiliary tool for programming. Because it can express complex logical relationships and combinations of multiple conditions in a specific and clear way.

Table-Driven Analysis Method

A table is usually composed of four parts.

Condition stub: lists all the conditions for the problem. It is generally considered that the Order of the listed conditions is irrelevant.

Action stub: lists the actions that may be performed as specified by the problem. The order of these operations is not restricted.

Condition entry: lists the values of the condition in its left column. True or false values in all possible circumstances.

Action entry: lists the actions that should be taken when the value of a condition item is different.

Rule: the specific values of any combination of conditions and the operations to perform. The column that runs through the condition item and action item in the criterion table is a rule. Obviously, the number of set of condition values listed in the table is also the number of rules, including the number of columns of condition items and action items.

Procedure for determining the table: (based on the software specifications)

① Determine the number of rules. Suppose there are N conditions. Each condition has two values (0, 1), so there is a rule.

② List all the condition and action columns.

③ Fill in the condition items.

④ Fill in the action item. Wait until the table is finalized.

⑤ Simplify and merge similar rules (same action ).

B. beizer points out the conditions suitable for designing test cases using the discriminant table:

① The specification description is given in the form of a decision table, or it is easy to convert to a decision table.

② The sorting order of conditions does not affect the operations performed.

③ The Rule sorting sequence does not affect the operations performed.

④ When the conditions of a rule are met and the operations to be performed are determined, no other rules need to be tested.

⑤ If a rule is satisfied and multiple operations are to be executed, the execution sequence of these operations is irrelevant.

　　Advantages of black box testing

1. Basically no one needs to worry about it. If the program stops running, it will be crash.

2. After the test case is designed, the job is cool. Of course, it is even harder to determine the cause of crash.

　　Disadvantages of black box testing

1. The result depends on the design of the test case. The design of the test case comes from experience, and ouspg is worth learning.

2. There is no concept of state conversion. At present, some successful examples are basically for PDU and cannot be used for state conversion of the tested program.

3. For tests without the concept of state, finding and determining test cases that cause program crash is a hassle and the possible test cases around the program must be confirmed separately. In the case of stateful testing, it is more troublesome, especially because it is not caused by a single testcase. These are more prominent in heap problems.

　　Selection of black box testing (Function Testing) Tools

Then, how can we test functions efficiently? Selecting an appropriate functional testing tool and training a team of high-quality tools is undoubtedly crucial. Although there are a few software service enterprises engaged in Function Testing outsourcing projects that do not use any functional testing tools at this stage. In the short term, the profitability of such enterprises is acceptable, but in the long term, they are likely to be replaced by software service enterprises with a high degree of automation.

Currently, many tools and software are used for functional testing, and tools for software of different architectures are constantly updated. Here we will focus on a typical automated testing tool, winrunner of mercury.

Winrunner is an enterprise-level software functional testing tool used to test whether an application can run on schedule. By automatically capturing, detecting, and simulating user interaction operations, winrunner can identify the vast majority of software functional defects, this ensures that applications that span Multiple Functional points and databases do not encounter any functional faults during release.

Winrunner has the following features: compared with traditional manual tests, winrunner can perform Function Point Tests quickly and in batches. It can perform the same actions for the same test script, this eliminates understanding errors caused by manual testing. In addition, it can repeat the same action, and the most boring part of the test can be done by machines. It supports Program-style testing scripts, A high-quality test engineer can use it to perform extremely complex tests. By using wildcards, macros, condition statements, and cyclic statements, the test script can be reused; it provides a good integration and support environment for most programming languages and Windows technologies, which greatly facilitates functional testing of applications based on Windows platforms.

The workflow of winrunner can be roughly divided into the following six steps:

1. Identify the application GUI

In winrunner, we can use GUI spy to identify various GUI objects. After identification, winrunner will store them in the GUI map file. It provides two GUI map file modes: Global GUI map file and GUI map file per test. The biggest difference is that the latter generates a GUI file for each test script, which can be automatically created, stored, and loaded. This mode is recommended for beginners. However, this mode is not easy to change the description object, and its efficiency is relatively low. Therefore, it is a better choice for an experienced tester, it generates only one shared GUI file, which makes the test script easier to maintain and more efficient.

2. Create a test script

When creating a test script, you can record the script first, and then manually add the required TSL (similar to the C language) to the recorded script ). The recording script has two modes: context sensitive and antive. The selection is based on whether to simulate the mouse track. analog is generally used for playback. During the recording process, the two modes can be switched through the F2 key.

You only need to look at the scale of modern software and the number of functional points to understand that functional testing has already crossed the stage of manual typing and mouse clicking. Performance testing is an effective means to control system performance. It plays an important role in Software Capability Verification, capability planning, performance tuning, and defect repair.

3. debug the test script)

There is a special debug toolbar in winrunner for debugging the test script. You can use step, pause, and breakpoint to control and track test scripts and view variable values.

4. Execute the test script in the new application

When a new version of the application is released, we will test various features of the application, including new features. At this time, of course, it is impossible to record and write all the test scripts again. We can use existing scripts to run these test scripts in batches to test whether the old Function Points work normally. You can use a call command to load test scripts. You can also add various TSL scripts in the call command to increase the batch capability.

5. Analyze test results

The analysis of the test results is the most important throughout the test process. Through analysis, you can find various functional defects of the application. After a test script is run, a test report is generated. From this test report, we can find the functional defects of the application and see the differences between the actual results and the expected results, and various dialogs generated during the test.

6. Return defect (defect)

After the test report is analyzed, various defects of the application should be returned according to the test process, and the defects should be sent to the designated person for modification and maintenance.

　　Common functional testing methods

The function test is to verify the functions of the product. Based on the function test cases, perform one-by-one tests to check whether the product meets the user requirements. Common test methods are as follows:

1. Page Link check: whether each link has a corresponding page, and the switching between pages is correct.

2. Correlation check: whether deleting or adding one item will affect other items. If any, whether these effects are correct.

3. Check whether the button functions are correct, such as update, cancel, delete, and save.

4. String Length check: Enter the content exceeding the string length stated in the requirement to check whether the system checks the string length and whether an error occurs.

5. character type check: enter other types of content where the specified type of content is to be entered (for example, enter other types of characters where the integer type is to be entered ), check whether the system checks the character type and whether an error is returned.

6. Check punctuation marks: the input content includes various punctuation marks, especially spaces, quotation marks, and enter keys. Check whether the system process is correct.

7. Chinese Character Processing: enter Chinese characters in a system that can enter Chinese characters to check whether there will be garbled characters or errors.

8. Check the integrity of the extracted information. when viewing the information and update information, check whether all the information is provided ., Whether the extracted information is consistent with the added information

9. duplicate information, and whether the system correctly processes the entered content by inputting spaces before and after it.

10. Check the deletion function: if you do not select any information for deleting multiple information at a time, press "delete" to see how the system will handle the problem; select one or more information and delete it to check whether it is handled correctly.

11. Check whether the adding and modifying items are consistent: Check whether the requirements for adding and modifying information are consistent. For example, if the adding requirement is required, the modification should also be required. add an item that is specified as an integer, it must also be an integer.

12. Check whether the item cannot be renamed to an existing item during modification. Check whether the item will be processed and report an error. At the same time, you should also pay attention to whether you will report the same name as yourself.

13. Repeat the submission form: a record that has been successfully submitted, back and submit again to see if the system has processed it.

14. Check whether the back key is used for multiple times: when the back key is available, return to the original page and back again. Repeat multiple times to see if an error will occur.

15. Search check: if the search function is available, enter the system's existing and nonexistent content to check whether the search results are correct. If you can enter multiple search conditions, you can add reasonable and unreasonable conditions at the same time to check whether the system process is correct.

16. Position of input information: Note whether the cursor and entered information will jump to another place when the cursor is entered.

17. upload and download file check: whether the upload and download functions are implemented and whether the uploaded files can be opened. What are the provisions on the format of the uploaded file, whether the system has interpreted information, and whether the system can do so.

18. Check required items: when the required items are not filled, whether the system has processed them and whether prompt information is provided for the required items. If yes, add *

19. Shortcut Key Check: whether common shortcut keys are supported, such as Ctrl + C Ctrl + V backspace. For fields that do not allow information input, such as selection, specifies whether the shortcut is restricted by the date.

20. Enter key check: Press enter after the input is complete to check whether the system will handle the problem and report an error.