测试用例的设计方法总结

了解

测试用例是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：(标题、)测试环境【含设备及系统】、操作步骤、测试数据、预期结果(、重要性)等要素

评价标准：

• 用例表达清楚，无二义性
• 用例可操作性强【容易操作，可执行力强，可用工具进行测试】
  eg:测试10000人同时操作，用loaderrunner
• 用例的输入与输出明确。一条用例只有一个预期结果
• 用例的可维护性好
• 用例对需求的覆盖率高
• 暴露程序Bug的能力强

作用
测试执行者的依据、使得工作可重复，自动化测试的基础、评估需求覆盖率、用例的复用、积累测试的方法思路以供后续借鉴
困扰
测试用例的设计是费时费力的工作，往往设计测试用例所花费的时间比执行所花费的时间还多
解决的问题：
不知道是否较全面的测试了所有功能，测试的覆盖率无法衡量，对新版本的重复测试很难实施存在大量冗余测试影响测试效率

设计方法

总体而言是基于需求的设计RBT是基于需求的测试方法，会使测试更加有效，因为它使测试专注于质量问题产生的根源：需求

基于需求的测试是一种最根本的软件测试，重点关注两大问题：

1. 验证需求是否正确、完整、无二义性，并且逻辑一致
2. 要从“黑盒”的角度，设计出充分并且必要的测试集，以保证设计和代码都能完全符合需求

具体设计方法

等价类
依据需求将输入(特殊情况下考虑输出)划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题

• 有效等价类：对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能
• 无效等价类：根据需求说明书，不满足需求的集合

缺陷：只考虑输入域的分类，没有考虑输入域的组合

边界值
是对输入或输出的边界值进行测试的一种黑盒测试方法
通常边界值分析法是作为对等价类划分法的补充，其测试用例来自等价类的边界

因果图
是一种简化了的逻辑图，能直观地表明程序输入条件和输出动作之间的相互关系
因果图法是借助图形来设计测试用例的一种系统方法，特别适用于被测试程序具有多种输入条件、程序的输出又依赖于输入条件的各种情况

四种关系：

设计测试用例步骤：

1. 分析需求中所有输入输出
2. 找出输入输出间关系
3. 画因果图
4. 根据因果图画判定表(2^输入个数种情况)
5. 根据判定表设计测试用例

正交法【PICT工具】
因果法设计用例过多时使用：正交法目的是为了减少用例数目。用尽量少的用例覆盖输入的两两组合

正交试验设计是研究多因素多水平的一种设计方法，它是根据正交性，由试验因素的全部水平组合中挑选出部分有代表性的点进行试验，通过对这部分试验结果的分析了解全面试验的情况，找出最优的水平组合
正交试验设计是一种基于正交表的、高效率、快速、经济的试验

因素（T-因素数）：在一项试验中，凡欲考察的变量
水平（C-水平数）：在试验范围内，因素被考察的值称为水平，即变量的取值

因素表必须保证所有变量的取值数相等

正交表的行数【初时测试用例个数】：N=(C-1)*T+1
正交表的表示：L=N(TC)

性质：

1. 每一列中各数字出现的次数都一样多
2. 任何两列所构成的各有序数对出现的次数都一样多

---

设计测试用例步骤：

1. 找出所有因素【变量】
2. 找出每个因素的水平【变量的取值】
3. 根据T&C确认正交表
4. 画正交表
5. 补充认为可能但没有在表中出现的测试用例

场景设计法
现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流
可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，使测试
用例更容易理解和执行

典型的应用：
用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向

• 基本事件流：业务每个操作正常完成，没有异常情况产生，直到操作完成
• 备选事件流：
  操作异常：流程不能进行下去【流程中断】
  操作有误：经过反复修改后流程可以继续正常运行

错误猜测法
错误猜测法是经验丰富的测试人员喜欢使用的一种测试方法

基于经验和直觉，找出程序中认为可能出现的错误，有针对性地设计测试用例。经验可能来自于在对某项业务的测试较多，也可以来自于售后用户的反馈意见，或者从故障管理库中整理bug。梳理出产品以往哪些地方容易出现问题，问题越多的地方，潜在的bug也就越多

其他

测试用例的粒度
好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试
测试用例可以写得很简单，也可以写得很复杂
最简单的测试用例是测试的纲要，仅仅指出要测试的内容，如探索性测试中的测试设计，仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等
最复杂的测试用例就像飞机维修人员使用的工作指令卡一样，会指定输入的每项数据，期待的结果及检验的方法， 具体到界面元素的操作步骤，指定测试的方法和工具等

---

• 测试用例写得过于复杂或详细，会带来两个问题：一个是效率问题，另一个是维护成本问题。另外，测试用例设计得过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维
• 测试用例写得过于简单，则可能失去了测试周例的意义。过于简单的测试用例设计其实并没有进行“设计”，只是把需要测试的功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个简单的测试计划，提醒测试人员测试的主要功能包括哪些而已测试用例的设计的本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试
  如何把握好粒度是测试用例设计的关键，也将影响测试用例设计的效率和效果。应该根据项目的实际情况、测试资源情况来决定设计出怎样粒度的测试用例

---

主要考虑可以参考如下内容：

• 产品的质量要求
• 项目对用例的要求
• 测试时间和资源是否充分
  【不管用例怎么简化，都不应该省略】

---

测试用例的评价
如何提高测试用例设计的质量？就像软件产品需要通过各种手段来保证质量一样，测试用例的质量保证也需要综合使用各种手段和方法
评审分为正式和非正式评审：
同行评审
用户检查
项目组评审

• 测试用例的检查可以有多种方式 但是最敏捷的应当属临时的同行评审。同行评审，尤其是临时的同行评审，应该演变成类似结对编程一样的方式。从而体现敏捷的“个体和交互比过程和工具更有价值”，要强调测试用例设计者之间的思想碰撞，通过讨论、协作来完成测试用例的设计，原因很简单，测试用例的目的是尽可能全面地覆盖需求，而测试人员总会存在某方面的思维缺陷，一个人的思维总是存在局限性
• 除了同行评审，还应该尽量引入用户参与到测试用例的设计中来，让用户参与评审，从而体现敏捷的“顾客的协作比合同谈判更有价值”这一原则。这里顾客的含义比较广泛，关键在于如何定义测试，如果测试是对产品的批判，则顾客应该指最终用户或顾客代表；如果测试是被定义为对开发提供帮助和支持，那么顾客就是程序员
• 由测试负责人组织协调开展会议，用例编写人对用例进行讲解，参会人员有异议的当场提出