Software test is one of the important means of ensuring software product quality. It is a measure of measurement, assessing software product features and capabilities. Some software companies in China are still not enough for software testing. It is considered that the test work is very simple, but simply operates the software products measured. This kind of error has seriously affected the quality of domestic software, should cause us to attach great importance. The software test phase can be divided into several small phases. There are many points in the stage. I am divided into four phases according to the process order: * Unit test: completed by the project team * integration test: completed by the project team * system Test: Completed by the professional test team * handover test: users and developers are done together. The four stages of the test were completely reversed to detect the various stages of software development. The unit test is mainly the test program code. The integrated test is mainly for design detection. The system test mainly tests the functionality of the software, and the handover test is mainly a test for user needs. However, each test phase still has to test the test content of other test phases, just different test focus. In this article, I only explain the unit testing process without involving specific test methods. About testing methods (such as: using manual testing or automatic test) If there is an opportunity to explain in other articles. Before the unit test, let us understand the following questions, which makes us clearer with unit testing. * Entire target: Make sure the module is correctly encoded * Who is doing: Usually test * How to test: Function test can be used in black box test method, code test available white box test method * When you can stop: When the programmer feels no defects * records: Usually, we can write test cases after we know above. The test case is the intended result set of input, execution conditions, and a special goal. It can be divided into the following types according to the test object: * Demand test case: Test if the requirements are required to specification * Design test case: Test if the test is compliant with the system logical structure * Code test case: test code logical structure and data requirements The use case is typically written input data and desired output according to the functionality executed by the requirements. A good demand usage is that you can override all program functions with a small amount of testing. Design test cases are detected whether code and design are fully consistent. It is a test of underlying design and basic structures. The design test case may involve the code space covered by the demand test case (eg, the design of the interface). The code test case is based on running software and data structures. It is guaranteed to overwrite all program branches, the smallest statement and output. The data used in the above three use cases can be divided into normal data, edge data, and error data. * Normal data: The amount of normal data used in the test is the greatest, and it is also the most critical. A small amount of test data cannot completely override the requirements, but we have to extract some highly representative data as test data to reduce test time. * Edge data: Edge test is a data boundaries between normal data and error data. It can specifically set for a programming language, programming environment, or specific database. For example, if you use a SQL Server database, you can set the SQL Server keyword (such as: '; as; join, etc.) to edge data. Other edge data also include HTML HTML; <> and other keywords and spaces, @, negative numbers, long characters, etc. Edge data must be developed by the rich experience of testers.
* Error data: Obviously, error data is to write data that does not match the program input specification to detect the branch of the input filter, error handling and other programs. Since the amount of data to perform test cases is huge and the regression test is required, it is possible to consider using the automated test tool, but the extraction test data still relies on the experience of writing test cases. And, we must also note that the automatic test may not find all the errors in the program, and the error that the manual test finds is more than the automatic test. With test cases, we can test it? Many companies have done this, but here I suggest that everyone must first review the code. Errors found through code review can be more deeper than the error that can be found more deeper than the test case test, and the error is found to be earlier than the test case. The code consider should be based on code standard (specific situation of the roots). In general, check the following: * Code style and rule audit * Program design and structure audit * Business logic audit code style and rules The audit is an inspection of coding specifications when each programmer completes a module or class. To hold a review meeting, all project groups are involved. In the session, the project manager is to be a checklist, based on the content of the table, the content of the checklist is mainly inspected. Every person in the auditor can see the code of the project in the project team, and there is a role in prevention. These issues are to be resolved and the resulting results are confirmed at the retrieval. The review of programming and structures is due to the different design of the development tools and the limitations of the project time. A more in-depth design is usually done during the coding phase, but due to the experience of program personnel and designers, there is a big problem. We introduce program design and structural audits to ensure quality. Audit staff must have advanced technology development experience. Before reviewing, a review list is listed, and the main items are listed, such as the profile of the program, detailed design. However, it is only limited to the list. The reviewer also deliberately deliberately deliberately deliberately rely on experience without relying on the content in the list. The width and depth of the code detected by different programmers are also different. The project manager can formulate the width and depth of the considered personnel according to the different programmer experience. For example: Young programmers should consider all code. But experienced can be appropriately reduced. Business logic consideration must be considered after the code is completed. Business logic deliberation is actually the function of deliberating the unit module. These functions are based on system description. Reviewers must have experience in development and are familiar with the system. The review personnel understand the state of the underlying code by executing the program. The review of this phase actually contains the first two reviews because the deliberator can also detect the accuracy of the unit module design and structure through the final result. The above three reviews take certain time and resources, but it can find and solve the incorrect mistakes earlier. After the review, we can finally use the case to perform code testing and debugging. The debugging of the code is a means used to ensure that the program can function properly according to the system requirements. But this code debugging I mentioned is not simple debugging. It should include the following two parts: * Feature debug * Code overlay debugging First we must first make a feature commissioning. It is the error in the code in the code by running the program, which is the same as the commissioned we usually make. Once the program is running, we can use the three types of useful use cases and test with normal data test cases. If you do not work properly, you should use debugging tools to debug. At this stage, we have to test with a lot of normal data. After testing, the program should be run in most normal data. Second, we have to make code override test, and have always reached the following targets to: * Test to each of the minimum statements * Test all the outputs We should run all the programs and branches of each program through a step debugging . If we want to cover 100%, you should use edge data and error data. The quality test is difficult to master at this stage. It is based on programmers' responsibility and experience. When this phase is completed, the depth measured by each programmer is also different.
Therefore, before this test phase, the project manager (or test engineer) should formulate test guidance and plan. They should at least include the following: * The main object of the test * Main adjustment points * How to test * When can be completed so far, we have completed the review and debugging of the code. If we are strictly done in the above steps, then you can guarantee that there is not much error in the code, at least if you don't make the program run an error. If we can't perform code review and correct debugging, then we can't go smoothly, sometimes we have to return to do these things. Ok, we finally completed the work of unit testing, the programmers can breathe, but don't forget that there are more stringent integration tests to do
