探索式测试--第一章(软件质量)第二章(手工测试)--读书笔记

本书为James Whittaker编写。本书写的是一种比其他任何缺陷都重要的特殊缺陷:即逃过所有各种检测手段而最终存在于发布产品中的缺陷。本书是作者设计“漫游”这个隐喻来指导软件测试。写本书对作者本人来说是一种享受,对读者来说也是一种享受。希望大家仔细品读。

第1章 软件质量
软件的魔力
“任何足够先进的技术,看上去都与魔法无异。”,在这里,如果用它来比喻软件的魔力最为恰当不过,远远比形容其他任何一项发明贴切。
不仅战争离不开软件,其他几乎所有的尖端发明都一样。
未来50年,软件必将推动更多的发明创造。
如果有一个奥林匹克故障大会,如果有一个让人揪心和悲痛的世界杯产品大会,软件必定所向披靡,荣膺冠军。在人类创造的所有产品中,软件出问题的可能性是其他所有产品无可匹敌的。
人类迫切需要软件来实现未来的梦想,但是在现实生活中,软件却又是最不可靠的一种产品。软件对我们的未来至关重要,但目前软件故障率已达到让人触目惊心的程度。
软件失效
有时候,软件的最终用户并不是软件缺陷的受害者,倒霉的是软件开发商或部署了该软件的公司。
有些软件缺陷会使用户工作效率降低。
软件缺陷还会给用户带来各种各样的不便,或者会让用户暗暗摇头。
软件缺陷是软件魔力上的瑕疵。在我们尽情挥洒软件魔力,解决愈来越困难和关键的问题的时候,我们也必须仔细研究软件哑火失效的情况,这可以把软件缺陷的瑕疵变得最小,同时减少它带来的副作用。本书是从一个测试人员的角度试图解决以下问题:理解软件缺陷是如何产生的,熟悉查找软件缺陷的各种方法,从而充分兑现软件魔力的诺言。
小结
科学孕育了软件,给予它非凡的魔力,现在是通过软件魔力来创造新科学的时代了,我们需要这种魔力来解决世界上亟待解决的各类问题,其中包括人口过剩、温室效应、治疗疑难杂症和延长人类寿命。软件在其中都扮演着重要的角色,这就迫切需要尽可能地提高软件质量。过去的失败再也无法忍受。
第2章 手工测试
软件缺陷的根源
软件缺陷的根源来自于软件开发本身。世上第一个软件含有缺陷,最新开发的软件也有缺陷,这一过程中自然也不待言。软件现在不是毫无缺陷的,将来多半也不会是。
本书中,我们会讨论两种缺陷:程序员引入的缺陷和运行环境导致的缺陷。
缺陷预防和检测
因为错误是不可避免的,所以需要讨论一下如何尽可能地把缺陷排除在软件开发周期之外,以便尽可能减少错误并提高软件质量。事实上,这主要有两大类技术,分别是缺陷预防和缺陷检测。
缺陷预防
缺陷预防技术一般是从开发人员角度说的,包括编写更好的设计规范,实施代码审核制度,运行代码静态分析工具,运行单元测试。所有的这些缺陷预防技术都有些根本性的问题,如果不解决这些根本的问题,这些技术都不会很有效。
问题1:开发人员只能是个糟糕的测试者。开发需要做测试且具备测试思维;需要开发外的测试人员来检查一些微妙情况,提前发现这些缺陷。
问题2:处于静止状态的软件。如果软件不在真实运行环境中运行起来,很多缺陷不会被触发。
问题3:缺乏数据。往往会出现这样的情况,软件运行一段时间后,数据积累到一定程度后,软件出现故障了。在模拟的真实运行环境中运行软件以及使用大量接近事实数据的测试数据。
谁能提供“第二双眼睛”呢?答案就是软件测试人员,他们可以熟练使用各种测试技术来检测软件缺陷,并将其上报,这样,缺陷才能被修复。测试是一个动态的过程,它包括在不同的环境中运行软件,使用合理的测试数据,并在较短的测试周期内尽可能多地尝试不同的输入值。这就是软件测试人员可以施展身手的地方。
缺陷检测
测试人员一般使用两种形式的测试:自动化测试和手工测试。
对自动化测试的评价可以说是毁誉参半。说他不好是因为使用代码来进行测试,首先必须编写这些代码,这意味着测试人员也必须是一个开发人员。说他好使因为自动化测试很炫。编写一个简单的程序,就可以执行无数次测试用例。在软件测试行业,自动化测试也已经行之多年,有些领域甚至已经有几十年历史了,但为什么软件发布到最终用户手里时还会出问题?这是因为自动化测试和开发人员所做的其他测试都有某些共通的问题。首先是运行环境,代码运行在一个测试环境,而不是一个真实环境。自动化还有一个致命弱点就是“预言家难题”,至今尚无解决方案。
现在,测试人员该怎么办呢?如果测试人员不能依靠开发人员的缺陷预防工具和自动化手段,他们还能希望于什么呢?唯一的答案就是手工测试。
手工测试
手工测试,就是需要人来动手进行测试。由人来进行手工测试,可以最大程度地发挥人的主观能动积极性,设计出真实的用户情况,在真实的用户环境中使用真实的用户数据,同时可以识别出那些是显而易见的缺陷和那些比较难以觉察的缺陷。
如果想发现与应用程序业务逻辑相关的缺陷,手工测试是最理想的选择。业务逻辑往往非常复杂,需要真人检测来确定是否正确,这里如果使用自动化测试,一般不会获得理想的效果。
如果简单的使用手工测试就可以彻底解决问题,那就太好了,一直以来,软件产业在手工测试都没有很好地发展。手工测试很慢,没有规律,不可反复使用,发现问题后也不能复现,又不能移植,而且没有很多可借鉴的经验教训来帮助测试人员做得更好。
现在是时候应该让我们在手工测试领域里使用目前最好的技术了!这就是本书中所要阐述的主题--探索式测试。希望软件产业可以跨过从前那种没有规律的手工测试作坊,迈步进入一个使用具有明确目的、非常规范的探索式测试的新时代。这里所说的过程要求手工测试必须经过精心策划,以防万一,同时又要预留一定的发挥空间,让测试人员在测试时可以随机应变。手工测试太重要了,不可轻视啊!
手工测试中使用脚本
很多手工测试人员会使用预先编写好的测试脚本。脚本用于指定该使用什么样的输入值,也定义了如何去判断正确的软件输出结果。脚本起的另一个作用就是它其实还记录着实际运行了哪些测试。
脚本可以规定的很细,也可以只含有一些粗线条的描述。当测试脚本比较笼统时,测试人员就需要学习随机应变的本领,掌握面对各种选择时如何可以进行合理的判断,这些就是探索式测试所要阐述的问题之一。
本书中,我们只讲述那些比较笼统的测试脚本。
探索式测试
如果完全抛开测试脚本就称为探索式测试。测试人员在测试应用程序中可以天马行空地想怎么测就怎么测,利用应用程序所提供的信息自由发挥,没有限制,不受任何约束地探索程序的各种功能,对一个有经验并熟练掌握探索式测试法的人员来说,这种测试方式可以说非常强大有效。
使用探索式测试并不是说不写文档。测试结果、测试实例和测试文档都会在运行测试时创建。这和普通测试在测试计划里预先编写好截然不同。用于记录探索式测试结果的最佳工具就是那些截屏软件和记录击键的软件。手工测试并不是说在测试过程中不能使用各种自动化工具,即使测试人员测试时使用了某些工具,还是算作手工测试,只是比起那些不用工具的人,他们的工作会更有实效。
探索式测试最适用于那些新潮使用“敏捷开发过程”的WEB应用程序。
探索式测试的缺陷在于测试人员有可能在测试中没有重点,从而漫无目的地尝试各种情况来试图发现软件缺陷,这会浪费大量的时间。在没有测试文档的情况下,测试人员如何保证良好的测试覆盖率呢?
这里要强调方法的重要性。探索式测试如果没有一个好的指导方法,就好像游客新到一座城市,然后盲目彷徨想碰巧找到景点一样。从测试策略的角度来说,明确到底要测试什么和怎么测试同样重要。
探索式测试有两种指导方法,都可以帮助测试人员做具体决策。一种称为局部探索式测试法,它辅助测试人员在测试过程中作出决定。另一种称为全局探索式测试法,它用于帮助测试人员设计整体测试计划和测试策略。
局部探索式测试法
手工测试人员的大部分工作都可以用下面一个词来形容,“变化无穷”。理论上可以这么说,运行任何一个测试用例都需要测试人员在测试期间做出几百个这样的抉择。
探索式测试法可以帮助测试人员在这种情况下做出明智的选择。当测试人员在面临前述抉择时,如果使用了探索式测试的策略,我们就称为局部探索式测试法,因为这样所做的决定基本上是针对局部小范围的。问题是很多测试人员在面临需要做出一系列这样小决定的时候往往不知所措。探索式测试有哪些智慧结晶可以帮助我们在测试时对这些细枝末节都能做出正确的决定呢?
本书第3章就致力于传授这些智慧火花。
全局探索式测试法
对测试而言,不仅仅是必须对所有这些细节做出正确的抉择,还有更多的东西,事实上,在所有的细节问题都解决之后,有可能会发现我们还缺乏一个综合的测试集,该测试集用于确定软件是否已经满足正式发布所需达到的质量标准。
这就说明测试人员非常需要一种可以帮助他们设计测试用例的策略。这里我们把前述问题的答案称为“全局探索式测试法”,因为这里做出的决定不仅仅影响单个的对话框或单个用户界面,它的范围涉及到软件的全局。这里所做的决定不仅仅是确定如何测试某个单一功能,而是确定了如何对软件进行探索式测试的整体方向。
第4章中,我把全局探索式测试法和旅游法进行类比。可以这么来看,如果一个游客来到一个从没有去过的城市,他需要参考那些全局性的建议选择去哪个饭店吃饭,然后再参考那些局部性的建议来决定点哪些菜和喝什么饮料。全局性的建议有助于确定一整天的行程,告诉你一天要干些啥,参观哪些景点,观看哪些演出,去哪里就餐。局部性的建议不仅可以帮助你一一处理这些事情,还可以协助你处理全局性建议无法涉及的细节问题。如果测试人员能把这两种方法很好地有机结合起来,那他就可以称得上是一名探索式测试人才了。
同时使用探索式测试和脚本测试
没有必要把探索式测试和使用脚本的手工测试对立起来,也没有必要认为两者不并存。事实上,这两种方法可以很好地结合起来。测试人员最终可以发现位于这两者中间的一个平衡点,在那里进行测试会最有效。
据我所知,同时使用这两种方法最好是从正式脚本开始,然后再使用探索式测试法在脚本中加入各种各样的变化。这样做的话,单一的测试脚本会演化出很多探索式测试用例。
第5章将讲述基于脚本的探索式测试法,因为这个主题太重要了,它算得上是手工测试人员必备的关键利器之一。
小结
在IT行业,从事手工探索式测试算得上是最有挑战性和最让人称心的一份工作。长久以来,对探索式测试一直没有比较好的参考指南,只有那些摸索探索式测试法多年并从实践中掌握了经验教训的老手才真正地在使用它。本书汇集了关于探索式测试法的大量经验教训和真知灼见,希望可以更快更多地培养出精通该技术的人才,为软件产业提供高质量的软件测试,为开发高质量软件做一份贡献。
在测试软件时,必须全神贯注,决不能心不在焉。本书的内容就是帮助我们集中精力,全力以赴,使测试更彻底、更完整。









猜你喜欢

转载自blog.csdn.net/zimingzim/article/details/80984961