新書推薦：
《
素描简史：从文艺复兴到现代艺术
》
售價：HK$
436.8
《
智慧宫丛书028·神工智能 诸神与古代世界的神奇造物
》
售價：HK$
87.4
《
街头健身训练指南
》
售價：HK$
266.6
《
留学早规划
》
售價：HK$
76.2
《
文化的演化：民众动机正在重塑世界
》
售價：HK$
88.5
《
布鲁克林有棵树（孩子喜欢的阅读经典读本 基于真实生活的全球经典成长小说 走出成长困境 追逐梦想 人生励志 自我塑造小说）
》
售價：HK$
76.2
《
构建未来教育图景：实践以学生为中心的育人模式
》
售價：HK$
87.4
《
技术统治（未来哲学系列）
》
售價：HK$
53.8
|
| 編輯推薦： |
测试是敏捷开发的关键组成部分。敏捷方法的广泛应用使人们开始关注如何有效测试，同时敏捷项目改变了测试人员的角色。但是，测试人员的许多职责还是得到了不少误解，测试人员的真正职能是什么？敏捷团队真的需要具有QA背景的成员吗？敏捷测试人员到底意味着什么？业界经验*丰富的两位敏捷测试实践者和顾问Lisa Crispin和Janet Gregory在《敏捷软件测试：测试人员与敏捷团队的实践指南》中给出了这些问题和更多问题的答案。在《敏捷软件测试：测试人员与敏捷团队的实践指南》中，Crispin和Gregory定义了敏捷测试的概念，并通过来自现实敏捷团队的示例阐述测试人员的职责。她们讲述如何利用敏捷测试象限来识别需要哪些测试，谁来做，以及哪些工具有帮助。《敏捷软件测试：测试人员与敏捷团队的实践指南》从测试人员的角度记录了敏捷软件开发迭代的一个完整周期，并解释了敏捷测试的七大关键成功要素。
注：两款不同封面，随机发货。
|
| 內容簡介： |
|
读者将从《敏捷软件测试：测试人员与敏捷团队的实践指南》中收获 测试人员如何参与敏捷开发 测试人员和QA经理如何适应敏捷团队 敏捷测试人员的招聘要求是什么 如何从传统模式迁移到敏捷模式 如何在短期迭代中完成测试任务 如何利用测试指导开发 如何克服困难实现测试自动化
|
| 關於作者： |
|
Lisa Crispin是一名敏捷测试实践者和教练。她专注于向测试人员和敏捷团队讲述测试人员如何创造价值并利用面向业务测试指导开发。她的使命是把敏捷的快乐带给软件测试领域，并把测试的快乐带给敏捷开发领域。Lisa在2000年第一次加入敏捷团队，作为开发人员、分析人员、测试人员和质量保证主管工作了若干年。从2003年起，她成为ePlan Services公司ePlan Services团队的测试人员。她经常在北美和欧洲的会议上教授有关敏捷测试的课程。Lisa经常发表敏捷测试的文章，刊物包括Better Software magazine、IEEE Software和Methods and Tools。Lisa与Tip House合著了Testing Extreme Programming Addison-Wesley, 2002。Janet Gregory是DragonFire公司致力于敏捷质量过程咨询和培训的创始人。她希望帮助团队构建质量系统。在过去十年间，她作为教练和测试人员，把敏捷实践介绍到各种规模的公司。她关注于让业务客户和测试人员理解其在敏捷项目中的角色。Janet的编程背景使她能更好地与敏捷团队中的开发人员合作以实施新颖的敏捷测试自动化方案。Janet经常在敏捷和测试软件会议上发表演讲，也是北美敏捷测试社区的主要贡献者。
|
| 目錄：
|
|
目录第Ⅰ部分 简介第1章 敏捷测试的定义31.1 敏捷价值31.2 敏捷测试意味着什么41.3 敏捷团队中角色和活动的情境61.4 敏捷测试有何不同71.5 整体团队运作方式111.6 小结12第2章 敏捷测试人员的十条法则152.1 敏捷测试人员的定义152.2 敏捷测试思想162.3 应用敏捷法则和价值162.4 创造价值232.5 小结24第Ⅱ部分 组 织 挑 战第3章 文化挑战273.1 组织文化273.2 测试质量保证团队成功适应敏捷的障碍313.3 引入变化353.4 管理层期望363.5 改变并不容易393.6 小结40第4章 团队构成414.1 团队结构414.2 人员分布444.3 人力资源454.4 团队建设474.5 小结49第5章 迁移传统过程515.1 寻找轻量级过程515.2 度量标准525.3 缺陷跟踪555.4 测试计划605.5 现有的过程和模型615.6 小结64第Ⅲ部分 敏捷测试象限第6章 测试的目的676.1 敏捷测试象限676.2 知道一个用户故事何时完成726.3 管理技术债务736.4 上下文环境中的测试736.5 小结74第7章 支持团队的面向技术测试757.1 敏捷测试基础757.2 为什么编写并运行这些测试777.3 面向技术的测试在何处停止827.4 如果团队不做这些测试怎么办837.5 工具箱847.6 小结86第8章 支持团队的面向业务测试898.1 通过面向业务测试驱动开发898.2 需求困境918.3 小增量988.4 如何知道我们完成了1008.5 小结102第9章 面向业务测试工具包1039.1 面向业务测试的工具策略1039.2 激发示例和需求的工具1049.3 基于示例自动化测试的工具1119.4 编写测试的策略1199.5 可测试性1239.6 小结125第10章 评价产品的面向业务测试12710.1 象限三简介12710.2 实例演示12910.3 场景测试12910.4 探索测试13110.4.1 基于会话的测试13510.4.2 自动化和探索测试13610.4.3 探索测试人员13610.5 可用性测试13610.5.1 用户需求和角色测试13610.5.2 导航13710.5.3 研究竞争对手13810.6 图形用户界面背后13810.6.1 API测试13810.6.2 Web服务14010.7 测试文档和文件14010.7.1 用户文档14010.7.2 报告14110.8 探索测试辅助工具14210.8.1 测试设置14310.8.2 生成测试数据14410.8.3 监控工具14410.8.4 模拟器14410.8.5 仿真器14410.9 小结145第11章 利用面向技术的测试评价产品14711.1 象限四简介14711.2 谁应该做14911.3 何时做15011.4 ility测试15111.4.1 安全性15111.4.2 可维护性15311.4.3 交互性15411.4.4 兼容性15511.4.5 可靠性15511.4.6 可安装性15611.4.7 ility小结15711.5 性能、负载、压力以及可伸缩性测试15711.5.1 可伸缩性15711.5.2 性能与负载测试15811.5.3 性能与负载测试工具15811.5.4 基准15911.5.5 测试环境16011.5.6 内存管理16011.6 小结161第12章 测试象限总结16312.1 回顾测试象限16312.2 系统测试实例16412.2.1 介绍该应用软件16412.2.2 团队和工作流程16512.3 测试驱动开发16612.3.1 单元测试16612.3.2 验收测试16612.4 自动化测试16612.4.1 自动化的功能测试结构16712.4.2 Web服务16812.4.3 嵌入式测试16812.5 评判产品的面向业务测试16912.5.1 探索性测试16912.5.2 测试数据源16912.5.3 端对端测试16912.5.4 用户验收测试17012.5.5 可靠性测试17012.6 文档17012.6.1 用文档记录测试代码17012.6.2 汇报测试结果17112.7 熟练运用测试象限17212.8 小结172第Ⅳ部分 自 动 化第13章 自动化的原因和障碍17513.1 为什么要自动化17513.1.1 手动测试需要太长的时间17613.1.2 手动过程容易出错17613.1.3 自动化让人们有时间做更有价值的工作17713.1.4 自动化回归测试提供了安全网17813.1.5 自动化测试较早并频繁地给出反馈17913.1.6 驱动编码的测试和实例可以做更多事情17913.1.7 测试是强大的文档17913.1.8 投资回报率和回报18013.2 自动化的障碍 妨碍自动化的因素18013.2.1 Bret的列表18013.2.2 我们的列表18113.2.3 程序员的态度 为什么要自动化18113.2.4 痛苦的积累学习曲线18113.2.5 初始投入18213.2.6 总是改变的代码18313.2.7 遗留代码18413.2.8 恐惧18413.2.9 旧的习惯18413.3 可以克服这些障碍吗18413.4 小结185第14章 敏捷测试自动化策略18714.1 测试自动化的敏捷方法18814.1.1 自动化测试的分类18814.1.2 测试自动化金字塔18914.2 哪些测试可以自动化19114.2.1 持续集成、构建与部署19214.2.2 单元与组件测试19314.2.3 API或Web Services测试19314.2.4 GUI底层的测试19314.2.5 测试GUI19314.2.6 负载测试19414.2.7 比较19414.2.8 重复的任务19414.2.9 创建数据19414.3 什么测试不应该自动化19514.3.1 可用性测试19514.3.2 探索性测试19614.3.3 永远不会失败的测试19614.3.4 一次性测试19614.4 哪些测试不易于自动化19714.5 从哪里开始自动化策略19814.5.1 不愿自动化的原因19814.5.2 多层方法19914.5.3 思考测试设计与维护20014.6 选择正确的工具20114.7 将敏捷法则应用到测试自动化上20414.7.1 保持简单20414.7.2 迭代式反馈20514.7.3 整体团队运作方案20514.7.4 花时间做正确的事情20714.7.5 边做边学20814.7.6 将敏捷编码实践应用到测试上20814.8 为测试提供数据20914.8.1 数据生成工具20914.8.2 避免访问数据库21014.8.3 如果数据库访问不可避免或是必须要使用数据库21114.8.4 明确所需21314.9 评估自动化工具21314.9.1 确定自动化工具的需求21314.9.2 一次一个工具21414.9.3 选择工具21514.9.4 适用于敏捷的工具21714.10 实现自动化21714.11 管理自动化测试21914.11.1 组织测试21914.11.2 组织测试结果22114.12 开始行动22214.13 小结222第Ⅴ部分 测试人员经历的一个迭代第15章 测试人员在发布或主题计划阶段的工作22715.1 制定发布计划的目的22715.2 故事评估22915.2.1 如何评估故事22915.2.2 测试人员在评估故事工作中的角色23015.2.3 一个故事评估的实例23115.3 设定优先级23315.3.1 为什么要为故事设定优先级23415.3.2 设定优先级时关于测试的注意事项23415.4 开发的范围23515.4.1 截止日期和时间表23515.4.2 关注产品价值23615.4.3 系统范围的影响23615.4.4 第三方的介入23815.5 制订测试计划23815.5.1 从何处开始23915.5.2 为什么要写测试计划23915.5.3 测试的种类23915.5.4 测试基础设施24015.5.5 测试环境24015.5.6 测试数据24115.5.7 测试结果24115.6 测试计划的可选形式24215.6.1 轻量级测试计划24215.6.2 使用测试矩阵24315.6.3 测试表格24515.6.4 白板24515.6.5 自动化的测试列表24515.7 准备可见性24515.7.1 跟踪测试任务及其状态24515.7.2 传达测试结果24815.7.3 产品发布的关键24815.7.4 已通过的测试数24815.7.5 代码覆盖率25015.7.6 缺陷度量25215.8 小结254第16章 迭代前的准备25516.1 积极主动25516.1.1 益处25616.1.2 真的需要吗25716.1.3 提前准备的潜在弱点25816.2 事先明确25816.2.1 客户意见一致25816.2.2 用户故事的规模25916.2.3 地域分散的团队26016.3 实例26116.4 测试策略26316.5 确定缺陷的优先级26416.6 资源26416.7 小结264第17章 迭代开始26517.1 迭代计划26517.1.1 了解细节26617.1.2 考虑所有观点26717.1.3 确定工作量27217.2 可测试故事27217.3 与客户协作27417.4 高层次测试和示例27517.4.1 与客户一起审查27717.4.2 与开发人员一起审查27717.4.3 测试用例作为文档27817.5 小结278第18章 编码和测试27918.1 驱动开发28018.1.1 从简单入手28018.1.2 增加复杂度28018.1.3 评估风险28018.1.4 编码和测试同时进行28218.1.5 识别变更28218.1.6 三方协作的力量28318.1.7 关注一个故事28318.2 评判产品的测试28418.3 与开发人员协作28418.3.1 结对测试28418.3.2 自我展示28518.4 与客户交流28518.4.1 展示给客户28518.4.2 理解业务28618.5 完成测试任务28618.6 处理缺陷28718.6.1 这是一个缺陷还是一项功能28718.6.2 技术债务28718.6.3 零缺陷容忍28818.7 如何选择28818.7.1 判断应该记录哪些缺陷28918.7.2 何时修补缺陷29018.7.3 选择记录缺陷的介质29118.7.4 处理缺陷的方案和建议29218.7.5 从简单入手29418.8 促进沟通29518.8.1 测试人员促进沟通29518.8.2 分散式团队29618.9 回归测试29718.9.1 确保构建通过29718.9.2 确保构建快速29818.9.3 构建回归测试集29818.9.4 注意全局观29818.10 资源29818.11 迭代度量29918.11.1 度量进度29918.11.2 缺陷度量30018.12 小结302第19章 迭代结束时的收尾工作30319.1 迭代演示30319.2 迭代回顾30419.2.1 开始、停止、继续30419.2.2 做出改进30619.3 庆祝成功30719.4 小结309第20章 成功的交付31120.1 产品的构成31120.2 为测试计划足够的时间31320.3 结束阶段31320.3.1 测试候选发布构建31420.3.2 在分期环境上测试31420.3.3 最后的非功能测试31520.3.4 与外部应用集成31520.3.5 数据转换和数据库更新31520.3.6 安装测试31720.3.7 沟通31720.3.8 如果没有准备好该怎么办31820.4 客户测试31920.4.1 UAT用户验收测试31920.4.2 alphabeta测试32020.5 开发后的测试周期32020.6 可交付的东西32220.7 发布产品32320.7.1 发布验收标准32320.7.2 发布管理32520.7.3 打包32620.8 客户期望32620.8.1 产品支持32620.8.2 理解对业务的影响32620.9 小结327第Ⅵ部分 总结第21章 关键成功要素33121.1 成功要素之一：使用团队整体参与的方法33121.2 成功要素之二：采用敏捷测试思维33221.3 成功要素之三：自动化回归测试33321.4 成功要素之四：提供并获取反馈33321.5 成功因素之五：构建核心实践的基础33421.5.1 持续集成33421.5.2 测试环境33521.5.3 管理技术债务33521.5.4 增量工作33521.5.5 编码和测试是同一个过程的组成部分33621.5.6 实践之间的协作33621.6 成功因素之六：与客户合作33621.7 成功要素之七：保持大局观33721.8 小结337术 语 表339参考文献345
|
| 內容試閱：
|
我们是极限编程XP的早期实践者，在完全不了解测试人员应该如何工作的XP团队中从事测试工作。那时候，敏捷当时还没有这个称谓资料中对验收测试和专业测试人员的工作方式介绍得很少。我们通过自身的经验和小规模敏捷社区这两方面来学习。在2002年，Lisa和Tip House合著了《测试极限编程》，该书的出版得到了Janet的大力帮助。从那时起，敏捷开发模式开始演变，敏捷测试社区不断繁荣。在众人的群策群力下，我们对敏捷测试的学习更加深入。我们凭借个人和合作的力量帮助团队过渡到敏捷模式中，帮助测试人员了解如何在敏捷团队中贡献自己的力量，并与敏捷社区的其他成员紧密协作寻找让敏捷团队在测试方面更加成功的方法。我们两人的经历各异。Lisa作为一名敏捷测试人员在稳定的团队中工作了若干年，针对零售、电信和金融行业的Web应用。Janet则在软件公司中开发各个行业的企业系统。这些敏捷项目包括开发消息处理系统、环境跟踪系统、远程数据管理系统包括嵌入式应用和交互网络、石油天然气产品统计应用和飞机运输应用。她扮演过很多角色 有时是测试人员、有时是指导 但是她一直在努力使测试人员与团队的其他人更融洽。她参与团队的时间从六个月到一年半不等。因为存在不同的视角，我们学会了合作和互补各自的知识库，并一起做了许多演讲和共同编写了许多教材。《敏捷软件测试：测试人员与敏捷团队的实践指南》的由来目前，市面上已经出版了一些有关面向敏捷开发中的测试和测试模式的优秀书籍见参考书目。这些书一般关注于如何帮助开发人员。《敏捷软件测试：测试人员与敏捷团队的实践指南》的目的是在帮助敏捷团队通过业务人员能够理解的测试来更加有效地创造业务价值。我们想帮助测试人员和质量保证QA人员从传统的开发模式过渡到敏捷开发。在《敏捷软件测试：测试人员与敏捷团队的实践指南》中，我们将讲述如何通过实用、逐步的方式应用我们在不同团队中的经验成果和来自其他敏捷先驱的思想，帮助测试人员、质量保证经理、开发人员、开发经理、产品负责人和其他任何致力于敏捷项目高效测试的人员，交付客户所需的软件。但是，我们更关注测试人员这个角色，因为很多专业人员都会担当此任。敏捷测试实践不局限于敏捷团队成员。它们也可以用于传统开发模式项目的测试。我们希望能够帮助在任何开发模式下的测试人员。敏捷开发不是成功交付软件的唯一方式。但是，我们参与过的所有成功团队，不论是敏捷模式还是瀑布模式，都存在一些共性。其中包括，程序员编写和自动化单元测试和集成测试覆盖多数代码，严格使用源代码控制和代码集成系统。测试人员从开发周期一开始就参与工作，并拥有足够的时间和资源来完成所有类型测试的任务。定期运行和检查自动化的回归测试集在高层次覆盖系统功能。开发团队理解客户的工作和需求，与业务专家紧密合作。人是促使项目成功的关键，而不是开发模式或者工具。我们喜欢敏捷开发，因为它的价值、准则和核心实践能够让人出色地工作，测试和质量是敏捷开发的中心。《敏捷软件测试：测试人员与敏捷团队的实践指南》将讲述如何将敏捷价值和准则应用到自己的具体测试工作中，并使团队取得成功。第1章和第2章将详细讨论这个问题。编写《敏捷软件测试：测试人员与敏捷团队的实践指南》的方式因为体会到敏捷开发的益处，所以我们采用敏捷实践来编写《敏捷软件测试：测试人员与敏捷团队的实践指南》。在开始动工的时候，我们与世界各地的敏捷测试人员和团队讨论了他们遇到的问题和解决办法。然后，我们计划如何在《敏捷软件测试：测试人员与敏捷团队的实践指南》中包含这些内容。我们制订了一个两周一迭代的发布计划。每两周在我们的图书网站上发布两章草稿。因为我俩身处异地，所以要使用工具交流，并对各章实施源代码控制，向读者发布书稿，并获得反馈。我们无法实时地结对工作，但是各章会经过反复的审阅和修订，并通过即时消息进行非正式的站立会议。我们的客户就是敏捷社区中志愿审阅草稿的好心人。他们通过电子邮件或者亲自提供反馈。我们在随后的编写和修订中利用反馈作为指导。在所有草稿完成之后，我们针对修订做了新计划，其中包括了来自客户的所有积极的建议。最重要的工具是思维导图。首先创建了一张思维导图描述全书的构思。然后对每一章创建思维导图。在编写各章之前，我们基于思维导图展开头脑风暴。在修订的时候，重新查看思维导图，帮助我们发现可能遗失的想法。因为我们认为思维导图存在很大作用，所以在每章的开始部分包含了相应的思维导图。希望它们能够帮助你总览本章包含的所有信息，并鼓励你尝试使用思维导图。读者对象如果你曾经问过以下某个问题我们已经听到过许多次，那么《敏捷软件测试：测试人员与敏捷团队的实践指南》将对你有所帮助：● 如果开发人员编写测试，那么测试人员做什么？● 我是一名质量保证经理，公司正在实施敏捷开发Scrum、XP、DSDM等，我的职责是什么？● 我曾经在传统的瀑布式团队中做过测试人员，并且对敏捷非常感兴趣。我应该需要哪些知识来适应敏捷团队？● 敏捷测试人员意味着什么？● 我是敏捷团队的开发人员，团队采用测试优先开发模式，但是客户仍然对我们交付的产品不满意。我们存在哪些缺陷？● 我在领导敏捷开发团队。质量保证团队无法跟上我们的速度，测试总是滞后。我们应该在开发的后一个迭代中测试吗？● 我是开发经理，最近转而采用敏捷开发，但是所有测试人员都离职了，为什么？● 我是测试人员，团队即将采用敏捷模式。我没有任何编程和自动化技能，在敏捷团队中还能立足吗？● 测试如何才能跟上两周一迭代的节奏？● 负载测试、性能测试、可用性测试等所有非功能性测试怎么办？如何在敏捷中实施？● 我们存在审计约束。敏捷开发和测试如何解决这些问题？如果你有类似的问题并且正在寻找切实可行的建议来指导测试人员如何帮助敏捷团队，以及敏捷团队如何有效地进行测试，那么这《敏捷软件测试：测试人员与敏捷团队的实践指南》正适合你。敏捷开发有许多风格，但是它们存在不少共性。正如在第1章所说的，我们支持敏捷宣言，不论你在实施Scrum、Extreme Programming、Crystal、DSDM，还是在实施自己的敏捷开发模式，都会在《敏捷软件测试：测试人员与敏捷团队的实践指南》中找到有助于测试的信息。敏捷测试书籍的用户故事当Robin Dymond一位帮助许多团队实施精益和敏捷模式的管理顾问和指导得知我们正在编写《敏捷软件测试：测试人员与敏捷团队的实践指南》时，给我们发来了他想要实现的用户故事，其中包含了许多我们计划满足的需求。满足条件：● 消除害怕失去对测试控制的担忧。● 消除必须编写代码以前从未做过的担忧。● 作为测试人员，要了解对团队的新价值。● 作为初次接触敏捷的测试人员，要能够容易地理解新角色中最重要的事情。● 作为初次接触敏捷的测试人员，要能够容易地忽略新角色中不重要的事情。● 作为初次接触敏捷的测试人员，要能够容易地获得对自身情况非常重要的敏捷测试的更多细节。当我考虑问题解决方案时，我想到了Scrum和XP。通过Scrum你能够简单地了解如何使大家快速实施敏捷。但是，Scrum只是成功敏捷团队的冰山一角。对于初次接触敏捷的测试人员来说，应该通过分层的方式向他们展示敏捷测试思想。今天应该了解什么？明天应该了解什么？应该为持续改进考虑与情境相关的什么具体事情？我们努力在《敏捷软件测试：测试人员与敏捷团队的实践指南》中提供上述的细节，从全新的角度教授敏捷测试：过渡到敏捷开发、使用敏捷测试矩阵指导测试、解释在敏捷开发周期中发生的所有不同的测试活动。如何阅读《敏捷软件测试：测试人员与敏捷团队的实践指南》如果不知道如何阅读《敏捷软件测试：测试人员与敏捷团队的实践指南》或者想要快速浏览一下，我们建议阅读最后一章 第21章，然后随着它的引导来阅读。第Ⅰ部分：简介如果想快速得到如下问题的答案，如敏捷测试和瀑布式项目测试有区别吗、传统测试人员和敏捷测试人员有何不同，那么请阅读第Ⅰ部分，包含以下几章：● 第1章：敏捷测试的定义● 第2章：敏捷测试人员的十条法则这两章是Robin在其用户故事中提到的冰山一角，概述了敏捷和传统阶段式方法的区别，并引入了整体团队方式来进行质量保证和测试。在《敏捷软件测试：测试人员与敏捷团队的实践指南》的这部分中，我们讨论了敏捷测试思想和敏捷团队中测试人员成功的因素，解释了测试人员如何运用敏捷价值和准则来贡献他们的专业技能。第Ⅱ部分：组织挑战如果你是传统质量保证团队的测试人员或者经理，或者在指导一个团队转变到敏捷模式，那么第Ⅱ部分将帮助解决过渡期间遇到的组织挑战。整体团队运作代表了团队成员文化上的大部分变化，它有助于克服测试人员在害怕失去控制权或者被迫编写代码时的恐惧。第Ⅱ部分回答了如下问题：● 如何招聘质量保证团队？● 如何对待管理层的期望？● 如何组织敏捷团队，如何定位测试人员？● 聘用敏捷测试人员的标准是什么？● 如何应对分布在全球各地的团队？第Ⅱ部分也讨论了一些折磨人的主题，像如何过渡过程和模型，如审计或者符合萨班斯法案，这些要求在传统环境中很常见。度量标准和如何利用它一直富有争议，但是存在一些有效的方式使团队受益。缺陷跟踪很容易成为团队的争论焦点，热点问题包括我们使用缺陷跟踪系统吗？或者何时记录缺陷？来自传统测试团队的人员通常会询问两个常见问题：如何制定测试计划？和测试项目中没有任何文档，是真的吗？。第Ⅱ部分将解开这些谜团。
本部分包含以下各章：● 第3章：文化挑战● 第4章：团队构成● 第5章：迁移传统过程第Ⅲ部分：敏捷测试象限你想知道敏捷团队中实施的测试类型吗？你想知道谁来做哪种测试吗？如何判断所需的全部测试都已完成？如何判断哪些实践、技术和工具最适合你的情况？如果有上述疑虑，请阅读第Ⅲ部分。我们采用Brian Marick的敏捷测试象限来描述测试的目的。象限可帮助定义测试的不同领域，从单元测试到可靠性测试和其他非功能性测试，以及介于两者之间的一切测试。我们将讨论如何交付高质量的产品，介绍有助于沟通客户和理解其需求的工具。此部分展示了测试如何在各个层次上驱动开发，同时提供了工具帮助你有效地定义、设计和执行支持团队和评判团队的测试。本部分包含以下各章：● 第6章：测试的目的● 第7章：支持团队的面向技术测试● 第8章：支持团队的面向业务测试● 第9章：面向业务测试工具包● 第10章：评价产品的面向业务测试● 第11章：利用面向技术的测试评价产品● 第12章：测试象限总结第Ⅳ部分：自动化测试自动化是敏捷测试团队成功的关键，而且对很多人来说是个可怕的话题我们知道，因为之前我们对这些生活题材曾感到过恐惧。如何把测试自动化塞进短迭代中，而且保证项目顺利完成？第Ⅳ部分详细讲述了自动化的时机和理由、克服自动化障碍的方法，以及如何确定和实施适合自身团队的测试自动化策略。因为测试自动化工具的发展非常迅速，所以我们的目的不是介绍如何使用某个具体的工具，而是帮助你选择和使用适合自己的工具。敏捷测试自动化经验将帮助你面对各种挑战，如测试遗留代码。本部分包含以下两章：● 第13章：自动化的原因和障碍● 第14章：敏捷测试自动化策略第Ⅴ部分：测试人员的一个迭代如果只是想知道在敏捷测试周期中测试人员是如何工作的，或者想把《敏捷软件测试：测试人员与敏捷团队的实践指南》的内容综合在一起，那么请阅读第Ⅴ部分。我们以测试人员的身份讲述了一次迭代的经历。首先，我们参与计划发布和迭代使某次迭代有个良好的开端，然后进入迭代，与客户和开发团队协作，测试、编写代码。迭代的最后是发布新功能，并想办法改进过程。本部分包含以下6章：● 第15章：测试人员在发布或主题计划阶段的工作● 第16章：迭代前的准备● 第17章：迭代开始● 第18章：编码和测试● 第19章：迭代结束时的收尾工作● 第20章：成功的交付第Ⅵ部分：总结在第21章，我们列举了敏捷团队取得测试成功的7个关键要素。如果你不知道如何开始敏捷测试或者如何改进当前的工作，这些成功要素将对你有很重要的指导意义。其他内容《敏捷软件测试：测试人员与敏捷团队的实践指南》还包含了词汇表和参考书目书籍、文章、网站和博客，希望对你有所帮助。现在就开始实践 从今天开始！敏捷开发的目的其实就是出色地工作。每一个团队都面临自己的挑战。我们努力把自己想到的可能会帮助敏捷测试人员、团队、经理和客户的信息都分享出来。请根据自身情况选择合适的技术。不断地实验、评估结果，然后重新翻书看看哪些能助你进行改进。我们的目标是帮助测试人员和敏捷团队交付最优秀、最有价值的产品，并享受这个过程。我们曾询问Canoo WebTest的创始人和项目经理Dierk Knig，敏捷测试的第一成功要素是什么？他说：现在就开始实践 从今天开始！。你可以现在就启程来改进团队的测试工作。现在就开始吧！
|
|
購物車/收銀台(0) | 在線留言板
| 付款方式
| 運費計算
| 聯絡我們
| 幫助中心 |
加入書簽
HOME
新書上架
