设计测试用例的四条原则

原创 2013年12月05日 14:59:25





今天是2011年的第一天,2010年就这样匆匆忙忙,紧紧张张地过去了。这一年里来来去去,变化最大的就是很多一起工作了多年的同事离开了,很多都去了"更给力”的地方,呵呵!公司里来来往往是很正常的,想想我最近一次换到“更给力”的地方,那都是5年前了。总之,现在的地方还是挺给力的,好好工作,争取2011年有更大的进步,呱唧呱唧!
  测试用例设计的最基本要求:覆盖住所要测试的功能。这是再基本不过的要求了,但别看只是简单的一句话,要能够达到切实覆盖全面,需要对被测试产品功能的全面了解、明确测试范围(特别是要明确哪些是不需要测试的)、具备基本的测试技术(如:等价类划分等)等。那么满足了上述这条要求是不是设计出来的测试用例就是好的测试用例了呢?答案:在理论上是,但在实际工程中还远远不是。之所以理论和实际会有这样的差别,是因为在理论上不要考虑的东东,而在实际工程中是不得不考虑的 - 成本。这里的成本包括:测试计划成本、测试执行成本、自动化测试用例、测试自动化成本,测试分析成本,以及测试实现技术局限、测试环境的Bug、人为因素和不可预测的随机因素等引入的附加成本等。
  由于成本因素的介入,决定了工程中设计好的测试用例原则不只有“覆盖住所要测试的功能”这一条,下面是我根据自己的工作经验总结出的其它四条原则,在这里抛砖引玉,希望大家拍砖和指正。这些原则特别是针对那些需要被自动化,并且是要被经常执行的测试用例。
  1. 单个用例覆盖最小化原则。
  这条原则是所有这四条原则中的”老大“,也是在工程中最容易被忘记和忽略的,它或多或少的都影响到其它几条原则。下面举个例子来介绍,假如要测试一个功能 A,它有三个子功能点 A1,A2 和 A3,可以有下面两种方法来设计测试用例:
  方法1 :用一个测试用例覆盖三个子功能 -Test_A1_A2_A3,
  方法2 :用三个单独的用例分别来覆盖三个子功能 - Test_A1,Test_A2,Test_A3
  方法1适用于规模较小的工程,但凡是稍微有点儿规模和质量要求的项目,方法2则是更好的选择,因为它具有如下的优点:
  测试用例的覆盖边界定义更清晰
  测试结果对产品问题的指向性更强
  测试用例间的耦合度最低,彼此之间的干扰也就越低
  上述这些优点所能带来直接好处是,测试用例的调试、分析和维护成本最低。每个测试用例应该尽可能的简单,只验证你所要验证的内容,不要“搂草打兔子”捎带着把啥啥啥啥都带进来,这样只会增加测试执行阶段的负担和风险。David Astels在他的著作《Test Driven Development:A Practical Guide》曾这样描述,最好一个测试用例只有一个Assert语句。此外,覆盖功能点简单明确的测试用例,也便于组合生成新的测试,在Visual Studio中就引入了Ordered Test的概念。
  2. 测试用例替代产品文档功能原则。
  通常我们会在开发的初期(Scrum每个Sprint的头两天)用Word文档或者OneNote的记录产品的需求、功能描述、以及当前所能确定的任何细节等信息,勾勒将要实现功能的样貌,便于团队进行交流和细化,并在团队内达成对产品功能共识。假设我们在此时达成共识后,描述出来的功能为A,随着产品开发深入,团队会对产品的功能有更新的认识,产品功能也会被更具体细化,在一个迭代或者Sprint结束的时候最终实现的功能很可能是A+。如此往复,在不断倾听和吸收用户的反馈,修改产品功能,多个迭代过后,原本被描述为A的功能很可能最终变为了Z。这是时候再去看曾经的Word文档和OneNote页面,却仍然记录的是A。之所以会这样,是因为很少有人会去(以及能够去)不断更新那些文档,以准确反映出产品功能当前的准确状态。不是不想去做,而是实在很难!这里需要注意:早期的Word或者OneNote的文档还是必要的,它至少能保证在迭代初期团队对要实现功能有一致和准确的认识。

设计测试用例的四条原则

由于成本因素的介入,决定了工程中好的测试用例原则不会只有“覆盖住所要测试的功能”这一条,下面是我根据自己的工作经验总结出的其它四条原则,在这里抛砖引玉。这些原则特别是针对那些需要被自动化,并且是要被经...
  • quicknet
  • quicknet
  • 2011年01月01日 23:25
  • 19309

设计自动化测试用例的原则

测试用例设计的最基本要求:覆盖住所要测试的功能。这是再基本不过的要求了,但别看只是简单的一句话,要能够达到切实覆盖全面,需要对被测试产品功能的全面了解、明确测试范围(特别是要明确哪些是不需要测试的)、...

单元测试用例设计原则

问题: 1没有数据构造和清理的过程 用户数据,业务数据 2.没有对业务数据返回和业务逻辑做判断的一个过程 3. 对于一个业务测试用例单一 4. 方法名比较乱 5.测试方法前没有注释 6....

测试用例设计(含:用例设计原则 用例设计方法 )

第一篇测试文档,大多数是在网上收集。刚看的到这些文档时真是让人惊吓,原来有这么多的信息是第一听到,慨叹一句“学海无崖”哦。目录一、       定义... 3二、       输入... 3三、   ...

5.1.2 测试用例的选择原则

1 目的:统一测试用例编写的规范,以保证使用最有效的测试用例,保证测试质量。 2 范围:适用于公司对产品的业务流程、功能测试测试用例的编写。 3 术语解释 3.1 测试分析:对重要业务、重要流程...

接口测试用例设计实践总结

接口测试用例设计实践总结 by:授客 QQ:1033553122   设计思路 1)   优先级--针对所有接口 1、暴露在外面的接口,因为通常该接口会给第三方调用; ...

黑盒测试用例设计方法之等价类划分

1.等价类划分法 概念:把程序的输入域划分成若干子集,然后从每个子集中选取少数有代表性数据作为测试用例,每个子集的代表性数据在测试中的作用等价于该集合中的其他值。 等价类分为有效等价类(对于程序的...

黑盒测试用例设计模式-因果图

黑盒测试用例设计模式-因果图

Selenium自动化测试用例设计注意事项

http://www.uml.org.cn/Test/201304113.asp 自动化测试设计简介 我们在本章提供的信息,对自动化测试领域的新人和经验丰富的老手都是有用的。本篇中描述最常见的...

(九)黑盒测试用例设计--总结

一.黑盒测试法小结(测试方法的选择) l 通常,在确定测试方法时,应遵循以下原则: Ø 根据程序的重要性和一旦发生故障将造成的损失来确定测试等级和测试重点。 Ø 认真选择测试策略,以便能尽可能少...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:设计测试用例的四条原则
举报原因:
原因补充:

(最多只允许输入30个字)