Method of Construction 05

the 13th chapter is software testing, the main steps of software testing are unit testing, integration testing and validation testing.

Unit tests are also called module tests. Usually unit testing can be placed in the coding phase, after the programmer writes the good one module, it will always (should) test its own module, check whether it implements the detailed design specification of the module functions and algorithms. Unit tests mainly identify errors in coding and detailed design, usually using white-box testing.

Testing a module requires writing a driver module and several stub modules, as shown in. The function of the drive module is to provide test data to the tested module, drive (i.e. call) the tested module, and accept the test results from the tested module. The function of the pile module is to simulate the submodule called by the module, which accepts the call of the module being tested, verifies the call parameters, simulates the

Call the Submodule function and send the result back to the module under test. In the module structure diagram, the top-level module is not required to test the driver module, the bottom of the module test does not require the pile module.

Integration testing, also known as assembly testing, is a program that is assembled from each module to test the interface and communication between modules. Integration testing primarily finds errors in the design phase, usually using black-box testing.

The integrated approach can be divided into non-incremental integration and incremental integration. Non-incremental integration tests all the modules first and then integrates the modules together to test the entire program. Incremental integration is the combination of unit and integration tests, which, according to the module structure diagram, select a module that has not been tested in some order, and combine it with the tested module to test the entire program, adding one module at a time until all modules are fully integrated into the program.

The incremental integration can also be divided into top-down integration and bottom-up integration. Top-down integration test the upper module first and then test the lower module. Since the upper module of the lower module has been tested, its upper module can be used as its driver module, rather than the other driver module. Bottom-up integration test the lower module before testing the upper module. Similarly, in the bottom-up integration, the lower module can be used as the upper module of the pile module, without the need to write another pile module.

The task of confirming the test is to check that the functionality, performance, and other characteristics of the software are consistent with the user's needs, and that it is a test based on the requirements specification (i.e. requirements Protocol). Validation tests are usually made in black-box tests.

Confirm Test First Test whether the program meets the requirements listed in the requirements specification, and then to perform software configuration review, especially the documentation is complete, the quality of all aspects of compliance with the requirements. If a software is customized for a particular customer, then the customer is finally implementing the acceptance test (acceptance testing) so that the customer confirms that the software is what he needs. If a software is used as a product by many customers, it is impossible for each customer to conduct acceptance testing. Most software producers use a process of alpha testing and beta testing to uncover errors that can only be discovered by the end user.

Alpha testing is performed by the customer at the developer's site, and the software being tested is run in the context of the developer's general setup from the user's perspective. Beta testing is performed on the site of one or more customers by the end user of the software. Unlike the alpha test, developers are usually not present during beta testing. Alpha and beta tests, in addition to the bugs found in the program, can also identify problems with use. Software that has been validated for testing is usually available for delivery.

The 14th chapter emphasizes the quality assurance, software quality including program quality, software engineering quality, software engineering quality embodied in the aspects: Software development process visibility, software development process risk control, software internal module, Project intermediate stage delivery quality, project management tool factors, Control of software development cost and completion of internal quality indicators. Using CMMI model to manage the project not only reduces the cost of the project, but also improves the project quality and the schedule completion rate.

The 15th chapter is to write the stability and release phase, the software before the release of the software before the various problems require the following: 1. The Consultation group: the various roles of the software team constitute the consultation group. Handle every issue that affects the release of the product 2. Consultation on complex projects: in the early stages of the stabilization phase, the team decides which defects need to be repaired and then the team members perform the necessary design, implementation, and testing work. and check in code modification 3. Tricks: Design changes: Rewriting or refactoring 4. Tricks: ZBB: Make this version of the build to solve all the known bugs 5, tricks: The final regression test: At the close of the project, all personnel (development, management, Test) all the Bug6. Tricks: Cut off the function 7. Tricks: The threshold for fixing bugs is increasing by 8. Tricks: Gradually freeze, with the improvement of the function of the program, we want to make the program all aspects of the order of "freeze", so that the stable software delivery to the user.

The 16th chapter is the innovation of IT industry, any technology has its own development law, with a new technology experience different stages, the total value of its expectations, speculation is also a big difference

1. Technology trigger period 2. Expected expansion period 3. Confusion period 4. Low-key development period 5. Mainstream development period

The 17th chapter is about people, performance and professional ethics, team growth has the following stages: The embryonic stage, the running-in phase, the normative stage and the creation stage.

Method of Construction 05