大数据统计点教你写测试用例

大数据统计点教你写测试用例

随着产品的不断进步，每一个Team对测试的要求越来越高，既需要快速迭代，又要保证版本质量不下降，不得不说这是测试的一个痛点。

从精准测试覆盖率的搭建就可以看出，我们一直为这种问题绞尽脑汁，一直在思考是否可以更加准确的从用例上去寻找突破点。经过不断的实践，我发现精准测试的基石就是用例精简。

从增量阶段、FT集成阶段、主线集成阶段到上线前阶段，用例数都决定着测试的效率。我认为用例是需要精简和变得精准的，只有这样才能够以最高的效率为项目组争取更多的时间。

那么，怎么既能做到用例精简不冗余，又能把控到用户的主要路径呢？此处应有掌声！！走过路过不要错过，只此一家，别无分店，请接着往下看。

总结写在前面：

如果把用户的真实路径告诉你，你还会质疑能否把控到用户的主要路径么？用户路径表达方式最直接最暴力的就是统计点。如果能用大数据统计点来映射用户操作，整整一份精准的用例不就摆在你面前么？

1.统计点介绍

提到统计点的含义，这里就多扯出些统计学各种高大上的货。换句话说，统计点是为了统计用户的一些行为操作预埋下的点。不得不说，为了学习统计点的各个指标，我秉着人人都是产品经理的优良品质跟产品学习了一番。

下面就总结一下，为什么统计点适合作为用例的映射呢？

1．1 点的多，证明用户用的多，能反映用户真实操作

统计用户行为预埋下的点，只要用户点击的多，换句话就是用户在这里操作的多，按照统计点的排序大致可以敲定一部分用例的大致内容。之前挑选阶段用例是凭借自己对用户的感知来挑选，现在可是有杠杠的几百万数据的支撑，特别可靠。

1．2每个模块的版本统计点数据趋于稳定

基本上，除非版本新增内容的统计点数据不太好评估，旧功能的统计点数据一直都是趋于稳定的，产品们对统计点的埋点也是采用漏斗模型分布，层层过滤；用户使用次数的数据稳健并且有迹可循，测试路径非常的清晰明朗。并且提数对产品经理们简直易如反掌，门槛低，提数快，并且数据可重复利用。

1．3渗透率=功能点击人数/用户

说了那么多，统计点有比较多指标数据，选取哪一个指标来作排序呢？我选取的是日活跃-总用户渗透率，管家用户点击功能的次数/总用户日活的人数。其他的指标有日活跃-版本升级用户渗透率、日活跃-新增用户渗透率、日活跃-老版本用户渗透率等。我比较过这几个渗透率排序，指标差异不会很大，但是从基数的比较上看，总日活比较靠谱，基数大。

1．4心里话：对产品的更深入的闭环，充分利用用户数据

闭环是互联网的重中之重，如何将辛辛苦苦得来的运营数据充分利用，这是一门很深的学问。目前产品生产主要流程是依照：产品->开发->测试->运营->产品，如图1.1所示，如果能够把产品数据利用起来，模拟用户真实操作，是实现对产品的更深入的闭环。

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%的用户行为操作，棒棒的有木有！