设计测试用例的方向

Posted 2021-09-03 怪人叙谎言

测试用例的设计方法
基于需求的测试方法
等价类
边界值
因果图
正交排列
场景设计法
错误猜测法
测试用例的概念：
测试用例是为了实施测试而向被测试的系统提供一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素
评价测试用例的标准：
用例表达清楚，无二义性
用例可操作性强
用例的输入与输出明确，一条用例只能有一个预期结果
用例的可维护性好
用例对需求的覆盖率高
暴露程序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）测试时间和资源是否充分
测试用例的评价
分为：
同行评审 
用户检查 
项目组评审