Smart Testing

All about smart testing

软件测试读书列表 (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
作者讨论了测试人员所面临的十大“人际挑战”。从具体案例出发,介绍了挑战的表现形式、产生根源、解决方法和可能遇到的问题。虽然,外企的文化氛围与中国企业有一定差别,但是分析问题、解决问题的思路仍值得借鉴。

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

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

Advertisements

Written by liangshi

August 24, 2013 at 8:43 am

Posted in Uncategorized

探索式测试的问与答

leave a comment »

本文摘录自《探索式测试实践之路》第1.3节,用对话的形式讨论探索式测试的概念与实践。提问者是本书的一位虚拟读者,回答者是本书的作者们。

 

问:探索式测试中的“探索”该如何理解?

答:所谓探索是指有目的的漫游,即带着使命在某个空间中漫游,但没有预先确定的路线 [Kaner01]。探索包括对产品与技术的深入研究和基于研究成果的实践应用。

问:如何实施探索式测试?

答:本书第3部分将专门讨论该问题。这里先介绍一种可行的探索式测试实施方法,其灵感来源是基于测程的测试管理(Session-Based Test Management)[Bach2000]。(在Session-Based Test Management中,Session是一段专门用于探索式测试的时间,其常用的中文术语“会话”并不适合该语境。经过慎重考虑,笔者将Session翻译为“测程”,以表达它是一段专注于测试的过程。)

探索式测试鼓励测试人员依据当前语境选择合适的测试流程与技术。在测试过程中,SMART原则为测试者提供了很好的指导。

  • Specific(具体的):测试需要一个具体的目标。
  • Measurable(可度量的):有明确的指标可以评估目标是否达成。
  • Achievable(可实现的):目标应该是可实现的。这潜在地要求将一个大目标分解为多个小目标,且每个小目标也是具体的、可度量的、可实现的。而且,追踪小目标的完成情况提供了整体进度的可度量性。
  • Relevant(相关的):目标要切合当前语境,符合团队利益,且不忘企业愿景。
  • Time-boxed(有时间限制的):为每个目标设定一个合理的最后期限。这可以帮助测试人员在固定的时间窗口(Time Window)中排除不相关干扰,专注地工作。

依据SMART原则,测试人员可按如下描述展开探索式测试。

  1. 测试人员制订测试计划。分析被测试应用,确立若干个具体的测试使命(Mission),每个使命针对一个可能的产品风险。
  2. 测试人员将测试使命分解为一系列测试任务(Charter),每个任务都有明确的退出条件和时间限制。
  3. 在短暂的测试计划之后,测试人员根据优先级选择一个任务,在一个固定的时间窗口中执行探索式测试(窗口的长度是60~120分钟,以90分钟为宜)。这样一个时间窗口被称为一个测程(Session)。在该测程中,测试人员设计测试、执行测试、评估测试结果。他会根据获得的知识和发现的疑问再设计测试用例,以拓展测试的广度和深度。
  4. 在测程结束后,测试人员适当休息,放松思维。
  5. 随后,他会反思当前的测试进展,并优化测试计划。也许他会为当前任务追加一个测程;也许他会再增加一个新的任务以弥补先前测试计划的不足;也许他会删除一些任务以反映他对测试对象的最新认知。
  6. 这时,他会更有自信地开始新一轮探索式测试。

以上只是一种可能的探索式测试实施方法。负责任的测试人员一定会选择他自己的方式展开测试,因为只有作为领域专家的他,才能做出最符合语境的决策。此外,集合整个团队的力量,进行同行评审、头脑风暴、结对测试等活动,有助于产生更好的测试结果。

问:探索式测试与即兴测试(Ad-hoc Testing)有何区别?

答:探索式测试与即兴测试都强调“即兴发挥”,即利用直觉和经验,快速地测试软件,并不停地调整测试策略。软件专家Andrew Hunt指出,直觉是非显性知识的代名词,是大脑富(Rich)模式的杰出能力。如果人类只使用大脑的线性模式(包括语言可表达的显性知识、抽象能力、逻辑能力等),而漠视富模式的能量,我们将浪费自身的巨大潜力[Hunt08]。

然而人是不完美的,某些直觉可能是认知偏见或错误。这就引出了探索式测试与即兴测试的关键不同:探索式测试是带着“反思”的测试。在探索式测试中,测试人员不断地提出假设,用测试去检验假设,并分析测试结果来证实或推翻假设。在此过程中,测试人员持续完善头脑中的产品模型和测试模型,然后利用模型、技能、经验去驱动进一步的测试。通过将测试学习、设计、执行和结果分析作为相互支持的活动并行展开,探索式测试总是在不停地优化测试模型、测试设计和测试价值。因为测试设计和测试执行的切换速度很快,许多人误以为探索式测试没有计划和设计。实际上,这些活动被划分到细微的时间片中,被反复执行。

即兴测试往往利用错误猜测、典型风险和常见攻击来快速地试探软件,可以在短时间内发现许多软件错误。但是即兴测试不强调测试的系统性和完整性,测试遗漏的风险很高,也难以发现一些需要深入研究才能发现缺陷。探索性测试通过测试来透彻地理解被测试产品,从而拓展测试的广度与深度,以持续优化测试的价值。

问:如果探索式测试是硬币的正面,那么硬币的反面是什么?

答:探索式测试的对立面是脚本测试(Scripted Testing)。脚本测试要求预先编写好测试脚本(Script),脚本规定了如何配置被测试软件、如何输入、如何判断软件输出了正确的结果。编写详细的脚本往往需要大量的测试资源。

如果运用得当,脚本测试可能有如下收益[Kaner08]:

  • 测试人员可以仔细地思考被测试软件。
  • 测试脚本可以被项目关系人(Stakeholder)评审。
  • 测试脚本可以被复用。
  • 测试团队可以评估测试脚本集的完备性。
  • 测试团队可以度量测试脚本的执行情况,以评估测试进度。

问:本书为什么反对脚本测试?

答:笔者不反对任何测试思想或方法,但是反对不分语境地滥用某一种测试思想或方法。例如,苛刻地要求编写详细的测试脚本可能会导致如下测试风险。

  • 在测试执行前,大量的测试资源被用于测试设计。但是,产品的发展往往难以预料,早期的预先设计不能有效地处理动态变化的情况。有可能花费了大量的时间,却获得了一批充满缺点的测试脚本。
  • 过于详细的测试脚本压抑了测试执行的灵活性,使得测试执行变成单调的过程。这可能导致测试人员对一些明显的错误视而不见,因为它们不在测试脚本的检查范围之内。此外,运行测试是观察软件行为、获得测试灵感、设计新测试用例的极佳时刻,这要求测试人员在测试执行时全神贯注、头脑灵活、反应敏捷。但是,枯燥的测试执行将使这些目标难以实现。
  • 大量的详细测试脚本导致了沉重的维护代价。在进度压力下,测试人员可能没有时间更新测试脚本,这使得测试脚本不能随需求和产品一同演化。随着时间的推移,大量的测试脚本成为过时的、无人问津的“摆设”,原先投入大量资源所获得的测试资产几乎消耗殆尽。
  • 要求测试人员编写求全责备的测试脚本,很可能带来不良的心理暗示:测试人员在不知不觉中将编写脚本看做测试的目的,而不是辅助测试的工具。他们会盲目追求脚本的数量,而很少关注产品和项目的风险,用看似“完备”的脚本集提供虚假的安全感。更糟糕的是,醉心于脚本数量的测试领导很可能会鼓励这种以“文案工作”为核心的测试流程,使测试的价值进一步流失。

相比“硬币”的比喻,笔者更喜欢Cem Kaner的观点:“纯粹的探索式测试和纯粹的脚本测试好似区间的两个端点。在实践中,大多数测试者位于这两者之间。然而,大多数好的测试非常接近探索式测试的一端。”[Kaner09]

此外,根据语境驱动测试的基本原则,测试人员需要经常反思:根据当前语境,测试策略是应该偏向探索式测试,还是脚本测试?如何综合它们的优势,以获得更好的测试结果?

问:探索式测试编写测试文档吗?

答:探索式测试者创建任何有助于实现其目标的文档 [Kaner08],他会撰写并维护符合语境的测试文档。这里提出一种可能的测试计划编写方法,供读者参考。

在不同的开发组织,测试计划有不同的名称:测试计划、测试规格说明和测试设计文档等。但是,大多数测试计划会涵盖产品概述、测试范围、测试风险、测试策略、部分详细测试用例、资源分配和日程安排。

与脚本测试在测试执行前编写大量文档不同,探索式测试在整个测试过程中持续编写、修改、优化测试计划。测试计划的内容、格式、详略是由项目语境决定的。

在项目计划阶段,测试计划可以包含产品概述、测试范围、测试风险、测试策略、资源分配和进度安排。编写文档的目的是建立对产品的整体认知,根据风险提出相应的测试策略,并安排测试任务和日程。测试计划不必面面俱到,用精简的格式记录必要的内容即可。此时项目的不确定性较大,未知因素较多,很可能不适合做出详细的测试决策。

在项目计划阶段,应该邀请项目关系人对测试计划进行评审。评审的形式可以多种多样,会议评审、桌面走查、邮件评审、在线文档批注、头脑风暴皆可。评审的目的是发现“大图景”上的缺陷,并丰富测试策略。眼界开阔的项目经理、负责任的开发人员、经验丰富的测试同事能够提供很好的建议。

在测试阶段,测试人员需要根据测试进展持续更新测试计划,内容可能包括产品模型、检查列表、测试策略、覆盖大纲和风险列表等。测试计划应该是“活”的文档,能够反映测试人员对产品和项目的最新认识。对测试范围、测试风险、测试策略和进度安排的重大变化应该写入测试计划,重要的测试用例(如发现严重缺陷的测试用例)也应该及时融入测试策略。测试计划应该尽可能地精简,这有助于文档的持续更新,而冗长的文档将不利于阅读、增删和修订。

当测试人员认为测试计划相对完整之后,他还应该邀请项目关系人对测试计划进行评审。评审的目的是发现测试遗漏,补充测试策略,提高测试覆盖率。

以上方法有三个重要的特点。

  • 测试计划的编写与改进贯穿整个测试过程。在测试执行之前,对测试计划不必求全责备。在测试执行中,测试人员根据测试反馈,动态地调整测试范围、项目风险和测试策略,生成新的测试用例,并对测试计划做必要的更新。
  • 测试人员持续地收集对测试计划的意见,并将改进意见纳入测试实践。正式和非正式的测试计划评审可以识别潜在风险,丰富测试策略。在一些测试流程中,测试计划评审只发生在测试开始之前。但是,笔者建议在测试流程的中期再次评审测试计划,目的是进一步丰富测试策略的多样性,并发掘可能的测试遗漏。这时,测试团队对产品与风险拥有更深刻的理解,能够提出更具针对性和多样性的测试策略,也可以帮助测试人员发现测试盲点,从而提高测试覆盖率。
  • 测试计划侧重测试规划(一组指导测试过程的想法)和测试策略(一组指导测试设计的想法)[Kaner01],而不是脚本化(Scripted)的测试用例,即测试计划用精简的格式表达测试人员的测试想法,而不必详细记录测试用例的设置、步骤和预期结果。测试人员可以用文字、列表、表格、思维导图等任何合适的方式表达想法,目的是激发测试灵感,并促进测试思想的交流。此外,他会利用发现缺陷的测试用例来完善测试策略,而不是让过去的测试用例控制未来的测试。

关于其他形式和内容的测试文档,测试专家Michael Bolton的文章What Exploratory Testing Is Not: Undocumented Testing提出了很好的建议。

:探索式测试的核心优势是什么?

:探索式测试的核心优势是有助于“学习”。此处的学习是指学(获取知识)与习(应用知识)的持续过程。

对于测试人员,软件测试是一个持续学习并实践的过程。他的学习范围如下。

  • 行业知识:为什么需要这个软件?软件如何帮助使用它的人和团体去获得成功?
  • 用户角色:目标用户是谁?他们有什么特点,有什么期望?软件如何帮助他们去获得个人成就?
  • 软件产品:产品是一种解决方案,它解决了行业和用户所面临的问题吗?
  • 计算平台:只有深刻理解软件所依赖的计算平台(如操作系统、中间件和网络协议等),才能更好地进行测试。
  • 开发技能:理解项目所使用的具体技术,知晓典型的技术缺陷,具备测试开发的能力。
  • 测试技术:针对当前项目,选择合适的测试技术,并能够熟练地应用。
  • 程序缺陷:研究已知的软件缺陷,提炼错误模式,制订缓解或预防方案。
  • 开发团队:语境决定策略和实践。在一起工作的人,是所有项目语境中最重要的组成部分。

测试人员不需要在项目之初就掌握所有知识,他可以通过每天的工作去逐步理解用户、项目、技术和团队。更重要的是,他需要在每天的工作中实践所学的内容:规划测试方案、创建并执行测试用例、分析测试结果和编写测试报告。实践是练习,是“学”的自然延伸。知行合一才构成“学习”的完整内核。

学习的一个重要成果是成为更优秀的测试人员。他们可以根据项目语境,选择合适的流程、技术和工具来高效地测试,以推动软件质量的提高。

既然学习非常重要,那么如何才能高效地学习呢?软件专家Andrew Hunt指出:“一种高效的学习环境应该允许你安全地做三件事情:探索、创造和应用。”[Hunt08] Andrew的解释如下:

  • 探索就是在陌生的环境中玩(Play)。你需要自由地探索才能学习。我们不仅仅接受信息,而是亲自探索和构建思维模型。玩引入了一种新奇的感觉,也就是乐趣。用一种好玩的方式学习新资料或者解决问题,可以让这个过程变得更让人享受,也让学习变得更容易。为了更好地学习,请更好地玩。
  • 你需要自由地创造——不介意自己的创造没有成功。通过构造来学习,而不是通过学习来构造。这是“原型”、“曳光弹”、持续集成等方法获得成功的原因之一。(曳光弹是Andrew Hunt和David Thomas在《程序员修炼之道》中提出的开发方法,通过快速实现系统的部分功能以获得即时反馈。曳光弹与原型制作都可以快速获得反馈,其主要差别是,原型制作生成实验性且最终被抛弃的代码,曳光弹生成简约却完整的代码,并且构成了最终系统的一部分。)
  • 你需要在日常实践中应用到你学到的东西。你持续使用和实践的技能会在脑皮层竞争中占据统治地位,大脑会为它们提供更多方便。
  • 这种探索应该相对没有风险,因为你肯定不想因担心害怕而止住探索的脚步。安全有助于更好地利用反馈,让失败也变得有意义。

虽然Andrew讨论的是广义的学习与探索,但是他的话解释了探索式测试的成功之道:探索式测试在本质上鼓励测试人员去自由地探索、创造和应用。

  • 探索是带着使命在某个空间中有目的的漫游,但没有预先确定的路线。探索包括不断学习和实践[Kaner01]。
  • 探索式测试者持续应用他所学到的知识。所谓“学而时习之,不亦说乎”,探索式测试将学习与应用作为相互支持的活动逐步展开,为测试者的知识提升提供了平滑的学习曲线。
  • 探索式测试有助于测试人员在合适的时间学习合适的内容,并立即应用,以获得真实反馈。这提高了学习效率和效果,并降低了浪费测试资源的风险。
  • 在探索式测试中,测试者创造出一切有助于学习和实践的数据和工具。它们包括测试输入数据、结果检查脚本、数据分析报告和业务流程图表等。
  • 探索式测试是一项富有智力挑战的活动,充满了乐趣。

问:“学习”有助于独立测试人员更好地工作与发展。从测试团队和开发组织的角度看,探索式测试能够提供什么帮助?

答:探索式测试有助于“机动性”,该特性在现在比以往任何时候都更重要。

随着互联网与Web应用席卷全球,软件竞争比以往更加激烈。开发组织不仅要减少缺陷,还要跟踪不断变化的用户需求和市场需求,在紧迫的时间约束下交付赢得用户的产品。这要求软件企业在业务、研发、营销等方面均保持高机动性。其中,探索式测试可以在以下方面为产品研发提供帮助。

首先,探索式测试将许多测试决策置于更合理的时机,从而避免了浪费。在Web应用等高竞争性领域中,开发组织面临模糊且持续变更的用户需求。更重要的是,他们必须在一切明朗之前着手行动,因为交付的时机将在很大程度上决定市场的反应,此外真实的用户反馈将有助于下一次更准确地交付。面对高变动性的开发过程,测试人员需要将测试设计合理地分配到整个开发周期,根据当前的开发进度和真实的测试反馈,做出恰当的测试决策。这有助于避免在信息不充分的情况下做出错误的决定,从而导致严重的浪费和返工。

其次,探索式测试不停地根据实际情况,调整测试计划,优化测试策略,因此能够更有针对性地测试,从而更快速地稳定(Stabilize)产品。探索式测试和语境驱动测试建议,测试人员总是自问:“我现在可以测试什么?应该如何测试?”这有助于测试人员更动态地审视被测试产品和测试策略,并运用多样化的手段去探索产品。随着对业务领域的认识不断深入,随着逐渐了解产品的设计和弱点,随着对测试技术和工具的更加熟悉,测试人员会不断调整测试策略,使得在整个产品开发过程中,重要错误的发现率都保持在比较高的水平[Kaner01]。而及时地发现重要错误能够帮助开发组织降低风险、快速推进。

测试需要探索,而探索要要大量的思考[Kaner01]。积极思考的探索式测试是具有挑战性的智力过程,常常需要以不确定的顺序反复实施钻研、尝试、迂回、调整、评估等活动。好的探索式测试不会使测试更简单,但是它会使测试更有效,从而在测试速度和缺陷发现上获得更多的回报。

问:探索式测试是否只适用于功能性测试?

答:作为一种测试风格,探索式测试可应用于各种类型的测试。

以安全测试为例,请想象一下黑客是如何攻破软件产品的。他们的基本方法是“错误猜测”:通过分析已知的安全缺陷,抽象出可利用的缺陷模型,然后开发出相应的缺陷挖掘工具。这些工具可以是黑盒工具,通过持续地输入攻击数据来发现缺陷;也可以是白盒工具,通过扫描(开源)源代码来识别漏洞。他们运行工具,分析输出中的蛛丝马迹,一旦发现疑似缺陷,便深入探索。整个攻击过程常常需要广泛扫描、深入挖掘、迂回前进、反复尝试。从安全测试的角度看,黑客都是探索式测试的绝顶高手。

相比安全测试只需“断其一指”,性能测试需要建立被测试产品的性能模型,并考察它在不同负载下的性能指标,因此需要更多的预先设计。然而性能测试的关键内容:用户的行为模式、充足的高质量测试数据和完整的性能监测指标(特别是面向业务的性能指标),是难以仅通过一次测试设计便可以获得的。性能测试工程师需要与开发团队紧密协作,通过阅读、研究、实验等手段来探索性能测试模型和技术,并逐步挖掘用户行为、制造测试数据及建立性能指标。

问:在功能实现之前,探索式测试是不是无用武之地?

答:对于探索式测试有一个误解,那就是探索式测试只通过运行测试以获得知识。实际上,探索式测试者能够也必须通过其他手段探索被测试软件。

语境驱动测试认为:产品是一种解决方案,它必须解决现实世界中的问题。因此,探索式测试者必须从项目关系人(包括软件用户、项目投资人和开发团队等)的视角考察整个产品,研究显式规格说明和隐式规格说明,从而发现软件在概念、需求、设计、实现等层面上的缺陷。值得强调的是,测试人员应该主动探究隐式规格说明,从而拓宽探索的范围。以下是一些常见的隐式规格说明。

  • 竞争产品。竞争产品不一定是软件,例如笔记软件的竞争者就包括纸质笔记本和铅笔。
  • 相关产品。软件套装(如Microsoft Office)中的软件往往相互补充、相互约束。
  • 同一软件的已发布版本。向前兼容可能是非常重要的约束。
  • 口头讨论、采访、闲聊。
  • 电子邮件、会议记录、采访记录。
  • 用户反馈:电话支持记录、论坛讨论、Beta测试反馈。
  • 技术反馈:软件提交的崩溃信息、错误消息。
  • 第三方评论:杂志文章、博客文章、社交网络反馈。
  • 技术标准。所有软件都建立在一系列技术标准之上,某些标准会对测试产生重要影响。
  • 法律法规。法律可能对软件有强制性约束。
  • 领域专著。测试财会软件需要学习相关著作,以掌握财会知识。
  • 测试人员经验。

Cem Kaner拥有法律学位,对语言文字非常敏感。他认为积极阅读(Active Reading)是探索式测试者需要具备的技能 [Kaner08]。积极阅读是一个内涵丰富的主题,广受好评的经典书籍包括《如何阅读一本书、《探索需求和《你的灯亮着吗?

此外,在功能实现之前,可以通过小组讨论、头脑风暴等方式发掘测试策略和测试思路。针对一个开发中的功能,测试人员可以邀请几个同事,组织一个测试研讨会。在会议上,大家自由发言,提出自己的测试策略,通过脑力震荡相互启发,从而获得一批观点各异、视角不同的测试策略。会后,测试负责人对这些相对粗糙的测试思路进行整理,将完善后的结果写入测试计划。

问:如何评估探索式测试的测试效果?

答:评估探索式测试结果的前提是测试记录。

探索式测试者常常在一个固定的时间窗口内(60~120分钟),根据预设的测试目标,对软件进行Z探索式测试。这样的测试活动被称为测程(Session)[Bach00]。

测程类似于科学实验。一次科学实验大致可以分为以下三个阶段。

  1. 实验设计:确定实验目标。科学实验的常见目的是假设检验,那么此次的假设是什么?
  2. 实验记录:执行实验步骤,并记录实验所发现的点点滴滴。
  3. 实验分析:分析实验数据,总结实验结果,为下一次实验提供目标和假设。

相应地,一次测程包含如下三个阶段。

  1. 测试计划:明确测试目标。测试是获得信息的过程,那么此次测试要获得什么信息?
  2. 测试执行:设计并执行测试用例,记录测试所发现的点点滴滴。
  3. 测试分析:分析并总结测试所发现的信息,为下一次测试提供目标。

详细的实验记录是科学实验的基本要求之一。同理,详略适当的测试记录也是测试执行的自然结果,是测试评估的基本要求。通常,测试记录可以包含如下内容[Wikipedia11a]。

  • 测试目标:本次测试要提供什么信息?
  • 测试范围:本次测试覆盖了哪些功能、模块、用户情景?
  • 测试策略:本次测试使用了何种测试方法?
  • 缺陷列表。
  • 在测试过程中发现的疑问,它们值得进一步探索。
  • 可以复用的测试资源:被测试软件配置、测试数据和测试脚本等。
  • 测程的耗时。
  • 测程的时间分配:在测试设计与执行、缺陷调查与报告、测程的启动与结束和非测试活动上各花费了多少时间。

测试记录可以转化为测试备忘录,供今后的测程参考。测试记录也可以提炼为测试报告,反映当前项目的进展。更重要的是,测试记录是测试评审的素材。基于测试记录,测试团队可以开发出符合项目语境的评估方法,对测程进行专家评审和定量度量。这有助于度量探索式测试结果,并提出改进方案。

问:探索式测试只适合测试专家,不适合测试新手?

答:“探索式测试不适合测试新手”是一种似是而非的说法。第一,所有高效的测试都依赖于测试人员的测试技能和行业知识。测试专家能够准确地选择测试策略、有效地运用测试方法,因此测试效果更佳。第二,测试新手采用任何测试方法,都需要指导和帮助。这有助于他们充分利用方法的优点,并避免方法的潜在陷阱。可见,更有意义的问题是:如何帮助测试新手尽快地掌握测试方法,尽快地成长为测试专家?

从个人发展的角度看,探索式测试有助于测试新手快速学习。探索式测试将学习与应用作为相互支持的活动逐步展开,为测试人员的技能提升提供了平滑的学习曲线。此外,并行地进行测试学习、测试设计、测试执行和测试评估为测试人员的成长提供了持续、及时、有效的反馈,这有助于他主动学习和快速调整。

从企业发展的角度看,测试团队应该积极帮助测试新手成长。可以采用的方法包括:为他安排工作导师、评审其测试文档、评审其测试记录、在测程中安排测试专家与他结对测试、定期进行一对一的会谈等。这些活动会消耗测试团队的人力资源,但是它们是帮助新员工成长最快速、最有效、最廉价的方法。

Peter Drucker指出:知识工人的创造性(Productivity)要求他们被视为企业的资产(Asset)而不是开销(Cost)[Drucker99]。培养高水平测试人员是测试团队和测试领导不可回避的职责。

问:有什么工具可以支持探索式测试?

答:本书第5章将讨论探索式测试的工具。这里强调两个基本观点。

第一,作为一种测试风格,探索式测试可以使用任何开发和测试工具。探索式测试者应该根据语境选择合适的工具,去完成自己的使命。

第二,软件测试存在大量的创新空间,测试人员应该勇于开发自己的探索式测试工具。

测试专家James A. Whittaker提出过一种测试工具构建方法[Whittaker01],值得测试人员参考。

  • 寻找缺陷:发现或收集软件的缺陷。
  • 提炼模式:分析出缺陷的根本原因,编写一个模式,用它捕获相似的缺陷。一个模式是一个结构化的攻击手段,它包含如下内容。
    • 何时实施该攻击?
    • 该攻击会捕获何种错误(Fault)?
    • 利用该攻击如何识别软件失败(Failures)?
    • 如何实施攻击?
    • 样例和分析。
  • 开发自动化工具:识别出攻击过程中机械的部分,编写一个工具去自动化模式的应用。此处的测试自动化不是自动地执行测试用例,而是提供计算机辅助功能,其目的是让计算机完成高负荷运算,让人专注于富有智力挑战的任务。

按照James的方法实施软件测试,测试团队可以积累一批有益的模式和测试辅助工具。这可以帮助团队更有效地测试现在和未来的项目。

问:探索式测试能用于测试自动化吗?

答:本书第6章将讨论探索式测试与测试自动化。这里简单陈述一下笔者的观点。

  • 测试自动化可以大致分为测试用例自动执行(Automated Test Execution)和计算机辅助测试(Computer-Assisted Testing)。
  • 对于测试用例自动执行,探索式测试可以提供一批适合自动执行的测试用例。
  • 对于计算机辅助测试,探索式测试要求人尽其才(自由发挥测试者的智能)和物尽其用(充分利用计算机的性能),利用计算机强大的计算能力去帮助测试人员完成测试使命。
  • 许多复杂的测试自动化应该以探索式的风格来构造。对于困难的测试,应该先构建简单的测试代码,将其投入测试,利用测试反馈来改进测试代码。然后,将改进后的测试代码投入测试实践,分析测试反馈,再优化测试代码。所谓探索式测试自动化,就是将学习、设计、实现、评估纳入迭代开发,以逐步提高测试自动化和产品的质量。

问:探索式测试与敏捷测试有何关系?

答:探索式测试在本质上是敏捷的,且可以很好地应用于敏捷项目。

2001年,17位软件专家在美国犹他州雪鸟(Snowbird)城集会,缔结敏捷联盟,并发表敏捷宣言。与会者之一Brian Marick具有深厚的测试背景,因此软件测试社区对敏捷宣言亦有贡献。

敏捷软件开发宣言[Agile01]

我们一直在实践中探寻更好的软件开发方法,身体力行,同时也帮助他人。由此我们建立了如下价值观:

  • 个体和互动高于流程和工具
  • 工作的软件高于详尽的文档
  • 客户合作高于合同谈判
  • 响应变化高于遵循计划

也就是说,尽管右项有其价值,我们更重视左项的价值。

语境驱动测试的基本原则“任何实践的价值都取决于其语境”和“人,在一起工作的人,是项目语境中最重要的部分”,与敏捷宣言的首条价值观“个体和互动高于流程和工具”不谋而合。高效的探索式测试不但需要优秀的测试人员,也要求测试人员、开发人员、客户和项目关系人紧密协作、频繁互动。

在思想层面,探索式测试要求测试人员不断地研究产品,通过应对、激励、拥抱变化来驱动对问题空间的积极探索。这不但符合敏捷价值观,也可以应用于其他类型的测试项目。敏捷测试专家Lisa Crispin和Janet Gregory指出:“敏捷测试可以发生在敏捷项目之外。例如探索式测试,无论它是否应用于敏捷项目,其本质是敏捷的。通过测试逐渐学习产品,并让所学信息指导测试实践,这无疑符合敏捷价值观:工作的软件和响应变化。”[Crispin09]

在实践层面,探索式测试是评价产品的面向业务测试的主要手段[Crispin09]。在用户故事和测试策略的指导下,测试人员会模拟真实用户去测试系统。当一部分代码被签入,一部分用户故事被实现后,测试人员就会探索新的区域,并逐步完善测试模型和测试策略。随着测试人员对产品的了解,探索式测试不但可以弥补自动化测试的不足,还可以揭示出更有效的自动化测试区域,为自动化测试设计添砖加瓦。此外,探索式测试能够发掘新情景(Scenario),而这些情景往往会演变成新的用户故事,从而在需求层面提高产品质量。

从术语的历史看,“探索式测试”(Exploratory Testing,Cem Kaner提出于1983年)的历史比“敏捷软件开发”Agile Software Development,敏捷宣言缔结于2001年)更悠久。它们都是在描述已经长期存在但是没有得到合适命名的思想及实践:Cem Kaner用“探索式测试”来描述一种已经长期存在的测试思维,敏捷宣言的缔造者们用“敏捷”来描述他们对软件开发的共识。虽然这些思想来自不同的头脑、实践和社区,但是它们拥有相似的核心,并可以相互借鉴与补充。

Written by liangshi

September 21, 2012 at 10:22 am

Posted in Test

语境驱动测试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

测试建模:Google ACC

leave a comment »

ACC(Attributes Components Compatibilities)是Google测试团队使用的一种建模方法,用来快速地建立产品的模型,以指导下一步的测试计划和设计。在Google内部,ACC得到较普遍的应用,一些工程师还开发了支持ACC模型的Web应用,并将其开源。本文将介绍ACC的内容,所引用的Google+的例子摘录自《How Google Tests Software》一书。此外,本文还将使用启发式测试策略模型(Heuristic Test Strategy Model,简称HTSM)来分析ACC。

运用ACC建模的第一步是确定产品的Attributes(属性)。按照谷歌的定义,Attributes是产品的形容词(adjectives),是与竞争对手相区别的关键特征。按照敏捷开发的观点,Attributes是产品所交付的核心价值(values)。从HTSM的角度,Attributes位于HTSM->Quality Criteria->Operation Criteria,隶属于面向用户的质量标准。

Google+的Attributes如下:

    • Social(社交):鼓励用户去分享信息和他们的状态
    • Expressive(表现力):用户可以运用各种功能去表达自我
    • Easy(容易):让用户以直观的方式做他们想做的事
    • Relevant(相关):只显示用户感兴趣的内容
    • Extensible(可扩展):能够与Google的已有功能、第三方网站和应用(Application)集成
    • Private(隐私):用户数据不会泄漏

ACC以Attribute开始,是产品竞争的自然选择,也符合Google的开发实践。在Google的项目中,开发人员和测试人员的比例通常是10:1或更高。开发人员会编写大量的自动化测试用例,对产品实施周密的测试,因此测试人员主要关注用户价值和系统级测试。即便如此,测试人员也没有足够的资源测试所有用户行为。所以,测试人员需要通过确定Attributes来明确产品的核心价值,从而区分出测试对象的轻重缓急(priorities)。获取Attributes的信息源可以是产品经理、市场营销人员、技术布道者、商业宣传材料、产品广告等。测试人员也可以使用“卖点漫游”(The Money Tour)来发掘和检验产品的卖点。

第二步是确定产品的Components(部件)。Components是产品的名词(nouns),可以理解为产品的主要模块、组件、子系统。从HTSM的角度,Components位于HTSM->Product Elements->Structure和HTSM->Product Elements->Function,即同时具备代码结构和产品功能的特征。

Google+的Components如下:

  • Profile(个人资料):用户的帐户信息和兴趣爱好
  • People(人脉):用户已经连接的好友
  • Stream(信息流):由帖子、评论、通知、照片等组成的有序的信息流
  • Circles(圈子):将好友分组,如把不同的好友归于“朋友”、“同事”等小组
  • Notifications(通知):当用户被帖子提到时,向他显示提示信息
  • Hangouts(视频群聊):视频对话的小组
  • Posts(帖子):用户和好友所发表的信息
  • Comments(评论):对帖子、照片、视频等的评论
  • Photos(照片):用户和好友所上传的照片

Components可以看作功能列表(Function List)的顶层元素,是产品核心功能的清单。《How Google Tests Software》建议Components列表要尽可能简单,10个Components很好,20个就太多了。其目的是重点考虑对产品、对用户最重要的功能与代码,并避免漫长的Components列表所导致的分析瘫痪。

第三步是确定产品的Capabilities(能力)。Capabilities是产品的动词(verbs),描述了一个Component提供了何种能力来实现一个Attribute。在HTSM的角度,Capabilities位于HTSM->Product Elements->Function和HTSM->Quality Criteria->Operation Criteria->Capability,刻画了产品实现其核心价值的手段。

Google+的Capabilities矩阵如下:

Social

Expressive

Easy

Relevant

Extensible

Private

Profile

在好友中分享个人资料和兴趣爱好

用户可以在网上表达自我

很容易创建、更新、传播信息

向被批准的、拥有恰当访问权限的应用提供数据

    • 用户可以保密隐私信息
    • 只向被批准、拥有恰当访问权限的应用提供信息

People

用户能够连接他的朋友

用户可以定制个人资料,使自己与众不同

提供工具让管理好友变得轻松

用户可以用相关性规则过滤好友

向应用提供好友数据

只向被批准、拥有恰当访问权限的应用提供信息

Stream

向用户提示其好友的更新

用户可以根据兴趣过滤好友更新

向应用提供信息流

Circles

将好友分组

根据用户的语境创建新圈子

鼓励创建和修改圈子

向应用提供圈子数据

Notifications

简明地展示通知

向应用提供通知数据

Hangouts

    • 用户可以邀请他们的圈子加入群聊
    • 用户可以公开其群聊
    • 好友访问用户的信息流时,他们被告知群聊

加入群聊前,用户可以预览自己的形象

    • 只要几次点击就可以创建并加入群聊
    • 只要一次点击就可以关闭视频和音频输入
    • 可将好友加入已有的群聊

    • 用户可以在群聊中使用文字交流
    • YouTube视频可以加入群聊
    • 在“设置”中可以配置群聊的硬件
    • 没有摄像头的用户可以音频交谈
    • 只有被邀请的用户才能加入群聊
    • 只有被邀请的用户才能收到群聊通知

Posts

表达用户的想法

向应用提供帖子数据

帖子只向被批准的用户公布

Comments

用评论表达用户的想法

向应用提供评论数据

评论只向被批准的用户公布

Photos

用户可以分享他的照片

    • 用户能方便地上传照片
    • 用户能方便的从其他来源导入照片

与其他照片服务集成

照片只向被批准的用户公布

Capabilities通常是面向用户的(user-oriented),反映了用户视角的产品行为。测试人员也应该保持Capabilities矩阵的简洁,他们应该关注对用户而言最有价值、最有吸引力的能力,并在合适的抽象层次(right level of abstraction)记录Capabilities。最重要的是,Capabilities应该是可测的(testable),测试人员能够设计测试来检查产品实现了预期的Capabilities

有了Capabilities矩阵,测试团队就完成初始的测试计划。这就是前Google测试总监James Whittaker所说的10分钟测试计划(The Ten Minutes Test Plan)。其基本思路是专注于核心属性、核心功能和核心能力,而省略一切不必要的细节。之后,测试团队会利用矩阵去指导测试设计,通常矩阵中的一条Capability就是一个测试对象、测试策略或测试情景,而复杂的Capability会演化出更多的测试设计。

Google所提供的开源Web应用可以分析项目信息,包括测试用例、代码变更、产品缺陷等,以确定Capabilities矩阵中的高风险区域。下图引用自James Whittaker在GTAC 2010的闭幕演讲的幻灯片,是Chrome OS的Capabilities矩阵的热点图(heap map)。图中绿色表示低风险区域,红色表示高风险区域,粉红色和橙色则表示风险居于前两者之间。测试人员可以根据热点图,更好地确定测试优先级,将有限的资源运用在最需要的地方。

Clipboard01

许多团队的风险分析依赖于测试人员的经验和猜测,Google的ACC工具则通过分析项目元素(测试用例、代码变更、产品缺陷等)来识别风险。这些被分析的元素位于HTSM->Project Environment,是项目环境的一部分。即便不使用Google的工具,测试人员也可以利用电子表格记录Capabilities矩阵,并自行计算各个条目的风险(一些Google的测试人员也是这么做的)。在评估风险时,他可以考虑如下因素:

  • 自动化测试用例:该区域有自动化测试用例吗?测试在定期运行吗?测试通过率是多少?测试用例覆盖了哪些方面,没有覆盖哪些方面?
  • 手动测试:有人手动测试该区域吗?经过测试,他们对该区域有信心吗?如果满分是10分,他们会打几分?
  • 代码变更:该区域近期存在代码变更吗?变更频繁吗?变更是新增功能、代码重构、还是缺陷修复?
  • 代码复杂度:代码的规模是多少?代码是否复杂?如果复杂度的满分是10分,该区域的代码能得几分?
  • 产品缺陷:该区域的缺陷多吗?有哪些典型缺陷?哪些缺陷已经被修复?哪些缺陷还没有被修复?活跃的缺陷是在快速增加还是稳步下降?

在计算此类风险因素时,测试人员可以采用尽可能简单的度量方法。一方面,简单的方法更容易解释度量值的含义,从而有助于针对度量值采取相应的行动。另一方面,复杂的方法增大了分析的难度,却往往不能提供更多的收益。通过测试去获得直接的反馈,并定期重新度量风险因素,是更注重实效的方法。这也符合ACC的风格:快速的前进,持续的迭代。在测试计划时,测试人员只要快速地确定Capabilities矩阵,而不必担心遗漏。随着测试的进展,他会对矩阵做出必要的调整,以优化测试的价值。

Written by liangshi

April 23, 2012 at 7:32 am

Posted in Test

测试建模:功能列表(Function List)

with one comment

功能列表(Function List)是一种功能测试(Function Testing)的建模方法,在启发式测试策略模型(Heuristic Test  Strategy Model)中位于 HTSM -> Product Elements –> Function 分支中。虽然它只覆盖了很小的测试领域,不适合作为主要的测试方法,但是仍不失为一种有启发、有帮助的测试建模技术。本文将简介功能列表及其应用。

什么是功能列表?

Cem Kaner在Black Box Software Testing 中将功能列表定义为:程序功能的大纲( an outline of the
program’s capabilities)。对于PowerPoint的图片功能,测试人员可以建立如下功能列表:

Picture1

Clipboard01

限于篇幅,该功能列表只列出了PowerPoint图片的部分功能(真实的测试需要更详细的功能列表),但是它很好的体现了功能列表的特点。第一,它列出了图片的主要功能:输入、操作、应用、输出、打印和文件读写,使得测试人员能够在整体上把握被测领域。第二,它的层次结构提供了可扩展的框架,测试人员可以持续地补充细节:具体的功能和针对该功能的测试想法。第三,它为功能覆盖提供了覆盖目标,为制定测试计划提供了有益的信息。第四,功能列表可以包含一些助记符(如标签)和链接。作为大纲,它可以指向更多的资料;作为测试触发器(trigger),它可以启发测试思路。

功能列表的形式

我习惯用符号列表(bulleted list)制作功能列表,因为符号列表被大量的文档编辑器和文档格式所支持,能够快速地编辑、修改和发布。

此外,许多测试人员喜欢用思维导图(Mind Map)记录功能列表、测试设计和测试计划,也获得了很好的效果。下图是思维导图形式的功能列表。
Clipboard01

功能列表与漫游测试

漫游测试(Tour Testing)是一组以漫游隐喻为核心的测试方法。在应用漫游测试时,测试人员常常会游历被测产品的结构、功能或数据,在此期间运用他的技能和经验去发掘产品的缺陷。

功能列表为功能漫游(Feature Tour)提供了有益的信息。它像一幅地图,既描绘了产品的概况,又提供了必要的细节,为探索者提供了指南与参考。测试人员可以漫游功能列表上的所有元素,以实施全面探索;也可以选择遍历某个功能子集,以实施专项测试。

在测试之初,测试人员对被测产品尚不了解,他可以通过功能漫游来建立功能列表。从这个角度,漫游的过程就是测试建模的过程,功能列表就是漫游测试的产出。Cem Kaner建议,在软件尚不成熟时,测试人员应该同情地测试(test sympathetically)。此时,测试的目的不是发现所有缺陷,而是提交重大问题,发现风险区域,建立测试模型,为今后的测试奠定基础。对此,测试专家Michael Bolton有一番精彩的论述:

同情的测试非常重要,虽然一些测试人员会发现它的反面(全力寻找缺陷)难以拒绝。Jon Bach(测试专家,其兄弟James Bach也是测试专家)指出在探索式测试的早期,他通过测试来发现产品的优点(benefits)。我觉得这很奇怪,直到他指出寻找并记录缺陷使得他不能专注地漫游产品并构建产品的模型。

测试人员需要建立产品的大局观,同时掌握产品的优点、缺点、概念模型和实现逻辑。漫游测试是很好的学习过程,功能列表是一个有益的学习成果。

用功能列表启发测试设计

在测试设计时,测试人员可以将功能列表视作覆盖率指南。他逐个检查每个功能,阅读相关的测试想法,从而设计测试策略。在此过程,他可以自问:

  • 该功能与当前测试任务相关吗?
  • 该功能存在什么风险?可能会有什么缺陷?
  • 通过什么测试可以发现这些缺陷?
  • 在上次测试中,该功能表现如何?已有的测试想法,哪些值得再次尝试?哪些不必再测?
  • 依据当前的进度和资源,如何实施这些测试?
  • 功能列表是否充分?有没有漏掉一些功能?

另一种更有威力的方法是综合功能列表中的多个元素,开发测试策略,以测试它们的交互和影响。随着产品逐渐成熟,隐蔽的缺陷往往存在于功能的组合,暴露于复杂的流程。这要求测试人员综合多方面的信息,来更深入、更多样地测试系统。当测试人员考虑功能的组合时,他可以自问:

  • 该功能与哪些功能相关?
  • 功能的组合有没有揭示出新的风险?可能会有什么缺陷?
  • 哪些功能访问同一批数据?哪些是生产者?哪些是消费者? 
  • 如何设计测试,以同时测试这些功能?
  • 如何构造一个(有意义的)业务流程,它能够访问尽可能多的功能与数据?
  • 对于相互依赖的功能,某个功能的失败是否对其他功能造成恶劣影响?

在回归测试时,功能列表是很好的参考。例如,测试人员可以按如下测试策略对PowerPoint的图片功能进行回归测试。

  1. 新建一个PowerPoint文档
  2. 向文档中插入图片
    1. 覆盖所有支持的图片格式
    2. 覆盖典型的图片尺寸
    3. 覆盖来自单反相机的大型图片(该条目显示随着硬件的发展,测试策略也需要变化)
  3. 操作文档中的图片
    1. 覆盖Picture Tools下的所有命令
    2. 一些图片只被一个命令修改
    3. 一些图片被多个命令修改
    4. 一些图片不被修改
  4. 应用文档中的图片
    1. 将图片与其他元素组合使用
    2. 覆盖文本框、形状、SmartArt、图表等
  5. 将文档中的元素另存为图片
    1. 覆盖所有可以被输出的元素:图片、形状、SmartArt、图表等
    2. 覆盖所有支持的图片格式
  6. 打印该文档
    1. 打印到(黑白和彩色)打印机
    2. 打印到PDF文档
    3. 打印到XPS文档
  7. 另存该文档并重新打开
    1. 另存为所有支持的格式
    2. 用PowerPoint打开生成的文档
    3. 用旧版本PowerPoint打开生成的文档

利用该测试策略,测试人员可以用一个很长的流程覆盖大多数的图片功能,不但可以测试图片功能的组合,还可以顺便测试程序的稳定性和资源占用。测试结束时,测试人员可以获得一个大型的PowerPoint文档,它包含各种图片和相关元素,为今后的回归测试提供了良好的素材。

参考资料

Written by liangshi

April 2, 2012 at 12:27 pm

Posted in Test

测试建模:启发式测试策略模型(Heuristic Test Strategy Model)

with one comment

启发式测试策略模型(Heuristic Test Strategy Model,简称HTSM)是测试专家James Bach提出的一组帮助测试设计的指南(guideline)。本文将介绍HTSM的内容与应用。

为什么需要HTSM

根据产品的风险(risk)设计测试是一种常见的测试设计思路。在复杂的现实世界,产品面临的风险多种多样,只有全面考虑、周密测试才能避免风险暴露导致的严重后果。因此,测试人员需要一个相对完整、可以定制、容易扩展的风险列表或参考模型,来帮助他们发现产品风险。HTSM就是一个结构化的、可定制的参考模型,从测试技术、产品元素、项目过程、质量标准等多个角度启发测试设计。

HTSM能够在测试全程提供有益的提示。在制定测试计划初稿时,它可以帮助测试人员完整地思考产品的方方面面,从而产生系统性的(systematic)测试计划。在测试过程中,它可以帮助测试人员组合测试想法、深入探索产品,以开发出强有力的测试策略。在回归测试中,它可以帮助测试人员确定测试范围,制定测试方案。

HTSM的内容

Clipboard02

上图是HTSM的概要描述,测试人员利用质量标准(Quality Criteria)、项目环境(Project Environment)、产品元素(Product Element),指导测试技术(Test Techniques)的选择与应用,并产生观察到的质量(Perceived Quality)。

HTSM是层次结构,其顶层元素(质量标准、项目环境、产品元素、测试技术)可以分解为次层元素,而次层元素可进一步分解为第三层元素。本文只概要介绍次层元素,更多的细节请参考James Bach的文档

测试技术:生成测试的策略。有效地选择和实施测试技术,需要综合分析项目环境、产品元素和质量标准。

  • 功能测试(Function Testing)
  • 域测试(Domain Testing)
  • 压力测试(Stress Testing)
  • 流测试(Flow Testing)
  • 情景测试(Scenario Testing)
  • 声明测试(Claims Testing)
  • 用户测试(User Testing)
  • 风险测试(Risk Testing)
  • 自动测试(Automatic Testing)

项目环境资源、约束和其他影响测试的项目元素。测试总是受到项目环境的约束。在某个团队运转良好的策略不一定适合另一个相似的团队,以往富有成效的方法未必适应当前的项目。有经验的测试人员会根据当前语境(Context),在约束条件下充分运用资源,以高效地测试。

  • 用户(Customers):理解产品的用户
  • 信息(Information):发现测试所需的信息
  • 开发者关系(Developer Relations):与开发者协作加速开发
  • 测试团队(Test Team):利用团队的力量支持测试
  • 设备与工具(Equipment & Tools):可利用的硬件、软件、文档等
  • 进度(Schedule):项目实施的流程
  • 测试条目(Test Items):测试范围和重点
  • 交付品(Deliverables):测试的产出

产品元素:需要测试的对象

  • 结构(Structure):产品的物理(physical)元素(如代码、接口、配置文件、可执行文件等)
  • 功能(Functions):产品的功能
  • 数据(Data):产品所操作的数据
  • 平台(Platform):产品所依赖的外部元素
  • 操作(Operations):产品将被如何使用
  • 时序(Time):影响产品的时间因素

质量标准之操作性标准(Operational Criteria):面向用户和运营团队

  • 能力(Capability)
  • 可靠性(Reliability)
  • 可用性(Usability)
  • 安全性(Security)
  • 可伸缩性(Scalability)
  • 性能(Performance)
  • 可安装性(Installability)
  • 兼容性(Compatibility)

质量标准之开发标准(Development Criteria):面向开发团队

  • 可支持性(Supportability)
  • 可测试性(Testability)
  • 可维护性(Maintainability)
  • 可移植性(Portability)
  • 本地化(Localizability)

由以上介绍可知,HTSM由一组指导性词语(guide word)组成,它们构成一个层次结构,让测试人员从高层抽象到底层细节对产品和测试进行思考。这些指导性词汇是测试的指南,其作用不是教导如何具体地测试,而是启发测试人员的思维,发掘测试对象和测试策略。

下图摘录自James Bach的培训教材Rapid Software Testing,体现了HTSM对于测试设计的意义。

  • 测试设计以风险驱动。测试人员分析质量标准、项目环境、产品元素中的风险,设计有针对性的测试策略。
  • 在测试设计时,质量标准启发测试先知(Oracles),项目环境启发测试过程(Procedures),产品元素启发测试覆盖(Coverage),观察到的质量启发测试报告(Reporting)。
  • 对于测试,HTSM强调测试策略的多样性(Diversification),平衡代价和收益(Cost vs. Value),利用启发式方法(Heuristics)充分发挥测试人员的技能(Skill)。

Clipboard01

定制HTSM

在定制化之前,HTSM对测试人员的帮助很小,因为此时的HTSM是“James Bach的模型”,而不是符合当前语境的模型。HTSM是通用的模型,虽然能够普遍使用,但是不能快速、高效地指导具体的测试工作。测试人员需要将其“本地化”,才能发挥其威力。

Cem Kaner教授在教程Blank Box Software Testing 中提出利用思维导图(Mind Map)定制HTSM。他将HTSM作为图的为中心,将Quality Criteria、Project Environment、Product Elements和Test Techniques作为主干。

Clipboard03

在分支上,Cem Kaner添加了他觉得重要的节点。例如,他在Product Elements下增加了Benefits节点和Time节点,使HTSM符合他的工作需要。

Clipboard03

恰如Cem Kaner所说:“大多数严肃对待此模型的人会定制它以符合自己的需要”(Most people who work seriously with this model customize it t meet their needs),测试人员可以也应该修改HTSM,以获得符合项目语境的模型。

  • 增加节点:增加与当前项目相关的测试技术、测试想法、测试对象和任何测试人员认为有价值的元素。
  • 删减节点:忽略一些与项目或任务无关的元素。
  • 增加标记、注释、链接等图元:标记可以突显重要的元素,注释可以增加更多的细节,链接可以指向更详细的信息源。

定制HTSM是理解并掌握HTSM的过程。与大多数方法一样,测试人员需要修改它,加入自己的风格和元素,才能正真掌握它。

测试专家Michael Larsen在XMind.net提供了他制作的HTSM思维导图,为测试人员制作自己的HTSM提供了很好的基础。

Clipboard04

应用HTSM

定制HTSM就是应用HTSM的过程。测试人员遵循HTSM的结构化指南,深入地思考产品、项目与测试,添加自己的想法、评论、标记和启发式问题。这本身就是极好的测试学习过程。作为学习的结果,定制化的HTSM为进一步地测试设计提供了坚实的基础。在测试过程中,测试人员会接触新信息,学习新知识。他应该持续地将新知补充到HTSM中,以迭代地优化测试略模型。从这个角度,HTSM既是测试想法的源头,也是测试过程的产出。

在测试设计时,测试人员可以逐个检查HTSM中的每个元素(指导性词语),阅读相关标记、注释和链接,以启发测试思路。他可以自问:

  • 该元素与当前测试任务相关吗?
  • 针对该元素,产品有什么风险?可能会有什么缺陷?
  • 通过什么测试可以发现这些缺陷?
  • 依据当前的进度和资源,如何实施这些测试?

另一种更有威力的方法是综合HTSM中的多个元素,开发测试策略。当开发人员用单元测试检查了组件,测试人员需要在系统层面检查产品。此时,产品的缺陷往往存在于组件的交互和复杂的流程。综合产品的多个方面,开发多样化的测试,以更深入地测试产品,才能够更好地体现测试人员的价值。一些有帮助的启发式问题包括:

  • 该元素与哪些元素相关?
  • 元素的组合有没有揭示出新的风险?
  • 如何设计测试,以同时测试这些元素?
  • 能否让来自元素A的信息帮助元素B的测试?

参考资料

Written by liangshi

April 2, 2012 at 10:31 am

Posted in Test