前言

在测试的过程中，你是否会有下面的几个烦恼？嗯，反正我有 。既然有烦恼，我们就应该解决它，今天就来分享一下一个测试策略的思路，帮助解决下面的问题

1. 用例的精简
2. 发版前checklist的优化
3. 版本发布太多，覆盖测试怎么办
4. 机型太多？兼容性很难测
5. 自动化主功能覆盖的依据
6. 专项测试的依据(性能、专项、压力).如何应对快速发版的压力
7. 如何最准确模拟用户环境和行为进行测试，完善测试点呢

上报数据的分类和提取

用户上报这个是产品运营同学研究产品走向的一个平台，我们的项目集成了umeng上报平台，我们对此的测试的功能保障只要求

1. 统计点符合需求
2. 准确上报到平台

那么这些数据对产品运营是很有意义，研究用户的习惯就是研究产品的走向。那么同理，对测试是否也是具有意义呢，首先我们看下上报给我们提供什么样的有用信息。

那么下面这幅图是笔者整理的umeng上提供给我们的导图，可以看到上报系统提供给我们非常丰富的功能。

虽然选项很多，但是我们还是需要经过一层过滤，找出对我们测试有用的一些数据类型，那么经过思考和整理之后，画了一个excel的表格

所以其实就分成三大类，功能、习惯和环境，接下来的工作就是从这些数据中得到我们制定测试策略的科学依据。

接下来的工作，就是挨个分析，到底上报的数据能和我们测试檫出怎样的火花呢?

功能使用篇:

这个可以说是重点吧，因为这是测试上报数据的时候最直观看到的对象，通过统计的自定义事件，可以知道用户对新旧功能的使用情况。

上述列出来的是demo数据，根据消息数排个序，那么可以看出用户使用次数最多的模块，以及模块中使用最多的功能，知道了这个，你可以：
1.评估用例的优先级，然后精简用例
2.有紧急上线的任务，不用过全部的用例也能让你心里有底
3.写自动化脚本/做性能测试的时候可以有侧重点
比如笔者根据上面的数据，测试的重点模块变成了拍摄页、播放页，同时这两个模块变化不会很大，可以考虑通过自动化去覆盖一些用例。

环境篇：

机型覆盖

创业公司有个难点，自购手机成本太大，所以一般采用云测真机解决，但是云测出现问题的时候我们不好排查，所以个别使用率高的手机还是需要购入的，这时候根据上报的机型，合理分配采购列表，达到缩减成本提高覆盖率的目的。

版本列表

相信大家都测试过覆盖安装，当项目版本越来越多的时候，覆盖成了一个难题，通过上报的app版本分布，可以指导我们执行数据覆盖的时候，哪些是不用覆盖的，哪些是需要重点覆盖的，重点覆盖是否需要多覆盖几个重要页面

网络和运营商
这块可以作为用例提高覆盖率的依据，比如下面这张是笔者从umeng上导出的网络分布图

这个图可以告诉我们，wifi启动和4g启动占了96%左右，平时测试的时候请切换到这种环境执行，3g/2g/无网络在进行网络测试的时候也需要覆盖

地域

我们作为一个多国语言用户，除了中国外，美国日本泰国占比最大，意味着测试的时候不能都用中文界面去测试，而是重点切换这个几个国家的语言，避免文案或者UI问题。
同时，这个曲线图我们还需要关心接口访问速度的问题，因为我们是租用阿里云的海外节点，这点我们就可以略过了。

用户习惯篇：

时段详情

这个指标的意思是一天中每个时间段的用户日活

那么图中的数据我们知道了用户活跃时间段的分布主要是下午到晚上这一时间段，这个数据影响的是后台数据的使用，知道了这个，我们就要避免在用户使用高峰上线后台的新特性，避免接口不稳定的现象发生
同时在该时间段也需要做好接口的监控，可以考虑调整持续集成的执行策略。

使用时长/使用频率

上面两幅图，第一副是使用时长，第二个是使用频率，那么可以看出我们的应用是单次使用时间1~10分钟，每天使用1~2次占大多数，从这个特性来看我们的用户是快使用，也就是打开app，使用某个功能，然后关闭，这个快使用我们可以结合具体的事件上报进行分析，在这条路径为了保持良好的体验，需要重点测试模块跳转的流畅度，这个路径也可以纳入主功能用例当中去。此处上报数据重点是提升用户体验。

使用间隔/访问页面

这是umeng新加的东西，这个目前没想到什么运用的地方，但是总感觉很有用，有说不出来，以后想到再写吧 [��]

两个小例子

下面是一个用例执行策略变更的小例子
(滤镜的使用)(分享的使用)
例子1：
提高兼容性测试的效率
公司采购了一大批手机，每次测试新功能都需要测试一堆手机，除了保留android系统版本，手机厂商版本覆盖外，引入了上报机型分布作为指导，用户量使用top5的机型，作为提供给开发和测试同学的常用测试手机，这样测试的时候，就可以减低了测试时间，同时，还能保证大部分用户使用的机型不出问题(开发测试阶段就解决了).

例子2：
我们项目拍摄页功能非常丰富，除了支持美颜滤镜，也支持调节ISO、EV、SHUTTER、白平衡等参数，每次发版都要过这些功能非常费劲，重复劳动太多。笔者选取了上报的相关数据，进行用例优化。
根据上报用户使用参数的情况来看，我把要验证的参数进行优先级标识p1、p2、p3,下面是一个定时拍照打上优先级后的效果，1级最重要，2级有用户使用，但是不多，3级为基本没有用户使用。

有了前面的标号之后，基本没有用户使用的用例可以不执行，只有大版本或者周期性执行。而2级，用户量比较少，可以抽取一些执行，1级肯定是需要发版本前都要执行的，执行分类之后，发版的成本自然会减少许多。

总结

通过上报数据，作为测试的反馈，并影响我们测试策略的指定，达到事半功倍的效果，让我们设计出更加合理的测试用例。