A group of classic test ideas

A group of classic test ideas 

 

Tests cannot be exhausted. When the test exit conditions are met, the test can be stopped.
Some test masters say that testing is to discover errors. A good test is to discover errors that have not been found before. However, this requirement may make people go to the extreme. In fact, different systems have different quality requirements. For systems with strict quality requirements, it may take a long and comprehensive test to discover defects in the system as much as possible. However, for systems that do not have very strict quality requirements, errors may occur in the system. Therefore, we must pass tests to reduce the number of defects in the system to an acceptable range.
Testing cannot be exhausted, and resources and time are limited. Therefore, when testing, we need to analyze which functions are critical to users. Some types of errors in these functions are unacceptable to users, while some other functions are not, errors can be tolerated. In this way, when testing, we should focus on looking for errors unacceptable to users, rather than searching for errors without any purpose. At the same time, we should define reasonable exit standards for the test, because the test is not exhaustive, and you can always find problems in the system. However, we cannot find these problems endlessly. When the conditions are met, we should stop the test. The quality requirements and resource requirements of the system must be taken into account when setting the test exit conditions. Someone once said: When time and resources are used up, the test will stop. This is the best solution.

 

Testing is a continuous process, not a phase
The traditional waterfall development model defines specialized testing stages, such as unit testing, integration testing, or system testing stages. However, this does not mean that the test is only performed at this time. I have met many projects. In these projects, the understanding of testing is based on the concept of phase. In their thinking, testing starts only when appropriate, and it can end at a certain point. This is a wrong understanding, and it is very dangerous for the quality of the product. Modern testing has evolved into a verification and validation activity throughout the entire development lifecycle. To maximize the benefits, the development and preparation of testing must begin before coding. To ensure the final quality, we must ensure the quality of the development process at each stage of the development process.

 

The test must be scheduled, controlled, and provided with time and resources.
The test is not a random activity. The test must be scheduled and allocated enough time and resources. Testing activities should be controlled, and intermediate products of testing should be reviewed and included in configuration management.
A test plan is a key management function that defines the policies, methods, test environment, test pass or failure criteria used for testing at various levels. The purpose of the test plan is to provide a foundation for organized completion of the test. From a management perspective, a test plan is the most important document because it helps manage test projects. If a test plan is complete and well-thought-out, the execution and analysis of the test will be smooth.
A test plan can be either hierarchical or a general plan, and a test plan is an evolving document. If you do not consider the initial source of the application software (reusable components or implemented components), the software requirement is driven by the test activity. Therefore, the test plan should focus on documented requirements. In addition, the process of supporting testing should be documented to create a repeatable process, which will ensure the quality of the development work products.

 

Testing is not to proveProgramCorrectness
As Mayer said, the purpose of the test is to prove false rather than true. In fact, it is impossible to prove the correctness of the program. A large integrated software system cannot be tested to traverse every path. Even if all the paths are traversed, the error may still be hidden. We conduct tests to discover errors as much as possible. Therefore, the test must contain a series of test levels. These test levels maximize the coverage of the tested objects.
There must be some criteria that can be used to average all test activities. All tests that can track requirements can be executed in three ways:
Valid information under normal data traffic;
Use excessive data input rate in a control environment;
Use a pre-planned combination of normal and abnormal data;
The ideal testing environment should be able to make a system damaged in a controllable manner. For example, data and data combinations must constantly change until the system cannot accept them normally. Points where system support becomes unacceptable must be validated and documented.
Tests must be run at all test levels and both normal and abnormal conditions are used. This is very strict, even if the test environment is difficult to establish.

 

Early and frequent tests
An important philosophy of modern testing requires testing as early as possible, as frequently as possible, and as much feedback as possible from development. This includes preparing tests as early as possible, and reviewing, reading, unit testing, prototype evaluation, early simulation, and so on with developers. Early testing aims to discover any unexpected bad messages as early as possible and help developers generate high-quality units.
This method is intended to detect and correct defects when they occur. It assumes that problems found during early testing can be described and corrected in a timely manner. Many project managers delayed bug fixes until developers have completed the design and coding of all features. This greatly increases the possibility of system errors and the modification cost. Generally, it is more effective to design and encode a feature at a time and ensure its correctness.
Why should we discover and correct defects as soon as possible? This is mainly due to the following reasons:
1. The defect modification cost will increase sharply with the passage of the phase. After the product is released, the cost of fixing a defect will be 100 times or higher than that of the demand phase;
2. defects are magnified. A delay of several weeks or even months for defect modification will make the system more prone to errors;
3. Design judgment and smallCodeRestrictions and conditions are easily forgotten;
4. Fixing defects as soon as possible can save time for re-analysis and design;
5. Early feedback helps prevent similar errors;
6. A large amount of defect and problem tracking work will be mitigated;
7. If necessary, you can re-design and code the job, and the job will be more and more impossible in the future.

 

Tests should not only contain functional verification, but also non-functional verification.
At present, many companies only conduct tests in functional areas. This may have an impact on the progress of the product. On the other hand, the tester's understanding of the test is still quite limited. From the user's perspective, in addition to functional requirements, it also includes non-functional requirements. Some non-functional requirements may be explicit, while some non-functional requirements are implicit. During the test, we should pay attention to all the requirements. while verifying the functions, we also need to verify the performance, reliability, stability, maintainability, security, operability, and installability of the product. The defects of a product are often generated at the boundary of its performance. If we ignore this part of the test, many defects will be missed into the user's hands.

This article is shared with you at http://www.cnblogs.com/itest/archive/2008/06/30/1232557.html!