精准测试之项目案例实战大剖析（中）

threadingtest

[size=18.6667px]精准测试之项目案例实战大剖析（中）八、      测试用例执行与分析1.   测试用例执行分析

测试用例总数：136

执行测试用例：129

缺陷数目：60

测试用例通过率：67%

根据测试用例的执行来了解测试人员工作量和工作效率，以及整个测试的最终大概结果，通过率以及完成度，管理人员能够随时根据实际情况做出进度和工作上的安排调整，更好的管理团队和监督整个产品的测试进度。

2.   缺陷分类：

BUG类型	代码错误			标准规范			其他
程度	严重	中等	普通	严重	中等	普通	严重	中等	普通
BUG数目	40	3	0	2	5	3	0	2	3

根据BUG分类和严重程度的数据课判断该版本的整体质量，若是严重的BUG占比太高，则可能根据项目需要是否打回开发重新测试后再交于测试进行测试，保证不会有太多的流程上的缺陷，导致测试工作停滞不前，影响版本发布的实际时间。

3.   测试用例与缺陷的情况：

通过星云测试测试过程监控趋势图，我们分析清晰地看到，项目九点钟在这几天的测试中的BUG发现情况，并通过测试用例执行得日期与BUG提交日期以及描述判断出，具有大量BUG的模块。如9点钟在2015-12-7号的时候做了很多测试用例以及提交了不少的BUG。

通过直观的曲线绘制图能够看到一周内或截至目前为止整个测试工作期间BUG的发现率和测试用例的执行情况，测试人员的参与人数，根据实际要求进行管理和调整。

我们查看详细信息的描述

BUG的详细列表显示的是所有发现的BUG以及每个BUG对应的提交人员和出现的测试环境以及对应的测试用例，都有利于我们判断BUG出现的主要因素和修复的方法，便于开发去修复并且也会考虑到同类环境下的兼容情况。

如：可以看出2015-15-7我们测试的重点主要在优惠卷、订单、支付等领域模块，在这个模块中出现不少的友好度或者操作上的问题，测试人员就可以拿此数据和开发进行交互，要求对这些模块进行总计修改。

九、      测试覆盖率与漏洞分析

按需求文档以及功能说明书设计并进行测试运行，通过星云测试查看出每日覆盖率增长趋势

在这几天的测试中，测试人员虽然遍历了完整的流程，但是覆盖率一直不高，段覆盖率才41.1针对这种情况，我们通过漏洞分析进行查找原因。

首先我们通过星云报表找出复杂度高密度以及覆盖率0，这些都是测试漏洞，风险较高的遗漏点，若不逐一解决，后期上线后产生的问题造成的影响可能是相对比较严重地，为了避免这一现象的产生，我们必须把这些毒素攻克掉。这时，如果测试人员不懂代码可以邀请开发进行协助查看，通过可视化界面查看该函数的代码。

如1：函数ID 1465 handleMessage 通过代码可视化和开发交流得知，此模块为处理列表的上拉下拉的事件，但是在最新的九点钟项目中已经不在使用，这就造成了测试人员无法遍历到该模块的原因，对于这些废代码，测试人员有义务要求开发对其注释掉，或者进行删除处理，这样使得后期对代码的维护有了保障。

如2：函数ID 1880 isrefreshview scroll通过代码可视化和开发交流得知，此模块为优惠卷拉升加载功能，但是此功能需要优惠卷超过一定量后才会出现，但是实际测试中，测试人员只得到了一张优惠卷的账号，在遍历中自然无法覆盖到该功能。

如3：函数ID 1530 zoom通过代码可视化和开发交流得知，此模块为主界面地图功能，覆盖率不高的原因是：

该函数主要针对地图的比例进行不同的比例值选择，地图调节的情况，但是在九点钟中的地图是调用百度地图，如果要全部覆盖，需要后台对其代码进行相应的改动模拟。此状况主要针对核心功能的测试，测试人员需要预判该模块是否需要各种后台状态的处理测试，并和开发交互后进行配合性覆盖率提升。

如4：函数ID 1449 onClick通过代码可视化和开发交流得知，此模块为酒店评论功能， 根据可视化分析

        

查到因为没有测试到酒店评论中评的情况，所以没有覆盖到，执行次数是0，需要设计用例，酒店评论中评的情况，提高测试的覆盖率，保证没有严重的测试漏洞