随着产品的不断进步，对测试的要求也越来越高，既需要快速迭代，又要保证版本质量不下降，不得不说这是测试的一个痛点。解决这个问题的方法就是用有限的精力去完成最重要的事情。TestBird 的自动化测试在效率提高上的作用无需多言，在工具的优化同时，我们也一直在思考是否可以更加准确的从用例上去寻找突破点。经过不断的实践，我发现精准测试的基石就是用例精简。
从增量阶段、FT 集成阶段、主线集成阶段到上线前阶段，用例数都决定着测试的效率。我认为用例是需要精简和变得精准的，只有这样才能够以最高的效率为项目组争取更多的时间。
那么，怎么既能做到用例精简不冗余，又能把控到用户的主要路径呢？
下面来讲讲统计点在这上面的作用:
1、统计点介绍篇
提到统计点的含义，一句话概括：统计点是为了统计用户的一些行为操作预埋下的点。
下面就总结一下，为什么统计点适合作为用例的映射呢？
1．1 点越多，越能反映用户真实操作
统计用户行为预埋下的点，只要用户点击的多，换句话就是用户在这里操作的多，按照统计点的排序大致可以敲定一部分用例的大致内容。之前挑选阶段用例是凭借自己对用户的感知来挑选，现在可是依靠了数据支撑，排除了主观影响。
1．2 每个模块的版本统计点数据趋于稳定
基本上，除非版本新增内容的统计点数据不太好评估，旧功能的统计点数据一直都是趋于稳定的，产品们对统计点的埋点也是采用漏斗模型分布，层层过滤；用户使用次数的数据稳健并且有迹可循，测试路径非常的清晰明朗。
1．3 渗透率 = 功能点击人数/用户
说了那么多，统计点有比较多指标数据，选取哪一个指标来作排序呢？我选取的是日活跃 - 总用户渗透率，管家用户点击功能的次数/总用户日活的人数。其他的指标有日活跃 - 版本升级用户渗透率、日活跃 - 新增用户渗透率、日活跃 - 老版本用户渗透率等。我比较过这几个渗透率排序，指标差异不会很大，但是从基数的比较上看，总日活比较靠谱，基数大。
1．4 对产品的更深入的闭环，充分利用用户数据
闭环是互联网的重中之重，如何将辛辛苦苦得来的运营数据充分利用，这是一门很深的学问。目前产品生产主要流程是依照：产品->开发->测试->运营->产品。

2、实践篇
我采取了病毒查杀模块作为具体的实践模块，筛选一份上线前用例为例子。病毒查杀之前经过处理，统计点特别的清晰，层层过滤，是最适合做为实践的一个模块。跟产品提取了一份操作类的统计点数据，拿到数据就可以开工了，只需要三步：
Step 1：排序、选取渗透率大于 0.02% 的统计点数据
将操作数据进行日活跃 - 总用户数渗透率进行排序，并挑选大于 0.02% 的渗透率进行筛选，这里为什么选取大于 0.02% 的数据，一方面这渗透率已经算比较低了，一万个用户里面只有两个人点击了这个功能点；另外一方面对于上线前来说，颗粒可以不用特别的大，大于 0.02% 大概有 40 个统计点左右；最后也是最重要的，剩下所有所有的统计点渗透率相加不超过 10%，也就是其实你已经掌控了 90% 的用户行为操作 。
Step 2 ：按照统计点对梳理，大致由哪一些三级模块构成
统计点梳理特别重要，因为梳理的好，几个统计点可以用一条用例就可以进行覆盖。而且梳理操作不用每次都重复，梳理一次，可以受益终 ‘身’，因为统计点渗透率数据每个版本变化都不是很大。
Step 3 : 编写用例，合并用例，切勿点到为止，结合真实场景还原
按照梳理后的病毒查杀统计点内容进行用例编写，尽可能覆盖多个统计点 (如果忘记统计点操作内容，可以询问开发，有时候历史久远，难免会遇到这个问题)。编写用例环节特别重要，真的覆盖到统计点就点到为止么？不，结合真实的实际场景，尽可能的把用户操作还原。例如用户举报统计点，需要假设自己是用户，填写信息资料等。
因为一些失败的统计点已经在 FT 增量模块、FT 集成时候模拟过，上线前不需要太注重这部分内容。
3、收益篇
虽然之前在用例精简过程中已经把病毒查杀模块各个阶段的用例都整理的很清楚，其中上线前仍然有 51 条用例，耗时至少为 2 小时/人，并且覆盖质量不能完全受控。目前按照映射出来的上线前用例为 10 条，大约耗时 20 分钟/人就可以完成上线前测试，并且能覆盖到 90% 的用户行为操作。
总结：
了解到用户的真实路径后，就完全不用质疑是否把控到用户的主要路径了。用户路径表达方式最直接的就是统计点。如果能用大数据统计点来映射用户操作，整整一份精准的用例就不是难事了。