Test experience ------------------------------------------- ------------------------------------ The quite part of the software engineering is about software testing:
1. Category of test concepts
In general, testing refers to all inspections, review, and confirmation activities in the survival cycle of software products. Such as: design review, system testing.
In a narrow sense, the test is the inspection and evaluation of software product quality. On the one hand, check the quality problems in the quality of software products, and objectively evaluate product quality.
2, the purpose of the test
Simply put, it is to be used by the user, the ultimate goal of the test is to ensure that the function of the product that is finally handed over to the user meets the user's needs, and discovers as many issues to the user before the product is discovered and corrected. Under acceptable overhead, improve the confidence of the software.
Specifically, testing generally needs to achieve the following goals:
1) Make sure the product has completed its commitment or published features, and all users can access the ability to have a clear written description ------ in a sense to ISO9001 is the same idea. Finally, the uncomfortable or even incorrect written document is also the biggest and most headache encountered in the test work. Its direct consequence is low, the test goal is not clear, the test range is not sufficient, resulting in the final test role Can not be fully utilized, the test effect is not ideal.
2) Ensure that the product meets performance and efficiency requirements
Use products that have low efficiency (low performance), or user interface is unfriendly, and users operate (less efficient) cannot be said to be a competitive product. Users are most concerned about how advanced your technology, how powerful features, but he can get from these technologies and these features. That is, the user cares about how much it can be taken from it, not how much you have already put.
3) Make sure the product is robust and adapting to the user's environment.
The robustness is stability, which is the basic requirement of product quality, especially for a working environment for transaction critical or time. In addition, it is not possible to assume a user's environment (except for some projects).
3, the principle of testing - goodenough
For relatively complex products or systems, Zero-bug is an ideal, good-enough is our principles.
Good-enough principle is a principle of weighing investment / output ratios: insufficient testing is irresponsible; excessive testing is a waste of resources, and it is also an irresponsible manifestation. Our difficulty is: how to define what test is insufficient, what kind of test is excessive. The current situation is the only answer to: Develop the minimum test through standard and test content, and then specific analysis.
4, the law of test ---- Wooden barrel principle and 80-20 principles
1) Wooden barrel principle.
In software product production is the concept of comprehensive quality management (TQM). The key factors of product quality are analyzed, design and implementation, and tests should be integrated into their supplemental inspection methods, other management, support, and even cultural factors will also affect the quality of the final product. It should be said that the test is the necessary conditions for improving product quality, but also to improve product quality is the most direct and fastest means, but it is not a fundamental means. Conversely, if the weight of the product is improved, it will be a horrible and long disaster.
2) BUG's 80-20 principles.
In general, in analysis, design, implementation, the review and testing work can be found and avoided by 80% of BUG, and the system test can find 80% of the rest of the bug, and the last 5% bug may only be in the user. Large range, it will be exposed after a long time. Because the test can only be guaranteed as much error as possible, it is impossible to ensure that all errors can be found.
5, the challenges and countermeasures encountered in traditional test processes ---- The sooner the problem, the smaller the cost of solving
For test theory, it is mainly based on software lifecycle V word model. It can be seen through the software testing, and the basis for each level of test is a variety of detailed documents in the development phase. Testing is currently dependent on: Test staff experience and quality; product description documentation and project team technical consultation; test tools; test plan design. 6, test classification
Press functionality:
- WhiteTest
- Black Box Test (BlackTest)
According to the test time:
- UnitTest
- Integrated Testing (Integratetest)
- Confirmation test (ValidationTest)
- System Test (SystemTest)
Press the operating status:
- Static test (statictest)
- Dynamic Test (DynamicTest)
Press direction:
- forward test
- reverse test
7, test strategy:
Test Policy Description Test Engineering Overall Methods and Targets. Describe the current test (unit test, integrated test, system test), and test types (function test, performance test, overwriting test, etc.) per stage (function test, performance test, overlay test, etc.).
Test strategies include:
1. Test technology and tools to use;
2, test completion standards;
3. Special considerations affecting resource allocation, for example, testing and external interfaces or simulating physical damage, security threats. One of the most critical steps in the test plan is to break down the software into a unit, and write a test plan in accordance with the requirements.
There are several benefits to decompose software into units:
1. Software demand is the basis for testing design and development test cases, and the divided into units can be better designed;
2. Detailed test demand is an important indicator for measuring test coverage;
3. The demand for testing includes various test actual development and resources required.
The input of the test plan is the test design of the measurement software. The output is based on the requirements of the testing process; the test process and test case creation can be reused by the design test plan, and maintain the test process, test case and related test needs. correspond.
