共计 2088 个字符，预计需要花费 6 分钟才能阅读完成。
测试用例的设计办法
基于需要的测试方法
等价类
边界值
因果图
正交排列
场景设计法
谬误猜测法
测试用例的概念：
测试用例是为了施行测试而向被测试的零碎提供一组汇合，这组汇合蕴含：测试环境、操作步骤、测试数据、预期后果等因素
评估测试用例的规范：
用例表白分明，无二义性
用例可操作性强
用例的输出与输入明确，一条用例只能有一个预期后果
用例的可维护性好
用例对需要的覆盖率高
裸露程序 Bug 的能力强
测试用例给咱们带来的影响
益处
测试执行者的根据
使得工作可反复，自动化测试的根底 (自动化测试的前提：性能稳固，页面变动小)
评估需要覆盖率
用例的复用积攒测试的办法思路以供后续借鉴
应用中带来的困扰
测试用例的设计是费时费力的，往往测试用例所破费的工夫比执行所破费的工夫还多
解决如下问题
不晓得是否较全面的测试了所有性能
测试的覆盖率无奈掂量
对新版本的反复测试很难施行
存在大量冗余测试，影响测试效率
测试用例的设计办法
基于需要的设计
会使测试更加无效，因为他使测试专一于品质问题产生的本源，即需要
须要重点关注以下两个问题：
1. 验证需要是否正确、无二义性，并且逻辑统一
2. 要从黑盒测试的角度，设计出充沛并且必要的测试集，以保障设计和代码都能完全符合需要
具体的设计办法
1. 等价类
概念：根据需要将输出划分为若干个等价类，从等价类当选取出一个测试用例，如果这个测试用例验证通过则认为所代表的等价类测试通过，这样就能够用较少的测试用例达到尽量多的性能笼罩，解决了不能穷举测试的问题
等价类划分
无效等价类：对于程序的规格说明书是正当的、有意义的输出数据形成的汇合，利用无效等价类验证程序是否实现了规格说明书中所规定的性能和性能
有效等价类：依据需要说明书，不满足需要的汇合
2. 边界值
概念：对于输出或输入的边界值进行测试的一种黑盒测试方法。通常边界值分析法是对等价类划分法的补充，这种状况下，其测试用例来自等价类的边界
3. 因果图
概念：因果图是一种简化了的逻辑图，可能直观的表明程序输出条件 (起因) 和输入动作 (后果) 之间的互相关系。因果图是借助图形设计测试用例的一种零碎办法，特地实用于被测试程序具备多种输出条件、程序的输入又依赖于输出条件的各种状况
因果图法设计测试用例的步骤如下：
（1）剖析所有可能的输出与可能的输入
（2）找出输出与输入之间的对应关系
（3）画出因果图
（4）把因果图转换成断定表
（5）把断定表对应到每一个测试用例
注：因果法设计测试用例能够帮忙测试人员理清输出和输入的关系，然而对于较简单的输入输出，会消耗大量的工夫，网页游戏
4. 正交排列
概念：钻研多因素、多程度的一种设计办法，依据正交性，由试验因素的全副程度组合中挑选出局部有代表性的点进行试验，通过对这部分试验后果的剖析理解全面试验的状况，找出最优的程度组合。正交试验设计是基于正交表的、高效率、疾速、经济的试验
目标：缩小用例数目，用尽量少的用例笼罩输出的两两组合
首先先来介绍两个名词：
因素：在一项试验中，凡欲考查的变量称为因素 (变量)
程度：在试验范畴内，因素被考查的值称为程度 (变量的取值)
正交表的形成：
行数：正交表中行的个数，即试验的次数，用 N 代表
因素数：正交表中列的个数用，用 C 代表
程度数：任何单个因素可能获得的值的最大个数，用 T 代表
正交表的示意模式：L = 行数 (程度数 * 因素数) ==> L = N(TC)
正交表的两条性质：
1. 每一列中各数字呈现的次数一样多
2. 任何两列所形成的各有序数对呈现的次数都一样多
正交法设计测试用例的步骤：
（1）有哪些因素 (变量)
（2）每个因素有哪几个程度(变量的取值)
（3）抉择一个适合的正交表
（4）把变量的值映射到表中
（5）把每一行的各因素程度的组合作为一个测试用例
（6）加上你认为可疑且没有在表中呈现的用例组合
5. 场景设计法
概念：当初的软件简直都是用事件触发来管制流程的，事件触发时的情景便造成了场景，而同一事件不同的触发程序和处理结果就造成事件流。该办法能够比拟活泼的描绘出事件触发时的情景，有利于测试设计者设计测试用例，使测试用例更容易了解和执行
典型的利用：用业务流把各个孤立的性能点串起来 (业务测试)，为测试人员建设整体业务的感觉，从而防止陷入性能细节漠视业务流程要点的错误倾向
6. 谬误猜测法
概念：是经验丰富的测试人员喜爱用的一种测试方法
教训的三个起源：
（1）来自于对某项业务的测试较多
（2）来自于售后用户的反馈意见
（3）从故障治理库中整顿 Bug
什么是测试用例的有效性？？
（1）测试用例对应的性能曾经删除，不可操作了
（2）执行一条测试用例未发现 Bug，理论该处有 Bug
（3）执行一条测试用例发现了 Bug
（4）执行一条测试用例未发现 Bug，理论此处 Bug 已批改
测试用例的粒度
粒度：测试用例编写的具体水平
（1）测试用例写的过于简单或具体，会带来两个问题：一个是效率问题，一个是保护老本问题
（2）测试用例写的过于简略可能会失去了测试周例的意义
编写测试用例时能够参考以下几个方面：
（1）产品的品质要求
（2）我的项目对用例的要求
（3）测试工夫和资源是否充沛
测试用例的评估
分为：
同行评审
用户查看
项目组评审
