声明： 本文的测试用例评审优化为原创，后面的测试用例设计方法参考了相关博文。有做总结。

测试用例评审过程优化建议

1. 聚焦：每次用例评审不超过 1 小时，只评审核心内容及测试设计思路，不对具体的每条用例展开评审，实际上这个意义确实不大，只要测试思路没什么问题，大体上也不会有偏差；
2. 事先准备：事先和研发及产品沟通，让他们提前阅读文档。在评审的时候，不需要拉上所有的人，只需要相关人员即可
3. 持续反馈：测试用例并不是一成不变的，哪怕是评审完。不能让测试用例成为一个借口（很多测试人员经常对其它人说为会不在评审的时候提出来，这种做法很不推荐，别人只是帮你 check，而不是让他来替你思考）
4. 给出行动项：需要修改的内容，及时修改并反馈，让大家有参与感，同时表示感谢。
5. 要注意测试用例的颗粒度，在评审时，不需要逐条过，评审测试思路即可。本质上测试用例也是一个测试思维可视化的过程，不应该在评审时去逐条过，不要拉上整个团队
6. 关于评审能给团队带来什么，个人的理解是这是又一次三方对齐需求理解的机会。可以保证大家对同一个需求的理解是一致的，避免更多可能出现的返工浪费。

测试用例设计方法

测试同学在面对复杂的需求时候，往往不得其力，导致测试时间过长，测试的结果也不尽如人意，这往往是对需求理解不到位所导致的。如同武林大会中对战双方使用的兵器，测试在接受到战书之后一样可以选择一样趁手的武器，而对于我们测试来说，我们在这场战斗中使用的武器，就是建模。

然而软剑不敌巨斧，短匕难撼长枪。建模方法种类繁多，功能各样：

• 从结构上来说，有类图，E-R图，组件图；
• 从功能上来说，有用例图，因果图，决策表；
• 从行为上来说，有活动图，状态图，序列图；

如何挑选一件合适趁手的武器，迎接接下来的战斗，就是我们测试在每个迭代中都需要考虑的问题。下面我将结合自己半年以来应用测试建模在客户端上的测试经验，选择几个比较典型的测试建模方法加以介绍。

1.1 ACC建模

ACC（Attributes Components Compatibilities）是Google测试团队使用的一种建模方法，用来快速地建立产品的模型，以指导下一步的测试计划和设计。

ACC建模既可以针对整个产品来做，也可以针对单独的功能来做。针对整个产品来做，可以确定产品的核心测试点，针对单个功能来做，可以评估模块风险。

如同其文字描述，ACC建模可以分为三步来做：

1. 确定产品的属性（Attributes），不同类型的产品侧重于不同的属性，一些通用的属性是：可靠性、易用性、安全性、可拓展性、稳定性等等。这里你需要结合自己对产品的理解确定产品的关键属性，如果自己无法确定的话，可以和产品经理请教。
2. 第二步是产品的组件（Component）分割，待建模的产品可以分为哪些模块，这里需要注意一点，模块之间最好能够相互独立不交叉，这样一方面可以比较清晰的定义能力，另一方面也方便在ACC建模的基础上拓展测试用例
3. 在上面两步骤确定好之后，我们一般会得到一个M*N的表格，表格的第一栏是属性，第一列是产品的组件列，针对每一个组件对属性的作用，我们依次填写组件的能力（Compatibilities），这个能力可以理解为组件以何种功能来实现产品的属性。举个例子，地图产品有导航功能（组件），有可靠性（属性），在导航功能中，播报准确，就是导航组件在可靠性上的一个能力。如果该组件对于属性没有实现，那么可以在表格中空出不写。

1.2 测试用例

ACC建模虽然不能直接生成测试用例，却能在很大程度上指导后续测试方案的制定，根据风险模块的分布合理规划测试方案。

ACC建模的组件属性粒度比较大，很难直接根据ACC建模输出测试用例。ACC建模后的测试用例有两种方法编写：

1. 在ACC建模的基础上根据需求特点分组件建模，再根据具体的建模结果输出测试用例。
   这种方法的好处是，可以对模块进行比较详细的覆盖。缺点也比较明显，建模两次，需要花费额外的时间。
2. 在ACC建模中，根据建模结果，对每一个属性进行测试用例的编写。可以理解为，覆盖了所有ACC建模中属性的测试用例，即对功能覆盖完全。
   这种方法的好处是，可以在比较短的时间内输出测试用例。缺点是，需要编写用例人本身有较高的测试用例编写能且对功能模块有较高的熟悉度。

1.3 运用实例

需求描述：
针对数据下载模块进行了对应的优化

需求分析：
数据管理模块是导航APP最早的功能模块之一，接受导航APP的测试之后并没有该模块的新功能需求，本次功能优化由开发同学牵头完成，主要从功能本身的使用出发，对功能进行优化，无新功能的加入。考虑到以下两点：

1. 之前没有对数据管理模块进行过全面的测试
2. 本次优化并没有实际的需求文档

因此，我们针对数据管理模块进行了ACC建模，具体建模如

备注：该建模结果在原基础上有一定的调整

通过ACC建模，我们可以比较清楚的看到，数据管理模块的测试重点在于数据下载更新功能。U盘数据模块功能比较简单，因此我们针对U盘数据这块儿直接撰写测试用例。

2.1活动图 【重点学习！！！】

如果说有什么建模方法可以帮助开发一个功能，那么这个建模方法是流程图。流程图是流经一个系统的信息流、观点流或部件流的图形代表。对于开发同学来说，流程图可以很好的帮助他们捋清开发的思路。而如果说有什么建模方法可以详细的了解一个功能，那么这个方法是活动图。

活动图可以说是一个在软件开发整个周期中最为通用的一种建模方法了，产品在设计功能的时候，通常都会用到流程图。

对于产品同学来说，流程图可以帮助他们思考整体模块功能的疏漏，而对于我们测试来说，活动图无疑是快速了解一个陌生功能最有效的方法。通过活动图，我们可以快速的熟悉模块功能，了解功能主要流程，同时也可以在活动图图上清晰的看到可能存在异常逻辑分支的节点。

活动图在模型建立上并没有什么难点，唯一的难点就是你对于系统是否足够了解。活动图的建模一般分为一下几步：

1. 找出负责工作流实现的业务对象：这些对象可以是显示业务领域的实体，也可以是一种抽象的概念和事物
2. 确定工作流的初始状态和终止状态，明确工作流的边界
3. 对动作状态或活动状态建模：找出随时间发生的动作和活动，将它们表示为动作状态或活动状态
4. 对动作流建模：可以首先处理顺序动作，接着处理分支/合并等条件行为，然后处理分叉/汇合等并发行为
5. 对对象流建模：找出与工作流相关的重要对象，并将其连接到相应的动作状态和活动状态
6. 对建立的模型进行精化和细化

2.2 测试用例

活动图可以看作是一个长满枝叶的大树，而测试用例就是到达每一片树叶（结束态）的枝桠，从根节点开始，把流程图中的每一条分支串联，形成一个个工作流，再把这些工作流转换成测试用例即可

这里说一个活动图在用例转化时候的小技巧，如果你绘制的活动图整体流程很长，而且流程中又存在很多分支，在构造用例的时候可以对整个活动图进行切割，对于切割开的活动分别以活动覆盖来构造测试用例。

2.3 运用实例

下面，我们将以“应用内升级”需求为例，讲解活动图建模的适用范围以及注意事项。

部分需求描述：

• 提示框提示升级：进入地图时检测一次更新，如果有最新版本，则弹框询问是否马上升级。选择马上升级，升级程序自动进入后台，结束后提示用户进入系统进行安装。此时用户如果进入到“关于”中，如果当前在下载中，则显示下载进度，如果已经下载完成，则显示安装，同时弹出提示用户进入系统进行安装。
• 小红点提示升级：选择忽略则下一次进入导航时，设置项中出现小红点，同时首页－更多－设置－其它设置－关于中出现更新提示，小红点出现在“其它设置”的右上角，以及关于右上角出现小红点。当前版本信息右上角出现小红点。用户主动更新版本后，所有小红点提示均取消….

需求分析：
该需求描述整体功能流程较长，且需求中有不少的异常逻辑分支描述，且该功能为全新开发功能，测试同学对于功能不是特别熟悉，基于此，我们选择对功能进行活动图建模。

通过阅读需求文档，我们从功能的描述中抽取每一个流程节点，对其进行串联形成活动图的主流程。在主流程的基础上，考虑每一个流程节点可能存在的异常分支，并将“合理”的异常分支补充进活动图中，形成最终的活动图。如下：

可以看到，该活动图中存在一个小的更新包下载的状态机（图中已方框中的），这是在活动图中某个流程节点存在多个状态，但是如果将不同的状态绘制成不同的流程节点，将大大增加流程图的复杂度，也不适合进行测试用例的编写，

因此，将其状态转换单独建模，形成一个状态机，在后续测试用例编写的时候，流程图所转换测试用例不变，而针对状态机的状态流转也单独编写了相关的测试用例。

3.1 状态机

状态机的组成其实比较简单，要素大致有三个：输入，输出，还有状态。输入和输出比较容易理解，那么什么叫做状态呢？状态就是对象生命期中的条件或情况，在这种状态中，对象满足某种条件，执行某种活动，或者等待某种事件。

在基于状态的测试中，状态机的准确度直接决定了测试效果，所以状态机的绘制是非常重要的一环，我们可以通过以下三步来分析如何绘制状态机：

步骤一：列出研究对象拥有的各种状态

通过启发式的探索来发现系统的状态：

1. 通过三个简单问题发现状态：有没有什么事情是我现在可以做但之前不可以做的？有没有什么事情是我现在不可以做但之前可以做的？我现在所采取的行动是否产生了和之前不同的结果？
2. 留意用于描述正在发生事情的言辞，如“当……的时候”(While)、“当系统正在导入数据的时候……”、“当账户被冻结的时候……”
3. 每个状态都由事件所触发，认出状态可回过头找出触发事件，反之亦然

步骤二：列出状态之间的转换，确定引起各个转换的事件

在步骤一的基础上，考虑状态之间的事件。从测试的视角来看，引起状态转换的事件可以分为三种类型：

1. 外部产生事件：来自于软件之外的任何事件，如用户操作
2. 系统产生事件：软件自己产生的任何事件，如系统完成了某些后台活动而产生的结果
3. 时间流逝：超时、计时事件（如After 3 sec）

步骤三：分析各个转换过程中发生的事情

转换代表了从一种状态到另一种状态的改变，当然也可以是自身到自身的。每个状态都可以指定三种可选的信息：

1. 触发器：触发器对应事件
2. 守卫：守卫是一个布尔表达示，事件发生时，守卫必须为真，转换才会执行
3. 效果：效果是在转换过程中执行的行为（活动或交互）

步骤四：状态机review

在上面三步做完之后，就形成了一个状态机。但是，状态机的正确性，完整性是否可以得到保证呢？状态机的绘制是否符合规范呢？这些都需要通过人工或者工具的方式进行review。

3.2 测试用例

状态图测试用例转换可以参考文章：

《用FSM写Case，你会么？》
https://mp.weixin.qq.com/s/4ypvZ4mhj7oroCxjZlYnDg

3.3 运用实例

需求描述：
数据下载模块功能优化

需求分析：
在数据下载中，不仅涉及到多个城市下载状态切换管理，而且耦合了配置文件状态在里面，其流程环境使用简单的流程图无法表达，测试用例自然也就无从写起。所以，针对数据的下载状态，进行了单独的状态图建模，具体建模结果如下：

在上述状态图的基础上，我们使用基于状态机的测试用例编写用法撰写用例，如下图所示：

4.1 组合测试

组合测试建模的步骤：

1. 确定变量Xi；
2. 确定每个变量Xi的取值集合；
3. 为了更充分的发现缺陷，每个变量的取值要进行充分的设计，尤其是“典型取值”，可以通过等价划分、边界值等方法进行取值。测试集中没有包含可以暴露错误的特定取值是缺陷遗漏的主要原因；
4. 确定检查方法，以判断Y1，Y2，…，Yn是否正确。错误的或不严谨的检查都有可能遗漏的缺陷。

4.2 测试用例

在确定了所有变量及其取值集合之后，可以使用PICT工具，PICT工具的使用方法可以参考下面文章：

《组合测试从理论到实践——从吃货的角度实现组合测试用例的自动设计》
https://mp.weixin.qq.com/s/6ciHrYeUeWOpzNJwQ3LjhQ

4.3 运用实例

需求描述：
开发同学在修复BUG的时候，调整了整个算路功能的功能架构，需要对算路的功能进行全面的覆盖。

需求分析：
这又是一个没有文档描述的需求，仅仅是说了可能涉及到算路的功能。算路作为一个功能流程，我们最初考虑的是使用流程图对其进行建模。但是在实际操作过程中，我们发现由于算路功能本身涉及到的条件特别多，流程图中的功能节点也比较复杂，输出的流程图并不能简单明了的概括整个算路功能。

考虑到算路功能本身涉及到不同的功能条件，我们将所有可能影响算路的功能进行分别列举，如下所示：

//组合测试条件枚举
网络环境:WIFI,3G,无网络
离线数据情况:有离线数据,无离线数据
在线离线优先:在线优先,离线优先
偏好情况:111,X11,1X1,11X,XX1,X1X,1XX,XXX
途经点:有,无
路线长度:市内,省内,跨省
算路入口:底图选点(长按短按),微信位置推送,路线检索页,常用地点,首页手势,路线搜索历史,周边搜索,poi检索
在上述条件的基础上，补充了部分约束条件：
    IF [偏好情况] = "111" THEN [在线离线优先] <> "离线优先";
    IF [在线离线优先] = "离线优先" THEN [离线数据情况] <> "无离线数据";
    IF [算路入口] = "周边搜索" THEN [路线长度] = "市内";
...
//组合测试条件枚举结束

以此为输入，使用PICT组合测试用例功能进行测试用例的编写，输出用例如下：

    

使用无须实名的阿里云国际版，添加 微信：ksuyun  备注：快速云！