敏捷软件测试

出版时间：2010-10  出版社：清华大学  作者：(美)克里斯平//格雷戈里|译者:孙伟峰//崔康  页数：350  译者：崔康  
Tag标签：无  

前言

“质量正在培育中”，程序员总是这样告诉我。作为收购计划的一部分，老板要求我对开发团队和其产品做彻底调查。我们已经确信该公司最近推出的产品在市场上表现良好，但是我必须确保收购投资带来的麻烦不会大于回报。因此，我花时间与开发团队在一起，寻找可能在产品快速发布时出现的问题。我会提问：“代码没有问题吗？是否有些模块是由单独一位开发人员实现的？是否可能找到成百上千个缺陷？”当询问团队的测试方式时，“质量正在培育中”就是我得到的答案。因为这种独特的俗语可能存在各种解释，所以请允许我进一步说明。我发现这种说法其实是公司管理层概括了质量先驱W.Edwards：Deming的著名十四要点之一：把质量构建进产品中而不是在生产出来之后再进行测试。把质量构建进产品中的思想是敏捷团队工作的中心任务。敏捷团队在短迭代中工作以确保掌握应用程序的质量状态。敏捷团队是高度跨职能的，程序员、测试人员和其他人在整个迭代中协作，通过各种技术（如验收测试驱动开发等）确保把质量构建进产品中，特别强调自动化测试和整体团队（whole-team）思维。优秀的敏捷团队通过持续地构建产品来培育质量，及时地集成新进展。敏捷团队利用各种技术（如重构和简单化）来避免技术债务累积。很难学习如何做这些事情，特别是对于测试人员来说，该角色在以前的书籍中没有得到足够的重视。

内容概要

测试是敏捷开发的关键组成部分。敏捷方法的广泛应用使人们开始关注如何有效测试，同时敏捷项目改变了测试人员的角色。但是，测试人员的许多职责还是得到了不少误解，测试人员的真正职能是什么？敏捷团队真的需要具有QA背景的成员吗？“敏捷测试人员”到底意味着什么？    业界经验最丰富的两位敏捷测试实践者和顾问Lisa、Crispin和Janet Gregory在本书中给出了这些问题和更多问题的答案。在《敏捷软件测试：测试人员与敏捷团队的实践指南》中，Crispin和Gregorv定义了敏捷测试的概念，并通过来自现实敏捷团队的示例阐述测试人员的职责。她们讲述如何利用敏捷测试象限来识别需要哪些测试，谁来做，以及哪些工具有帮助。本书从测试人员的角度记录了敏捷软件开发迭代的一个完整周期，并解释了敏捷测试的七大关键成功要素。

作者简介

作者：（美国）克里斯平（Lisa Crispin） （美国）格雷戈里（Janet Gregory） 译者：孙伟峰 崔康克里斯平（Lisa Crispin）是一名敏捷测试实践者和教练。她专注于向测试人员和敏捷团队讲述测试人员如何创造价值并利用面向业务测试指导开发。她的使命是把敏捷的快乐带给软件测试领域，并把测试的快乐带给敏捷开发领域。Lisa在2000年第一次加入敏捷团队，作为开发人员、分析人员、测试人员和质量保证主管工作了若干年。从2003年起，她成为ePlan Ser、，ices公司ePlan Services团队的测试人员。她经常在北美和欧洲的会议上教授有关敏捷测试的课程。Lisa经常发表敏捷测试的文章，刊物包括Better Software magazine、IEEE Software和Methodsand Tools。Lisa与Tip House合著了Testing Extreme Programming（Addison-Wesley,2002）。格雷戈里（Janet Gregory）是DragonFire公司（致力于敏捷质量过程咨询和培训）的创始人。她希望帮助团队构建质量系统。在过去十年间，她作为教练和测试人员，把敏捷实践介绍到各种规模的公司。她关注于让业务客户和测试人员理解其在敏捷项目中的角色。Janet的编程背景使她能更好地与敏捷团队中的开发人员合作以实施新颖的敏捷测试自动化方案。Janet经常在敏捷和测试软件会议上发表演讲，也是北美敏捷测试社区的主要贡献者。

书籍目录

第Ⅰ部分  简介  第1章  敏捷测试的定义    1.1  敏捷价值    1.2  “敏捷测试”意味着什么    1.3  敏捷团队中角色和活动的情境    1.4  敏捷测试有何不同    1.5  整体团队运作方式    1.6  小结  第2章  敏捷测试人员的十条法则第Ⅱ部分  组织挑战  第3章  文化挑战  第4章  团队构成  第5章  迁移传统过程第Ⅲ部分  敏捷测试象限  第6章  测试的目的  第7章  支持团队的面向技术测试  第8章  支持团队的面向业务测试  第9章  面向业务测试工具包  第10章  评价产品的面向业务测试  第11章  利用面向技术的测试评价产品  第12章  测试象限总结第Ⅳ部分  自动化  第13章  自动化的原因和障碍  第14章  敏捷测试自动化策略第Ⅴ部分  测试人员经历的一个迭代  第15章  测试人员在发布或主题  第16章  迭代前的准备  第17章  迭代开始  第18章  编码和测试  第19章  迭代结束时的收尾工作  第20章  成功的交付第Ⅵ部分  总结  第21章  关键成功要素术语表参考文献

章节摘录

插图：如果像Lisa的团队那样，每个迭代都发布，那么每个迭代的最后一天或两天将完成“收尾”工作，这时可能进行用户验收测试、培训、修补缺陷，并且将产品部署到阶段环境中。其他团队，例如Janet的团队，每几个迭代一起发布，甚至可能有整个迭代作为“收尾”工作，进行发布准备。此处的区别在于所有的测试都将持续到最后。作为敏捷团队的测试人员，可能像在传统环境中一样，你还是发布代码产品代码的关键人物。可能通过运行脚本或手动测试来验证一个版本中的所有元素都是正常的，例如数据库更新脚本。所有的团队成员都会参与回顾或其他过程来改进每个迭代或版本中可能存在的活动。整个团队将以头脑风暴的形式来解决问题并改进过程和实践。敏捷工程有许多不同的情况。团队是从一个全新的状态，在一个全新的开发项目中开始的吗？如果是，则可能不需要在没有自动化回归测试集的情况下重新编写或构造遗留系统。与第三方一起工作会带来额外的测试挑战。不管正在使用哪种开发模式，都会经历几乎同样的软件开发生命周期元素。敏捷的不同之处在于时间段显著变短，并且活动同步进行。参与者、测试和工具都需要适应敏捷测试。敏捷项目中测试人员的最重要区别是快速从测试中得到反馈。它驱动项目前进，如果没有达到某些里程碑，那么也没有人来阻止项目继续进行。我们曾经遇到测试人员抵制敏捷开发，他们认为“敏捷开发”等同于混乱，缺乏原则、缺乏文档，并且将使测试人员处于绝境。同时，有些团队似乎在使用“敏捷”这个词来证明这只是简单地按他们的想法做，真正的敏捷团队都是可重复的、高质量的、高效的。按照我们的经验，敏捷团队是测试人员的乐土。

编辑推荐

《敏捷软件测试:测试人员与敏捷团队的实践指南》是由清华大学出版社出版的。

用户评论 (总计18条)

•   正是要找的那本，书不错，讲的很生动，送货也很快，就是翻译的太生硬了，影响阅读连贯性
•   这书有些方法是先进的，但大部分是在凑字数。书不在厚，关键是有核心内容。这种书功利心太强。
•   速度挺快的，书的质量感觉还不错
•   纸张·装订都还行·就是这翻译的太硬了·读起来比较累··
•   此书还不错哦，很适合刚刚转入敏捷测试的人员阅读
•   说的还行，具体如何实施的话，目前还是没有一些思绪。
•   不错，不过没看完，有待继续研究
•   敏捷开发的团队管理，还是值得一读的
•   快递很给力，书的印刷不错，内容正是现在想要的，基本的流程和处理的方法
•   敏捷测试能够大幅提高测试的质量和效率，强调以自动化和整体团队为基础。作者经验丰富，书的内容来自实战，很实用
•   本书的总体框架还不错，将测试用象限来表达跟总结还算新颖。但不知是作者本来就这么记述的，还是翻译问题，某个标题下面的核心经常是散落在各个段落中，得自己去发现其point；或者干脆一路看下来却感到What's the point？或许本书适合慢慢看慢慢咀嚼的人吧。
•   很满意，纸质也很好。
•   这个有很多公司在用，不过不是所有场景都需要敏捷。
•   一开始觉得测试理论是虚的，做了两年发现还是需要测试理论的
•   内容还算ok，翻译不怎么样
•   书很好，很受用；在敏捷开发中，测试人员担任的角色作用，真是收益颇多
•   概念理论东西太多，难以理解
•   想了解一下敏捷团队中的测试人员如何工作