精简后的覆盖率测试-经济日报
发表时间：2023-11-26 13:02:54
文章来源：炫佑科技
浏览次数：141
菏泽炫佑科技
精简后的覆盖率测试-经济日报
时间：73个用例一般需要1天/人执行，大大提高了效率。
4. 用例简化效果的粗略验证
这里只提到粗略验证，因为我们认为验证用例简化有效性的方法有两种：功能点检查和全覆盖结果。 功能点的完善可以通过内部和外部评审来实现，但比较耗时。 通过标记新旧用例的对应关系，我们确保不会遗漏精简后的用例所覆盖的功能点。
全覆盖验证主要使用同版本测试包对精简前后的用例进行覆盖测试。 目前，覆盖测试包括行覆盖、方法覆盖和块覆盖。 行覆盖比方法覆盖具有更高的准确性。 虽然不是100%准确，但可以作为基本的测量标准。 因此自动化软件开发，我们提取了一些简化的用例进行覆盖。 率测试。
5. 准确的测试计划和实践
如上所述，用例简化是准确测试的基础之一。 因此，在简化用例之后，我们还进行了精确的测试。
练习练习。
精准测试的本质是当代码发生变更时，用更少的用例覆盖变更涉及的功能点，从而提高测试效率。
从代码变更到用例选择，这自然引出了一个问题，那就是当代码发生变更时，如何快速找到对应的测试用例。 目前有两种方法可以解决这个问题。 一是通过阅读代码来梳理软件架构。 该方法的输出是代码文件和功能逻辑之间的对应关系。 当代码发生变化时，找到相应的功能逻辑来选择需要执行的用例。 这个想法是一次性投资，可以获得长期效益，但比较耗时，需要考验学生。 代码功力比较强，需要开发同学的帮助； 另一种是执行某个功能模块用例集时输出代码日志。 从代码日志中也可以找到功能模块的对应关系。 这个方案对于测试同学的代码非常有用。 能力要求不高，比较适合外包学员执行，但也比较耗时，需要不断维护对应的关系数据库。
同时，识别版本之间的变化有两种思路。 一是查看SVN日志，然后从日志的详细代码中识别变更逻辑，找到对应的应用示例； 另一种是使用SVN diff直接识别版本之间的变化。 SVN diff 用于获取代码变化； 这两种方法的思路类似，都是利用SVN来查找版本之间的差异。 然而，与SVN日志相比，SVN diff结果没有那么直观，只能看到差异，而不一定能看到差异前后的代码。 只有零散的增删改查，没有整体的概念。 这是因为SVN diff结果只会回溯7行增删改查的代码。 例如，很难看出以下更改的代码在哪里。 哪个功能点发生了变化：
我们的解决方案与上述两种思路并不完全相同，但也是采用了SVN diff作为技术基础。 SVN diff结果需要重新处理。 我们采用类似的迭代思路逐步细化，即当我们开始选择用例时，我们将经验建立在它的基础上。 尝试尽可能的找到对应的用例集，并在执行结束时，根据本轮的覆盖率来决定是否需要选择较小的用例集。 这种想法比提前阅读所有代码并使用日志解决方案更加敏捷，并且不需要详细了解软件代码。 如果结合开发同学的讲解，效率会更高，对架构的理解也会更深。
在给出具体做法之前，我先补充一下精准测试的背景：作为测试人员，你在版本测试的时候是否经常收到开发人员的消息，即开发人员说某个功能没有大的改动，简单的就可以了之后就可以了，但是就这么一句话，测试人员可能会忙上半天。 具体改变了什么？ “简单生活”到底能走多远？ 这些都是令人头疼的事情。 例如，手机管家 5.1 版中的广告拦截功能发生了变化。 开发者的测试建议如下：
除了**点关于广告拦截之外，其他变化都集中在第四点。 听到这样一句话，你是不是就释然了呢？ 作为测试人员，我们需要有怀疑精神精简后的覆盖率测试-经济日报，所以如果我们想要保证质量，不做无用功，就必须考虑准确的测试。
我们做了一个比较粗略的展示系统，可以实现我们“迭代思路逐步完善”的思路：
1. 分析版本之间的变化
改变内容的基础是SVN diff，但是由于SVN diff的原始结果并不直观，所以我们需要对结果进行解析和处理。 处理后，可以在源代码中用不同的颜色标记更改的内容，而不是直接使用 SVN diff 结果。
初步结果报告覆盖率基本为0：
2. 根据源代码的变更情况，确定变更的大致模块，并选择本轮的用例。
根据代码改动（快速的方法是找开发同学一起查看改动），我们可以知道5.1和5.0版本之间广告拦截的主要功能变化如下：
1）检测系统通知栏中的新消息
2) 调用临时root失败
3）清除卸载安装包时的通知栏消息；
4）启动通知栏监控；
5）获取广告行为表
6) 修改广告软件配置
7) 广告详情页展示
8）广告页面刷新
由此可以看出，通过查看改动后的代码，可以了解到需要覆盖的测试点。
3、执行本轮用例，利用覆盖执行结果ec文件再次生成用例执行覆盖率。
4. 根据本轮用例的执行覆盖率，决定是否选择下一轮用例。
基于上面对用例的粗选，发现覆盖率还是比较低，所以通过检查具体代码，然后增加测试用例覆盖率，覆盖率逐渐提高：
5、*终完成变更的覆盖，达到准确测试的目的。
*终逐渐选取了50个左右的用例来覆盖两个版本之间的实际代码变化，不再进行盲测。 由于大约 10% 的更改代码是受保护代码，因此 90% 的行覆盖率已经是理想的情况。 同时，随着测试人员逐步分析修改后的代码，大家对广告拦截的代码逻辑有了更加清晰的认识，对发布质量的信心也越来越大。
