Smart Testing

All about smart testing

Archive for the ‘Uncategorized’ Category

软件测试读书列表 (2013.8)

leave a comment »

列表格式为:图书分类、中文书名、英文书名、作者。排名不分先后,用红色标记出我推荐的书籍。

 

 

测试入门

软件测试(第2版)
Software Testing (2e), Ron Patton

一本测试入门的好书,较全面地介绍了各种测试领域和方法,为测试新手提供了正确的观念和宽泛的基础。

软件测试的艺术(第2版)
The Art of Software Testing (2e), Glenford J. Myers, Corey Sandler, Tom Badgett, Todd M. Thomas
一本“久经考验”的测试经典:1979年,第一版面试;25年后,第二版登场。平心而论,有些观点已经不能直接应用在测试实践中,但是仔细品味仍有所收获。毕竟,这是一本需要思考的书,而不是操作手册。

软件测试实战–测试Web MSN
蔡为东
以Web MSN为测试对象,形象生动地介绍了针对图形界面的黑盒测试技术,有很强的实践性。围绕一个实例,全面地的介绍各种测试方法,是此书区别于其他测试书籍的一大特色。附文《胶着》是作者一段开发经历的回顾与小结,有笑有泪,仅凭此文便值回书资。

软件测试工程师面试指导
蔡为东
面向初学者,介绍了软件测试行业、测试工程师素质要求、基本测试技术、求职策略、面试技巧、典型试题,对于测试新手或迈向测试行业的朋友有较高的参考价值。此书还收录了一些对读者来信的回复,内容涉及职业规划、大学生就业、测试学习、测试实践等,针对当前常见的困惑,做出了谨慎且深思熟虑的回答。附文《我在微软做软件测试外包》对于了解微软中国的流程与文化很有参考价值。

Essential Software Test Design
Torbjrn Ryber

该书专注于测试设计,深入浅出讲解了所有测试人员都需要掌握的基本测试技术。全书言简意赅、条理清晰、案例翔实,为测试实践打下了坚实基础。测试专家James Bach受邀编写了第6章“探索式测试解析”(Exploratory Testing Explained),对于理解探索式测试的思想和方法很有帮助。

 

通用测试技术

计算机软件测试(第2版)
Testing Computer Software (2e), Cem Kaner, Jack Falk, Hung Quo Nguyen
一本值得反复参考的好书,"The bestselling software testing book of all time" 的美誉绝非浪得虚名。作者将多年的实践经验用平实的语言娓娓道来,内容涉及测试技术、测试管理、开发流程、思考方法、实践模式,可谓是一本测试典籍。部分内容看似有些过时,但是其思想和方法仍旧有很高的借鉴价值。

Black Box Software Testing
Cem Kaner
由美国国家科学基金(National Science Foundation)资助的、Cem Kaner教授主持的黑盒测试在线课程。免费提供了详尽的课程幻灯片、学习资料和教学视频,系统性地讲授了黑盒测试的方法体系和关键方法,具有很高的参考价值。

Rapid Software Testing
James Bach, Michael Bolton
测试专家James Bach与Michael Bolton常年举办Rapid Software Testing培训,为许多测试人员理解并实施探索式测试提供了有益的起点。James Bach的网站提供了培训幻灯片和学习资料,以启发式测试策略模型(Heuristic Test Strategy Model)为核心,详细介绍了探索式测试的方方面面,值得深入学习。

微软的软件测试之道
How We Test Software at Microsoft, Alan Page, Ken Johnston, Bj Rollison
微软的资深测试者审视微软当前的测试方法,并展望软件测试的未来发展。缺点是没有结合Windows或Office这样的著名且复杂的产品,详细讨论具体项目的具体技术。优点是提供了许多小故事,讲述了Windows、Office、Live等产品开发中的点滴。从经验传承、启发思路的角度,这些故事是全书的精华,具有很高的参考价值。

How Google Tests Software
James A. Whittaker, Jason Arbon, Jeff Carollo
谷歌的测试总监和测试工程师介绍谷歌的测试团队、测试管理、测试方法和测试人员职业发展。优点是介绍了Chrome、Chrome OS、Google+和GMail等世界级产品的测试实践,并富有前瞻性地讨论了软件测试的未来发展。缺点是没有讨论谷歌的核心产品搜索引擎,没有介绍谷歌如何处理海量业务数据及其测试之道,颇让人遗憾。

敏捷测试:测试人员与敏捷团队的实践指南
Agile Testing: A Practical Guide for Testers and Agile Teams, Lisa Crispin, Janet Gregory
敏捷测试专家全方位讲解敏捷测试的专著,体系完整,论述周详,有正本清源、答疑解惑之功效。其中,“测试自动化金字塔”、“敏捷测试四象限”等思想很有启发性。

探索式测试实践之路
史亮,高翔
我与高翔合作,全面地介绍探索式测试的概念、理论、方法和实践。不敢自夸,且引用探索式测试专家James Bach对此书的推荐:This is the first book on exploratory testing, in any language, that summarizes the published work in the field.

Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing
Elisabeth Hendrickson
作者以基于测程的测试管理(session based test management)为基础,介绍了探索式软件测试的概念和方法。全书行文流程,生动地介绍了一批实用的测试方法,对于“测程”的灵活应用尤为精彩。
 

The Little Black Book On Test Design
Rikard Edgren
该书是作者十余年测试经验的总结与升华,面向有经验的测试人员,以测试学习、测试分析、测试设计和测试执行为主题提供了大量的启发式方法,具有较高的参考价值。此外,该书的参考文献非常丰富,为深入学习提供了良好的素材。

测试有道:微软测试技术心得
梁博, 许珊, 徐歆恺
内容由一系列技术点组成,每一个点都有精要的描述和作者的心得体会,力图以小搏大,以精粹胜广博。但是没有提供一个理论框架将这些点有机地联系起来,读起来有只见树木、不见深林之感,也缺少“授人以渔”的独到见解。最大优点是介绍了一批免费且实用的工具,可以放在案头备查。

软件测试基础:方法与度量
Software Testing Fundamentals: Methods and Metrics, Marnie L. Hutcheson
以风险分析为核心,讨论了测试计划、测试组织和测试设计。其中,关于“测试价值的可说明性”和“利用Office Suite来撰写、管理测试计划”的内容有启发性。适合有一定工作经验的测试人员参考。

软件测试(第2版)
Software Testing A Craftsman’s Approach (2e), Paul C. Jorgensen
将理论与工艺结合在一起的测试教科书。比较严谨地讨论了软件测试的基础理论,适合软件测试研究者研读。

面向对象的软件测试
A Practical Guide to Testing Object Oriented Software, John D. McGregor, David A. Sykes
介绍了面向对象软件测试的基本思路和方法。第7章“测试类的层次结构”比较有启发性,讨论了针对继承的测试设计和组织,相关内容在其他测试书籍中并不多见。

软件测试技术大全:测试基础、流行工具、项目实战
陈能技
该书由多位作者共同撰写,内容涉及测试理念、测试技术、测试开发、测试自动化、测试管理和常见的测试工具,不愧“测试大全”的书名。有些内容失之于粗糙,一些论述也不够严谨,缺乏参考文献更是此书的硬伤。瑕不掩瑜,此书理论和实践结合紧密,仍值得测试工作者学习和思考。

 

测试管理

笑傲测试–软件测试流程方法与实施
魏伟
以小说为体裁的测试管理书籍。通过令狐冲和风清扬的对话,从一个逐渐成长的新人的角度,介绍了测试管理的点点滴滴。全书轻松幽默,全无技术读本的枯燥乏味。附录所收录的文章“从新鲜人到新仙人”对于行业新人颇有帮助。

步步为赢–软件测试管理全程实践
蔡为东
以“管理就是负责人”为核心,介绍作者担当测试领导的切身经验:自我管理、自我成长、编写测试计划、编写测试用例、执行测试、沟通、测试计划/用例评审、测试总结、员工管理、测试思想等。也适合第一线的测试工作者阅读,所涉及内容皆和他们的日常工作密切相关。

 

专项测试技术

软件安全测试艺术
The Art of Software Security Testing: Identifying Software Security Flaws, Chris Wysopal, Lucas Nelson, Dino Dai Zovi, Elfriede Dustin
软件安全测试的入门书,用很短的篇幅涵盖了软件安全测试的多个领域,为测试人员提供了模型、方法和工具。对于Threat Modeling的介绍很精彩,为进一步的行动提供了良好的理论与实践基础。

Web安全测试
Web Security Testing Cookbook: Systematic Techniques to Find Problems Fast, Paco Hope, Ben Walther

一本实践性很强的Web安全测试手册。从网络安全的角度,介绍了一批免费的网络通信分析、监控、修改、调试工具;以条目为组织,介绍了的测试方法或策略;以实践切入,穿插介绍理论知识,通过精心选材和组织,降低了Web安全测试的门槛。

探索式软件测试
Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design, James A. Whittaker

测试专家James Whittaker旗帜鲜明地捍卫手工测试,探讨如何用探索式测试来应对严峻的现实挑战。作者以隐喻“漫游”(Touring)为核心,提出了一套有助于探索式测试的测试方法(多数为漫游测试和快速测试)。作者历任微软测试架构师和谷歌测试总监,其理念已经在微软和谷歌的测试产品中逐渐体现。

实用软件测试指南
How to Break Software: A Practical Guide to Testing, James A. Whittaker
软件测试专家编写的实战指南,以“缺陷模式”(defect mode)为核心介绍了一批快速测试(quick  test)方法和相应的的测试工具,对于压力测试、极限测试有较强的参考价值。

软件测试新技术与实践
于秀山, 于洪敏
介绍了组合测试技术在测试中的应用。适合组合测试研究者参考。

Web应用程序性能测试指南
Performance Testing Guidance for Web Applications, J. D. Meier, Carlos Farre, Prashant Bansode, Scott Barber, Dennis Rea
微软模式与实践(pattern & practices)团队的佳作,介绍了性能测试的正确观念、流程和实践。篇幅短小,内容深邃,值得在实践中反复参考和体会。

应用程序性能测试的艺术
The Art of Application Performance Testing: Help for Programmers and Quality Assurance, Ian Molyneaux
经验丰富的软件性能测试专家分享他的经验,内容包含性能测试的架构、模型、典型方法和结果分析。适合有一定经验的测试者参考。

Tap Into Mobile Application Testing
Jonathan Kohl
探索式测试专家的力作,针对运行在智能手机和平板电脑之上的移动应用,提出了一组有针对性的漫游测试和情景测试方法。其中,针对真实使用情景挖掘测试想法的策略极具启发性,也值得其他领域的测试人员参考。

 

测试自动化

Experience of Test Automation:Case Studies of Software Test Automation
Dorothy Graham, Mark Fewster
面向有经验测试人员的测试自动化案例分析汇编。第0章是全书案例的经验总结,第1~28章是来自28个不同类型项目的测试自动化报告,第29章则提供了一组真实的测试故事。软件测试是语境驱动的,观察不同团队的实践,分析成败得失,可谓开卷有益。

XUnit Test Patterns: Refactoring Test Code
Gerard Meszaros
此书是为数不多的以测试为主题获得Jolt生产力大奖
的名著。以翔实的案例充分讨论了自动化测试代码的设计、模式和重构方法,堪称单元测试“大典”,对于集成测试也有很高的参考价值。

.NET软件测试自动化之道
.NET Test Automation Recipes:A Problem-Solution Approach, James D. McCaffrey
该书讲解了在.NET平台上编写轻量级测试程序的实用技术。作者曾经在微软工作,该书与微软测试开发工程师的培训材料的契合度很高,实践性很强。对于Windows平台的测试工程师而言,此书的参考价值很高。

.NET软件测试指南
A Tester’s Guide to .NET Programming, Randal Root, Ary Romero Sweeney
严格来说,这是一本以测试为目标的讲解.NET编程的书。内容浅显、涉猎面广,适合没有太多.NET开发经验的测试人员参考。

集成测试框架–用Fit进行敏捷软件测试
Fit for Developing Software: Framework for Integrated Tests, Rick Mugridge, Ward Cunningham
Fit是一种编写系统测试的测试框架,作为一种业务交流工具,它深刻地反映出敏捷软件开发的若干特质。此书由Fit之父亲自编写,不但可以了解Fit的方方面面,还能从中体会大师的感悟与实践。

互联网单元测试及实践
陈卫俊, 赵璨, 周磊, 陈洪
介绍了常见的单元测试框架,并结合具体项目讲解了单元测试的基本理论和技术。对于Web测试的新手,有较高的参考价值。

Visual Studio 2005 Team System软件测试专家教程
Professional Software Testing with Visual Studio 2005 Team System: Tools for Software Developers and Test Engineers, Tom Arnold, Dominic Hopton, Andy Leonard, Mike Frost 
介绍如何利用Visual Studio 2005 Team System进行有效的单元测试、数据库测试、Web测试、负载测试和代码分析。以介绍概念和流程为主,适合新手快速上手。

.NET软件测试实战技术大全:测试基础、流行工具、典型案例
陈能技
系《软件测试技术大全》的.NET版,在内容的深度和价值上,皆不及前者。胜在专注于.NET和Windows平台上的测试自动化,介绍了多种测试技术和工具,覆盖面广,且切合实践。适合.NET平台上的新手参考。

 

经验总结

软件测试:经验与教训
Lessons Learned in Software Testing, Cem Kaner, James Bach, Bret Pettichord
值得反复研读的经典好书。Tom DeMacro的赞美——“这些经验中的任何一个,都抵得上这本书的价钱”,所言非虚。

完美软件–对软件测试的各种幻想
Perfect Software: And Other Illusions about Testing, Gerald M. Weinberg
该书没有介绍具体的软件测试技术,它讨论的是软件开发中的人、他们对测试的认知、软件测试的目的、实现目的的社会学和心理学上的探索。它试图建立正确的软件测试观念、协调的心理情绪和有效的思考方式。这些要素最终会决定在具体的项目中采用何种具体测试技术的组合。

测试之美
Beautiful Testing, Tim Riley, Adam Goucher
该书由27位测试实践者共同撰写,提供了22篇来自不同语境的测试实践小结。其“美感”来自于实践者之间的印证、启发、激励。这要求读者将自己的经验与思考带入阅读,与作者就更美的软件测试进行“对话”。

有效软件测试——提高测试水平的50条建议
Effective Software Testing: 50 Specific Ways to Improve Your Testing, Elfriede Dustin
测试领域的Effective C++,广受赞誉,所提供的50条经验有很强的实践指导意义。

软件测试求生法则
Surviving the Top Ten Challenges of Software Testing : A People-Oriented Approach, William E. Perry, Randall W. Rice
作者讨论了测试人员所面临的十大“人际挑战”。从具体案例出发,介绍了挑战的表现形式、产生根源、解决方法和可能遇到的问题。虽然,外企的文化氛围与中国企业有一定差别,但是分析问题、解决问题的思路仍值得借鉴。

赢在测试:中国软件测试先行者之道
蔡为东
介绍了一批测试先行者的个人经验的书。学习他人经验可以用较低的成本去扩大自己的体验,自然是他山之石可以攻玉,开卷有益。不过,个人经验非批判性地阅读与理解,不能有效,甚至有害,所以该书适合愿意学习且有能力学习的测试爱好者。不足是大部分被采访者都是管理者,没有真正的测试技术专家。

软件测试精要
董杰
作者分享他在测试领域的经验与思考,其热情和思辨跃然纸上。缺点是内容却有些散乱,即便是一章,其系统性也有些不足;对于测试工具背后的测试思想,挖掘得比较浅,没有上升到测试理论的高度。

Written by liangshi

August 24, 2013 at 8:43 am

Posted in Uncategorized

语境驱动测试7原则

leave a comment »

本文系《探索式测试实践之路》第1.2节,简要的讨论了“语境驱动测试”(Context Driven Testing)的7条原则。所引用文献的详细信息可以在这里找到。

 

探索式测试的奠基人和积极实践者Cem Kaner和James Bach都支持语境驱动测试[Kaner12]。语境驱动测试的7条基本原则对于正确理解并应用探索式测试具有重要意义,本节将予以简单讨论。

 

原则1:任何实践的价值都取决于其语境(Context)。

这条原则几乎是不言自明的。中国人很早之前就有相似的认识,“南橘北枳”(语出《晏子春秋》,其成书于战国,后经西汉刘向整理)指相同的种子在不同的环境中会结出不同的果实。因此古人建议“因地制宜”(语出《吴越春秋》,成书于东汉),即根据当地的具体情况,采用合适的措施。

然而,软件开发者往往会在无意中忘记这条原则。开发团队会照搬以往的经验,却不考虑经验可能已经过时;会不假思索地采用他人建议的开发方法,却不怀疑南橘北枳的可能;会按照高层的指示亦步亦趋,却不思索指令是否合理。更糟糕的是,在感觉到情况不妙后,却将错就错,不思变更。因此,开发团队需要频繁地反思其开发实践是否符合当前的语境,并做出相应调整。

 

原则2:在特定语境下存在好的实践,但不存在最佳实践。

这条原则看似有些武断,毕竟软件研发已经沉淀出一批公认的实践方法,它们是现代软件开发必不可少的核心实践。但是,细细一想便会发现这些方法也需要因地制宜。“持续集成”是公认的最佳实践,但是不同的团队往往有不同的集成频率。对于小型项目,一次签入(Check-in)会触发一次完整的构建;对于大型项目,开发团队可能每天做一次完整构建;对于超大型项目,做一次完整的构建可能需要几天甚至更长的时间。不同的构建频率和构建代价自然会导致不同的签入策略和测试方法。虽然都在实施“持续集成”,但是不同的团队会设计出不同的流程和方法。

对于测试工作者,这条原则表示任何一种测试方法(包括探索式测试)都不是无条件的最佳选择。测试人员始终要评估当前情况,寻找适合当前语境的测试风格和技术。

 

原则3:人,在一起工作的人,是项目语境中最重要的部分。

这条原则强调了软件开发的社会学因素。软件开发专家Tom DeMarco和Tim Lister指出:“本质上,我们工作中的主要问题,与其说是技术问题,不如说是社会学问题”[DeMacro99]。而社会学因素的根源是“软件开发是一个创造与沟通的协作游戏(Game也可以翻译为“博弈”。本书将其翻译为“游戏”是为了突出软件开发的乐趣、协作、沟通与互助。软件开发团队的对手不是团队成员,而是亟待解决的问题)”[Cockburn07]。在创造与沟通的过程中,一定是个体和他们的交互(Individuals and Interactions)起主要作用。

在软件测试中,以下观点反映了人的重要性。

  • 软件开发是具有挑战性的智力活动,开发人员(包括测试人员)的责任感、技能、状态将强烈影响软件实现和代码质量。因此,招聘、培训、挽留高水平开发人员是软件企业最重要的工作之一。
  • 软件开发是一种创造与沟通的游戏。软件企业应该营造一种开放、协作的工作环境,使得开发人员能够自如地去思考、去发明、去创造。
  • 软件测试的核心任务是寻找并传递信息。在寻找信息的过程中,测试人员的能力和相互协作的水平将在很大程度上决定信息的数量和质量。
  • 软件测试提供信息服务。服务就意味着有客户,测试人员是否成功,主要取决于是否很好地满足了客户的要求和最佳利益[Kaner01]。也就是说,测试人员的重要任务是理解客户,并与他们展开有效的交流。

以上观点只涉及该庞大主题的一小部分。笔者建议读者去阅读此领域的经典书籍(请参考本书附录中的“推荐阅读”)以获得更多见解。

 

原则4:项目的发展往往难以预料。

在一些语境中,项目的发展是可以预料的。图1.1摘自Steve McConnell所著的《软件估算》,它显示了(对项目范围、代价、功能的)估算值是如何随着项目的进展变得准确的[McConnell06]。随着时间的推移,项目的不确定性逐渐降低,当项目即将结束时,开发团队能够准确预期项目的结局。但是,图1.1也提示了在项目的开始阶段,项目的不确定性非常高。在初始概念(Initial Concept)阶段建立的估算值可能是实际值的4倍。

该原则并不是一个悲观的见解,相反它体现了一种实事求是的态度和对软件风险的成熟认知。探索式测试有助于快速获得信息,从而降低软件项目的不确定性。成功的测试团队在整个项目过程中会结合广度优先探索和深度优先探索,在特定的时间选择适合的方法,从而更明智地利用测试资源。

 

clip_image002

图1.1 根据日历时间得到的不确定性锥(Cone of Uncertainty)

 

原则5:产品是一种解决方案。如果问题没有被解决,它就是无用的(Doesnt Work)。

成功的软件必须帮助用户解决现实世界中的问题,辅助他们获得成功。在极端情况下,一个符合规格说明且没有技术缺陷的软件会遭遇失败,因为它没有解决用户的问题,甚至阻碍用户解决问题。图1.1显示,在需求完成(Requirements Complete)时,不确定的范围会大幅缩小。但是,如果需求存在重大缺陷,甚至初始概念就是错误的,那么稳定的开发过程只会“稳定地”产生失败的产品。

这一原则要求测试工作者用软件用户的视角考察整个产品,从显式规格说明(不完整、模糊、包含错误的项目文档)和隐式规格说明(包括竞争对手产品、相关产品、已发布版本、电子邮件讨论、口头讨论、论坛反馈、博客文章、领域专著、测试经验等)中,挖掘、推导、发现需求。这是探索式测试人员需要掌握的探索技能。

 

原则6:好的软件测试是一个具有挑战性的智力过程。

这又是一条不言自明的原则,相信本书的读者也会认同该原则。虽然您可能会质疑本书的一些观点,但是您的阅读已经说明软件测试的挑战性和复杂性需要认真研究与思考。

这条原则的推论是枯燥、机械、无成就感的测试过程不是好的软件测试。这样的过程压抑了测试人员的创造性,分散了他们的注意力,降低了他们的智力水平。然而,本书的作者们也必须承认,我们在日常工作中也时常会感到枯燥、单调、缺乏创造力。对此,笔者的基本观点是:第一,测试人员应该以合乎要求的质量完成自己的工作,这是测试人员必须履行的职责;第二,应该将单调的工作视为改进的信号,通过改变工作内容和流程,将更多的时间用于具有挑战性的工作。探索式测试、技术创新和测试自动化是笔者的常用工具。

 

原则7:只有通过判断和技能,并在整个项目过程中协同练习(Exercise Cooperatively)它们,我们才能在正确的时间做正确的事,以有效地测试我们的产品。

软件测试领域的一些文献似乎在暗示,只要严格遵循“优秀”的测试过程或模板,就可以使普通的测试人员成为测试专家,并获得理想的测试结果。这种观点是不正确的,因为只有高素质的测试人员才能根据语境设计出合适的流程、计划、策略和用例,而这些才是有效测试的基础。

那么该如何培养高素质的测试人员呢?Cem Kaner指出:“测试过程的一个重要成果,是更好、更聪明的测试人员。”[Kaner01]优秀的测试人员具备高超的技能,而这种技能只能通过持续的学习和实践才能获得。而且在一个合作与分享的环境中,测试人员可以学得更快、练得更好。

Written by liangshi

September 3, 2012 at 2:07 pm

Posted in Uncategorized

探索式测试:基于测程的测试管理(Session-Based Test Management)

leave a comment »

为了有效地管理测试,测试领导需要评估测试团队的生存力、当前测试的进度、测试覆盖的范围、已经暴露的风险、测试人员是否需要帮助等因素。一个好的测试流程可以帮助测试领导和测试团队了解这些因素,并实施积极的管理。为了使探索式测试满足软件开发团队对可管理性的要求,Jonathan Bach和James Bach提出了基于测程的测试管理(Session-Based Test Management,简称SBTM)[Bach2000]。本文将介绍SBTM的概念与方法。

Session的翻译:测程

在翻译Session时,我遇到了困难,因为现有的中文表达难以传递出SBTM中Session的两层含义:

  • Session是一段不受打扰的测试时间(通常是90分钟),是测试管理的最小单元。
  • 一系列Session相互支持,有机地组合在一起,周密地测试了整个产品。

在如此语境下,Session的同义词是Term(学期、会期)、Period(时段、课时)、Semester(学期),但是直接使用这些同义词的中译并不适当。进过反复考虑,我将Session翻译为“测程”,原因有三点:

  • 用专用术语“测程”指代SBTM的Session,与Session的其他含义或中译(如“会话”)做明显的区分,这有利于快速、清晰地传达语义。
  • “测程”表达出Session的基本语义:一段专注于测试的过程。
  • “测程”与“课程”有相似的词汇结构,暗示了一系列测程组合在一起研究了整个产品,正如课程通过一系列课时讨论了一个完整的领域。

测程的四个要点

测试专家Michael Bolton用一页幻灯片总结了SBTM的特征与内容[Bolton2006]。

image

如幻灯片的标题和右侧的图画所示,SBTM的重要特征是将测试过程分解为一组测程,从而提高整个测试项目的可说明性(Accountability)。为此,一个测程包含四个要点:主题(Charter)、时间盒(Time Box)、可评审的结果(Reviewable Results)和简报(Debriefing)[Bach2004]。

主题(Charter)是一个测程需要完成的任务。该任务应该是清晰且具体的,可以在90分钟的时间内完成,并提供有价值的简报。主题通常用一段简练的文字描述,其内容可以是测试一个功能、检查一个风险、测试一组用户情景(User Scenario)等。以下是两个实例[Michael2007]:

  • Create a test coverage outline and risk list for DecideRight. (为产品DecideRight生成测试覆盖大纲和风险列表)
  • Explore a decision created with QuickBuild – the wizard that guides the user through the options, criteria, and weights needed to calculate the best decision. (探索QuickBuild如何产生一个决策——用户向导应该引导用户使用选项、标准和权重来计算最佳决策)

时间盒(Time Box)是一段不受打扰的测试时间,其长度一般在60~120分钟,以90分钟较为常见。在此期间,测试人员不回答问题、不回复邮件、不应答即时消息,只专注地实施测试。从工程师的角度,时间盒使测试人员能排除干扰,全力应对测试的智力挑战。从测试团队的角度,固定且专属的时间盒使得测试规划和进度追踪变得更容易。

可评审的结果(Reviewable Results)是测程的产出,常见的形式是测程表(Session Sheet),其内容可以包括:

  • 主题(Charter)
  • 测试人员
  • 测试所覆盖的区域
  • 测试设计和测试发现
  • 测试所发现的缺陷(Bugs)
  • 测试所发现的问题(Issues)
  • 测试所使用的数据文件
  • 测试活动的时间统计:在产品安装、测试设计与执行、缺陷调查与报告、非测试活动中各花费了多少时间。

简报(Debriefing)通过面对面的交流将测试情况传递给测试领导。在一天的测程结束后,测试人员向测试领导当面汇报测试情况。领导查看测程表,提出一些问题,测试人员解释测试结果,并回答疑问。测试领导也可以召开小组会议,让测试人员轮流报告当天的测试结果,使测试团队对当前产品的质量形成较完整的认识。

测程表(Session Sheet)

传统上,测程表是一个文本文件,拥有固定的格式。这样,测试领导可以用一个文本处理程序从多个测程表中提取信息,形成聚合的测试报告。测试人员也可以用程序读取测程表,将其中的缺陷记录自动提交到缺陷管理系统。Michael Bolton曾经分享过两个测程表的实例[Bolton2007],本文摘录一个实例如下。

123

该实例反映了测程表的几个特点:

  • 测程表记录了一些任务分解(Task Breakdown)数据,如在测试设计和执行(Test Design and Execution)、缺陷调查和汇报(Bug Investigation and Reporting)、测程建立(Session Setup)等活动上花费的时间。这些数据配合简报有助于测试领导估算测试速度、评估测试效率。
  • 测程表拥有固定的格式,该实例用特殊符号“#”标记了文本处理程序可以提取的数据。测试人员只要遵循简单的格式,就可以产生易于自动分析的测程表。一个简单的文本处理程序(或脚本)能够批量地处理测程表,产生测试报告和图表,并完成自动化任务(如提交缺陷记录到缺陷管理系统)。
  • 测程表列举了测试所使用的数据文件(Data Files),为测试数据复用提供了基础。
  • 测程表的核心是测试笔记(Test Notes),它简略地叙述了测试故事(Testing Story):为什么测试,如何测试,为什么认为我们的测试是足够好的。
  • 测程表记录了缺陷(Bugs)和问题(Issues),它们不但是测程的直接产出,还是规划未来测试的参考资料。

近年来,出现了更多的SBTM支持工具[Carvalho2011],能够支持更富表现力的测程表。例如,RapidReporter可以方便的生成CSV和HTML格式的测程表,CSV格式便于进一步地自动处理,HTML格式则支持较复杂的排版和屏幕截图。

聚合测程表收集的数据,测试领导可以评估团队的测试速度。下图显示了已执行测程的总时间随日期的变化趋势,这有助于测试领导评估在项目结束前还可以执行多少测程[Jonathon2004]。如果余下的测试时间不足以完成测试使命,他需要采取措施,以避免项目失败。

Clipboard01

SBTM是动态管理

在项目之初,测试团队对产品还不够了解,测试领导可以安排一些“侦查型”的测程去学习产品的各个区域。例如,上文提到的“为产品DecideRight生成测试覆盖大纲和风险列表”就侦查了产品的主要功能和风险。基于这些测程的测程表和简报,测试领导可以拟定测试项目的总体计划,并大致规划出测程的数目与主题。

在项目过程中,好的测试领导会通过测程表和每日简报,积极发现产品或测试的问题,实施有针对性的解决方案。例如,测试领导老王通过阅读测程表,发现测试人员小张常常花费过多的时间在缺陷调查上,他会与小张交谈以了解情况。面对面的交流使信息得到高效地传递,并有助于消除统计数据的误导和书面文字的歧义。如果小张是喜欢打破沙锅、追根究底,老王会告诉他:在调查缺陷时,可以设定一个最长用时(如15分钟),当时间用尽,应该停止调查,根据已知情况提交缺陷报告。此外,他还会安排一些有技术挑战的任务给小张,以帮助他的技术成长。如果小张是不了解产品而花费了过多的调查时间,老王会安排有经验的员工指导小张,或亲自传授一些知识和技能,以帮助他渡过难关。如果是糟糕的可测试性导致了过长的调查时间,老王会和开发团队联系,提出改进意见,以推动产品可测性的提高。

随着产品和项目环境的变化,测试内容与策略也要做相应的调整。测试领导会根据测程的结果来调整下一步的测试计划。他可以新增几个测程,以调查最新发现的风险;他也可以合并几个测程,将省下的时间分配给更重要的测程。一切调整的目标都是为了优化测试的价值。

由以上论述不难看出,SBTM与敏捷开发宣言[Agile01]是高度一致的。在原则上,他们都认同:

  • 个体和互动高于流程和工具  
  • 响应变化高于遵循计划

在实践上,他们都认可:

  • 围绕被激励起来的个人来构建项目。提供他们所需的环境和支持,并且信任他们能够完成工作。
  • 在团队内部,最有效率与效果的传递信息的方法,就是面对面的交流。

可见,SBTM和敏捷开发虽然来自于不同的专家、实践和社区,但是他们拥有相似的核心,其思想和方法可以相互借鉴与补充。

SBTM是管理框架

测试专家Paul Carvalho指出SBTM一个管理框架(Management Framework),其基本元素是:设定清晰的主题、固定长度且不受打扰的工作时间、产生可检查的结果、利用评审和简报来驱动未来的Session [Carvalho2010]。该框架的合理名词也许不是Session-Based Test Management,而是Session-Based Task Management。个人或团队可以用它管理各种类型的(创造性)活动,如编程、写作、锻炼身体、整理房间等。

从这个角度,SBTM与SMART 原则(Specific, Measurable, Achievable, Relevant, Time-boxed)和番茄工作法有异曲同工之妙。

  • Specific(具体的):一个测程需要一个具体的主题,一个番茄钟需要一个具体的目标。
  • Measurable(可度量的):测程产出测程表以反映测试进展。番茄钟关注当前任务是否完成,并收集过程指标。
  • Achievable(可实现的):对于测程和番茄钟,主题和目标应该是可实现的。这潜在地要求将一个大目标分解为多个小目标,且每个小目标也是具体的、可度量的、可实现的。而且,追踪小目标的完成情况提供了整体进度的可度量性。
  • Relevant(相关的):测程要为测试项目服务,要切合当前情况,并优化产品价值。番茄钟要针对最重要的任务,以实现自我承诺。
  • Time-box(有时间限制的):测程和番茄钟都提供了一个固定的时间段以一心一意的工作。

参考文献

注:如果您想快速理解SBTM创建者的观点请参考[Bach2004]。如果您想获得SBTM的实践经验请参考[Carvalho2011] 。

Written by liangshi

June 20, 2012 at 11:40 am

Posted in Uncategorized

Test Tools on Windows

with 4 comments

在Windows平台上,做了两年的软件测试,小有收获。用这篇日志小结一下通用的测试工具。

Notepad2
测试者需要一种可以在任何机器上立即部署、立即应用的编辑器,Notepad2就是一个很好的选择。它是一个小巧的编辑器,用不到1M的大小提供了丰富的功能。在查看方面,它可以语法高亮多种程序文件,可以显示空格、回车、换行等特殊字符(这对测试者了解文件内容的细节很有帮助),可以轻松的放大或缩小字体。在编辑方面,它提供了基本的缩进、注释、字符集转换等功能。目前,我使用它完成80%的程序开发任务。

Notepad++
有时,测试者或他的工作伙伴也需要多标签的、功能更加丰富的源代码编辑器。开源的Notepad++是一个不错的选择。它的二进制格式查看和编辑能力,是Notepad2所不具备的。

WinMerge
在测试过程中,测试者往往需要比较不同版本的源代码,比较两个文件或目录的内容。WinMerge是开源的比较和合并工具,界面友好、功能实用。

IronPython/Python
Python是一门成熟的动态语言,特别适合测试自动化工作。IronPython是基于.NET平台的Python语言实现,特别适合.NET程序的测试。例如,IronPython可以绑定到.NET对象的私有成员,可以直接测试对象的实现细节。更重要的是,IronPython提供了快速测试、快速反馈的便利性,符合软件测试的语境驱动方法的理念。目前,我使用IronPython完成80%的测试开发任务。

Windows PowerShell
Windows PowerShell是Windows Server 2008以及后续Windows平台的内建组件。越来越多的Windows Service(如SQL Server、IIS、Visual Studio Team Fundation Server、Hyper-V等)已经或即将支持PowerShell。作为测试自动化工具,PowerShell是测试工具箱中不可或缺的一员。

SQL Server
测试工作者需要管理测试数据、检查测试输出、汇报测试结果,这都需要数据管理、操纵、计算工具。如果数据规模大、保持时间长、需要供多种系统使用,那么数据库就是值得仔细考虑的测试工具。SQL Server不但提供了强大的存储引擎、便利的管理工具,还可以与Visual Studio、ASP.NET等系统平滑集成,有利于测试开发和维护。一般情况下,免费的SQL Server Express可以满足大多数测试工作的需要。

Microsoft Office
测试人员最重要的能力是思考和交流;Microsoft Office Suite可以帮助测试者更好的思考和交流。

  • Word可以编辑测试文档、工作日志(Word 2007可以发布Blog)、Fit测试表格。它的批注功能便于团队成员之间的交流。
  • PowerPoint不但是制作测试报告的利器,也是测试大纲、会议纪要的记录工具。
  • Excel可以用于测试结果分析、测试图表生成。它还可以用ODBC连接数据库或其他的数据源,是方便的数据呈现和操纵工具。
  • OneNote可以记录工作笔记、测试灵感、待办事项等多种信息,可以解放测试者的大脑。
  • Outlook和Exchange是大型企业工作流的一部分,是每日必用的交流工具。当然,面对面的交流是远胜于邮件的协作方式。
  • SharePoint提供了团队合作的基础,其Wiki功能对于分享团队知识非常方便。

Windbg
面对测试环境中的异常,测试工作者往往有两个选择:第一、用Windbg附着(attach)到目标进程进行调试;第二、用Windbg或其他工具(自动)生成内存映像文件(memory dump file),然后用Windbg分析该文件。作为Windows平台上优秀的调试工具,Windbg是解决疑难杂症的好帮手。

Reflector
利用Reflector,可以方便地了解.NET程序集(Assembly)的实现细节,对于制定测试策略、编写测试用例很有帮助。它还支持多种插件,可以生成源代码文件、比较程序集异同、进行代码搜索,是.NET平台上必不可少的测试工具。

EPSnap
一图胜过千言万语,测试报告往往也需要图片来进一步说明。EPSnap是一个免费的绿色截屏工具,它可以自定义快捷键、抓取多种类型的区域、保持多种格式的图片。目前,我使用它完成所有的截图工作。

Windows Sysinternals
Sysinternals提供了一组好用的工具用于管理、诊断、检查Windows系统和应用程序。目前,我使用的最多的工具是进程管理工具Process Explorer和桌面制作工具BigInfo。

Perfmon
Windows内建组件Perfmon可以监控并记录Windows系统和应用程序的性能参数,是性能测试和故障诊断的好工具。

Event Log
Windows内建组件Event Log可以记录Windows系统和应用程序的重要事件,是故障诊断的好工具。

Schedule Tasks
Windows内建组件Schedule Tasks可以定时启动指定的程序。目前,我使用它完成数据备份、启动每日测试(daily test)和循环测试(rolling test)、自动部署被测试系统等多项任务。

Visual Studio
Visual Studio是Windows和.NET平台上最强大的开发工具,也是测试人员开发测试程序、调试产品代码的利器。配合Team Foundation Server (TFS),可以建立代码管理、缺陷管理、工作项管理、开发报告的集成环境,是团队协作的基础设施。目前,我所有的测试代码都签入(check-in)到TFS中。

Written by liangshi

January 1, 2009 at 12:06 pm

Posted in Uncategorized

Rolling Test

with one comment

持续集成是敏捷软件开发的核心实践。在我的项目中,我实践了一种与持续集成类似的测试活动:

Rolling Testing:每个小时,从源代码管理系统中获得当前版本,进行完整的构建(build)。在一台干净(clean)的机器上,部署新构建的系统,执行端到端(end to end)的系统测试。最后,用电子邮件将测试结果发送给开发团队。整个过程是无人值守的。

按照《持续集成》的定义,Rolling Testing不是严格意义上的“持续集成”(Continuous Integration)。不过,它所发挥的作用与持续集成非常接近。

Why

  1. Rolling Testing可以尽快地发现集成错误。开发者在自己的开发环境中工作,他所看到的系统是他最后一次检出(check-out)的结果。他根据这一版本的“知识”来开发新的功能。虽然两个开发者的都基于相同的“知识”来进行开发,但是不能保证他们所构造的新“理论”是相互一致的。往往,两部分的代码都通过了单元测试,但是检入(check-in)之后却引发了集成错误。Rolling Testing用端到端的系统测试弥补了单元测试的不足,能够提供快速的系统级的测试反馈。
  2. Rolling Testing可以节省大量的开发时间。集成错误往往会阻碍全面的系统测试。例如,模块A不能正确解释模块B的输出,它抛出异常并停止工作。这时,系统测试将无法覆盖模块A及其后续模块的代码。这将严重影响测试效率,甚至使得每日运行的全面回归测试变得毫无效果。Rolling Testing可以在检入之后的一个多小时内捕获到此类严重的错误,那么开发者就可以在第一时间修正错误,清除测试障碍(题外话:清除障碍并给予人们完成工作所需要的东西,是Scrum方法论的核心)。有时开发者的修正会引入的新的集成错误,Rolling Testing的安全网会再次捕捉到它,于是我们有机会保证:在下班回家的时候,没有明显的集成错误。
  3. Rolling Testing可以发现环境错误。所有的开发者都应该听从John Robbins的忠告:不要在开发机上使用Administrator权限。不过久经世故的Cem Kaner也说过:本书介绍的测试,假定的前提是你的同伴现在没有、将来也不会并且也没有必要遵循这些规定。由于开发者在开发机上拥有Administrator权限,他们安装了各式各样的工具和运行库,我们无法保证所开发出的系统能够在其他环境中以合适的权限正常工作。Rolling Testing在干净的机器上部署被测试系统,能够发现许多在开发环境中无法发现的错误。所谓干净的机器,并不要求重新安装操作系统,只是要求完整地卸载了旧版本的系统。
  4. Rolling Testing保证了被测试版本的基本质量,使测试团队更有信心进行大规模的功能测试和压力测试。

How

  1. 基本方法是利用Windows Schedule在每个整点触发流程,从源代码管理系统中获得完整的最新版本,然后利用构建工具执行完整的构建。如果构建失败,则无需继续:构建失败(build break)要求更紧急的修复。如果构建成功,在一台干净的机器上部署整个系统。然后,调用测试工具或测试框架执行系统测试。最后,汇总测试结果,生成测试报告,并用邮件发送给负责Rolling Testing的测试和开发人员。
  2. 自动化是Rolling Testing的关键。从以上流程可以看出,Rolling Testing所使用的工具无非是:操作系统自带的服务、源代码管理工具、构建工具、自动化测试框架、内部邮件系统,这些都是开发团队的常备工具(如果没有源代码管理和构建工具,那么立即部署合适的工具是开发人员的第一要务)。因此,用合适的方法将工具连接起来,构建出完整的流程,是架设Rolling Testing的主要任务。在Windows平台上,DOS Shell是最常用的脚本技术,可以满足大部分的要求。此外,PowerShell和IronPython能够直接利用.NET framework的强大功能,往往能事半功倍。
  3. Rolling Testing要能够在30分钟内完成(在我的项目中,Rolling Testing大约持续25分钟)。如果Rolling Testing发现了错误,开发人员需要在Rolling Testing环境中调查故障原因。为了不影响下一次的Rolling Testing,一般要留下30分钟的时间给开发人员进行诊断。

Tips

  1. 要部署完整的系统。对于一些分布式系统而言,将所有的子系统部署在一台机器上有些“不合情理”。但是,部署所有的子系统可以测试到所有的子系统的部署功能,也能够检查出由于子系统冲突造成的部署失败。部署是任何系统的核心功能,是Rolling Testing必不可少的测试内容。此外,在部署最新版本之前,Rolling Testing会反安装旧版本的系统。这也测试了系统的反安装功能。
  2. 测试用例集包含最重要的端到端系统测试。Rolling Testing的主要目的是发现集成错误,因此测试执行应该能够“从输入到输出”覆盖到所有的子系统。考虑到用户价值,测试用例应该能够体现最重要的用户情景(main user scenario)。由于Rolling Testing的时间有限,测试用例应该“贵精不贵多”,用较少的用户情景覆盖所有的子系统。
  3. 测试应该覆盖所有的子系统。有些子系统难以用常见的用户情景来覆盖,这时可以构建独立的测试来检验它不存在严重的错误。Rolling Testing的目的不是检查出所有的错误,而是发现那些会阻碍进一步测试的错误(blocking bug)。因此,不需要构建完备、严厉的测试用例集,只需要验证子系统的基本功能可以工作即可。
  4. 确保所有的测试用例是正确的。有时系统的设计会发生变更,这会导致部分测试用例需要更新。更新测试的工作有可能需要几个工作日才能完成。这时,应该将这些测试用例从Rolling Testing中排出出去。否则,当Rolling Testing报告测试执行失败时,测试人员不能立即判断是被测试系统的问题还是测试的问题,这将严重降低Rolling Testing的报警作用。特别是,如果测试人员“默认”测试失败是测试本身的问题,那么他有可能会漏过严重的集成错误。
  5. 及时地维护Rolling Testing测试用例集。系统会增加新的子系统、用户情景会发生变化、测试工具也需要更新,这都要求Rolling Testing的负责人及时地维护Rolling Testing的测试用例集,以确保:测试用例集可以覆盖到所有的子系统,且不包含错误的测试用例。
  6. 及时地响应测试报告。Rolling Testing的威力在于根据测试结果采取及时的行动。如果对于每小时一次的错误报告采取漠视的态度,那么之前所花费的精力将毫无价值。我的做法是利用Outlook的邮件规则,对测试报告邮件生成一个通知(alert)。当测试报告到达时,Outlook会弹出一个对话框,我只需要按一下“回车(Enter)”,就可以看到报告内容。如果有问题,则进行调查;如果没有问题,按两下”取消(Esc)”就可以关闭邮件、关闭对话框。此外,我还设置了另一条邮件规则,将所有的测试报告归档到一个单独的文件夹中。

Written by liangshi

November 17, 2008 at 5:09 am

Posted in Uncategorized