1.测试用例的基本要素
测试用例是为了实施测试而向被测试的系统提供的一组集合，这组集合包括：测试环境、操作步骤、测试数据、预期结果等要素；
测试用例的标准：对比好坏代码的评价标准：
- 用例表达清楚，无二义性；
- 用例可操作性强；
- 用例的输入与输出明确，一条用例只有一个预期结果；
- 用例的可维护性好；
- 用例对需求的覆盖率高；
- 暴露程序Bug的能力强大；
2.测试用例给我们带来的好处
1）测试执行者的依据
2）使得工作可重复，自动化测试的基础
3）评估需求覆盖率
总体的测试用例的个数，覆盖率高，缺陷少
4）用例的复用
5）积累测试的方法思路以供后续借鉴
- 使用中带来困惑：
测试用例的设计是耗是耗时耗力的工作，往往涉及测试用例所花费的时间比执行所花费的时间还多。
- 解决如下问题：
不知道是否较全面的测试了所有功能测试的覆盖率无法衡量，对新版本的重复测试很难实施，存在大量冗余测试影响测试效率。
3.测试用例的设计方法
3.1 测试用例的总体设计方法
3.1.1 基于需求的设计
RBT(Requirements Based Testing)是基于需求的测试方法，会使测试更加有效，因为它使测试专注于质量问题产生的根源，即需求。它是一种最基根本的软件测试。
关注以下两大关键问题：
1）验证是否正确、完整、无二义性，并且逻辑一致；
2）要从“黑盒”的角度出发，设计出充分并且必要的测试集，以保证设计和代码都能完全符合需求；
3.2 具体的设计方法
3.2.1 等价类
根据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例通过，则认为所代表的等价类测试通过这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。
强调输入的边界值
- 有效等价类：对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类型验证程序是否实现了规格说明书所规定的功能和性能；（满足用户需求）
- 无效等价类：根据需求说明书，不满足需求的集合；(不满足用户需求)
- 等价类只考虑输入域的分类，没有考虑输入域的组合，需要其他的设计方法和补充；
3.2.2 边界值
强调输入和输出的边界值（注意开闭区间）
边界值分析就是对输入或输出的边界值进行测试的一种黑盒测试方法，通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
3.2.3 因果图
强调输入和输出之间的关系
因果图是一种简化了的逻辑图，能直观地表明程序输入条件（原因）和输出动作（结果）之间的相互关系。因果图
法是借助图形来设计测试用例的一种系统方法，特别适用于被测试程序具有多种输入条件、程序的输出又依赖于输
入条件的各种情况。
因果图的需要掌握的知识：
1）恒等
如果原因为真，那么结果必定为真
2）与
只有2个原因都为真，那么结果为真
3）或
2个原因中有一个为真时，结果就为真
4）非
只有原因为假，结果才为真
因果图设计用例的步骤如下：
（1）分析所有可能的输入和可能的输出
（2）找出输入与输出之间对应的关系
（3）画出因果图
（4）把因果图转换成判定表
（5）把判定表对应到每一个测试用例
画因果图不一定要把所有的关系列举出来（显示==隐藏）
在判定表中可以看出：
画判定表，比如条件为n个,输出取值有m，表的列数为：m^n（m的n次方）
因果法设计测试用例可以帮助测试人员清理输入和输出的关系，但是对于比较复杂的输入和输出，会耗费大量时间
3.2.4 正交排列
正交法的目的是为了减少测试用例，用尽最少的用力覆盖输入的两两组合
正交设计实验是研究多因素水平的一种设计方法，它是根据正交法，由实验因素的全部水平组合中挑选出部分有代表性的点进行实验，通过对这部分实验结果的分析了解全面实验的情况，找出最优的水平组合。正交实验设计是一种基于正交表的、高效率、快速、经济的实验。
因素（Factor）：在一项实验中，考察的变量
水平（位级(Level）：在试验范围内，因素被考察的值称为水平（变量的取值）
正交表的构成：
行数(Runs)：正交表的行的个数，即实验的次数，用N表示
因素数(Factors)：正交表中列的个数，用C表示
水平数(Levels)：任何单个因素能够取得的值的最大个数。正交表中的包含的值为从0到数“水平数-1“或从1到”水平数“，用T表示
正交表的表达形式：L=行数（水平数*因素数）（L=N(TC)）N=C(T-1)+1;
正交表的两条性质：
每一列中个数字出现的次数都是一样多；
任何两列所构成的各有序数对出现的次数都一样多；
正交法设计测试用例的步骤：
1）有哪些因素（变量）
2）每个因素有哪几个水平（变量的取值）
3）选择一个合适的正交表
4）把变量的值映射到表中
5）把每一行的各因素水平的组合作为一个测试用例
6）加上你认为可疑但没有在表中出现的用例组合
（类似工具可以使用微软的PICT工具）
3.2.5 场景设计法
现在的软件几乎都是用事件触发来控制流程的，事件触发时的场景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。该方法可以较生动地描绘出事件触发时的 场景，有利于测试设计者设计测试用例，使测试用例更容易理解和执行。
典型的应用是业务流程法，一个业务流程不一定是一个场景
3.2.6 错误猜测法
错误猜测法是经验丰富的测试人员喜欢使用的一种测试方法。
三种来源：
- 业务流程比较熟悉
- 用户反馈
- 缺陷故障库（上线之后发现的故障）
没有上线之前叫bug，上线之后的叫故障，是很严重的
4.测试用例的粒度和评价
4.1 测试用例的粒度
好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试。
粒度：指测试用例编写的详细程度。
最简单的测试用例是测试的纲要，仅仅指出要测试的内容，如探索性测试中的测试设计，仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。而最复杂的测试用例就会具体到界面元素的操作步骤，指定测试的方法和工具等。
（1）测试用例写的过于复杂或详细，会带来两个问题：一个是效率问题，另一个是维护成本问题。另外，测试用例设计的过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维。
（2）测试用例写的过于简单，则可能失去了测试周例的意义。过于简单的测试测试用例设计其实并没有进行“设计”，只是把需要测试的功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个简单的测试计划，提醒测试人员测试的主要功能包括哪些而已。测试用例设计的本质应该是在测试过程中理解需求，检验需求，并把对软件系统的策划方法的思路记录下来，以便指导将来的测试。
把握好力度实测实用例设计的关键，也将影响测试用例设计的效率和效果，应该根据项目的实际情况，测试资源情况来决定设计出怎样粒度的测试用例。
主要考虑可以参考如下内容：
- 产品的质量要求；
- 项目对用例的要求；
- 测试时间和资源是否充分；
但是不管用例怎样简化，都不应该省略
5.2 测试用例的评价
- 同行评审
- 用户检查
- 项目组评审
