敏捷测试十种方法，掌握功能测试中的核心能力

3.1 编写测试用例的目的是什么 ？

设计测试用例可以说是测试人员的一项最基本技能 。很多时候当我们接到设计测试用例的任务时 ，往往都是想的该如何更快的完成这项任务 ？而很少去想为什么要完成这项任务? 对于测试用例也是如此，为什么要设计测试用例呢(目的)？其实这个问题是我们做好测试用例的元问题 ，回答好这个问题，你设计出的测试用例就更具有全面性 。

1.什么是测试用例 ？ 包含什么要素 ？

首先，让我们来了解一个最基本的问题，什么是测试用例 ？ 所谓的测试用例就是针对软件设计的一系列验证项 ，其中每个验证项中都包含了有输入，执行步骤，预期结果等要素 。其目的就是为了验证产品功能是否符合产品需求 。

通常情况下我们会将测试用例存放在一个具体的文档或工具中 ，比如 ：excel , xmind ,禅道 或一些其它的测试用例工具中 。

当然它里面包含的要素也会根据文档/工具的不同 ，里面所包含的要素也有所不同 ，但整体上来说差别不大。主要包括基本要素(必备要素)和扩展要素两个部分 。

• 基本要素 ：用例编号 ，产品/项目名称，模块 ，测试用例标题 ，前提条件 ，操作步骤 ，预期结果 ，执行结果 。
• 扩展要素 ： 输入数据 ，测试用例类型 ，适用阶段以及备注等。

有了这个这些要素 ，即使没有测试用例模板 ，也能很快的构建出来 。当然 ，经常设计测试用例的肯定是对这些了如指掌 。

2.为什么要编写测试用例 ？

那么，回到我们开头的那个问题 ，为什么要编写测试用例 ？它有什么好处 ？能体现在哪里 ？ 要想回答这些问题 ，我们可以去找出编写测试用例和不写测试用例它们之间的区别是什么 。从而这个问题的答案 。

首先，设计测试用例的过程是一个高度专注的过程，在此过程中你可能需要借助各种专业的方法、经验以及想象力 ，才可能设计出完备且有效的测试用例集。而这个过程最合适的时机就是找一个尽量没人打扰的时间段进行集中统一设计 。所以把它放在提测前统一设计是最合适的 ，到了执行阶段只负责执行即可。

但是假如这个用例因为其它原因未进行设计呢 ？ 那么我们的执行就会变的随机 ，你可以想象一下这样的场景，你一会在想测试点，一会又在执行测试用例 ，一会又在提bug ，甚至还要和同事进行各种的沟通，在这种如此频繁切换场景的情况下，你的测试点还能否保证覆盖度？ 其实是一个很大的未知数 。这也是编写测试用例和未编写测试用例的一个最本质区别 。即写测试用例会覆盖度更强 ，而不写测试用例它的随机性会更强，漏测点会更多。

那么，我们所编写的测试用例到底是在覆盖什么 ？很多人会说肯定是在覆盖需求 ，但是我觉得这个答案不够完整 。它应该是：

• 首先，验证每一个功能是否正确，即验证功能的正确性；
• 其次，应该针对每个功能需求进行深入的覆盖，即验证每个功能的深入性 。
• 最后，对需求中的每一个功能进行覆盖，即验证整个系统的全面性

也就是说，我们真正设计测试用例的目的就是为了保证这三个性：正确性、深入性和全面性 。

3.设计时该如何覆盖 ？

所以，一个好的测试用例的特点应该至少包括验证功能的正确性 、验证每个功能的深入性(测试深度)以及验证功能的全面性(测试广度) 。

其中，正确性很好理解 ，这里不在解释，但是深入性和全面性是什么意思呢 ? 或者说在设计测试用例过程中该如何体现呢 ？

先说全面性 ，全面性其实就是指所设计出的测试用例是否包含了全功能的覆盖(功能范围)和全类型的覆盖(类型范围)；

而深入性是指针对某个单一功能是否包含了各种方法的覆盖 ，因为归根结底测试用例是由各种方法设计出来的 。

这里面需要说明的是 ，每种测试类型都会有不同的方法 ，掌握方法的多少是决定设计出来的测试用例细粒度的一个主要因素 。这也是为什么我们需要掌握更多的测试方法的原因 。因这个话题太大，我们不在这里说明 。

4.无需求时该如何编写 ？

以上目的是有一个前提条件的 ，就是必须依赖于需求 ，比如说验证产品功能的正确性 ，那么产品的预期结果其实是来源于需求 ，同样其它两个目的也是如此 。但是在现实的工作中，常常会遇到没有需求而编写测试用例的情况 。那么这样的情况下，以上的目的还是否有效呢 ？答案是有的，但需稍作修改 。具体变为 ：

• 验证每个功能的正确性 ，依据用户逻辑去判断是否正确 。
• 验证每个功能的深入性 。
• 验证是否覆盖了所有的参考物 ，这里的参考物可以是已实现的系统功能、UI图中的功能，基于这些参考物我们也可以根据经验写出对应的测试用例来 。

通过以上的修改 ，就能兼容有需求和无需求的情况 。测试用例的目的就会变的更加通用。

5.总结

总结一下 ，编写测试用例可以说是一项非常基础的能力 ，我们不仅仅是要知道如何编写测试用例 ？ 而且更要知道为什么要编写测试用例 ，也就是知其然也要知其所以然 。在元问题上进行更多的思考，有助于我们提高对事物本质的认识 。

那么，我们编写测试用例的目的是什么呢 ？

• 验证每个功能的正确性 ，依据需求(用户逻辑)去判断 。
• 验证每个功能的深入性 ,从测试方法上去深入 。
• 验证是否覆盖了所有的功能(参考物 ) ,可以从功能的测试类型上考虑全面性 。

知道了测试用例的编写目的 ，也就知道了编写测试用例所要达到的目标 ，从现状作为起点到最终的目标的这个过程就是不断使用不同方法去靠近的一个过程 ，其中两者的差距就是我们提升的空间 。

### 3.2 测试用例的标题该如何写 ？

#### 1.一个好标题的作用

在编写测试用例的过程中，标题是整个测试用例中最主要的要素 。一个好的测试用例标题可以帮助我们达成以下目的 ：

- **提高编写测试用例的速度** ，通过定义统一的标题可以让我们将重点集中在验证点上，其它相同点都可以直接拷贝粘贴，从而提高测编写效率。

- **提高测试用例的执行速度** ，编写测试用例的目的是为了执行，编写用例的测试人员不一定去执行测试用例，所以一个清晰简洁且验证点突出的测试用例标题能让执行者更快速的理解它的含义，从而提高执行效率 。

- **进行更快速的筛选** ，很多时候我们都要选取不同的用例进行回归 ，通过内置关键字让我们更轻松快速的选取出不同套件的用例 。

所以，如果想达到以上的目的 ，测试用例的标题就应该包括 ： **统一的标准 ，验证点突出 ，以及内置关键字**，也是编写出好的测试用例标题的主要依据 。

什么是统一的标准呢 ？就是同一类型的测试用例标题编写模式是一样，里面除了关键字和验证点不一样 ，其它的几乎都是一样的 。所以，通过复制上一条用例的标题，你只需要修改关键字和验证点即可 ，这样就把焦点集中在了验证点上了 。其它无需过多的考虑 ，从而减少了其它干扰。这样我们就可以通过一个固定的公式给它定义出这个标准 ；

验证点突出就是在具体的验证点上加以标记 ，以突出此验证点，这样做的好处是能让执行者更快速的定位要验证的是什么，从而去提高执行效率 。但是测试用例标题是无法使用颜色去标记的 ，所以最好是一个选择固定符号来代替 。

内置关键字是为了我们搜索时方便 ，我们通过内置几个非常常用的关键字 ，以便让我们在搜索时快速找到这些特征的用例 。我个人认为搜索关键字给出三个是最好的 ，这样就能更全面的覆盖 ，但是这样会给编写时带来一些麻烦 ，所以经过取舍觉得还是两个好 。关键字的维度可以是 ： 功能 、功能重要度 以及 正反向 。

#### 2.用例标题编写规范

当然，在测试用例的编写过程中，通常也会把测试用例按照其特性进行分类 ，具体可以划分为：

- 功能测试用例

- 流程测试用例

- 非功能测试用例，包括易用性测试，兼容性测试 ，性能测试等。

那么 ，测试用例的标题也应该按照这三类进行区分 。这里我先给出以下三类测试用例标题公式 ：

- 功能测试用例 ：

- 【功能-正向】验证 具体的某个测试点 预期结果

- 【功能-反向】验证 具体的某个测试点 预期结果

- 流程测试用例 ：A->B->C->D , 其中每一个字母是流程中的一个节点 ，这个节点最好有具体的操作动作组成 。比如 ：登录->选择商品->加入购物车->结算->支付

- 其它类型的测试用例 ： 【测试类型】验证 具体的某个测试点 预期结果 。

#### 3.项目中的编写案例

**功能测试用例标题：**

流程测试用例

其它测试类型用例

4.测试用例相关文章3.3 测试用例的级别如何定义 ？1.级别的作用

在编写测试用例的过程中，用例的级别经常是一个不可缺少的字段 ，本篇幅就来聊下这个字段 ，首先从它的作用是什么呢 ？我觉得主要有两点 ，分别是 ：

• 用于测试用例不同套件的选取 ，即用例用于不同的场景 ，比如专门用于做回归测试或者冒烟测试用例。
• 确定测试用例的执行策略，即确定用例被执行的优先级 。

2.决定因素

决定测试用例级别的两个主要因素 ： 功能重要程度 用例类型 。

其中按功能重要程度又可划分为 ： 核心功能 ，主要功能 ，次要功能 ； 而用例类型主要分为 ：正向用例 和反向用例 。

然后将这两个因素进行正交，就得到了如下的划分 ，具体为 ：

3.用例级别划分

以上只是对功能用例进行了划分 ，接下来我们把所有的用例类型(功能用例，流程用例，其它测试类型用例)都包括进来，然后对其进行划分，具体如下 ：

4.根据级别选取套件

最后，让我们再回到测试用例级别的作用上，在上面我们说主要有两个作用 ，分别是套件的选择和用例被执行的优先次序。其中被执行的优先次序这个涉及内容比较多 ，不在本篇幅介绍，主要说明下测试套件该如何选择的问题 。

将测试套件具体也可以划分为

然后将设定好的测试用例级别和套件进行对应，具体如下：

3.4 如何设计测试用例 ？

设计测试用例应该算是测试人员最为主要的工作之一 ，好的测试用例往往具有覆盖性强 ，扩展性高以及复用性好等特点 。该如何设计出好的测试用例 ？是我们每一位测试人员需要重点思考的问题 ，下面是我对设计测试用例设计的思考 ：

1.建立设计用例框架

所谓的流程覆盖 ，就是对产品中存在的主要场景进行覆盖测试 ，参考依据就是产品原型的流程图以及用户的主要场景 ，通过流程图中的路径所进行的覆盖；

而功能的覆盖 ，主要指的是两个方面 ，分别为功能宽度的覆盖和功能深度的覆盖 ，具体原则就是先进行功能宽度(范围)的覆盖，再进行功能深度(方法)的覆盖。

类型覆盖就是针对质量模型中的特性，从测试的角度去覆盖测试 ，比如质量模型有易用性特性 ，你就可以通过易用性测试进行验证 。所以，最后的测试类型主要包括 ：

• 功能测试(在上面已经考虑，这里就可以忽略)
• 易用性测试
• 兼容性测试
• 可靠性测试
• 安全性测试
• 性能测试

2.对应的测试方法

3.测试的颗粒度

如果我们面对一个庞大而又复杂的系统时，如果系统中的每个功能都要考虑的很细 ，那么无疑会给我们带来很大的工作量 。而且很多时候也没必要 ，你永远也不能把电商系统的支付功能和站内信功能按照同样的方式去设计 ，因为本身它们的重要程度就不一样。 所以设计测试用例的颗粒度自然也会不同 。那么该如何确定测试用例的颗粒度呢 ？ 就是按照功能的重要程度来确定所使用的测试方法，越重要的功能使用的方法及策略会越多 ，反之就越少 。具体的使用步骤就是 ：

0. 确定功能测试范围 ，根据项目迭代的情况 ，确定本次版本所要测试的范围(确定范围边界) 。
1. 给对应功能设置级别 ，一般按照严重程度可以划分为四个等级 ，划分等级的目的就是为了后面设计测试用例和使用测试策略时的侧重点是不同的 。若没有等级划分 ，就很难确定出使用的测试方法以及测试策略 。
2. 针对每个功能给出设计的测试方法和测试策略 ，总体原则就是重要的功能测试方法会用的越多 ，同时测试策略也会加强该功能的测试 ，反之就会减少对其的测试 。这样可以将更多的时间花在重点功能上 。

按照以上步骤 ，结合一个案例就会得出如下的结果 ，如下图 ：

4.如何设计测试用例

最后让我们回到最开始的问题 ，如何设计测试用例呢 ？ 你可以按照如下的流程进行设计 ：

0. 提取测试点 ，主要是指根据需求提取测试点 ，需要与测试点不一定是一对一的关系 ，有时候可以是多个需求对应一个测试点 ，有时候也可以是一个需求能提取出多个测试点 。
1. 使用测试方法对测试点设计测试用例 ，通过上面提取的测试点 ，然后根据对应的测试方法进行设计测试用例 。
2. 复验回检测试用例，进入这个阶段，一般你的测试用例已经写完，你更多的是将已经编写的用例再进行一次检查 ，确实是否覆盖了需求 ？是否了不同的测试类型 ？ 是否已经覆盖了相对应的方法 ？总之 ，你的目的就是为了捡漏补全 。
3. 确定测试套件， 为了后续进行测试组合成各种套件，以便后续测试使用 。

下面我们就按照上面的框架去设计测试用例 ，依次先考虑 ：流程 -> 功能 ->其它测试类型 。

1.流程测试

首先 ，要站在整体的角度进行全局思考 ，理解用户需求及使用场景，这样能更好的梳理出用户的常用场景 ，当然一般在产品原型中也提供了产品流程图 。然后我们使用场景法和流程图的方法来设计这一类型的测试用例 。比如如下的流程图 ：

以上的流程图，一般有两种覆盖的方式，就是全覆盖和部分覆盖 。若进行全覆盖的话 ，就需要将每一个分支进行组合后覆盖 ，虽然从覆盖上来说是全的 ，但是花在用例上的陈本太高 ，大大超出了我们的正常的工作量 ，所以不建议这样覆盖。

最可取的办法将每一个分支至少覆盖一次就可以了 ，这样的话就会大大降低用例数量 ，比如上图就可以变为 ：

• 流程1 ：P1-d1-d2-d3-P5(基本流)
• 流程2 ：P1-d1-P2-d2-d3-P5(备选流-走P2分支)
• 流程3 ：P1-d1-d2-P3-d3-P5(备选流-走P3分支)
• 流程4 ：P1-d1-d2-d3-P4-P5(备选流-走P4分支)

下图是一个实际的案例 ，虽然流程少但是就可以按照这种流程去覆盖 。

2.功能测试

对单个功能设计测试用例的话 ，我们就可以按照先从需求提取测点，然后再设计测试用例的步骤来进行 ，比如下面的这个需求

最终将需求点转化为了测试用例 ，具体如下 ：

通过上面的案例可以看到 ，如果没有提取测试点这一步骤 ，其对应的测试用例就很容易遗漏掉，所以，在设计测试用例的过程中提取测试点是一个很重要的步骤 。

最后，就是从测试点到最终的测试用例的这一步其实就是用的不同的测试方法，具体方法可参考上面的测试方法，因这是一个很大的话题，暂时不在这里介绍，我在后面的文章进行详述 。

3.5 如何执行测试用例？

提起测试用例的执行 ，可以说是一个简单到再不能简单的话题 ，很多刚入行的测试人员 ，因测试经验有限或对业务不熟悉 ，往往在刚开始的时候都是做测试用例的执行工作 。当然 ，也正是觉得这个工作简单 ，所以很多人也不觉得在这里面会有什么问题 。但是 ，实际情况是果真如此 ？本篇幅我们就重点来聊聊这个话题 。

对于测试用例的执行来说 ，一般都会在第一轮测试中进行执行 ，已确保所有的测试用例都能至少执行一遍 。但是，在用例的执行过程中，你是否考虑过它们执行的顺序 ，哪些用例应该优先被执行 ？ 哪些用例应放在后面去执行呢？ 可以想想这样一种场景 ，其中一条测试用例能发现一个重要且难以修改的bug ，如果你的这条测试用例被早早的就执行了，那么此bug被修改的时间就能大大的前置 。但如果你是在最后阶段发现该bug的话 ，那么此bug就会对你后面的测试产生影响 。所以，在测试用例执行的过程中，如何安排测试用例的执行顺序是很有必要的 。

1.测试用例执行

这里，我们就以一个需要执行5天的用例场景来说明 ，在执行的过程中主要考虑的是功能级别或者用例级别 ，若以功能级别为例 ，我们可以看到 ，虽然每个功能的重要程度各不相同 ，但是在第一天的时候我们还是让不同级别的功能都要得到执行，至少要每个功能的基础用例都要得到执行。这样做的目的就是为了尽早确认出各功能是否可用，是否会阻塞后面的测试。

从第二天开始往后基本就是按照计划执行 ，同时也要结合实际情况进行动态的调整 ，在执行的过程中主要注意以下几种情况 ：

• 出现阻塞性的bug ，要和开发明确修改时间 ，同时阻塞期间 ，停止该模块的测试 ，开始切入到其它模块的测试 。
• 出现bug较多的模块 ，若其中一个模块出现bug较多，可以先暂停该模块的测试 ，让开发尽快的修改一波bug ，后续再进行回测。
• 出现开发人员修改不过来的情况 ，若部分开发人员要修改的bug较多，暂时修改不过来，先暂停他负责模块的测试 ，测试bug较少的开发人员所负责的模块 。这样可以平衡进度 ，减少资源投入不合理 。

通过以上的策略调整，要做到不能因为某个模块的阻塞而停止测试 ，也不要因为开发的阻塞而影响测试 ，整体的策略是注重整体推进，优先重要模块测试，能快的尽快测(甚至让其尽快进入二轮)，不能快的即使反馈和跟踪状态 ，确保不影响其它的测试 ，要从整体上关注执行情况，而非聚焦在某个点上。

同时，在执行期间 ，还要注意回归测试的策略和频度 ，若是阻塞性bug ，修改后需要及时的回归 ；对于bug较多的情况，也需要每天下班前回归一部分，以免出现bug积累太多 ，影响后面的测试。

2.测试用例数据构造

在执行测试用例过程中 ，你也会遇到很多的问题 ，其中最主要的问题就是测试数据的准备 ，比如有的时候需要构造出为空的数据 ，而有的时候又要测试最大值的情况 ，如果单从功能上构造这些数据，效率就会很低下 。这时候我们就的借助于工具来构造 ，常见的两种方法就是使用数据库和调用接口 。

数据库构造数据

通过数据库构造数据通常是将要测试的用例所需要用到的数据状态通过修改数据库使其直接具备当前状态 ，这样的话我们就可以直接进行测试了 ，无需再做数据进行前提准备 。比如你要测试一个要具有5张轮播图的用例 ，你就将直接写好的SQL编写为存储过程 ，保存到函数中，后续就可以直接使用。

如果你的SQL语句写的足够好的话，并且和测试用例一一对应起来 ，那么它能起到事半功倍的效果 。

当然，我还建议你在使用数据库的时候 ，最好备份几个状态 ，比如在每个版本前做一个备份 ，随着后面进行的回归测试，保持原始状态对复现bug很有帮助 。

调用接口构造数据

有时候通过修改数据库时非常不方便，可能会出现修改不全的情况 。 为了能产生正确有效的数据 ，你可以通过调用接口产生数据 ，而且这种方式往往更加简单，直接通过工具调用即可 。若想要产生多条数据的话，你也可以自己编写脚本让其循环产生多条数据 ，并且也能做到每条数据随机生成 ，保证每条数据都是不同的 。而且这样一次性就能产生多条数据 ，对于初始化多条数据来说非常方便 。

这样对于测试大数据量的时候非常有用 ，因为很多bug只有在数据里大的情况才能发现 。所以 ，通过这种方式能很有效的解决这个问题 。

最后，做功能测试时数据构造是一个费事费力的工作 ，无论使用修改数据库还是调用接口 ，其实最主要的是让其能更好的复用 ，这样的话就能最大化提高测试效率 ，所以，设计时最好要从全局考虑 ，能将设计的脚本复用到不同项目上 ，能达到数据自动化的效果 。

3.6 如何进行测试用例的分析

测试用例作为测试人员最重要的输出物之一 ，它的作用不仅仅是能保证需求覆盖 ，提高测试覆盖率等 。通过对执行后的测试用例分析 ，你也可以发现更多在编写上，执行上出现的问题，从而进行修改和完善 。

1.测试用例的分析指标

那么 ，我们该如何做测试用例的分析呢 ？我们可以通过以下几个方面去分析 ：

指标1：测试用例发现bug的占比 ：是指通过测试用例发现的bug数占总bug数的比率 ，因为除了通过执行测试用例发现bug外 ，还可以通过随机测试或探索式发现bug 。 我们一般是希望这个比值是一个合理的范围，太高或太低都其实都是一个不健康的测试 。那么如果这个比值太高的话 ，可能是以下的问题导致 ：

• 随机发散测试的时间不足 ，花在测试用例执行的时间太长 ，可能的原因是测试轮次安排不合理或者测试时间不够 。
• 太依赖测试用例发现bug ，测试手段单一 ，或者不愿意发散测试 ，可能原因是团队比较沉闷，缺乏激情 ，只是一味的去执行 。
• 发散测试或探索测试的效果不好 ，团队不擅长发散测试 ，不能有效的发现深入的bug ，可能原因是团队成员不注重这方面的积累，或者缺少这方面的能力等。

如果这个值太低的话 ，可能是以下的问题导致 ：

• 随机发散的测试投入过多 ，压缩了测试执行时间 ，可能的原因是测试轮次安排不合理或者测试时间不够 。
• 测试用例设计水平不高 ，存在测试设计遗漏情况 。可能的原因是不太会使用测试方法或者不去使用测试方法 。
• 对业务理解不深入，不准确导致 ，存在设计无效或错误的情况 。

指标2：测试用例的首次执行通过率 ：是指测试用例第一次的执行结果为通过的用例占总用例的占比 ，若此占比值高 ，有可能原因的是开发的版本质量比较高 ，或者是测试用例所使用的测试方法单一或不够深入等 ；若此占比值低 ，说明开发版本质量较低或者测试方法比较有效 。所以我们拿这个指标可以评估产品开发的质量或者测试方法的有效性 。

指标3：测试用例的有效率 ：是指执行时有效用例占总用例数的占比 ，若此值太低的话 ，有可能的原因就是测试方法使用不够熟练 ，或者是测试人员对业务理解不够准确或深入 ，亦或者需求变动大导致用例不适用了 。所以通过此指标可以评估测试人员对业务的理解情况或者需求的变更情况 。

指标4：测试用例的执行时间 ：一般我们会将测试用例执行安排在第一轮测试中，它的总占比时间不能超过50% ，如果这个时间太长的话 ，有可能的原因就是测试效率执行低下 ，遇到难以执行卡的时间太长 ，缺少对执行时间长的用例的有效解决办法 ，团队评估的测试周期差距大，没有估计到执行过程中遇到的各种问题 。所以通过此指标可以评估测试人员的执行效率 ，难执行用例的解决方案的效果 或者测试周期评估的准确性 。

2.可能原因的论证

虽然我们列举了几个分析的测试用例指标 ，也进行各种情况的分析 ，但是光分析还不够 ，你还要去论证和解决这些分析后所产生的结果 。比如你已经发现测试用例的首次执行通过率这个值很高，分析后得出的可能原因是版本质量高或者是测试方法使用不当导致 ，那么它的具体原因是什么 ？ 这个还需要我们去进行论证 ，可行的方法就是结合历史数据进行比对 ，分析出那个才是真正原因 ，比如说导致通过率过高可能是你的测试方法使用不当 ，那么就要分析在以往的版本中是否也是这种情况 ，其他测试人员编写的用例通过率如何 ？ 通过这么几个维度的数据比较，基本就能确定出具体的原因 。所以，在这个分析和论证的过程中，你要比较的历史数据和比较的维度就显得很重要 。所以，建议每个版本测试完毕后，尽量要保留重要维度的历史数据 ，以供在后续版本中进行分析。比如以下 ：

3.确定原因的解决方案

找到了具体原因还不行，我们总的解决它，否则以上工作做的再好也是白费劲 。想解决方案，在后续版本中实践此方案 ，同时监测其效果 。比如我们确定了使用的测试方法效果不太好 ，导致测试用例首次执行通过率很高 。那么你可能想到的方案是 ：

• 找设计用例比较好的同事进行培训 ，然后制定同一标准 ，让大家以后也按照这个标准来设计 ，并加强评审环节的监督 。
• 买一些测试用例设计的书籍或者视频 ，大家一起去学习 ，然后开会讨论 ，总结出经验 。
• 复盘以前bug ，通过对好bug的分析 ，然后形成一些方法，最终用到测试用例中 。

通过列举出以上的方案 ，并且在后续工作实践这些方案 ，然后在后续的版本迭代中在此监控用例首次执行通过率这个指标 ，并记录各版本的历史数据 ，通过多个版本历史数据比对最终确定方案是否有效 ，如若方案效果不好 ，可以更换方案再试，直到达到预期的效果。

所以，通过以上的过程我们可以看到 ，有的问题并非是我们想象的那么容易 ，提供了新方法，就能立马见效或者有效 ，是需要不断的重复尝试的一个过程 。

,