本文详细介绍了测试用例设计的概念、输入、设计原则和多种设计方法，包括等价类划分、边界值分析、错误推测等，旨在帮助测试人员有效地设计和执行测试用例，提高软件测试的质量和效率。
第一篇测试文档，大多数是在网上收集。刚看的到这些文档时真是让人惊吓，原来有这么多的信息是第一听到，慨叹一句“学海无崖”哦。
目录
一、 定义
测试用例：为特定目标而开发的一组测试输入、执行条件和预期结果，其目标可以是测试某个程序路径或核实是否满足某个特定的需求。
队列中(In Queue）： 测试用例在排队等待中；
进程中(In Progress）：表示测试正在进行，并且可能会持续一段时间，如果一个测试花费的时间少于一天或两天，只需将它显示在处于排队状态；
阻塞(Block）：一些外部条件 — 如缺少部分功能 — 将无法执行测试；
忽略(Skip）： 已经决定（或被告知）跳过这个测试用例；
通过( Pass）： 终点状态，没问题；
失败(Fail）： 测试用例执行出错；
警告(Warn）： 结果处于 Pass 和 Fail 之间，错误严重性等级较轻，不影响功能和性能；
关闭(Closed）：以前识别出的错误都已经被修正
二、 输入
测试需求分析文档，开始测试用例设计。
三、 用例设计原则
? 测试用例的代表性：能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的以及极限的输入数据、操作和环境设置等。
? 测试结果的可判定性：即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。
? 测试结果的可再现性：即对同样的测试用例，系统的执行结果应当是相同的。
根据需求重要性区分测试用例等级，测试执行阶段可以根据测试用例等级安排测试任务，分为四级：
? 冒烟测试(Smoke testing):在测试中发现问题，找到了一个Bug，然后开发人员会来修复这个Bug。这时想知道这次修复是否真的解决了程序的Bug，或者是否会对其它模块造成影响，就需要针对此问题进行专门测试，这个过程就被称为Smoke Test。属于“黑盒测试”
应用于：每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。
? 关键路径测试(Base path testing): 有时也中基本路径法，在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例的方法。设计出的测试用例要保证在测试中程序的每个可执行语句至少执行一次。属于“白盒测试”
详见: http://www.uml.org.cn/Test/200804036.asp
? 可接受级测试(Acceptability Testing): 有时也叫验收测试，把测试的版本交付测试部门大范围测试以前进行的基本功能的简单测试。因为在把测试的版本交付测试部门大范围测试以前应该先验证该版本对于所测试的功能基本上比较稳定。必须满足一些最低要求。
该级测试用例只要执行一次通过即可，该级测试用例通过意味着可以准备发布了；
? 建议执行的用例，如果有时间，最好执行该级测试用例，但不作为发布的必要条件。
测试用例执行结果 —— 执行时填写，分为通过、失败、警告、阻塞、忽略。
实际项目中，一个测试用例有多个执行步骤，每个步骤可能有不同结果，如步骤 1 通过，步骤 2 失败，步骤 3 被步骤 2 中的失败所阻塞，那么该测试状态如何？单纯指出这个测试用例阻塞或失败都将遗漏重要的信息。因此必须指定双重状态，如 Block/Fail ， Block/Warn ， Skip/Pass ， Skip/Closed 等。然而，如果显示十几个状态，则测试结果可能更难以解释。如何使结果明了又能精确反映实际结果，需要精明选择包括哪些状态。
四、 用例设计方法
等价列划分设计方法是把所有可能的输入数据划分成若干部分（子集），然后从每一个子集中选取少量具有代表性的数据作为测试用例，测试某等价类的代表值就等于对这一类其他值的测试。
详见：http://www.51testing.com/html/200811/n97668.html
边界条件指的是输入和输入等价类中刚好处于边界、或超过边界或小于边界的状态，使用边界值分析方法设计测试用例应先确定边界情况，然后选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。
详见：http://www.51testing.com/html/59/n-97459.html
错误推测法就是根据经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法。
详见：http://www.51testing.com/html/74/n-97674.html
前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）.
详见：http://www.51testing.com/html/77/n-97777.html
（Decision Table）是分析和表达多逻辑条件下执行不同操作的情况下的工具.在程序设计发展的初期,判定表就已被当作编写程序的辅助工具了.由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确.
因果图方法最终生成的就是判定表
详见：http://www.51testing.com/html/89/n-73189.html
利用因果图来设计测试用例时, 作为输入条件的原因与输出结果之间的因果关系,有时很难从软件需求规格说明中得到。往往因果关系非常庞大,以至于据此因果图而得到的测试用例数目多的惊人，给软件测试带来沉重的负担，为了有效地,合理地减少测试的工时与费用,可利用正交实验设计方法进行测试用例的设计。
正交实验设计方法:从大量的测试数据中挑选出适量的、有代表性的测试数据，依据伽罗瓦（Galois）理论导出的“正交表”,从而合理地安排测试的一种科学实验设计方法.
详见： http://www.51testing.com/html/75/n-96675.html
一个程序的功能说明通常由动态说明和静态说明组成.动态说明描述了输入数据的次序或转移的次序.静态说明描述了输入条件与输出条件之间的对应关系.对于较复杂的程序,由于存在大量的组合情况,因此,仅用静态说明组成的规格说明对于测试来说往往是不够的.必须用动态说明来补充功能说明.功能图方法是用功能图FD形式化地表示程序的功能说明,并机械地生成功能图的测试用例. 功能图模型由状态迁移图和逻辑功能模型构成.状态迁移图用于表示输入数据序列以及相应的输出数据.在状态迁移图中,由输入数据和当前状态决定输出数据和后续状态.逻辑功能模型用于表示在状态中输入条件和输出条件之间的对应关系.逻辑功能模型只适合于描述静态说明,输出数据仅由输入数据决定.测试用例则是由测试中经过的一系列状态和在每个状态中必须依靠输入/输出数据满足的一对条件组成.功能图方法其实是是一种黑盒白盒混合用例设计方法。
详见：http://www.51testing.com/html/73/n-96773.html
现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。
详见：http://www.51testing.com/html/93/n-97993.html
Myers提出了使用各种测试方法的综合策略：
1)在任何情况下都必须使用边界值分析方法，经验表明用这种方法设计出测试用例发现程序错误的能力最强。
2)必要时用等价类划分方法补充一些测试用例。
3)用错误推测法再追加一些测试用例。
4)对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例。
5)如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法。
详见：http://www.51testing.com/html/200811/n98004.html
五、 设计用例
见《VE3111_系统测试用例.doc》
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
