测试用例设计之道.docx

测试用例设计之道 --测试用例学习专题 测试之前的“战略部署” 测试用例的编写作为QC特定的概念、技能，成为唯一广泛公认的东西。在项目测试过程中，最值得考虑的、最重要的当属测试用例的设计以及创建有效的测试用例。 　　但是，仍然有不少的测试团队和测试人员认为没有必要编写和设计测试用例，尤其是当敏捷开始盛行后，很多人更是认为编写和设计测试用例是浪费时间。 为什么要写测试用例？ 　　测试用例的创建至少会有两个用途或目的： 　　（1）如果顾客有要求的话，测试用例会是交付给顾客的产品中的一部分。测试用例在这里充当了提高可信度的作用。 　　（2）测试用例只作为内部使用。在这里测试效率是目的。在代码尚未完成时，我们基于设计编写测试用例，以便一旦代码准备好了，我们就可以很快地测试产品。 　　但是随着敏捷的盛行，第二点逐渐受到很多人的置疑。“预先设计好的测试用例对指导测试执行有多大的作用呢？而且我们采用的是探索性测试方法，不写测试用例也能做测试。” 　　没错，预先写好的测试用例很可能要在测试执行的过程中不断地修改，尤其是在那些需求不明朗的项目中。但是预先的设计就好比提前的探索，除了能学习到软件涉及的业务知识外，还能对即将出现的软件进行一次测试的“演练”，在这个“演练”的过程中，往往能发现需求分析和设计的很多缺陷，将可能由此引致的BUG“扼杀”在萌芽期。 　　探索性测试虽然很少写正式的测试用例，但是并不意味着没有对测试进行设计。只是测试的设计是在探索过程中、测试过程中进行的，测试的设计与测试的执行同步进行。并且根据Jams Bach介绍的基于Session的探索性测试管理的方法，是要写测试用例的，只不过不被称为测试用例，而是被称为“探索任务”。 　　基于Session的测试管理把测试过程划分成多个Session，或者叫“探索任务”，每个Session都是目的驱动的，每个Session由一名测试员负责执行，在一个Session结束后，测试员提交一份session报告，附上关于测试过程的重要信息。 　　“探索任务”可包括如图1所示的任务矩阵中列出的方面。 　　图1? 探索性测试任务 　　由此可见，探索性测试也有测试的设计，也有测试用例，只是相比起传统意义的测试用例编写而言，其测试用例更偏向于“设计”，并且其设计是与测试执行和探索行为同步进行的。 　　测试永远也无法保证发现所有的错误。测试用例的“设计”如此重要正是因为完整的测试是不可能的，任何项目的测试都是不完整的，因此，很显然我们需要通过设计测试用例，让测试尽可能的完善。在有限的时间和资源下，测试的关键问题是：哪些测试用例是最有可能发现最多错误的呢？ 　　图2? 某个程序的结构流程图 　　某个程序的结构流程图如图所示，这样一个少于100行Pascal代码的程序，却有100,000,000,000,000种可能的路径需要遍历，如果尝试遍历所有可能的路径，假设每秒钟执行1000个测试用例，也需要3170年的时间来完成所有测试。 　　详尽地遍历所有测试的可能路径、场景、输入条件和数据是不可能的，因为它们的组合接近无限，但是时间和资源都是有限的。以有限“拼”无限，无异“以卵击石”。因此有些人在这些困难面前妥协了，仅仅使用随机的输入来测试程序，这种测试方式无异“缴枪投降”。 　　正确的方法是设计合理有效的测试策略，建立合理有效的测试用例库，选择合理有效的测试用例来执行。 测试用例的设计策略 　　测试用例的设计方法有很多，一般常用的测试用例设计方法有以下几种。 等价类划分法。 边界值分析法。 基本路径分析法。 因果图法。 场景设计法。 错误猜测法。 　　另外，还有以下几种测试用例设计方法是用于有效减少测试用例个数的。 正交表法。 均匀试验法。 组合覆盖法。 　　注：关于这些测试用例设计的具体方法，可参考我写的《软件测试技术大全》一书中的第7章。 　　测试人员为什么要掌握这么多的测试用例设计方法呢？这是因为每一种测试用例设计方法都有其最适合的地方，需要综合应用才能让测试用例的设计省时省力而且能有效发现尽可能多的BUG，另外，交叉使用各种测试用例的设计方法，有助于避免“思维死角”，让BUG“无处遁形”。 　　最近，日本的测试界比较流行使用思维导图（Mind Maps）工具进行测试用例设计，原因是传统的测试用例设计方法都比较局限在某个区域，缺乏整体业务建模和整体测试逻辑的考虑。而通过“头脑风暴”工具，则可以协助测试人员更全面、更清晰都思考测试涉及的软件功能和业务模型，从而设计和构建出更加完善合理的测试用例。 　　测试人员通过画出一些关系图、测试对象的相关信息，帮助整理思路，组织内容、想法、创意等。例如，如图3所示的是FreeMind的编辑界面。 　　图3? FreeMind的编辑界面 　　类似的还