Original article published on 20:49:49
In the previous article, I briefly introduced someTestMost of the tools related to coverage are not used by the author, So I simply searched the relevant information from the Internet and sorted it out. For details about the previous article, see test coverage rate 4-Test Coverage Rate tool summary.
This article mainly discusses howImprove test coverage. In fact, the most basic or even the only way to improve test coverage is to increase test cases. But how can we "quickly" improve our test coverage by adding test cases?
Code LookupUnfamiliar code makes our code coverage slow. We need to know how many conditional branches and loops exist in the code, branches and loops have always been the cause of low code coverage. In addition, are there outdated code, there may be some dead code that has not been referenced in the code that has not run the code monitoring tool, in particular, code lookup for modules with low coverage will help you increase relevant use cases and increase code coverage.
ToolsThis is not to say that some tools can help you directly increase code coverage. At least I have never seen such tools. The tools mentioned here mainly include two types. One is the code analysis tool and the other is the code coverage tool mentioned in the previous article. Code analysis tools can help us analyze the redundant parts of the Code, which can help us to eliminate dead functions that are always impossible to overwrite. Some compilers already provide similar functions. Using the code coverage tool can help us quickly monitor low code coverage, so that we can quickly locate the weak links of our tests, through code lookup orOthersYou can quickly add use cases. Generally, the time required to increase the code coverage of a module from 30% to 50% is far less than the time required to increase from 60% to 80%.
RulesThe rules mentioned here refer to some basic test methods, such as equivalence classification and Boundary Value Analysis. Sometimes we need to use these methods to check the test cases that we have not considered one by one, so as to help us increase the relevant test cases.
ExperienceThis seems a bit nonsense, because we generally know that the rich experience in testing helps design test cases and write test cases that others don't think. The main purpose I put forward this sentence here is to tell everyone to pay attention to the daily accumulation. In some cases, the current aura may become an important use case in the future. Previous failed lessons can also help us to learn from them. After all, "experience is synonymous with their mistakes ".
Note:One thing I want to remind you again: the unilateral improvement of test coverage does not effectively help improve the test quality, especially when the code quality is poor. Taking a typical triangle test case as an example, the developer's code may only determine that "the sum of the two sides is greater than the third side" and then return "this is a triangle ". In test cases, we may have considered many problems, such as the type and validity of input data. However, this does not help increase the test coverage rate. The results of running these tests are red. Remember that it is meaningless to consider test coverage when your test cases fail. I have two reasons: first, these test cases may have problems in the middle of the Code. Therefore, the use cases should have been overwritten by the statements, which reduces the code coverage; the second reason is that the test case fails. It may be the same as the triangle problem just mentioned. Developers do not have so many statements to overwrite, at this time, the code coverage data obviously has little effect. This also confirms that "high code coverage is more useless than low code coverage" mentioned in the previous article '".
Here, my point of view has been expressed. This series of articles can also be completed. Of course, we also have some important "tail"-test coverage tools. As mentioned in yesterday's articleLearningI am not sure about using some tools and organizing relevant materials, but I am afraid it will take some time to get started.
Test Coverage in the series of articles are the author's personal opinion, if you have any questions or suggestions please contact unique.wuchaodong@hotmail.com or leave a message directly.