测试用例设计之道.docx
《测试用例设计之道.docx》由会员分享，可在线阅读，更多相关《测试用例设计之道.docx（129页珍藏版）》请在冰豆网上搜索。
测试用例设计之道
测试用例设计之道
--测试用例学习专题
测试之前的“战略部署”
测试用例的编写作为QC特定的概念、技能，成为唯一广泛公认的东西。
在项目测试过程中，最值得考虑的、最重要的当属测试用例的设计以及创建有效的测试用例。
但是，仍然有不少的测试团队和测试人员认为没有必要编写和设计测试用例，尤其是当敏捷开始盛行后，很多人更是认为编写和设计测试用例是浪费时间。
为什么要写测试用例？
测试用例的创建至少会有两个用途或目的：
（1）如果顾客有要求的话，测试用例会是交付给顾客的产品中的一部分。
测试用例在这里充当了提高可信度的作用。
（2）测试用例只作为内部使用。
在这里测试效率是目的。
在代码尚未完成时，我们基于设计编写测试用例，以便一旦代码准备好了，我们就可以很快地测试产品。
但是随着敏捷的盛行，第二点逐渐受到很多人的置疑。
“预先设计好的测试用例对指导测试执行有多大的作用呢？
而且我们采用的是探索性测试方法，不写测试用例也能做测试。
”
没错，预先写好的测试用例很可能要在测试执行的过程中不断地修改，尤其是在那些需求不明朗的项目中。
但是预先的设计就好比提前的探索，除了能学习到软件涉及的业务知识外，还能对即将出现的软件进行一次测试的“演练”，在这个“演练”的过程中，往往能发现需求分析和设计的很多缺陷，将可能由此引致的BUG“扼杀”在萌芽期。
探索性测试虽然很少写正式的测试用例，但是并不意味着没有对测试进行设计。
只是测试的设计是在探索过程中、测试过程中进行的，测试的设计与测试的执行同步进行。
并且根据JamsBach介绍的基于Session的探索性测试管理的方法，是要写测试用例的，只不过不被称为测试用例，而是被称为“探索任务”。
基于Session的测试管理把测试过程划分成多个Session，或者叫“探索任务”，每个Session都是目的驱动的，每个Session由一名测试员负责执行，在一个Session结束后，测试员提交一份session报告，附上关于测试过程的重要信息。
“探索任务”可包括如图1所示的任务矩阵中列出的方面。
图1 探索性测试任务
由此可见，探索性测试也有测试的设计，也有测试用例，只是相比起传统意义的测试用例编写而言，其测试用例更偏向于“设计”，并且其设计是与测试执行和探索行为同步进行的。
测试永远也无法保证发现所有的错误。
测试用例的“设计”如此重要正是因为完整的测试是不可能的，任何项目的测试都是不完整的，因此，很显然我们需要通过设计测试用例，让测试尽可能的完善。
在有限的时间和资源下，测试的关键问题是：
哪些测试用例是最有可能发现最多错误的呢？
图2 某个程序的结构流程图
某个程序的结构流程图如图所示，这样一个少于100行Pascal代码的程序，却有100,000,000,000,000种可能的路径需要遍历，如果尝试遍历所有可能的路径，假设每秒钟执行1000个测试用例，也需要3170年的时间来完成所有测试。
详尽地遍历所有测试的可能路径、场景、输入条件和数据是不可能的，因为它们的组合接近无限，但是时间和资源都是有限的。
以有限“拼”无限，无异“以卵击石”。
因此有些人在这些困难面前妥协了，仅仅使用随机的输入来测试程序，这种测试方式无异“缴枪投降”。
正确的方法是设计合理有效的测试策略，建立合理有效的测试用例库，选择合理有效的测试用例来执行。
测试用例的设计策略
测试用例的设计方法有很多，一般常用的测试用例设计方法有以下几种。
∙等价类划分法。
∙边界值分析法。
∙基本路径分析法。
∙因果图法。
∙场景设计法。
∙错误猜测法。
另外，还有以下几种测试用例设计方法是用于有效减少测试用例个数的。
∙正交表法。
∙均匀试验法。
∙组合覆盖法。
注：
关于这些测试用例设计的具体方法，可参考我写的《软件测试技术大全》一书中的第7章。
测试人员为什么要掌握这么多的测试用例设计方法呢？
这是因为每一种测试用例设计方法都有其最适合的地方，需要综合应用才能让测试用例的设计省时省力而且能有效发现尽可能多的BUG，另外，交叉使用各种测试用例的设计方法，有助于避免“思维死角”，让BUG“无处遁形”。
最近，日本的测试界比较流行使用思维导图（MindMaps）工具进行测试用例设计，原因是传统的测试用例设计方法都比较局限在某个区域，缺乏整体业务建模和整体测试逻辑的考虑。
而通过“头脑风暴”工具，则可以协助测试人员更全面、更清晰都思考测试涉及的软件功能和业务模型，从而设计和构建出更加完善合理的测试用例。
测试人员通过画出一些关系图、测试对象的相关信息，帮助整理思路，组织内容、想法、创意等。
例如，如图3所示的是FreeMind的编辑界面。
图3 FreeMind的编辑界面
类似的还有分类树方法设计测试用例，也是一种测试用例的辅助设计方法。
分类树方法的基本原理是：
首先把测试对象的可能输入按照不同的分类方式进行分类，每一种分类要考虑的是测试对象的不同的方面。
然后把各种分开的输入组合在一起产生不冗余的测试用例，同时又能覆盖测试对象的整个输入域。
因此，可以把使用分类树方法设计测试用例的过程分为3大步骤：
（1）识别出测试对象并分析输入空间。
（2）对测试对象的输入空间进行分类。
（3）画出分类树、组合成测试用例。
图4所示的是利用CTEXL设计分类树并自动产生测试用例的效果。
图4利用CTEXL设计分类树
不管采用什么样的测试用例设计方法，最重要的是要体现测试人员的逻辑思维，测试用例的设计是测试人员智慧的集中体现，它代表了测试人员对软件的理解，代表了测试人员的测试思路。
测试用例的设计是测试人员与软件BUG进行一次歼灭战之前的战略部署，没有一场战争是在毫无准备和计划的情况下赢得胜利的，软件测试也无例外。
测试用例个数代表什么？
JamsBach在《软件测试经验与教训》一书中打了个形象的比喻来说明测试用例的个数并不代表什么：
如果拿出公司的所有箱子堆起来，并不会知道箱子所装东西的价值。
如果公司有37个箱子，总重量是384磅，这能从什么方面说明公司的未来吗？
不能。
但是这些箱子所装的东西可能和公司的未来是密切相关的。
因此要想知道价值所在，唯一的办法就是打开箱子，查看所装的东西。
其实测试用例就像箱子，只是统计箱子个数而不管里面的实际内容的话是没有什么意义的。
因此，仅仅统计测试用例的测试通过率也说明不了任何问题。
90%的通过率到底是好还是坏呢？
如果不了解里面的测试内容的话，谁也不能回答这个问题。
同样地，统计执行得测试用例与计划执行得测试用例的比例也说明不了任何问题。
因为也许最难执行的测试用例被推到了最后，或者最后的10%的测试用例需要50%的时间来完成，又或者计划要执行的那些测试用例其实远远不足以覆盖测试的需求，也没有覆盖重要的风险。
因此，衡量一个项目的测试设计是否到位，是否完善，并不能单从所设计的测试用例个数来衡量，还要真正看到测试用例里面的内容。
要想让测试用例的个数代表点什么的话，我们必须进行测试用例的评审。
测试用例的评审
测试用例设计出来了，质量如何，如何提高测试用例设计的质量？
就像软件产品需要通过各种手段来保证质量一样，测试用例的质量保证也需要综合使用各种手段和方法。
测试用例的检查可以有多种方式，但是最敏捷的应当属临时的同行评审。
我认为同行评审，尤其是临时的同行评审，应该演变成类似软件开发中的“结对编程”一样的方式。
从而体现敏捷的“个体和交互比过程和工具更有价值”，要强调测试用例设计者之间的思想碰撞，通过讨论、协作来完成测试用例的设计，原因很简单，测试用例的目的是尽可能全面地覆盖需求，而测试人员总会存在某方面的思维缺陷，一个人的思维总是存在局限性。
因此需要一起设计测试用例，善用“集体智慧”、“群众的智慧”。
测试用例的评审要点需要至少包括以下几个方面：
∙测试用例对需求覆盖的完整性。
∙测试用例的有效性。
∙测试用例的清晰性。
∙测试用例的可理解性。
∙测试用例的可维护性。
除了同行评审，还应该尽量引入用户参与到测试用例的设计中来，让他们参与评审，从而体现敏捷的“顾客的协作比合同谈判更有价值”这一原则。
这里顾客的含义比较广泛，关键在于你怎样定义测试，如果测试是对产品的批判，则顾客应该指最终用户或顾客代表（在内部可以是市场人员或领域专家）；如果测试是指对开发提供帮助和支持，那么顾客显然就是程序员了。
邀请程序员参与测试用例的评审，就好比临战前的“演练”，测试人员是“剑”，开发人员是“盾”，如果开发人员能回答测试人员基于测试用例提出的所有问题，那么OK，测试人员要好好考虑是否应该增强自己的测试用例了，另外，开发人员回去可能也会好好考虑如何增强自己的程序在处理可能出现的异常和错误方面的代码，真可谓“一举两得”！
当然，在这种开发人员参与的测试用例评审中，也是一个暴露两方对于同一需求的不同理解的机会，通过评审和交流，能尽早达成共识，避免造成在测试执行和BUG修改阶段产生的“误会”。
小结
鼓吹测试用例无用论的测试人员可能并没有真正理解测试用例的意义，没有意识到测试之前进行“战略部署”的重要性，同时也很可能误解了敏捷测试、探索性测试的方法，把自由、随意当成了敏捷，把随机的、即兴的测试当成了探索性测试。
测试用例可粗可细，可建立完善的测试用例库，也可仅仅用一个Excel表来记录，但是一定要对测试进行“设计”，在与软件BUG进行的持续“战斗”中，一定要体现出测试人员的“智慧”来，相信“胸有成竹，则战无不胜”。
测试用例的设计方法概述
1引言
1.1测试用例在软件产品中的作用和意义
软件产品化之后给人们日常生活和工作带来了极大的便利。
同样的，也使人们对软件产品的质量重视上升到了更进一步的高度。
随着软件危机的不断出现以及人们对于软件更进一步的认识，测试的地位得到了前所未有的提高，并且人们意识到：
测试开始的时间越早，软件的缺陷将越早被发现，带来整个软件开发中的成本也下降越多。
软件测试是发现软件中缺陷的主要手段和唯一有效的方法。
软件质量的重视度越高，软件测试工作在软件开发过程中就越重要。
完全覆盖测试又要求测试工作的力度和深度以及每一种现实中可能发生的操作都要保证正确，很多人觉得这个似乎是矛盾的。
软件测试中永远不可能做到穷举测试，又想使得测试工作的效率达到最高，那么该如何兼顾工作量和效率的问题，往往成为测试工作中的瓶颈问题所在。
如何测试，用什么方式来测试，在什么环境和什么样的条件下进行测试，测试的工作量和如何避免重复的测试，等等各种应该考虑的因素在测试工作中如何协调和同步，在测试用例中应该充分描述这些问题。
因此，软件测试工作中处于重中之重的测试用例的设计要求也随之上升到了更高的层次。
测试用例不但构成了设计和制定测试过程的基础，而且测试的深度与测试用例的数量成正比。
一般来讲，判断测试是否完全的一个主要评测方法是基于需求的覆盖，而这个又是以确定、实施和（或）执行的测试用例的数量为依据的；测试工作量与测试用例的数量成比例；测试设计和开发的类型以及所需的资源主要都受控于测试用例。
这些使得测试用例在整个的软件开发过程中处于更加重要的地位。
1.2测试用例的定义
测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
RobertV.Binder是这样描述的，测试实例：
输入、执行条件，及为一个特殊目标所开发的预期结果的集合。
一个定义IUT（被测实现，即被测代码）及其环境、测试输入或条件，及预期结果的测试前状态的表示或实现。
1.3测试用例应该包含的要素
首先测试用例应该包含软件或者项目名称、所服务的范围、背景、作者、编写时间等文档类信息；根据测试用例的定义和目的，测试用例的内容应该有：
标题和用例编号、版本号、修改记录，针对目标和假设前提/可能发现的错误，输入数据/代码，测试步骤，预期输出和错误发现方法。
1.4测试用例中需要注意的问题
每个测试用例清楚地阐述了正在进行评估的用例、用例场景、测试目标或条件的有关说明。
每个测试用例都描述了预期结果和评估该结果的方法。
对于每个测试需求，在测试用例中需要考虑在正面测试和负面测试的条件下的测试，或者通过确定两个测试用例来实现，一个测试用例代表预期的条件，它可用于核实行为是否正确或符合预期（正面测试）。
另一个测试用例代表不可接受的、异常的或意外的条件，它可用于核实测试需求是否未以非预期方式执行（负面测试）。
在一般情况下，对于测试的每个需求来说，至少要有一个正面测试用例和为数较多的负面测试用例，以此来检查在异常情况下系统能否正常处理，或者用户进行了错误的操作时的友好提示等等。
测试用例已被确定用来执行测试目标中所有的产品需求行为，包括（视情况而定）：
功能、数据确认、业务规则实施、测试目标工作流程或控制、数据流、对象状态、性能（包括工作量、配置和强度）、安全性/可访问性、兼容性。
每个测试用例都说明或者/代表一个唯一的输入集或事件顺序，它能够产生唯一的测试目标行为，复审那些产生相同行为的测试用例并判定它们是否等同，即它们是否都执行测试目标中的路径。
每个测试用例（或每组相关的测试用例）确定初始的测试目标状态和测试数据状态。
测试用例名称和/或ID与测试工件命名约定一致。
2测试用例的设计方法概述
根据测试的方法分为黑盒测试和白盒测试，相应的测试用例的设计方法也可以分为针对黑盒测试的用例设计和针对白盒测试的用例设计。
至今提出的测试用例设计方法有许多，下面简要的介绍一些比较重要的、常用的方法。
2.1白盒测试的测试用例设计方法
2.1.1逻辑覆盖
逻辑覆盖包括：
语句覆盖、判定覆盖、条件覆盖、判定－条件覆盖、条件组合覆盖、路径覆盖，各自的定义简略描述如下：
语句覆盖就是设计若干个测试用例，运行被测程序，使得每一可执行语句至少执行一次。
判定覆盖就是设计若干个测试用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次。
条件覆盖就是设计若干个测试用例，运行被测程序，使得程序中每个判断的每个条件的可能取值至少执行一次。
判定－条件覆盖就是设计足够的测试用例，使得判断中每个条件的所有可能取值至少执行一次，每个判断中的每个分支至少执行一次。
条件组合覆盖就是设计足够的测试用例，运行被测程序，使得每个判断的所有可能的条件取值组合至少执行一次。
路径测试就是设计足够的测试用例，覆盖程序中所有可能的路径。
2.1.2基本路径测试
基本路径测试方法把覆盖的路径数压缩到一定限度内，程序中的循环体最多只执行一次。
它是在程序控制流图的基础上，分析控制构造的环路复杂性，导出基本可执行路径集合，设计测试用例的方法。
设计出的测试用例要保证在测试中，程序的每一个可执行语句至少要执行一次。
2.2黑盒测试的测试用例设计方法
2.2.1等价划分
所谓等价类划分是指一套被选择的值，这些值分别代表了许多众多的可能输入值，程序对其处理的方式都是一样的。
等价类划分的方法作为继边界值分析方法之后补充的测试用力设计试用的一种方法。
划分等价类、确定测试用例
等价类划分是一种典型的黑盒测试方法，使用这一方法时，完全不考虑程序的内部结构，只依据程序的规格说明来设计测试用例。
等价类划分方法把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数有代表性的数据做为测试用例
等价类的划分有两种不同的情况：
有效等价类：
是指对于程序的规格说明来说，是合理的，有意义的输入数据构成的集合。
无效等价类：
是指对于程序的规格说明来说，是不合理的，无意义的输入数据构成的集合。
在设计测试用例时，要同时考虑有效等价类和无效等价类的设计。
2.2.2边界值分析
在设计测试用例确定输入和输出参数时，大多数情况下都是用边界值分析方法，采用边界值分析设计的测试用例发现程序错误能力最强。
边界值分析也是一种黑盒测试方法，是对等价类划分方法的补充。
人们从长期的测试工作经验得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。
因此针对各种边界情况设计测试用例，可以查出更多的错误。
2.2.3错误推测法
人们也可以靠经验和直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的例子。
这就是错误推测法。
错误推测法的基本想法是：
列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。
2.2.4因果图
如果程序的功能说明中含有输入条件的组合情况，则一开始就可以选用因果图法。
如果在测试时必须考虑输入条件的各种组合，可使用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来设计测试用例，这就需要利用因果图。
因果图方法最终生成的就是判定表。
它适合于检查程序输入条件的各种组合情况。
3测试用例的评审及维护
3.1测试用例的评审
测试用例在设计之后需要经过评审，需要评审的内容如下：
用例是否完整？
是否每一个需求都有其对应的测试用例来验证？
是否每一个设计元素都有其对应的测试用例来验证？
事件顺序，能否产生唯一的测试目标行为？
是否每隔测试用例都阐述了预期结果？
是否每个测试用例（或每组相关的测试用例）都确定了初始的测试目标状态和测试数据状态？
测试用例是否包含了所有单一的边界？
测试用例是否包含了所有的业务数据流？
是否所有的测试用例名称，ID都与测试工件命名约定一致？
测试用例评审时需要参加的人员：
项目经理，系统分析员，测试设计员，测试员
3.2用例库的更新维护
随着软件项目的开发，用例库的数据随着项目的进展动态变化也是需要维护的，主要包括：
不合适用例的修改、冗余用例的删除、测试用例的增加，并对进行的操作在备注中署名修改者以及修改时间和改动原因。
4测试用例实例
该测试案例是以一个B/S结构的登录功能点位被测对象,该测试用例为黑盒测试用例。
假设用户使用的浏览器为IE6.0SP4。
功能描述如下：
1.用户在地址栏输入相应地址，要求显示登录界面；
2.输入用户名和密码，登录，系统自动校验，并给出相应提示信息；
3.如果用户名或者密码任一信息未输入，登录后系统给出相应提示信息；
4.连续3次未通过验证时，自动关闭IE。
表4-1登录界面测试用例
1
为什么要使用测试用例
其实，测试用例不是必须的。
如果你是一个特别有想法的人，或者在软件测试方面很有天赋，每天都能找到其他人几天时间才能找到的Bug，那么你可以不用测试用例，如果我是TestManager的话，就会让你做一个Ad-hocTester，因为我已经觉得你足够好了，不需要测试用例来指导你了，因为你很有想法，有自己的测试思路。
就像陈宏刚博士在Microsoft公司做Tester的时候，就是一个Ad-hocTester，因为他有自己的测试思路，他每天找到的Bug比他们小组其他所有Tester测试出来的Bug总和还要多，所以Testmanager根本就不管他，也不给他什么要求，就让他每天测好了。
但是不幸的是，你可能不是这样的人，或者你身上存在着几种情况，就最好使用测试用例。
1. 你工作不主动，你需要测试用例来催着你去工作；
2. 你测试时总感觉思维很混乱，或者总感觉有些功能没有测到，而一些功能已经测过好几遍了，这样测试用例能够帮你理清头绪，进行比较系统的测试，不会有太多的重复，也不会让你的测试工作产生遗漏；
3. 在测试时间紧迫的情况下，你不知道要测什么，或者要先测试那些功能，测试用例这个时候就可以帮你分清重点，因为测试用例写完后一定要标重要程度和优先级，以防止在紧急的情况下有重点的工作。
4. 你积极的工作状态不能持续，这个时候测试用例又帮你一个大忙，因为测试用例上面操作步骤和预期结果都已经写好了，你根本不用思考，只需要照着上面做就行了。
5. 测试用例是你工作的见证，也是你每次测试以后向上级汇报的依据，有了测试用例，我知道我这次测试了那些功能，还有那些功能没有测到，对上级是一个交代，也做到了自己心中有数。
6. 测试用例可以记录你的灵感。
如果灵感突发，有一个新颖的测试思路，你可以写成测试用例，或许这个测试用例就是挽救整个软件的重大功臣。
7. 测试用例有助于不断的改进工作。
因为通过测试用例，可以知道哪些测试用例测出Bug的机率比较大，还有那些测试用例需要改进，对我们以后工作的改进提供了依据。
以上几条如果还不能推动你写测试用例的话，那么只有通过时间来证明了。
我现在已经习惯在测试之前写测试用例了，如果测试之前没有测试用例的话，反而觉得不习惯。
当然在不同的情况下（比如时间紧迫和有充足的时间的情况），测试用例的写法是不一样的。
软件测试用例的认识误区介绍
在实际软件项目测试过程中，由于对软件测试用例的作用和设计方法的理解不同，测试人员（特别是刚从事软件测试的新人）对软件测试用例存在不少错误的认识，给实际软件测试带来了负面影响，本文对这些认识误区进行列举和剖析。
误区之一：
测试输入数据设计方法等同于测试用例设计方法
现在一些测试书籍和文章中讲到软件测试用例的设计方法，经常有这样的表述：
测试用例的设计方法包括：
等价类、边界值、因果图、错误推测法、场景设计法等。
这种表述是很片面的，这些方法只是软件功能测试用例设计中如何确定测试输入数据的方法，而不是测试用例设计的全部内容。
这种认识的不良影响可能会使不少人认为测试用例设计就是如何确定测试的输入数据，从而掩盖了测试用例设计内容的丰富性和技术的复杂性。
如果测试用例设计人员把这种认识拿来要求自己，则害了自己；拿来教人，则害了别人；拿来指导测试，则害了测试团队。
听起来似乎是“小题大做”，但是绝不是“危言耸听”。
无疑，对于软件功能测试和性能测试，确定测试的输入数据很重要，它决定了测试的有效性和测试的效率。
但是，测试用例中输入数据的确定方法只是测试用例设计方法的一个子集，除了确定测试输入数据之外，测试用例的设计还包括如何根据测试需求、设计规格说明等文档确定测试用例的设计策略、设计用例的表示方法和组织管理形式等问题。
在设计测试用例时，需要综合考虑被测软件的功能、特性、组成元素、开发阶段（里程碑）、测试用例组织方法（是否采用测试用例的数据库管理）等内容。
具体到设计每个测试用例而言，可以根据被测模块的最小目标，确定测试用例的测试目标；根据用户使用环境确定测试环境；根据被测软件的复杂程度和测试用例执行人员的技能确定测试用例的步骤；根据软件需求文档和设计规格说明确定期望的测试用例执行结果。
误区之二：
强调测试用例设计得越详细越好
升级会员 