Minimum test method
-------------------------------------------------- ------------- author: Wang Hui joined: 2002-12-30 ------------------------- -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1 Introduction...
1.1. Introduction..
1.2. Test purpose
1.3. Test method
2. Internal test process
2.1. Preparation of the test
2.2. Write test plan
2.3. Test case design
2.3.1. Preparation of test cases
2.3.2. A example test case
2.4. Test Process
2.4.1. Development team programmer
2.4.2. Test team work form with program development group
2.4.3. Test team work requirements
2.4.4. Test Group Workflow
2.5. Routine problem
2.5.1. Program staff self-test is not strict
2.5.2. The rationality of data constraint is the first step in the table check
3. Software test standard
4. Appendix ...
4.1. Test Plan Outline
4.2. BUG list necessary ..
4.3. Common noun definition
4.4. About α, β test ..
1 Introduction
1.1. Introduction
For most software systems, how to test and effectively testing is a headache. In software engineering, testing is an extremely important part of software engineering; but in specific practical conditions, most of the domestic software companies have no theoretical complete testing, whether it is time, human hand and resource allocation. .
In this article, it is a test method that is simple and feasible, and the software system can achieve the minimum quality requirements.
1.2. Test purpose
For any software, its value is the correct implementation of the user's needs, then the ultimate goal of testing is to implement whether the software is really realized for the user's needs, and enables the system to reach the user to receive.
1.3. Test method
The user's ultimate recognition and acceptance of the software is the final identity of a software before it can be put into the correct use. Therefore, for developers, it is finally delivered to the user, and it is necessary to have a comprehensive scientific perfect internal test method. Internally testing, the development chamber of commerce consistently requires tester to use from the user's perspective and performs a test one by one, and the system will be submitted to the user.
That is to say, the internal test is at least in the relevant part of the system's confirmation and the system test.
2. Internal test process
2.1. Preparation of the test
Before the test, you must prepare the corresponding machines and equipment before the system, and build the corresponding test environment and equipped with the corresponding testers.
For the corresponding testers must be tested from the customer's perspective, that is to say, it is very clear that the functional goals to be achieved, the professional appreciation of the test staff should be understood, and the key points should be understood.
Test staff's clearness of the demand is the lowest requirements of internal testing.
2.2. Write test plan
The test plan must contain the following:
1. Determine the test personnel and divide the division, clear their respective responsibilities.
2. A clear test function is sorted in priority order.
The general order for test work arrangements is as follows:
Ø System installation
Ø System parameter setting
Ø Traverse all business functions, and clearly achieve all the needs
Ø Test
Ø Accuracy test (including data test)
Ø failed test
Ø Status test Ø Business handling function query function and report function
Ø System performance
3. Test data design description.
4. Training and other support conditions
2.3. Test case design
2.3.1. Preparation of test cases
key point
1. The function point of the test case must be written and analyzed by SA, and a large number of test cases are written by the test team, and the final test case is signed by SA.
2. Of course, if SA is not encoded, the test team leader is the most appropriate.
3. The tracking and change of function points must be updated instantly, generally performed by SA or PM, and the test case must also be updated.
During the actual process, you need to discover more errors based on the available resources (labor, material forces and time, etc.). Provide end users with quality evaluation with certain credibility. If you want to write and test all the use cases are not realistic, the following is a specific example, a good programmer in the actual test process, can only list more than half of the test cases that actually needed below.
2.3.2. A example test case
Program: A program accepts 3 integer inputs. 3 integer values have three strips of the mean three angle. According to these three values, the program is to determine that this triangle is not equilateral triangle, the waist triangle or the equilateral triangle.
Complete test case:
The purpose of the test case, the effective non-equilatex triangle, such as 1, 2, 3, and 2, 5, 10, can not guarantee "Yes" answer, because there is no such triangular effective equilateral triangle
Equivalent of the waist triangle 1, 1, 2 type test cases cannot be calculated, since there is no such a triangular test case is an effective plahete triangle, thereby includes three substitutions of two equilaters, for example: 3, 3 , 4; 3, 4, 3, and 4, 3, one side is 0
One side is negative
3 integers greater than 0, and two numbers and the third number are equal if the program is considered 1, 2, 3 means that there is at least three test cases in the above test, so you You can try three arrangements. One of them is equal to the length of the other 2 side and the length.
3 integers greater than 0, and 2 numbers of and less than the third number, such as: 1, 2, 4, and 12, 15, 30 at least 3 test cases in the above test, so you can try three kinds of alignment such as : 1, 2, 4; 1, 4, 2 and 4, 1, 2 all the edges 0
Non-integer value
Number of input data If you enter 2 or more than 3 numbers specify the expected output of each test case
(Excerpt from "Software Verification and Confirmation Best Management")
2.4. Test Process
The process of testing has two types:
2.4.1. Development team programmer
A large-scale system between programmers occurs in multiple subsystems or a system of multiple subsystems is written according to functional division of labor.
The test process generally initiates a test by the function writer of the service initiation point, and the endpoint of arriving at the business is end.
The specific form is as follows:
After the start-up developer launched the business, the paper-free test book, clearly initiated, and sent to the next processing link.
The corresponding next link programmer is performed accordingly. After the processing is completed, the corresponding part of the joint test book is added or the signature of the joint test book has completed the corresponding processing, and then the programmer of the next processing link, the final point is reached by this similar layer approval. , Complete the internal coordination process.
Internal coordination is a test for each programmer compiled, which is generally easy to generate every programmer's workload and progress, and the division of labor is flexible for the division of staff of the joint test period. Mobilized way.
2.4.2. Test team work form with program development group
1. After the program is self-test, submit the project manager to request test acceptance, project manager text or other way to notify the test person in charge to prepare for the test, the person in charge of the test, the programmer, the programmer, the programmer, the programmer is discovered BUG number (recommended for each programmer's desk, a metrical bug table, each time the BUG number is recorded in the file, the weekly maximum and lowest personnel and bug number, the final test phase The initial BUG data affects the programmer assessment, used to enhance the extensive self-inspection value of the program) 2. First verified, programmer puts the project file (source package) and EXE file (or installation package) package In a zip file. Send to the internal file administrator or project specified test file storage directory, otherwise the programmer is modified and repeated step 1.
3. After the file administrator performs the version file archive of this test, the file administrator will notify the test person in charge to store the location where the test is stored.
4. Test the person in charge take the corresponding system to test, record the test process, and finally submit the test results to form a bug list, convey to the project manager, and then transfer to the programmer after reviewing the project manager.
5. The programmer performs the corresponding program modification according to the bug list, and updates the BUG list file, sent to the project manager, and then transferred to the test person in charge.
6. Repeat Step 1, the test staff will conduct a review of the original test error in the late test.
The test person in charge and document administrator can be a special person or a project manager or a system analyst.
If you use the end user as a tester, pay more attention, too many bugs (especially for the amount of error) will make users fear of the system, thinking that the process given to them will be a big bomb. So before committing, strict self-test must be performed. For the necessary serious treatments for bugs, it will not affect the user's confidence in the system. For unscrupulous bugs, necessary criticisms (weekly or group meeting) must be made to strengthen their own inspections.
2.4.3. Test team work requirements
1, BUG list submission and data submission
A) Requires all bugs.
B) Major bugs instantly submitted by the project group, but must be made to record, and continue other tests (except for testing).
C) If some testers think the tests should be conducted, if they can't do it, they should be submitted for BUG.
D) The record of the data should be detailed, all of the operational critical data of the operation should be recorded.
2, BUG tracking
A) Track the bug that it discovers has resolved and unresolved.
B) The problem that is still not resolved in the new version should be recorded separately, and "legacy issues" can be indicated.
3, test task division
Clarify each person's test focus, file storage location, submitting the BUG, all bugs are submitted to the project group after summarizing the test team leader.
2.4.4. Test Group Workflow
1. Project group PM submit test procedures;
Requirements: All project files and execution documents (the first request is the running program that the project group is predicted)
2. Test staff acceptance;
3. Test staff put all files into a package;
4. Submit to the project configuration library;
5. Test execution
Explanation: Test staff perform tests on "test task division", "business dependencies" and related "demand documents"
6. Fill in "Test Record" and "BUG List"
Requirements: "Test Record" in the test process, according to the requirements, detailed fill in; "BUG list" is filled in after the test is completed
7. Submit the Test Textage with the Test Bug List (not more than 2 days);
Explanation: Test staff do not longer than 2 days to complete a round of testing 8. Test the team leader statistical test situation and timely submit the BUG list to the project group PM
9. The project group changes the program and tracks the resolution of the record bug;
Requirements: The project team is not longer than 2 days, and a new software version is submitted to test the test team (with a date-defined version). The new version of the software is submitted to the configuration library and promptly notifies the test group.
2.5. Routine problem
2.5.1. Program staff self-test is not strict
The programmer has tested the test team for testing for the test team, so that the test team is tested to test, so that the test team takes too much responsibility, the solution: the program personnel perform unit test, provide units Test records, strengthen the rigorism; the code is temporarily sealed in a certain (one or two days) time procedures, the programmers make each other, so that the procedures you have compiled, how to demonstrate the leadership, destroying its self-superior sense .
2.5.2. The rationality of data constraint is the first step in the table check
Whether the data is within the conventional conditions; whether it is normal if the offshore processing is normal; the default, blank, NULL value, and zero value processing is normal.
3. Software test standard
For software testing from the following aspects:
1. The integrity of user needs: whether the implementation of the specific system is carried out according to the business process required by the user.
2. Integrity of the document: Whether the contract and all documents clearly have been completed.
3. Test (including accuracy test)
The first step in the test, what work can be done.
4. Conditions Overwrite the second step of test testing, how to test a multifaceted test system. It is clear whether sufficient condition coverage is made by certain test data to achieve sufficient quality.
5. Rationality of data constraints: whether the data is within the conventional conditions; whether it is normal; default, blank, null value, and zero value processing is normal.
6. Status control is performed in system and functionality in different states, such as databases, whether the client is powered on.
7. Software General Performance and Other: Software The operating environment and easy usability, portability, compatibility, error recovery capabilities, and maintenanceability, etc. are approved for users.
There are two possibilities for the results of the test, one possibility is a variety of aspects (mainly functional and performance indicators) to meet the requirements of the software requirements, the user accepts the system; the other may be software does not meet the requirements of software requirements, users Can not accept. During this stage, the serious error (generally referring to important business logic) is generally difficult to correct in a predetermined time, so it is necessary to negotiate with the user, seek a method of properly solving problems.
About the Author:
Wang Hui, with eight years of programming and system management experience, the language used is C and Java programming languages. At present, a project manager in Shenzhen, using C and Oracle database development application systems. Can contact DDXXKK@21cn.com.
4. Appendix
4.1. Test Plan Outline
From the computer software product development documentation Guide GB 8567-88 The test herein is mainly to refer to the assembly test and confirmation test of the entire program system. The preparation of this document is to provide a test plan for the software, including the content, schedule, design consideration, test data for each test activity, and evaluation criteria. The specific content requirements are as follows: 17.1 Introduction 17.1.1 Writing 17.1.2 Background 17.1.3 Definition 17.1.4 Reference 17. 2 Plan 17.2.1 Software Description 17.2.2 Test Content 17.2.3 Test 1 (identifier) 17.2.3.1 Schedule 17.2.3.2 Conditions 17.2.3. 3 Test Information 17.2.3.4 Test Training 17.2.4 Test 2 (identifier). . . . . . 17.3 Test Design Notes 17.3.1 Test L (Identifier) 17.3.1.1 Control 17.3.1.2 Enter 17.3.1.3 Output 17.3.1.4 Procedure 17 . 3.2 Test 2 (identifier). . . . . . . 17.4 Evaluation Guidelines 17.4.1 Range 17.4.2 Data Consolidation 17.4.3 Scale 4.2. BUG list necessary
Includes error program names and versions, error themes, errors, testing process descriptions, testers, test time, modification results, modification, modification time.
The classification of the wrong level of error is as follows:
? Serious error: lead to the system unable to implement functional goals, so that the test cannot continue. Mainly include: the program cannot start, the program is abnormal, the program crash, the key demand is not implemented, and the serious numerical calculation is wrong, security errors, documentation and software are serious.
? Medium error: causes the system to fail to implement functionality normally, but know how to avoid errors through other ways. Mainly include: The procedure is abnormal but avoidable, the system boundary value is wrong, non-critical needs to understand errors, system document errors.
? Masonic error: It causes user / operator to use it inconvenience, but does not affect the implementation of system function targets. Mainly include: query report format error, user interface is not very friendly, display format error, slight numerical calculation error, system processing is not optimized, system documentation is slightly wrong.
? Suggestions: Make the system more complete constructive opinions.
4.3. Common noun definition
White box test: If the internal activity of the known product can test whether its internal activity meets the design requirements, this method is called white box test, checking the internal logic structure of the software, is based on the details of the process carefully, By providing a set of specified conditions and cyclic test cases, the logical path through the software is tested, and the program can be checked at different points to determine whether the actual state is consistent with the expected state. Black box test: focused on the external characteristics of the software without considering the internal logical structure of the software. Refers to the test on the interface of the software, that is, see if it meets the functional requirements, the input can be properly received, and the correct output result, and whether the integrity of external information (such as data file) can be maintained.
Unit test (module test): It is equivalent to a division, that is, a module-by-module, is a guide to describe an important control path to find an error. Use a white box test method.
Integrated test (assembly test or joint test): Equivalent to coordination, mainly to investigate the interface between the modules and between the modules
Confirmation test (effectiveness test): It is the function and performance of the software and whether other features are consistent with the requirements of the user. Whether the function is consistent with the needs of the user. Use a black box test.
System Test (System Distribution): It is combined with the entire computer system, peripheral, some support software, data, and other system elements, data, and personnel, etc. In the operation (use) environment, a series of assembly tests and confirmation tests are performed on the computer system.
Acceptance test: Implementation by the user, to confirm whether the demand for software functions and description by so-called black box testing
Return test: Duplicate partial or all tests
Recovery Test: It is a system test that enhances software failure in a different way, and it is used to complete the software to complete recovery.
Safety Test: Try to verify the prevention mechanism to establish within the system to prevent from abnormal intrusion.
Strength Test: Really require a very quantity, frequency, or capacity resource mode to run a system. It is actually a sensitivity test technology
Performance Test: It is the performance of test software to run in the environment of the group. Performance tests should cover every step of the test process
Test case: A group is most likely to discover some errors or test data for a class
4.4. About α, β test
In fact, software developers cannot fully anticipate the actual use of users. 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.
