一、背景
手机管家目前有6年多的历史了，一直在持续不断的加入新特性，每次发布前除了新增功能之外，旧的核心功能也是发布之前必须确保的。
1.1当前用例情况
6年的沉淀，虽然每次版本都会用例存档，但是日积月累下来，出现了以下几个问题：
1、新增功能的用例直接添加上去存档，并不会修改优先级，当前版本新增功能中有些路径的优先级是1，2级，但是站在整个版本上来看或许并不是这么重要。
2、旧功能的修改或删减，对已有功能做出修改或者是废弃，用例也是直接归档，并没有对之前的用例修改或删除，虽然用例后面都有写最后需改的版本，但是因为数量太过庞大，想要找到那个点修改也是力不从心。
鉴于以上两点，用例越来越多：
1.2碰到的问题
由于有这么多的用例，每次FT集成，主线集成，上线前都需要多这么多用例，带来了以下3个思考：
1、旧功能测试的时间过长，性价比不高
这些旧功能不是本次版本的重点，值得花多于新功能的时间执行吗？
2、新人学习成本大
功能用例都是外包执行，外包的流动性非常大，如果是一个新人外包，让他在短短的时间内执行这么多用例，数量大且有很多用例不知道怎么执行，需要咨询的时间，这样算起来在计划内的时间根本执行不完，还需要申请资源支持，可是这么做值得吗？
3、外包工作量化
当面对如此庞大的用例时，新人时期可能会一条一条执行，但是熟悉之后，经验会告诉他哪些可以不执行，那么接口人如果按照量级去分配任务，是否不合理呢？
二、精简的收益与目标
鉴于以上分析，用例精简值得做，且会有很大收益.
2.1预期获得的收益
1、缩短测试时间：
可以减少FT集成，主线集成，上线前的测试时间。
2、减少新人学习成本：
只保留最“精“的用例，去除不必要的用例，划分清晰的模块，利于新人学习和执行。
3、外包工作量化：
做到外包实际做的和接口人预估的符合，不会有太大的水分。
2.2精简的目标
1.集成阶段的用例缩减至少50%，执行时间缩减为0.5d，包括FT集成，主线集成。
2.上线前用例缩减到100以内，执行时间缩减为1h，包括定位问题的时间。
3.解决的思路
知道了精简的必要性之后，思考要怎么去执行，时间+成本最小的做法，我认为如下：
1.充分利用经验，把经验转化为可见的东西，即运用集体智慧
第一轮：人工筛选，由于是要善于利用外包同学的经验
力度：粗，不必要太精细，每个模块的要大胆删除
2.工具辅助：代码覆盖率+知识库
通过工具辅助来补充人工的不足和冗余
完善整个模块的知识库，便于后续利用
方法：
经验沉淀＋代码覆盖率＋知识库
精准测试之精简之执行，收益与维护
1 改造用例
了解实现原理，将用例按照代码实现方式来分类，比如手机管家。
1.1代码实现方式：插件
1.2划分功能用例功能模块
尽量完全独立，与其他功能模块少交互，这样才有利于第三部的划分，有耦合的也没有问题，只是相对应的插件会更多，见第三点
1.3理清功能模块与插件的关系
1、一般一个插件是一个主要的功能模块，这是最理想的状态
2、事实是，大部分的插件也会遵循一个插件是一个主要的功能模块，但是为了减少代码量或是其他原因，有时候会做一些移动，把某些的代码放到其他名字看上去完全不相关的插件里
3、要做的就是把上述2点，哪个功能模块的实现分别在哪几个插件中的对应关系整理清楚
1.4修改功能用例的模块
按照第三点都把功能用例对应的功能写清楚，基本全部能够直接对应到插件，这样后面的执行有利于筛选
2.分配功能模块的优先级
按照功能的重要性，分配每个功能模块的优先级，功能复杂的模块用时会多些，最后按照优先级以及耗时制定计划。制定计划清晰又有每个阶段应该做什么怎么做，避免浪费时间。
用例与计划都准备好之后，就可以开始精简之路了。
三、开始精简
精简方法：经验沉淀＋代码覆盖率＋知识库
采用先减后加，放开胆子去删的思路
覆盖率采用方法覆盖，工具为emma的二次开发工具—代码覆盖率平台
3.11级用例删减
1级用例的删减，采用采供过滤的方式，后面再查缺补漏即可。
1、1级用例中与当前版本不符的用例降级
分析这些用例应该是2级还是3级，确定之后标注好，这里尤其要注意那些历史问题，这一步完全可以让外包同学做，接口人review就好。
2、执行用例，查看代码覆盖率
此时一般都在50%左右，因为主路径基本都已涵盖
需要注意的是，这2步做完还不需要具体去分析没有覆盖到的代码，毕竟1级用例的占比不会太多，为了能够减少工作量，下文会提到什么时候才是合适的时机去分析没有覆盖到的代码。
3.22级用例删减
现在开始进行2级用例的删减，一般来说2级用例是量最大的，1级和3级用例都只占一小部分而已，所以最大的工作量在这里。
1、人工删减
人工删减2级用例要做到大胆的删，原则是只留属于主路径和重要的异常路径，其他全部降为3级
2、执行，查看代码覆盖率
这时代码覆盖率一般都在70%左右，接下来要开始分析代码了。
小tips：我做了8个插件，最后得出我认为最快捷的方式，举例为java代码，分析路径package-class-method。
3.3.1第一步的目标
消除所有0%的package，即每个class的method覆盖不为0，一般最多2次
找出所有0%的package分析，可以自己走读代码，也可以咨询相应对模块的开发，为了省时，我在开始精简代码开始之前已经找过开发负责人，每个插件都有对应的开发负责人接口。
1、查看package下的每个class，分析百分之0的原因，确认这个package的作用，有以下三种操作
a)冗余
b)忽略
例如：数据库升级
覆盖安装及对应的读写数据库
其他完全不相关的插件调用使用的
c)确认遗漏的，补充package和class的知识库，添加模块相应注释
2、根据注释补充用例，并确定优先级
3、执行，检查覆盖率是否还有0%
a)还有为0的要分析为什么之前补充的用例没有覆盖到？
注释有误，修改用例，接着重新执行
模块已废弃不用，路径跑不到，因为历史遗留代码的问题，开发对于代码的反应一般都是害怕错删，标注冗余
这一轮一般做2轮左右就ok了，如果执行的时候大于2轮，那要好好思考下第三点所提到的没覆盖的原因，是否是需要提高注释的质量等。
3.3.2第二步的目标
全部的package覆盖率达到50%以上，即每个class的method覆盖大于等于50%，次数在3次以内
1、package，根据覆盖率分为2类，大于50%，小于50%
1)小于50%的package，按照从小到大的顺序排序划分
再将每个package中的class的method覆盖小于50%的的class按照从小打到的顺序划分
分析class下method覆盖为0的，具体分析方式跟package为0%一致详见3.2.2.1
分析class下method覆盖小于50%的
做完3.2.2.1和3.2.2.2描述的2步，一般覆盖率就达到了80%左右。
3.3.3第三步的目标
每个class的method覆盖于大于等于90%左右，一般要5次左右
这个过程是整个流程中耗时最长，但增加最少的阶段，因为牵扯到细节，所以要耐心，全局查看method覆盖从小到大的class挨个分析。整个过程最好保留基线和已上传的ec，一直更新EC，再查看。
3.3.4第四步的目标
人工审核，查缺补漏
覆盖率只是个数据，并且是辅助工具，如何做到上线前的，主线集成的用例够精简且不会遗漏，精简后还需要再人工审核一遍，我的具体做法是：
1、主路径：
打开app，按照插件来检查每个模块的用例，app中能看到的所有入口必须涵盖在1级用例中。
2、用户常用场景：
将用户常用场景按照模块列出来，对照相对应的用例，1,2级用例必须全部涵盖。
3、运用集体智慧：
人的经验转换，一起共同测试的同学聚在一起，按照模块一起review用例，觉得哪里有遗漏，按照经验什么地方经常出问题，是否需要增加用例，PK之后觉得合理的加入。
4、线上缺陷&线上反馈：
版本发布后，根据线上缺陷&线上反馈来检查，是否是测试用例遗漏造成的，分析线上缺陷的根因，根据严重等级和用户反馈数来决定是否要添加用例，以及应该添加到哪个阶段最合适。
四、精简收益
1.用例精简效果，远大于目标
2.测试时间，精简之后的用例，历经2个版本，集成时间在0.5内，上线前时间2h。
五、后期验证与维护
1.维护：
（与当前版本不符的1级用例，即历史某个版本的1级用例，尤其是本次新添加的用例）规避：每次版本结束后归档时，新增内容优先级修改，FT集成，主线集成，上线前的用例明确，不要再留有历史1级用例
2.验证：
主线集成，上线前，灰度，线上bug跟进，看是否有bug是因为精简用例而造成的缺失，分析并查缺补漏，目前已经历了3个大版本，截止目前为止只有灰度期间发现的1个一般问题，补充上线前用例1条。
