快给你的用例做减法吧

01热身：数一数你的用例数

随着互联网时代节奏的日益加快，许多产品都会在版本迭代中对功能做加法，于是累计的测试用例似乎都无可避免地越来越多。从小编自己的经验，作为测试人员，最开始设计测试用例的时候追求做到“全面”，导致我们的用例似乎也不知不觉中在做加法。你有没有思考过一个问题，你的产品总用例究竟有多少？而当下你是否也感受着用例多带来的效率不高的痛点？

不妨坐下来，随小编一起打开这几个版本产品的总用例。

你的用例是否也有以下几个问题中的任意一个：

1、用例量庞大：以笔者的用例为例子，每个版本都有一份该版本的用例以及一份总用例，总用例文件分散，用例数多（总用例数接近2000），无整体清晰视图；

2、可读性差：由于测试人员分工的不断调整，同个模块的用例的维护是经由几轮不同编写风格的迭代，甚至有些用例格式不统一（既有excel又有mm图）；

3、用例优先级不明确：用例优先级是凭经验拍脑袋定的，同时历经几个版本未对旧用例的优先级做调整，导致测试执行时间冗长且部分用例已不是核心内容。

如果你的用例也有上述问题中的任意一个，是时候要开始思索，是不是该重新整理一下用例，是不是该对用例做减法了？如何用科学武装自己，有底气来做减法呢？

接下来请follow小编的脚步，一起对用例做科学的缩减大法。

02 缩减：ACC+统计点齐发力

小编的精简用例，运用了ACC建模法去建立核心模块的能力矩阵图，再根据产品数据埋点上报的排名来确定模块热点图（重要等级），确定测试优先级，最终运用到用例的删减中。

本次用例精简，可以解读为以下几步：

1、 建立能力矩阵图——根据ACC建模思想

注：ACC（Attributes Components Compatibilities）是Google测试团队使用的一种建模方法，是对测试内容进行划分属性（Attributes），部件（Components），组成能力表（Compatibilities），用来快速地建立产品的模型，以指导下一步的测试计划和设计。

ACC的定义与使用可以参考文章：

http://www.cnblogs.com/liangshi/archive/2012/04/23/2465897.html

ACC方法可以让测试人员对整体项目有一个全观的视图， 但是ACC也有一定的局限性——需要和其他的建模方法结合起来使用，也就是对某个模块可以通过ACC确定测试策略，具体测试实施需要依赖其他的建模方法。

小编跟产品同学根据产品策略，确认了当前的几个模块的属性值（即与竞争对手相区别的关键特征），再根据从HTSM的角度确立对应的能力（即产品实现其核心价值的手段），得出以下能力矩阵图：

2、确定热点图，得出测试优先级——根据梳理统计点数据

建立好能力矩阵图后，如何去确定模块的重要程度（矩阵热力图）呢？

以前我们会根据经验来做判断，那么有没有更科学一点的方法？

答案是肯定的，我们可以让用户来告诉我们，什么才是他们关注的，这才是合理的优先级划分的方式。也就是可以通过统计点的上报量来确立对应模块的重要程度。

（1）导出产品的统计点数据，根据模块做归类，根据渗透率做排序。

注： 渗透率 = 功能点击人数/用户数

（2）分析渗透率数据，定出合理的界定标准。

如何根据埋点数据来界定重要程度的标准呢?

小编这边采用的是二八定律（把主要测试精力花在20%模块上），于是选出排名前20%的统计点标为最高优先级，再把剩余80%按照一样的规则分成三层，得出如图的四层结构：

注：统计点从上到下按照渗透率从高到低的排序。

举个例子：假设一个产品总共100个统计点，那么我们将这100个统计点按照从高到低的顺序进行排序为（A1，A2,...,A100），那么可以得到以下的分层关系。  

注：这个划分依据是小编根据二八原则以及产品特点来划分的，统计点个数比接近为1:1:1:2，读者可以根据不同产品情况灵活调整。

（3）根据界定标准，完善能力矩阵的热点图，区分测试优先级。

据以上三个步骤所述，小编得到的最终的产品能力矩阵热点图如下，此时我们已对产品的重点模块已有了比较清晰的了解：

3、精简对应用例—根据能力矩阵热点图

走到这一步，终于可以开始进行用例精简了。那么问题来了，得到这张能力矩阵热力图之后，如何运用到用例精简中呢？

（1）对用例做预处理

为了方便下一步能痛快做用例精简，预处理测试用例是必要的。预处理主要是做以下几步工作：

① 统一用例格式与风格：如统一为思维导图或excel的形式；

② 合并测试路径：把操作与结果分开写的用例合并为完整的测试路径（如下图1），或者把可组合的场景的用例组合起来（运用场景组合如图2、正交法、最大路径组合等方式），减少用例的分支扩散；

  图1 操作与结果合并

 图2 场景组合

 ③ 去掉功能无关、已过时的需求对应的用例，确保当下用例为最新。

（2）对用例做二次处理

小编的用例精简二次处理，是采用与功能点重要程度强关联的原则（详见下图）。

在热力图为低优先级的功能点，采用只保留功能可用性相关的用例且优先级置低的方法。因为在整个产品功能里面，若一个功能重要程度较低却写了很多用例，那么我们需要反思一下是不是测试策略定位有问题。也就是说，功能的重要性占比小，那么对应的用例肯定少，同时测试执行优先级也不会很高。

在热力图为高优先级的功能点，会把统计点涉及的场景对应的用例标注较高优先级，其余异常或复杂路径按情况定义不同优先级来保留的方式，只删除无关或废弃或过于复杂的用例。一来是因为高优先级的功能点不会太多（根据之前所述的二八原则），二来是因为重要性高，用例保留得多可以方便对整体功能的把握。

03 精简用例的收益

经历了一场轰轰烈烈的精简后，小编这边也简单总结下缩减大法带来的收益：

1、整体用例数据

2、执行策略优化（发挥优先级的作用）

3、用例格式统一管理

格式统一为mm图，且模块重要性标注了颜色来区分，每个用例只有1个优先级，优先级按照第二点用例处理原则所述进行标识。

4、执行效率与质量

根据2.0两次灰度版本验证，得出如下数据：

有理论有实际、有科学有底气，既能对用例来次大裁剪，又能对产品逻辑有个整体的梳理和重点的把握。看到这里，你是否动心了？快给你的用例做减法吧。

04 读者互动环节

你在项目迭代间是如何管理测试用例的？是否有什么痛点？有尝试过哪些精简用例的方法呢？