设计测试用例应该算是测试人员最为主要的工作之一 ，好的测试用例往往具有覆盖性强 ，扩展性高以及复用性好等特点 。该如何设计出好的测试用例 ？是我们每一位测试人员需要重点思考的问题 ，下面是我对设计测试用例设计的思考 ：
1.建立设计用例框架
所谓的流程覆盖 ，就是对产品中存在的主要场景进行覆盖测试 ，参考依据就是产品原型的流程图以及用户的主要场景 ，通过流程图中的路径所进行的覆盖；
而功能的覆盖 ，主要指的是两个方面 ，分别为功能宽度的覆盖和功能深度的覆盖 ，具体原则就是先进行功能宽度(范围)的覆盖，再进行功能深度(方法)的覆盖。
类型覆盖就是针对质量模型中的特性，从测试的角度去覆盖测试 ，比如质量模型有易用性特性 ，你就可以通过易用性测试进行验证 。所以，最后的测试类型主要包括 ：
-
功能测试(在上面已经考虑，这里就可以忽略)
-
易用性测试
-
兼容性测试
-
可靠性测试
-
安全性测试
-
性能测试
2.对应的测试方法
3.测试的颗粒度
如果我们面对一个庞大而又复杂的系统时，如果系统中的每个功能都要考虑的很细 ，那么无疑会给我们带来很大的工作量 。而且很多时候也没必要 ，你永远也不能把电商系统的支付功能和站内信功能按照同样的方式去设计 ，因为本身它们的重要程度就不一样。 所以设计测试用例的颗粒度自然也会不同 。那么该如何确定测试用例的颗粒度呢 ？ 就是按照功能的重要程度来确定所使用的测试方法，越重要的功能使用的方法及策略会越多 ，反之就越少 。具体的使用步骤就是 ：
-
确定功能测试范围 ，根据项目迭代的情况 ，确定本次版本所要测试的范围(确定范围边界) 。
-
给对应功能设置级别 ，一般按照严重程度可以划分为四个等级 ，划分等级的目的就是为了后面设计测试用例和使用测试策略时的侧重点是不同的 。若没有等级划分 ，就很难确定出使用的测试方法以及测试策略 。
-
针对每个功能给出设计的测试方法和测试策略 ，总体原则就是重要的功能测试方法会用的越多 ，同时测试策略也会加强该功能的测试 ，反之就会减少对其的测试 。这样可以将更多的时间花在重点功能上 。
按照以上步骤 ，结合一个案例就会得出如下的结果 ，如下图 ：
4.如何设计测试用例
最后让我们回到最开始的问题 ，如何设计测试用例呢 ？ 你可以按照如下的流程进行设计 ：
-
提取测试点 ，主要是指根据需求提取测试点 ，需要与测试点不一定是一对一的关系 ，有时候可以是多个需求对应一个测试点 ，有时候也可以是一个需求能提取出多个测试点 。
-
使用测试方法对测试点设计测试用例 ，通过上面提取的测试点 ，然后根据对应的测试方法进行设计测试用例 。
-
复验回检测试用例，进入这个阶段，一般你的测试用例已经写完，你更多的是将已经编写的用例再进行一次检查 ，确实是否覆盖了需求 ？是否了不同的测试类型 ？ 是否已经覆盖了相对应的方法 ？总之 ，你的目的就是为了捡漏补全 。
-
确定测试套件， 为了后续进行测试组合成各种套件，以便后续测试使用 。
下面我们就按照上面的框架去设计测试用例 ，依次先考虑 ：流程 -> 功能 ->其它测试类型 。
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.功能测试
对单个功能设计测试用例的话 ，我们就可以按照先从需求提取测点，然后再设计测试用例的步骤来进行 ，比如下面的这个需求
最终将需求点转化为了测试用例 ，具体如下 ： 
通过上面的案例可以看到 ，如果没有提取测试点这一步骤 ，其对应的测试用例就很容易遗漏掉，所以，在设计测试用例的过程中提取测试点是一个很重要的步骤 。
最后，就是从测试点到最终的测试用例的这一步其实就是用的不同的测试方法，具体方法可参考上面的测试方法，因这是一个很大的话题，暂时不在这里介绍，我在后面的文章进行详述 。
