设计测试用例的四条原则

原创 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的文档还是必要的,它至少能保证在迭代初期团队对要实现功能有一致和准确的认识。

设计测试用例的四条原则

今天是2011年的第一天,2010年就这样匆匆忙忙,紧紧张张地过去了。这一年里来来去去,变化最大的就是很多一起工作了多年的同事离开了,很多都去了"更给力”的地方,呵呵!公司里来来往往是很正常的,想想我...
  • chen91yang
  • chen91yang
  • 2013年11月21日 14:10
  • 793

设计测试用例的四条原则 .

http://blog.csdn.net/quicknet/article/details/6111882   写的挺好的,转载一下。
  • wuxiaobingandbob
  • wuxiaobingandbob
  • 2013年02月21日 14:51
  • 311

测试用例的设计基本原则

1、测试用例的代表性:能够代表并覆盖各种合理的和不合理、合法的和非法的、边界的和越界的、以及极限的输入数据、操作和环境设置等。2、测试结果的可判定性:即测试执行结果的正确性是可判定的,每一个测试用例都...
  • skyxmstar
  • skyxmstar
  • 2017年04月06日 11:57
  • 652

【软件测试 1】如何写(好)测试用例 --网络整理

面对这个题目,其实我并不想写,因为去网络上搜索“测试用例”为关健字的东东,出来的太多太多,各个凡有关能涉及或不涉及到的测试有关的都会有很多东西出来。如果大家仔细研究一下,其实内容大致差不多,只不过看自...
  • lishanshan523
  • lishanshan523
  • 2012年01月11日 11:25
  • 275

测试用例制定的原则

测试用例要包括欲测试的功能、应输入的数据和预期的输出结果。测试数据应该选用少量、高效的测试数据进行尽可能完备的测试;基本目标是:设计一组发现某个错误或某类错误的测试数据,测试用例应覆盖方面:   1、...
  • achang21
  • achang21
  • 2013年09月15日 10:19
  • 1025

测试用例的特点与原则

测试用例的特点 1、正确性:测试用例最好是要求输入用户实际数据已验证系统是否满足需求规格说明书的需求,并且测试用例中的测试的应保证至少覆盖需求规格说明书中的各项功能。 2、完整性:一些基本功能,如...
  • yao150824
  • yao150824
  • 2015年09月29日 22:28
  • 1577

5.1.2 测试用例的选择原则

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

单元测试设计原则

背景 为了提高开发人员的代码质量,编写高质量的单元测试,要遵守3R(Responsible, Reliable, Repeative)原则,具体含义如下: Responsible: 谁开发...
  • heymysweetheart
  • heymysweetheart
  • 2016年07月06日 10:11
  • 998

场景分析法设计测试用例

场景分析法设计测试用例 1. 事件流,同一事件不同的触发顺序和处理结果形成事件流,事件流分为基本流和备选流 ·1)基本流:程序从开始执行直到成功结束所经过的最短路径。 ·2)备选流:一个备选流可...
  • jffhy2017
  • jffhy2017
  • 2017年02月16日 15:55
  • 1143

软件安全性测试设计的基本原则

2015年3月2日 百度了下网上已有的同类话题,讲的有些笼统。这里将我日常工作中涉及到的细化一下,以备忘。 1. 最小授权 只授予每个用户/程序在执行操作时所必须的最小特权。这样可以限制事故、错误、攻...
  • victory_xing126
  • victory_xing126
  • 2015年03月02日 20:26
  • 1447
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:设计测试用例的四条原则
举报原因:
原因补充:

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