设计测试用例
等价类测试方法是把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数有代表性的数据作为测试用例。使用等价类划分方法设计测试用例要经历划分等价类（列出等价类表)和选取测试用例两步。它将不能穷举的测试过程进行合理分类，从而保证设计出来的测试用例具有完整性和代表性。
二、边界值：
介绍：边界值分析法就是对输入或输出边界值进行测试的。也是一种黑盒测试。边界值分析法通常作为等价类划分法的补充.其测试用例来自等价类的边界;
长期的经验得知,大量的错误是发现在输入或输出范围的边界上，而不是发生再输入输出范围的内部，因此针对各种边界情况设计测试用例，可以查出更多错误.。
等价类划分法的区别:等价类划分法可以挑选等价范围内任意一个数据作为代表边界值分析法要求每个边界值都要作为测试条件边界值分析法不仅考虑输入条件,同样考虑输出产生的测试情况。
三、因果图法
定义：因果图法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况
特点:
1.考虑输入条件的相互制约及组合关系
2.考虑输出条件对输入条件的依赖关系。
核心因果图法比较合适输入条件比较多的情况，测试所有的输入条件的排列组合。
因果图中的符号
因果图法基本步骤：
1.找出所有的原因，原因即输入条件或输入条件的等价类。
2.找出所有的结果,结果即输出条件。
3.明确所有输入条件之间的制约关系以及组合关系。哪些条件不能组合到一 起，哪些条件可以组合到一起
4.明确所有输出条件之间的制约关系以及组合关系。哪些输出结果不能同时输出， 哪些输出结果可以同时输出
5.找出什么样的输入条件组合会产生哪种输出结果。
6.把因果图转换成判定表/决策表。
7.为判定表/决策表中的每一-列表示的情况设计测试用例。
四、判定表法：（类似因果图，可以由因果图得出）
定义：判定表也称决策表,是分析和表达多逻辑条件下执行不同操作的工具。它能够将复 杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此，利用判定表能够设计出完整的测试用例集合。 在一-些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即:针对不同逻辑条件的组合值，分
别执行不同的操作。判定表适合于处理这类问题。
使用场景：适合于有多个输入和多个输出,输入和输出之间有相互的组合关系,输入输出之间有相互的制约和依赖关系
组成：判定表是由条件桩、动作桩、条件项、动作项四部分组成，如下
条件桩(Condition Stub) :列出了问题得所有条件。通常认为列出的条件的次序无关紧要。
动作桩(Action Stub) :列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
条件项(Condition Entry) :列出针对它左列条件的取值。在所有可能情况下的真假值。
动作项(Action Entry) :列出在条件项的各种取值情况下应该采取的动作。
规则：任何一个条件组合的特定取值及其相应要执行的操作称为规则。在判定表中贯穿 条件项和动作项的一列就是一条规则。显然判定表中列出多少组条件取值，也就有多少条规则，既条件项和动作项有多少列。
五、正交表法
定义：正交法，也叫正交实验法或者正交排列法,就是使用最小的测试过程集合获得最大的测试覆盖率。
"正交实验"是研究多因素、多水平的一种实验方法，它利用正交表来对实验进行设计，通过少数实验代替全面的实验。
在一项实验中，把影响试验结果的量称为试验因素(因子)，简称因素。因素可以理解为试验过程中的自变量试验结果可以看成因素的函数。
在试验过程中，每一个因素可以处于不同的状态或状况，把因素所处的状态或状况，称为因素的水平，简称水平。
正交表套用：
六、场景法
定义：从起点，通过一系列操作步骤（事件)，达成某一结果，到终点的过程测试。在通过了场景测试后，再通过其他方法进行更为细腻的测试。
七、功能图法/流程分析法
定义：流程分析法主要是针对测试场景类型属于流程测试场景的测试项下的测试子项进行设计，是从白盒测试设计方法中的路径覆盖分析法借鉴过来的一种方法。在白盒测试中，路径就是指函数代码的某个分支组合，路径覆盖法需要构造足够的用例覆盖函数的所有代码路径。
路径覆盖法:把所有测试条件写成测试用例.白盒是根据代码分支分析写测试用例。
在黑盒测试中，若将软件系统的某个流程看成路径的话，则可以针对该路径使用路径分析的方法设计测试用例。黑盒测试是看文档来写测试用例.,不需要看代码。
广度图：
深度图：
步骤：
1.详细了解需求;
2.根据需求说明或界面原型，找出业务流程的各个页面以及各页面之间的流转关系;
3.画出业务流程;
4.写用例，覆盖所有的路径分支。
八、错误推断法
定义：基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。也就是，根据经验,列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。
使用场景：适用于项目时间比较短促，任务比较繁重的情况下，而且测试经验较多。
九、测试用例的力度
简单：仅仅试测试的纲要，可能只包含测试的内容。简单的测试用例其实并没有进行"设计"，而仅仅是记录.只是提醒测试人员主要功能有哪些。
复杂：包含具体的输入项、每一个步骤、期待的结果。
中庸：过于简单，会导致测试有遗漏，而且根据测试执行人员的水平不同导致偏差较大。过于复杂，会导致效率太低，维护成本太高，限制测试人员的思维一般在工作中都介于两者之间。
十、总结
测试用例的本质（基于需求)：
理解需求、反映需求，忠于需求
需求会变化，变化的"及时响应变更比遵循计划更有价值"
原则：
1.根据程序的重要性和一旦发生故障带来的损失，来确定测试等级和测试重点
2.认真选择测试策略。用尽可能少的鸿试用例发现尽可能多的错误。测试用例不足则会导致风险的增大;测试过度导致资源的浪费。需要找到平衡点
方法选取：
1.先关注主要功能也业务流程、业务逻辑是否正确实现，考虑场景法
2.需要输入数据的地方，考虑等价类划分法
3.在任何情况行都使用边界值法
4.如果程序的功能中包含输入条件的组合情况，则选取因果图和判定表法（判定表是因果图的最终结果）
5.对于配置类软件，需要考虑参数的组合情况，考虑使用正交排列法
6.对照程序逻辑，如果发现没有达到要求的覆盖标准。适当补充更多的测试用例
7.采用错误推断法，追加其他测试用例
