软件测试（2）软件测试基础/测试用例怎么设计

前言

        在经过一番对软件测试的软知识查缺补漏后，现在对软件测试这个领域总算稍微有了一点认知。那么反复提到的最重要的测试用例要怎么写，怎么设计呢？在讲设计用例里提到了设计的模版是由基本的八个部分组成，本来在公司里我也看到过不同的模版，不同的模版也有不同的好处，这里我就不强调用例的格式，强调用例设计的方法。

        btw，之前的博客写的非常的冗余，之后会用思维导图的形式快速的把整体想表述的内容先阐明，也方便自己归纳总结。所以这次的博客更新，我就对用例的设计方法的部分展开了自己的总结，根据网上有的资源和自己遇到的来进行一些总结。希望能够达到4个目标：1，对穷举法场景设计测试点。2，对限定边界规则设计测试点。3，对多条件依赖关系进行设计测试点。4，对项目业务进行测试点。

常见用例设计方法

        为什么有人能写出来看起来覆盖面广且有效的用例呢，因为他们能凭借丰富的测试经验下意识的去做到面面俱到的测试点范围。那么有没有一种走捷径哦不是科学的方法，来做用例设计呢？肯定是有的嘛，科学家都说过我们要站在巨人的肩膀上。所以最好的设计手段就是根据总结出来的规范化的方法来进行用例的设计。

        废话不多说，我们常见的几个方法如下：等价类划分法/边界值分析法/场景法/错误推荐法/判定表法。接下来会针对常见的测试场景由各自能处理的测试用例方法进行解决。

1.用等价类划分法解决穷举场景

1.1什么是等价类

        如字面意思所说，等价等价就是具有同样的价值，那么等价类就可以理解成具有某种相同价值的内容进行分类。如果放在测试用例里，那么就是对所有的测试数据依照是否有共同特征来做数据集合的分类。

1.2如何分类

        一般我们测试的内容都会采取正向和负向（也就是对和错）最基础的划分手段，那我们一般对于正向的只会去其中一个代表来作为有效等价类，这里的有效等价类其实也就是能满足软件产品需求的类，那么不满足需求的就是无效等价类了。

1.3分类的步骤

        首先，我们需要明确产品的需求（这点真的非常重要，反复强调！）其次，就是对确定有效和无效等价类的划分，最后才开始编写测试用例。

        感觉这部分有点说了又没说的感觉，但是要强调一点，正向的有效等价类最好一次能够覆盖多个，而负向的无效等价类一次只能覆盖一条，在后面的案例部分具体执行就明白了。

1.4案例

        由案例来分析更容易理解，首先还是以最常见的登录模块来举例。通常产品的定义会是对登录的qq号码有要求，比如说是6-10位的自然数。如果我们想写用例，是不是短短点一句需求就能穷举很多种组合方式？

        那我们要不断穷举来写用例吗？我们能够很明显的分析出来，这句简短的要求里就有两个限制：1，长度是6-10位，2，数据类型是自然数。因此，有效类的划分是怎么样的呢，还记得前面提到的正向负向（或者说有效和无效）吗？

        这时候举例有效类就是8位自然数，无效类有：3位自然数/12位自然数，8位非自然数/为空（这里的为空就是不填的意思）。是不是突然发现这样一下就写了好几条用例出来？

        到上一小段也就是我们前面分类步骤里提到的明确了有效类的划分了吧，那么接下来就是提取出数据来编写用例了，这里我直接用表格来表明能够提取出来的具体的符合分类的用例。能够明显看到作为比较常用的用例，我们在正向执行部分里一般都只会涉及到较少的用例数量，符合单次最大范围覆盖满足条件，用更多的心思在无效等价类也就是负向的错误点进行测试模拟，为了就是模拟客户在不同情境下去使用的情况。

 1.5适用场景

        一般来说，等价类的判断方法适合 需要大量测试数据输入，但是没有办法穷举的情景，这就是我们先前说的第一个目标，在穷举的情况下来设计测试点。实际案例就是页面的输入框类型，八位自然数这样无穷无尽的数据一个个去测试是不可能的，我们更主要是去关注单个输入类条件的测试，考虑输入条件与输出结果间有相互制约关系的测试。

        除了输入框类型的，还有下拉列表/单选复选项等进行穷举方法验证的测试情况，都可以采用等价类进行简单的正向和负向验证。

        

2.边界值分析法（必测--开发底层逻辑容易出错）

2.1边界值指的是什么？

        这个方法很容易理解，首先我们需要认识几个点：上点/离点/内点，看下面的图采取点成线的可视化来帮助理解。实际上，这条线就是从-99到+99之间我们去定义的七个点；-99和+99自己本身是一个上点，而离点自然会有两个在上点左右旁边是-100和-98，另外点对称就是98和100，而内点在-99到+99之间任意取一个中间值就是50。在线上的每个点都可以看作是一个边界点。记住，我们的边界值分析法也是经常和等价类划分法一起使用的。

      

        在图中，这样去看总共有七个点，那是不是对应着我们用这种方法一定就要写七条用例吗？答案肯定不是的，有更优化的方法，显然我们还是要对产品需求进行更细致的分析。可以稍微回忆一下中学时代学习的集合区间的口诀（提示：开内闭外）

        在上面提示的开内闭外，相比还是模棱两可的理解吧，其实这里的开就是开区间：不包含边界上的点（没有等号，如：a<10），闭就是闭区间：包含边界上的点（有等号,a<=10）。

 2.2步骤

        还是一样，需要对边界值分析法进行步骤的讲解。那么第一点当然还是要明确需求啦；第二点就是确定有效和无效等价类，不过这里只去考虑类型；第三点就是确定边界范围值；第四点也就是提取数据来进行测试用例的编写了。

2.3案例

        这里还是举例qq号码登录的需求，上述要求是6-10位的自然数，这是第一步明确需求的部分。我在下图直接从第二步划分等价类开始描述

        那么很好理解了，我们知道说边界值里的上点分别是6和10，那么对应的离点就是5，7，9，11，内点随意取一个中间值为8。那么我们是不是可以随便就能写出至少七条以上的用例。如下图所示即随意搭配的用例。

 2.4优化

        上面说了优化的形式，有人会觉得这么多条用例是不是会存在冗余的现象？确实现实里会有遇到这样的情况，比如说产品经理对这个需求定义就只针对说大于6位自然数，不要求等于，但是可以等于10位自然数。那么由优化部分的“开内闭外”是不是可以得出说，我们的离点测试部分不需要验证小于6位自然数的数据，因为我们一定会测试6位自然数（上点），产品也定义了要大于6位自然数，那么很显然比6位自然数小的数据更不可能会通过最终测试结果，同理当自然数为十的时候，我们测试了上点然后再对外边的离点进行验证，也就是大于10的自然数，因为小于10的我们已经验证过了内地是符合要求的，所以我们根据这个原则就可以少验证两个点，也更加的精准。

2.5适用场景

        反复强调了在等价类的基础上针对有边界范围值的测试数据输入的地方就需要重点关注边界！如果有遇到以下的词汇描述：如大小/尺寸/重量/最大/最小/至少/至多等修饰词语，那么我们就需要对其使用边界值判定方法也是最科学适用最广的方法。

3.用判定表法解决多条件有依赖关系场景

3.1什么是判定表

        很显然，它是一个以表格形式存在的用来判断多条件逻辑的工具。那么它是这么组成的呢？看下面的图片，用来理解判定表的组成。

3.2步骤

        步骤也和先前的很类似，第一步还是明确需求；第二步开始画判定表，1.列出条件桩和动作桩，2.填写条件项，对条件进行全组合，3.根据条件项对组合确定动作项，4.简化/合并相似规则（有相同的动作）；第三部就是根据规则编写测试用例 。

3.3案例

        我根据网上搜索到的一个需求用例，以及如何列出该判定表的图来直接进行距离，避免我的啰嗦文字。

         下面就是根据上面的需求写出的判定表，是否大于500和是否过期就是其中的条件桩，批准单/提货单/通知单就是其中的动作桩。

         画完判定表后，就是根据判定表来编写测试用例的数据了。

        可以非常直观的看的出来，我们的动作桩里的动作项一般就是最后的预期结果，而条件桩里的条件项就是实际的测试数据，并且条件项也会在用例标题里清楚的体现出来。        

3.3使用场景

        可以看的出来，我们在有多个依赖关系下的使用场景会经常用到判定表的方法，来让有多个输入条件/多个输出结果/输入条件之间有组合的关系。

        但是！判定表一般也只适用在组合数量较少的情况（比如4个条件以下），如果是大于四个条件的话最好使用正交法（因为比较少用，我在这就不强调了，感兴趣的可以看下面的这个链接做拓展）。正交实验法设计测试用例_qingyangfeng的博客-CSDN博客_正交法测试用例

4.用流程图来解决业务测试覆盖场景

4.1流程图介绍

        流程图大家应该都多多少少有接触过，在企业中流程图一般是用来说明某个过程，在我们测试涉及到的定义则是为了来梳理业务用例。一个完整的流程图一般会包含开始结束/执行的进程/判断语句/输入输出数据/箭头流向等相关符号定义。我在这里不多概述，放一个详细描述流程图的博客链接去了解。包含了说怎么去设计流程图的工具，还有流程图的图解定义。程序员必备画图技能之——流程图_码上得天下的博客-CSDN博客_程序员流程图

4.2案例

        因为这里基本上用到的都是常规的业务流程，我直接以银行atm机的业务流程规范来进行举例，观察下图常见的atm机的逻辑流程，不能看出由开始到结束的语句之间存在各种分支和判断语句，也走向不同的输出结果。

        

根据这个用例各个条件分支能够判断出来会有下图的测试用例

 4.3拓展---冒烟测试

        有这样的一种场景，当我们在正式开始一个测试项目之前，我们会对项目是否具备可测试性进行验证，这样的目的是为了避免项目不具备可测性，而去投入不必要的时间和人力成本。这样的测试就称为冒烟测试，一般对项目进行必要功能的验证，如果必要功能都未能实现就不进行正式的开始。

5.错误推测法

        这个方法的场景，也很好理解，在工作时若遇到时间紧任务量大的项目，我们可以根据经验推测有可能出现的故障。在测试完毕后，我们又时间充裕，则根据经验或者测试过程中出现的错误进行复测。这个在很多时候能够起到最大降低时间成本的方法，严格来说并不是一个用例设计的方法，更是一种应用场景。

6.总结

        这次主要是对几个会在项目中常见的场景做出了测试方法手段的分配，希望能够很好的应用上在平常的测试场景下。