Software test methods and techniques are varied. For software testing technologies, you can classify from different angles: from whether the angle of being measured software is required, it can be divided into static testing and dynamic testing. From the perspective of testing for the internal structure of the system and the specific implementation algorithm, it can be divided into white box testing and black box testing; 1, black box test black box test also known as functional test or data driver test, it is known The product should have functions, pass the test to detect if each function can be used normally, when testing, treating the program as a black basin that cannot be opened, does not consider the internal structure and internal characteristics of the program, test, test In the program interface, it only checks if the program function is used normally according to the requirements of the requirements specification, and the program can properly receive the input number saw to generate the correct output information, and maintain external information (such as database or file) Sex. The black box test method mainly has equivalence classification, boundary value analysis, due to fruit pictures, error speculation, etc., mainly for software confirmation testing. "Black Box" method is the external structure of the program, regardless of the internal logic structure, testing the software interface and software function. The "black box" method is exhausted input test, only use all possible inputs as a test case, in order to find all the errors in the program in this way. In fact, there is a number of infinity tests, but also do not only test all legal inputs, but also test those non-legal but possible inputs. 2, white box testing white box test, also known as structural test or logical drive test, it is known that the internal work process can be tested to detect whether the internal action is normal in accordance with the specification of the specification, according to the structural test procedures inside the program, Whether each passage in the inspection process can work correctly according to the scheduled requirements, regardless of its function, the main method of the white box test has logical drive, basis test, etc., mainly for software verification. "White Box" method fully understands the internal logical structure of the program and tests all logical paths. "White Box" method is exhausted path test. When using this scenario, the tester must check the internal structure of the program, from the checkpoint logic, to draw test data. The number of independent paths throughout the program is an astronomical figure. But even if each path is tested, there may still be errors. First, the exhaustive path test must not detect the program violates the design specification, that is, the program itself is a wrong program. Second, the exhaustive path test is impossible to detect the procedure for missing paths. Third, the exhaustive path test may not find some errors related to data. 3. ALAC (Act-Like-a-Customer) Test ALAC test is a test method developed based on knowledge of customers. ALAC testing is based on the principles of many errors based on complex software products. The biggest beneficiaries are users, defect findings, and corrections will be the most prone to errors for which customers are most prone to.
The basic method unit test of the unit test is the minimum unit - module of the software design. The basis of unit testing is to set up a description, and the unit test responds to all important control path design test cases in the module to discover errors within the module. Unit tests are multi-white box test technology, and multiple modules in the system can be tested in parallel. Unit test task unit test tasks include: 1 module interface test; 2 module local data structure test; 3 module boundary condition test; 4 modules All independent execution path tests; 5 modules Error handling path test. The module interface test is the basis for unit testing. Other tests are meaningful only if the data can flow correctly, and out of the module. The test interface should be correctly considered: 1 The number of actual parameters input to the form parameter is the same; 2 The actual parameter of the input is matched to the attribute of the formal parameter, and whether the actual parameter of the input is consistent with the dimension of the formal parameters 4 When calling other modules, whether the number of actual parameters is the same as the number of adjumbs of the modular module; 5 When calling other modules, whether the attribute gives the actual parameter is matched to the medial ginsenger of the modular module; 6 call other Whether the magnitude of the actual parameter is consistent with the formation of the modular module; 7 When calling the predefined function, whether the attribute and order is correct; 8 Is there any parameter reference to the current entry point; 9 Whether the read-only parameter is modified; 10 is the same as the definition of the entire variable, the module is consistent; 11 Whether certain constraints are passed as parameters. If the module includes external input output, the following factors should be considered: 1 File attribute is correct; 2 Open / close statement is correct; 3 Format Description Matching if the input output statement is matched; 4 buffer size is matched to the recording length; 5 files Whether it has been opened before use; 6 whether the file end is handled; 7 Have the input / output error; 8 There is a textual error in the output information; check the local data structure to ensure that the data is temporarily stored in the module in the program execution process It is complete and correct. The local data structure is often a wrong root, and the test case should be carefully designed. Strive to find the following types of errors: 1 Inappropriate or incompatible type of type description; 2 variables no initial value; 3 variable initialization or the provincial default; 4 Incorrect variable name (tuning or incorrectly truncated); 5 appears overflow, underflow and address exception. In addition to the local data structure, if possible, the unit should also find out the impact of global data (such as Fortran's public areas) on the module. Test each independent execution path in the module, the basic task of the unit test is to ensure that each statement in the module is at least once. At this point, the design test case is to find errors caused by incorrect comparison, incorrect comparison and inappropriate control flow. At this time, basic path testing and cyclic testing are the most common and effective test techniques. Common errors in the calculation include: 1 misunderstanding or use the wrong operator priority; 2 mixed type operation; 3 variable initial value; 4 precision is not enough; 5 expression symbols are wrong. The comparison judgment is often closely related to the control flow. The test case should also be committed to discovering the following error: Comparison between objects of different data types; 2 Errore using logical operators or priorities; 3 due to the limitations of computer representations, expectations Theoretically, the two quantities actually unhappy; 4 comparative operation or variable error; 5 cyclic termination conditions or impossible; 6 iterations When it is divergently, it cannot be exited; 7 incorrectly modify the cyclic variable.
A good design should be able to foresee a variety of error conditions, and preset various error handling paths. The error handling path also needs to be carefully tested. The test should focus on the following questions: 1 The error information of the output is difficult to understand; 2 record errors and actual The error does not match; 3 Before running the program-defined error processing segment, the system has been intervened; 4 exception handling; 5 error statements fail to provide sufficient positioning error information. Boundary condition testing is the final and most important task in unit testing. We know, software often invalidate on the boundary, using boundary value analysis technology, design test cases for boundary values and left, right, and is likely to find new errors. The unit test process generally believes that the unit test should be completed immediately after the encoding, the source program is completed and the unit test can be started by review and compiling checks. The design of the test case should be combined with the review work. The test data is selected according to the design information, and the possibility of the above various types of errors will be increased. While determining the test case, the desired result should be given. A driver module (DRIVER) and (or), and several pile modules (STUB) should be developed for the test module, and the following figure shows the environment of the general unit test. The drive module is called "main program" in most cases, which receives test data and passes the data to the test module. After being called by the test module, "Main Program" prints "Enter-Exit" message. Drive modules and pile modules are software for testing, not part of software products, but it requires a certain development fee. If the drive and the pile module are relatively simple, the actual overhead is relatively low. Unfortunately, only a simple drive module and the pile module cannot complete some modules test tasks, which can only use the comprehensive test method discussed below. Improve the internal polymetidity of the module to simplify unit testing, if each module can only complete one, the number of test cases required will be significantly reduced, and the error in the module is more easily discovered.
The basic method of integrated testing often occurs, and each module can work separately, but these modules are integrated and cannot work. The main reason is that the modules will introduce many new issues when they call each other. For example, the data can be lost by an interface; a module may cause no impact on another module; several sub-function combines that the main function is combined; the error has accumulated to achieve unacceptable levels; the overall data structure has an error, and so on. The comprehensive test is a system testing technology for assembly software. After assembling each module of the unit test, a comprehensive test is performed to discover various errors related to the interface. A designer is accustomed to assembling all the modules all in the design, and then performs overall testing, which is called non-increasing integration. This method is prone to confusion. Because of the test, a lot of errors may be found, which is very difficult to correct and correct, and can introduce new errors while correcting an error, and new and old mistakes are mixed, it is more difficult to determine the causes and positions of the error. In contrast, the incremental integrated method is extended, and the program is extended. The scope of the test increases in one step, and the error is easy to position and correct. The interface test can also be completely thorough. Two incremental integrated methods are discussed below. 1 Since the top-down integration of the top-down integration is an incremental method of constructing the structure structure. It starts from the main control module, according to the software control hierarchy, with a depth priority or breadth priority strategy, gradually put each module. Integrated together. The depth priority policy is first integrated together on the module on the main control path, as for which path is selected as the main control path, which has a randomness, generally determined according to the characteristics of the problem. The following figure is an example. If the left path is selected, the modules M1, M2, M5, and M8 are first integrated, and then the M6 is integrated, and then the path of the middle and right is considered. The breadth priority strategy will move downward along the control hierarchy. Still the following picture, it first integrates M2, M3, and M4 with the master module, and then integrated M5 and M6 and other modules. The specific steps of the self-top-down comprehensive test are: 1 Replace all the pile modules introduced by the main control module as the test drive module, replace all pile modules introduced when the main control module is tested; 2 According to the selected integration strategy (depth priority Or breadth priority), only replacing a pile module each time; 3 Each integrated module is immediately tested again; 4 After each group of tests are completed, it will be replaced with a pile module; 5 To avoid introducing new mistakes, it must constantly return Test (i.e., all or partially repeating the tests have been tested).
From the second step, the above steps are generated until the entire program structure is completed. In the figure below, the solid line represents a partially completed structure. If a depth priority policy is employed, the next step will replace the pile module S7, of course, the M7 itself may have a pile module, and then the corresponding actual module will be replaced one by one . The advantage of self-top-down integration is that the main control and decision mechanism of the program can be tested as soon as possible, so it has been found earlier. The disadvantage is that when testing a higher layer module, the low-level processing uses a pile module to replace the real situation, and the important data cannot be forwarded to the upper module in time, so the test is not sufficient. There are several ways to solve this problem, the first is to postpone some tests after replacing the pile module with the real module, the second is the development of the pile module that can simulate the real module; the third is the upward integrated module. The first method retracted into a non-increasing integrated method, making the error in positioning and correcting, and lost the possibility of some specific tests in the assembly module; the second method is undoubtedly increased; third The method is more practical, and it is discussed below. 2 Since the bottom up, the up-to-end test is to assemble the test from the "atom" module (ie, the lowest layer of the software structure). When testing the higher layer module, the desired lower module function has been required, so no longer needs Pile module. The steps of the summary test are divided into: 1 Tissue the low-level module into a module group that implements a sub-function; 2 Develop a test drive module, control the output of the input and test results of the test data; 3 pairs of each module The group is tested; 4 Delete the drive module used by the test, use the higher layer module to organize the module group into a new module group that completed the greater function. The above steps are started from the first step until the entire program is completed. The figure below illustrates the above process. First "atom" module is divided into three module groups, each module group introduces a driver module for testing. Due to module group 1, the modules in the module group 2 are partially affiliated to the module MA, so after the driving modules D1, D2 are removed, the module group 1 and the module group 2 directly with the MA interface, at which time the MAD3 is removed, M3 is Module Group 3 Direct Interface, MB can be integrated, and finally MA, MB, and MC are integrated together.
Since the beginning, the integrated method does not need the pile module, the design of the test case is relatively simple, but the disadvantage is that the last module is added to have an overall image. It is exactly the same as the advantages and disadvantages of the self-top integrated test method. Therefore, in the test software system, the appropriate test strategy should be selected according to the features of the software, and the appropriate test strategy is used, sometimes mixed and used two strategies, and the upper module uses the bottom downward method, the lower module is upstairs Methods. In addition, in the comprehensive test, it is especially necessary to pay particular attention to key modules. The so-called key modules generally have one or more features: 1 correspond to several requirements; 2 has high-level control functions; 3 complex, easy to erode; 4 has special performance requirements . The key module should be tested as soon as possible and recurrent regression test. After confirming the basic method of the test, the software has been completely assembled, and the interface error has also been excluded, the final step of the software test - confirms the test. Confirm that the test should be checked whether the software can work according to the contract requirements, that is, meet the confirmation standard in the software requirements instructions. 1. Confirm the test standard implementation software confirmation to test through a series of ink cartridges. Confirmation The test also needs to develop test plans and processes. The test plan should specify the types and test progress of the test. The test process defines some special test cases to explain whether the software is consistent with the demand. Nothing is still a process, it should focus on whether the software meets all the features and performances of the contract, whether the documentation is complete, accurate man-machine interface, and other aspects (for example, portability, compatibility, error recovery ability, maintenanceability Whether or not to satisfy users. There are two possibilities for confirmation tests. One is the requirements of functional and performance indicators to meet software requirements. The user can accept; the other is that software does not meet the requirements of software requirements, and users cannot accept. Projects By this stage, they have found that severe errors and deviations are generally difficult to correct within a predetermined period of time, so they must negotiate with the user to seek a way to properly solve the problem. 2. Another important part of configuring the review confirmation test is the configuration review. The purpose of review is to ensure that the software is fully equipped, classified or order, and includes the details necessary for software maintenance. 3. α, β test In fact, software developers cannot fully anticipate users' actual use programs. For example, the user may be wrong to understand command, or provide some strange data portfolios, may also confuse the designer's self-identified output information, and so on. Therefore, whether the software truly meets the final user's request, and should be conducted by the user a series of "acceptance tests". Acceptance tests can be both a non-formal test or have a planned, systematic test. Sometimes, the acceptance test has reached several weeks or even months, which continues to expose the error, leading to the development of extension. A software product may have many users, it is impossible to accept each user, at this time, the process called α, beta test is used, and the issues that seem to have only end users can find. Α test refers to the software development company organizes internal personnel to simulate various types of users to test the ultra-market software product (called α version), try to find errors and correct. The key to α test is to simulate the actual operating environment and users to operate the software products and do their best to cover all possible users. Software products adjusted by alpha tests are called β. Completed with the subsequent beta test refers to the actual use of a typical user in all aspects of the software development company actually uses the beta version in daily work, and requires the user to report an abnormal situation and propose criticism. The software development company is then changed and perfect for the beta version. The basic method of system testing computer software is based on an important part of the computer system. After the software development is completed, it should be integrated with other ingredients in the system, and a series of system integration and confirmation tests are required. The detailed discussion of these tests has exceeded software engineering, and these tests cannot be completed only by software developers.
