Because we never want to detect all possible inputs, paths, and statuses of the tested system during testing, what should we choose? When should I stop the test? When should I suspend the test? How can I compile a test package? It can detect a combination of enough messages and statuses to indicate that there are no failed operations, but it is small enough in practicality?
The test raised many basic but confusing challenges and involved several practical software testing trainings with these questions.
The complexity of software leads to the complexity of testing, so we cannot expect training to provide us with practical guidance in a lot of work. The emphasis on theory is positive, but it is not meaningless. Although the theory can also be obtained from relevant literature.
I have some experiences, which are scattered, recorded, and communicated with you. 1. The goal of a software tester is to identify Software defects as early as possible and ensure they are disabled. After careful consideration, I think this goal contains three meanings.
1. The basic goal of the software tester is to discover Software defects.
This seems self-evident, but it is necessary to emphasize it again. Because sometimes the development team only needs testers to verify that the software can run, rather than looking for defects. In this case, testers lack the spirit and enthusiasm for discovering defects. Therefore, the primary condition for testing is to clarify that the basic goal of the software tester is to discover Software defects.
2. The software tester seeks to identify Software defects as early as possible.
Because software repair costs will increase by dozens of times over time, software testers should identify Software defects as early as possible. For large-sized software, there should be tests immediately after software development. If testing is started only after the product has been developed, it is very likely to cause a lot of time-consuming and labor-intensive rework. How can we identify defects as early as possible? Theoretically, there are some testing methods: static black box testing, dynamic black box testing, static white box testing, dynamic white box testing, configuration testing, compatibility testing, usability testing ......, How to use these methods to discover Software defects as soon as possible requires constant exploration and summarization in work practices to continuously improve testing capabilities. For the company's situation, if the software scale is not very large, it may be appropriate for developers to complete the testing work in development.
3. Software testers must ensure that the software defects identified are disabled.
Not every software defect must be repaired. The reason may be that there is not enough time, Software defects are not counted as true, and the risk of fixing is too high. The product development team decided not to fix some Software defects. However, testers must ensure that the software defects identified are disabled, that is, once Software defects are registered, they must track their lifecycles and monitor their status, provide necessary information to ensure that it is repaired and disabled. 2. About testware.
There is a very concise and clear definition, software development engineers produce software, software test engineers produce testware. So what content does testware contain? Test Strategy, test plan, test specifications, test procedures, test cases, test reports, test data, test scripts, and defects data. Like software, testware also needs to be well maintained. For example, because the software interface is changed due to the fixing defect, the case and automatic test script must be modified accordingly. 3. test the product manual.
The software product function manual describes the final functions to be implemented. These features are the final customer needs to be met, as well as the capabilities required by the software. In the standardized software development process, the product function specification should be determined prior to the system outline design after user requirements are determined.
As to why the Product Specification should be tested, statistics show that many Software defects are caused by incomplete and frequent changes to the product functional specification. In addition, A feasible test plan can be drawn up only after you have carefully read the product feature documentation and confirmed the features required by the product.
The methods are described as follows.
1. check whether the functions of the product described in the product function manual are complete, accurate, consistent, and reasonable descriptions, and ensure that these functions are testable.
2. Check whether the product specification complies with the existing software design and development standards or specifications.
3. Research similar software to predict the final result of the product.
However, if it is applied to the actual development process, it is difficult. It is difficult for Software testers to participate in the project at the early stage of the project. Generally, software testers are asked to start testing after the prototype of the software is developed. Even in the initial stage, testers participate in the project, and only develop the test plan according to the product instruction and design plan. Testers are not given responsibility to inspect the product manuals. 4. Economic testing.
Testing is a complex task. Therefore, we need to consider its efficiency. There are several principles for economic testing.
1. If one case (x) depends on the other (Y), if y fails, then X may not be tested.
2. For a subset, if an input causes a failure, the remaining input may not be tested.
3. For a case, if a test subset fails, other subsets may not be tested.
As a result, we think of a real problem. All tests should be conducted once by developers according to the process. But if a defect is found at the initial stage of the test, will this round of test continue? If the test is not complete, the test report cannot be generated. Continue to the full test. If the detected defect is a serious defect that must be addressed, the subsequent test will be non-economical, because a comprehensive test is still required after the defect is repaired.
In accordance with the testing principles, the discovery of defects should be promptly reported to developers so as to timely understand the software status. However, in practice, developers often give a repair version immediately after receiving feedback, and then perform another test. The cause is that, by the end of the project, the number of defects found often goes through several rounds of tests, and each round of tests only verifies the repair of a defect.
Therefore, I think there should be good control over when to suspend the test, whether to suspend the test, and when the developer sends a new repair version. 5. Automated Testing
We use rational robot to write an automatic test script for automatic testing. It is mainly used for UI testing with some AP. Because writing SQA basic is costly, it is economical to use it in a slightly complex program or a project that requires multiple rounds of regression testing. If it is a simple UI, for projects that do not require multiple rounds of regression testing, it is necessary to compare the investment in script writing and the cost of implementing automatic testing.
If there are many program changes during multiple rounds of regression testing, it is also a heavy workload to rewrite the script. The above is a little bit of experience, write it down in scattered ways. |
