测试用例的基本要素
概念：
测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。
评价测试用例的标准：
- 表达清楚，无二义性。
- 可操作性强。
- 输入与输出明确。
- 一条用例只有一个预期结果。
- 可维护性好。
- 对需求的覆盖率高。
- 暴露程序Bug的能力强。
测试用例的好处
- 是测试执行者的依据
- 使得工作可重复，是自动化测试的基础
- 评估需求覆盖率
- 用例的复用积累
- 测试的方法思路以供后续借鉴
使用中带来困扰
测试用例的设计是费时费力的工作，还存在如下问题：
- 不知道是否较全面的测试了所有功能
- 测试的覆盖率无法衡量
- 对新版本的重复测试很难实施
- 存在大量冗余测试，影响测试效率
测试用例的设计方法
总体设计方法
基于需求的设计
RBT( Requirements-Based Testing)是基于需求的测试方法，会使测试更加有效，因为它使测试专注于质量问题产生的根源，即需求。
基于需求的测试是一种最根本的软件测试，重点关注以下两大关键问题。
- 验证需求是否正确、完整、无二义性，并且逻辑一致。
- 从“黑盒”的角度，设计出充分并且必要的测试集，以保证设计和代码都能完全符合需求。
具体的设计方法
等价类
思路：输入的集合是无穷的, 不能全都覆盖到。
依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。
- 有效等价类
对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能 - 无效等价类
根据需求说明书，不满足需求的集合。
等价类只考虑输入域的分类，没有考虑输入域的组合，需要其他的设计方法和补充。
边界值
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
因果图
因果图是一种简化了的逻辑图，能直观地表明程序输入条件（原因）和输出动作（结果）之间的相互关系。因果图法适用于被测试程序具有多种输入条件、程序的输出又依赖于输入条件的各种情况。
- 恒等
如果原因为真，那么结果必定为真。 - 与
只有2个原因都为真，那么结果为真。 - 或
2个原因中有一个为真时，结果就为真。 - 非
只有原因为假，结果才为真。
因果图法设计测试用例的步骤：
- 分析所有可能的输入和可能的输出。
- 找出输入与输出之间的对应关系。
- 画出因果图。
- 把因果图转换成判定表。
- 把判定表对应到每一个测试用例。
因果法设计测试用例可以帮助测试人员理清输入和输出的关系，但是对于比较复杂的输入和输出，会耗费大量时间。
正交排列
正交法的目的是为了减少用例数目。用尽量少的用例覆盖输入的两两组合。
正交试验设计(Orthogonal experimentaldesign)是研究多因素多水平的一种设计方法，它是根据正交性，由试验因素的全部水平组合中挑选出部分有代表性的点进行试验，通过对这部分试验结果的分析了解全面试验的情况，找出最优的水平组合。
正交试验设计是一种基于正交表的、高效率、快速、经济的试验。
- 因素（Factor）：在一项试验中，凡欲考察的变量称为因素（变量）
- 水平（位级）（Level）：在试验范围内，因素被考察的值称为水平（变量的取值）
正交表的构成：
- 行数(Runs)：正交表中的行的个数，即试验的次数,用N代表。
- 因素数(Factors)：正交表中列的个数，用C代表。
- 水平数(Levels)：任何单个因素能够取得的值的最大个数。正交表中的包含的值为从0到1
- “水平数-1”或从1到“水平数”，用T代表。
正交表的表示形式： L=行数(水平数*因素数) L=N(TC)
正交表性质：
- 每一列中各数字出现的次数都一样多。
- 任何两列所构成的各有序数对出现的次数都一样多。
正交法设计测试用例的步骤：
- 有哪些因素（变量）
- 每个因素有哪几个水平（变量的取值）
- 选择一个合适的正交表
- 把变量的值映射到表中
- 把每一行的各因素水平的组合作为一个测试用例
- 加上你认为可疑且没有在表中出现的用例组合
场景设计法
现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。
该方法可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，使测试用例更容易理解和执行。典型的应用是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向。
错误猜测法
基于经验和直觉，找出程序中你认为可能出现的错误，有针对性地设计测试用例。经验可能来自于在对某项业务的测试较多，也可以来自于售后用户的反馈意见，或者从故障管理库中整理bug。梳理出产品以往哪些地方容易出现问题，问题越多的地方，潜在的bug也就越多。
测试用例的有效性
测试用例对应的功能已删除，不可操作了
执行一条测试用例未发现BUG，实际该处有BUG
执行一条测试用例发现了BUG
执行一条测试用例未发现BUG，实际该处BUG已修改
测试用例的粒度和评价
测试用例的粒度
粒度：指测试用例编写的详细程度。
测试用例的设计的本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。如何把握好粒度是测试用例设计的关键，也将影响测试用例设计的效率和效果。
- 测试用例写得过于复杂或详细，会带来两个问题：一效率问题，二是维护成本问题。测试用例设计得过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维。
- 测试用例写得过于简单，可能失去了测试用例的意义。
应该根据项目的实际情况、测试资源情况来决定设计出怎样粒度的测试用例。主要考虑可以参考如产品的质量要求、项目对用例的要求、测试时间和资源是否充分。
测试用例的评价
测试用例的质量保证需要综合使用各种手段和方法。
- 同行评审
最敏捷的应当属临时的同行评审。同行评审，尤其是临时的同行评审，应该演变成类似结对编程一样的方式。从而体现敏捷的“个体和交互比过程和工具更有价值”，要强调测试用例设计者之间的思想碰撞，通过讨论、协作来完成测试用例的设计，原因很简单，测试用例的目的是尽可能全面地覆盖需求，而测试人员总会存在某方面的思维缺陷，一个人的思维总是存在局限性。因此需要一起设计测试用例。 - 用户检查
应该尽量引入用户参与到测试用例的设计中来，让用户参与评审，从而体现敏捷的“顾客的协作比合同谈判更有价值”这一原则。 - 项目组评审
由测试负责人组织协调开展会议，用例编写人对用例进行讲解，参会人员有异议的当场提出。
