James Whittaker的软件測试戒律(二)

摘录自《探索式软件測试》(注:作者模仿了圣经十诫的语气和内容编写了软件測试戒律)

1.汝应用大量输入重复锤炼汝之应用程序

2.汝应贪图汝之邻居的应用程序

3.汝应亲自寻找睿智的预言家

4.汝不应崇拜无法重现的失效

5.汝应尊重汝的模型和自己主动化測试

6.汝应利用开发者的过错与他们作对

7.汝应醉心于谋杀应用程序(庆祝蓝屏吧)

8.汝应保持安息日(指产品公布时刻)的圣洁

9.汝应贪图开发者的源码

下面内容主要来自《探索式软件測试》。本人依据自己的理解对部分内容稍作了改动

3.汝应亲自寻找睿智的预言家

我们都知道,測试至少存在两个部分。

首先我们使用输入数据,然后对结果进行检查。

我们将数据输入到软件中。然后測试该软件是否依照既定的方式回应这些输入。

假设我们无法对结果进行验证,測试就无法有效进行。

关于所谓睿智的预言家。我们有兴趣的是“应用某些測试后,该应用程序是否依照既定的方式执行?”。这就须要我们的预言家(也就是測试的基准)清楚的了解在给定特定的输入和环境条件组合的情况下,程序应有的行为。

(博主的理解:即要事先知道你要执行的測试会有如何的预期结果。博主更愿意把这个预言家叫做预期结果。假设不知道预期结果,你也就无法推断程序返回的结果是不是正确。)

将測试基准进行自己主动化是一件非常困难的事,可是非常值得去最求,由于这不只能够创建一个非常有价值的測试工具,其本身也是一个启迪智慧的追求过程。即通过自己主动化的活动,你得到了一个更加聪明的測试者。不管你终于是否能成功地将測试基准自己主动化,强迫自己像它一样思考。经常比你可能选择做的其它不论什么事情更有工作效率。

4.汝不应崇拜无法重现的失效

我们都曾遇到这样的情况。不是吗?你遇到一个缺陷,一般是非常好的缺陷,可是却无法重现。

缺陷越好,你的感觉越不好。

我以前见过很多优秀的測试人员,花了数小时甚至数天的时间试图重现一个他们仅仅见过一次的缺陷。

为了重现这样一个缺陷的尝试一般是英勇的,可是没有合适的工具,这些尝试仅仅能是浪费时间。而我看到的情况是时间被白白浪费了,而測试人员却没有意识到这点。

我以前看到一个測试人员花了一整天的时间试图记起一个崩溃缺陷的重现步骤,可是没有成功。

我更愿意那个測试人员把他的时间用在其他更好的地方。和其他不论什么一个測试人员一样,我全然理解那种挫败的感觉。可是最求一个这种缺陷的结果往往是无法充分利用时间。

这条戒律的教育意义是双重的。第一、尽你最大努力注意并记住(或记录下来)对软件採取的測试步骤。同一时候记住应用程序的响应。

第二、考虑使用调试器之类能追踪动作和软件状态的工具。这将去除重现缺陷时不少推測成分,并防止优秀的測试人员违背这条戒律。

博主理解:纵观全文,这条戒律的教育意义应该是有三重的,最后一条作者在前面提到了,但并没有在最后的归纳中写下

1、努力记录步骤和结果

2、尽量使用工具辅助

3、假设重现太困难,不要在它上面浪费太多时间,将你的时间投入到其他更有效率的測试中。这样对项目整体是更好的选择。

时间: 2024-10-23 00:43:56

James Whittaker的软件測试戒律(二)的相关文章

软件測试必读书籍

?? https://www.douban.com/doulist/264611/ 来自:豆瓣读书 模糊測试--强制发掘安全漏洞的利器 7.3 (15人评价) 作者: [美]Sutton, M. Greene / [美]A. Amini, P 出版社: 电子工业出版社 出版年: 2013-10 2015年4月19日 赞 回复 载入很多其它 > 我来回复 来自:豆瓣读书 探索吧! 深入理解探索式软件測试 7.5 (12人评价) 作者: (美)Elisabeth Hendrickson 出版社: 机

软件測试自学指南---从入门到精通

近来,软件測试行业发展迅速,企业越来越重视測试了.越来越多的人增加了測试大军中,非常多人也想通过自学来学习软件測试技术增加这个行业,可是如今软件測试的书籍越来越多,也良莠不齐,并且软件測试涉及的技术也越来越多.本文主要说明的是从事软件測试行业须要必备的知识,以及该怎样学习,主要给大家提供一些比較优秀的书籍,并给出学习的顺序.希望通过阅读本文,读者能够明白该怎样学习測试,并学习哪些知识.因为仅是个人建议,如有错误不妥的地方,敬请提出批评. 一.软件測试基础知识 要想进入測试这个行业,就必需要了解什

软件測试系列之入门篇(一)

一.你知道软件測试有多重要吗? 在国际上.软件測试(软件质量控制)是一件很重要的project工作.測试也作为一个很独立的职业. 在IBM.Microsoft等开发大型系统软件公司,许多重要项目的开发測试人员的比例可以达到1:2甚至1:4. 在国内软件測试的地位还不够高.而且大多仅仅停留在软件单元測试.集成測试和功能測试上.软件測试从业人员的数量同实际需求有不小差距.国内软件企业中开发者与測试人员数量一般为5:1.因此.国内的软件測试产业化还有待开发和深掘. 讲到这里不知道你反应是高兴还是失望?

软件測试系列之软件測试过程模型(四)

回想往昔: 在软件开发的不断实践过程中.人们积累经验教训,预估未来发展,总结出了非常多的开发模型,比較典型的开发模型有,边做边改模型,瀑布模型,高速原型模型.螺旋模型,增量模型.演化模型,喷泉模型,智能模型,混合模型还有RAD模型以及近期比較流行的.基于网络的面向对象的模型--RUP(RationalUnifiedProcess,统一软件开发过程. 可是遗憾的是.这些模型中.没有给予測试足够的重视和诠释.所以,才会有后来的软件測试过程模型的诞生.在这些測试模型中,兼顾了软件开发过程,对开发和測试

软件測试相关简要记录

软件測试 编码和測试统称为实现. 通常在编写出每一个模块之后就对程序做必要的測试,这叫做单元測试. 模板的编写者和測试者是同一个人. 之后会进行其它综合測试.由专门的測试人员承担这份工作.也就是软件測试project师. 软件測试的工作量往往占软件开发总工作量的40%以上. 编码 对于编码有例如以下要求: 1)程序内部的文档 2)数据说明 3)语句构造 4)输入输出 5)效率:程序执行时间.存储器效率.输入输出的效率 软件測试基础 一.软件測试的目标 1)測试是为了发现程序中的错误而执行程序的过

软件測试方法

软件測试方法 软件測试方法种类繁多,从不同的角度上去划分,能够划分为下面经常用法: 一.软件測试分类 以下我本文主要谈论的是白盒測试.黑盒測试盒和灰盒測试. 二.软件測试定义        白盒測试:在測试类书籍中,白盒測试有多种称法,如玻璃盒測试.透明盒測试,开放盒測试,结构化測试,基于代码的測试,逻辑驱动測试等.白盒測试是一种測试用例设计方法.在这里盒子指的是被測试的软件,白盒.顾名思义即盒子是可视的,你能够清楚盒子内部的东西以及里面是怎样运作的,因此白盒測试须要你对系统内部的结构和工作原理

金朝阳——软件測试试题11道题目分享

測试人员相对于开发者来说.对知识的广度要求更高. 1:以下所描写叙述的属于安全漏洞方面的有哪些?() A.SQL注入问题 B.跨站脚本(XSS) C.不安全的加密存储,比方CSDN站点的用户password是明文password D.站点訪问缓慢 2:关于Loadrunner下列说法正确的是() A.web_reg_save_param最经常使用來做关联的函数 B. 函数lr_save_string("我是一名软件測试project师","tester")的含义是&

软件測试计划模板

第1章 引言 1.1目的 简述本计划的目的,旨在说明各种測试阶段任务.人员分配和时间安排.工作规范等. 測试计划在策略和方法的高度说明怎样计划.组织和管理測试项目.測试计划包括足够的信息使測试人员明确项目须要做什么是怎样运作的.另外,清晰的文档结构能使不论什么一个读者在浏览计划的前面几页后,就能对项目有一个大概的认识.測试计划仅仅是測试的一个框架,非常多细节须要跟开发者或其它人员沟通,因此计划不包括測试用例的细节和系统功能的具体信息.在计划目的中须要指明读者对象. 1.2名词解释 列出本计划中使

软件測试中的那些不可遗忘的基础知识

软件測试是一项批判性的工作,目的就是找出软件中的缺陷. 这里临时不去深究为什么要进行软件測试,以及软件測试带来的优点. 仅仅介绍软件測试中一些主要的測试方法.依据是否查看代码程序分为黑盒測试和白盒測试:依据是否执行软件又可分为静态測试和动态測试. 黑盒測试:又叫功能測试或行为測试,仅仅需考虑各个功能.不须要考虑整个软件的内部结构及代码. 白盒測试:訪问代码,通过检查代码的线索来协助測试. 静态測试:測试软件不执行的部分,仅仅是检查和审核. 动态測试:使用和执行软件进行測试. 1.静态黑盒測试:检