之前文章提到过，测试用例是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。
对比好坏用例的评价标准：
（1）用例表达清楚，无二义性；
（2）用例可操作性强；
（3）用例的输入与输出明确，一条用例只有一个预期结果；
（4）用例的可维护性好（存放时避免PDF形式）；
（5）用例对需求的覆盖率高。
（6）暴露程序的Bug能力强。
注意：应该避免测试用例多种情况混合在一起，容易漏测！！
（1）首先要保证需求的合理性和正确性，要先验证需求；
（2）分析需求，把大需求细化成小需求，根据每一个小需求提炼出功能点，根据每一个功能点发散的考虑它的测试用例，去写测试用例（用具体的设计测试用例的方法）。
基于需求设计测试用例是测试设计和开发测试用例的基础。
第一步就要分析测试需求，验证需求是否正确、完整、无二义性，并且逻辑自洽。在需求正确的基础上细化测试需求，从测试需求提炼出一个个测试点或者测试项，然后根据每一个测试点进行测试用例的设计；
在分析测试需求时，一般分为功能测试需求和非功能测试需求。
1. 功能需求测试分析
对于功能测试中，可以借助功能框图来帮助我们进行测试的需求分析。概括起来，功能测试需求包括以下，通常包括以下几个方面。
（1）系统各个功能界面的验证
（2）借助业务把功能串起来进行测试
（3）功能的一致性，交互性（多功能互操作）的测试
（4）系统的不同输入，结果输出的业务数据测试。
（5）功能的错误操作，异常操作的测试（属于负面测试）
（6）功能实现用到的算法验证，有时需要用运代码评审
（7）用户操作的易用性，用户体验，往往结合功能测试同时验证
针对具体的需求，可以根据业务分类，用户角色（餐厅的会员系统）或者用户操作区域等将系统的功能分解成若干个功能模块，然后按照功能模块分别进行测试需求分析。按照功能模块划分，业务模块划分是最常见的做法。
2. 非功能需求测试分析
非功能测试需求主要涉及性能，安全性，可靠性，兼容性，易维护性和可移植性等。
从测试需求分析来看，每一类非功能特性测试都需要根据需求单独分析。他们之间可能会存在相互影响，如安全性越高，就越有可能给易用性，性能带来更大的挑战。
这里要说明的是对于每一个应用软件系统，非功能特性的质量需求都是存在的，但是不同的项目类型对各个非功能特性的要求是不一样的，这个需要根据具体的项目、具体需求和不同产品应用的特点进行分析。
（1）纯客户端软件，比如字处理软件（Word，PPT)，媒体（音频/视频）播放软件（电脑自带的）等。这类软件对系统的功能测试要求是最低的，但是对兼容性和稳定性，可移植性有一定的要求。
（2）企业内部的客户端/服务端（C/S)应用系统。比如电子邮件，即时通信系统（飞Q，企业QQ）等，在系统功能测试需求上比纯客户端复杂，要求功能正确，稳定性能好。但是整体上看，对性能，安全性，兼容性要求不高。
（3）外部大型复杂网络应用系统，比如电子商务，网上银行，视频网站（腾讯，优酷）等，除了有复
杂的系统的功能测试需求外，在系统的性能，安全性，兼容性，容错性，可靠性等都有很高的要求。
为了解决测试用例无法穷举的情况，把输入分成若干个等价类，每一个等价类当中选一个测试用例进行测试，如果这个测试用例测试通过，我们就认为这个测试用例代表的等价类测试通过。
分为有效等价类和无效等价类。
- 有效等价类：对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类验
证程序是否实现了规格说明中所规定的功能和性能- 无效等价类：根据需求说明书，不满足需求的集合。
等价类只考虑输入域的分类，没有考虑输入域的组合，需要其他的设计方法和补充。
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
一般设计测试用例的时候会把等价类和边界值结合在一起。
错误猜测法是对被测试软件设计的理解，过往经验以及个人直觉，推测出软件可能存在的缺陷，从而针对性地设计测试用例的方法。
这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，还有个人的经验和直觉。
错误推测法和目前流行的“探索式测试方法”的基本思想一致，这类方法在敏捷开发模式下的投入产出比很高，被广泛应运于测试。
根据测试人员的知识，经验去推断可能会出现问题的功能模块，有针对性的去设计测试用例
是一种补充的设计测试用例的方法，测试人员可以用其他设计测试用例的方法设计需求的测试用例，用错误猜测法作为一种补充的方式。
这个方法的缺点是难以系统化，并且过度依赖个人能力。
把各个孤立的功能点按照一定的策略组合起来，形成一个应用场景。
现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。该方法可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，是测试用例更容易理解和执行。
典型的应用是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节，忽视业务流程要点的错误倾向。
总结：找出场景当中的每一个功能点，根据每一个功能点的正常和异常的情况去设计测试用例。
例如：ATM取款机取款场景（流程）
插卡——选择语言——输入密码——输入取款金额——取钱——退卡
因果图是一种简化了的逻辑图，能直观地表明程序输入条件（原因）和输出动作（结果）之间的相互关系。因果图法是借助图形来设计测试用例的一种系统方法，特别适用于被测试程序具有多种输入条件、程序的输出又依赖于输入条件的各种情况。
当输入有多个，不同的输入组合有不同的输出时，可以使用因果图法来设计测试用例。
因果图的需要掌握的基本知识：恒等，与，或，非。
1. 恒等：
如果原因为真，那么结果必定为真。 例如：动物园运来大熊猫，动物园一定有大熊猫。
2. 与:
输入有多个条件，多个条件都为真的时候，输出为真。
3. 或:
输入有多个条件，其中一个条件为真，输出为真。
4. 非:
输入为真，输出为假。
如何使用因果图法设计测试用例？
1）找出所有的输入和输出；
2）确定不同的输入组合和输出之间的关系；
3）用因果图来表示输入和输出之间的关系；
4）根据因果图画判定表；
5）根据判定表写测试用例；
练习：
（1）输入：订单已提交，订单合计金额大于300元，有红包
输出：有优惠 没有优惠
（2）订单已提交，合计金额大于300元，没有红包，有优惠。
订单已提交，合计金额小于300元，有红包，有优惠。
订单已提交，合计金额大于300元，有红包，有优惠。
订单已提交，合计金额小于300元，没有红包，没有优惠。
订单没有提交，没有优惠（红包和金额组合4种情况略）。
（3） 因果图
（4）根据因果图画判定表
（5）写测试用例
（正式写测试用例的时候，一个都不能漏。最后四个测试用例必须分开写，分开测试。）
订单已经提交，金额大于300，有红包，有优惠
订单已经提交，金额大于300，没有红包，有优惠
订单已经提交，金额小于300，有红包，有优惠
订单已经提交，金额小于300，没有红包，没有优惠
订单没有提交，金额大于300，有红包，没有优惠
订单没有提交，金额大于300，没有红包，没有优惠
订单没有提交，金额小于300，有红包，没有优惠
订单没有提交，金额小于300，没有红包，没有优惠
研究多因素、多水平的一种测试用例的设计方法。
根据正交性，在所有的试验组合中找到最优的组合进行测试，通过这些最优组合的解来分析验证整个试验整体的结果。
特点：经济、高效
举个例子：邮箱注册（只讨论以下几个项的填写和不填写）
姓名，email，密码，确认密码，验证码，总共32种情况。
并不是32种情况都要测试，只要选出这几个输入（因素）的最优的取值（水平）组合进行测试。
较少的测试用例去判断整个功能的情况。
因素：输入
水平：输入的取值
正交表的组成：
列：因素数（C），输入的个数
水平数：每一个因素的取值的最大个数（T）
行：L=（水平数-1）*因素数+1
正交表的性质：
1：每一列各数据出现的次数一样多；
2：不同两列不同的数据组合出现的次数一样多。
根据正交表设计法设计测试用例的步骤：
（1）确定因素（输入）
（2）确定每一个因素的水平
（3）找出因素数和水平数
（4）根据因素数和水平数确定正交表的行和列
（5）根据正交表的性质去填充正交表里的数据
（6）根据正交表的每一行设计测试用例
（7）补充正交表里面没有的，但是个人认为可能比较关键的测试用例
例：邮箱注册测试（只讨论以下几个项的填写和不填写）
姓名，email，密码，确认密码，验证码
使用正交设计法：
（1）姓名，email，密码，确认密码，验证码；
（2）填写，不填写
（3）因素数：5 水平数： 2
（4）列=因素数=5，行=（水平数-1）*因素数+1=6
（5）填充数据
（6）测试用例：
姓名填写，email不填写，密码填写，确认密码填写，验证码不填写，注册失败。
姓名不填写，email填写，密码不填写，确认密码不填写，验证码不填写，注册失败。
姓名填写，email不填写，密码填写，确认密码不填写，验证码填写，注册失败。
姓名填写，email不填写，密码不填写，确认密码填写，验证码不填写，注册失败。
姓名不填写，email填写，密码填写，确认密码不填写，验证码填写，注册失败。
姓名不填写，email填写，密码不填写，确认密码填写，验证码填写，注册失败。
（7）补充测试用例
姓名填写，email填写，密码填写，确认密码填写，验证码填写，注册成功。
姓名不填写，email不填写，密码不填写，确认密码不填写，验证码不填写，注册失败。
小结：以上六种设计测试用例的方法都属于黑盒测试设计测试用例的方法。
