有关测试的业务及代码覆盖率分析

   做了这么多年的自动化测试，一直没有一个非常清晰的自动化覆盖，同时曾对自动化对业务场景（用例）、bug等的覆盖做过相关的分析，但由于庞大的业务系统不支持我们将所有的测试细化成小粒度测试用例的级别（不是不可以做，只是考虑资源及系统现状)、且测试用例难于穷尽（重点、非重点）、目前系统所处的阶段分析等考虑对已有bug的覆盖价值不大等等，导致分析一直处于一个挺尴尬的局面，当大家问起时，只能先给一个基准，比如基于模块的覆盖情况、基于界面控件覆盖情况、基于算法的覆盖情况等，由于统计对业务逻辑关系的覆盖情况依赖于我们的测试用例设计的成熟度，所以一直是在变的。

   以上说的都是自动化测试对于测试或业务本身的覆盖情况，即使做了以上分析，领导们或者部分开发人员仍然会问：你的测试对我们的代码覆盖情况如何,到了客户那里还可能出现其他的问题吗？所以上周采用AQtime对开发的代码进行了一些分析，工具具体的应用方法大家可以查到很多的学习资料，这里不强调，对于工具使用本身，只简单分享几个要注意的点：
（1）小心当你的代码或测试时间太长时，日志文件搞到AQtime崩溃
（2）将代码进行分类，分角度分别进行代码覆盖分析，比如或者户端代码、公共代码、不同服务端代码，或者其他不同功能代码，不然统计出来的结果价值不大，鉴于AQtime工具本身的性能问题，这点又额外显得更为重要
（3）不要对代码覆盖寄予过多期望，因为我们只能从行、类、函数等方面进行覆盖分析，但可能一行代码包含多个测试点，也可能多行代码包含一个测试点，所以要结合业务、用例覆盖一起分析，另外说下我们做代码覆盖分析的意义，
1、我们组的自动化每天都在跑，究竟覆盖了哪些代码，哪些代码还没有覆盖到？有了自动化代码覆盖分析，可以做到开发人员心里有底
2、指出未覆盖部分，然后测试人员与开发人员沟通后重点测试
3、参考：估计修改已有代码所需的时间：经过测试的代码更容易重构、维护和增强，知道代码有没有被测试，并看看实际的测试覆盖数值，可以让开发人员和管理人员更准确地预知修改已有代码所需的时间