敏捷测试

在敏捷测试中也有测试活动乃至专职的测试人员，但其活动内容和目标是有显著差异的。 一般在传统开发团队中，产品经理（或销售）为范围或称之为需求负责，项目经理和开发组为进度负责，测试组为质量负责，部门经理为成本负责，结果就是当四者发生矛盾时，会有四个部门各自站在自己的立场上，从而导致沟通不畅或或博弈成分超过合作。 在敏捷开发中需求与进度的冲突由计划会和自组织团队机制解决，成本由BDC和故事点开发率的提升来解决（解决的不好），而进度与质量间的矛盾，则由新型的测试理念来解决。 在传统测试中，测试团队被认为是找BUG的人，比如如果BUG众多，则测试人员和开发人员会一起加班，后者修改BUG，前者验证是否修改好。而如果BUG很难复现，则付出努力最多的不是开发人员，而是测试人员。 在敏捷测试中，测试人员则是帮助加快进度的人，也就是提高生产率的人。一个测试人员怎么能提高开发生产率呢？下面几个因素保证其可以发生。 1. 若缺陷发现越及时越容易修改。 比如在1天内就能发现，则1天内发生的改动很少，很容易找到问题。这就需要一个 自动测试 工具来以接近实时地发现缺陷。 比如如果在每天能进行一次 持续集成 ，则集成测试不能通过的原因会很单一很容易定位。设想一个数字电视系统，从授权/编码/加密/复用/调制/发送/接收/分流/解密/显示……环节很多信息很不透明，若在最后一刻才做集成，基本上无法判断问题出在哪里。 2

在敏捷测试中也有测试活动乃至专职的测试人员，但其活动内容和目标是有显著差异的。 一般在传统开发团队中，产品经理（或销售）为范围或称之为需求负责，项目经理和开发组为进度负责，测试组为质量负责，部门经理为成本负责，结果就是当四者发生矛盾时，会有四个部门各自站在自己的立场上，从而导致沟通不畅或或博弈成分超过合作。 在敏捷开发中需求与进度的冲突由计划会和自组织团队机制解决，成本由BDC和故事点开发率的提升来解决（解决的不好），而进度与质量间的矛盾，则由新型的测试理念来解决。 在传统测试中，测试团队被认为是找BUG的人，比如如果BUG众多，则测试人员和开发人员会一起加班，后者修改BUG，前者验证是否修改好。而如果BUG很难复现，则付出努力最多的不是开发人员，而是测试人员。 在敏捷测试中，测试人员则是帮助加快进度的人，也就是提高生产率的人。一个测试人员怎么能提高开发生产率呢？下面几个因素保证其可以发生。 1. 若缺陷发现越及时越容易修改。 比如在1天内就能发现，则1天内发生的改动很少，很容易找到问题。这就需要一个 自动测试 工具来以接近实时地发现缺陷。 比如如果在每天能进行一次 持续集成 ，则集成测试不能通过的原因会很单一很容易定位。设想一个数字电视系统，从授权/编码/加密/复用/调制/发送/接收/分流/解密/显示……环节很多信息很不透明，若在最后一刻才做集成，基本上无法判断问题出在哪里。 2

在敏捷测试中也有测试活动乃至专职的测试人员，但其活动内容和目标是有显著差异的。 一般在传统开发团队中，产品经理（或销售）为范围或称之为需求负责，项目经理和开发组为进度负责，测试组为质量负责，部门经理为成本负责，结果就是当四者发生矛盾时，会有四个部门各自站在自己的立场上，从而导致沟通不畅或或博弈成分超过合作。 在敏捷开发中需求与进度的冲突由计划会和自组织团队机制解决，成本由BDC和故事点开发率的提升来解决（解决的不好），而进度与质量间的矛盾，则由新型的测试理念来解决。 在传统测试中，测试团队被认为是找BUG的人，比如如果BUG众多，则测试人员和开发人员会一起加班，后者修改BUG，前者验证是否修改好。而如果BUG很难复现，则付出努力最多的不是开发人员，而是测试人员。 在敏捷测试中，测试人员则是帮助加快进度的人，也就是提高生产率的人。一个测试人员怎么能提高开发生产率呢？下面几个因素保证其可以发生。 1. 若缺陷发现越及时越容易修改。 比如在1天内就能发现，则1天内发生的改动很少，很容易找到问题。这就需要一个 自动测试 工具来以接近实时地发现缺陷。 比如如果在每天能进行一次 持续集成 ，则集成测试不能通过的原因会很单一很容易定位。设想一个数字电视系统，从授权/编码/加密/复用/调制/发送/接收/分流/解密/显示……环节很多信息很不透明，若在最后一刻才做集成，基本上无法判断问题出在哪里。 2

在敏捷测试中也有测试活动乃至专职的测试人员，但其活动内容和目标是有显著差异的。 一般在传统开发团队中，产品经理（或销售）为范围或称之为需求负责，项目经理和开发组为进度负责，测试组为质量负责，部门经理为成本负责，结果就是当四者发生矛盾时，会有四个部门各自站在自己的立场上，从而导致沟通不畅或或博弈成分超过合作。 在敏捷开发中需求与进度的冲突由计划会和自组织团队机制解决，成本由BDC和故事点开发率的提升来解决（解决的不好），而进度与质量间的矛盾，则由新型的测试理念来解决。 在传统测试中，测试团队被认为是找BUG的人，比如如果BUG众多，则测试人员和开发人员会一起加班，后者修改BUG，前者验证是否修改好。而如果BUG很难复现，则付出努力最多的不是开发人员，而是测试人员。 在敏捷测试中，测试人员则是帮助加快进度的人，也就是提高生产率的人。一个测试人员怎么能提高开发生产率呢？下面几个因素保证其可以发生。 1. 若缺陷发现越及时越容易修改。 比如在1天内就能发现，则1天内发生的改动很少，很容易找到问题。这就需要一个 自动测试 工具来以接近实时地发现缺陷。 比如如果在每天能进行一次 持续集成 ，则集成测试不能通过的原因会很单一很容易定位。设想一个数字电视系统，从授权/编码/加密/复用/调制/发送/接收/分流/解密/显示……环节很多信息很不透明，若在最后一刻才做集成，基本上无法判断问题出在哪里。 2

作为被冠以敏捷名称的测试，敏捷测试同样以快为目标。在敏捷测试中，快有三个方面的含义： 团队能够通过测试快速获知系统当前所处的状态，了解距离可工作的软件还有多远； 能够在一个迭代周期中快速完成回归测试和对新功能的测试； 开发工程师能够从持续的测试中得到快速的关于提交代码反馈。 　　简而言之，敏捷测试要求测试能够测试在短的时间间隔内持续发生且能够在短时间内完成。考虑到纯粹的依赖人工测试基本不可能达到短的时间间隔内持续发生和短时间内完成这两个目标，而自动化测试在执行效率方面具有天然的优势，在敏捷测试中使用自动化测试技术应该是自然而然的选择。 　　考察敏捷开发中的一个迭代周期： 在迭代周期开始的时候，团队与客户一起定义本迭代周期内需要完成的功能； 团队建立验收测试验证标准； 开发工程师开始实现新功能，使用TDD为产品建立安全网，使用持续集成尽可能保证每一次代码提交不引入新的缺陷； 所有新功能被添加后，在RC上运行回归测试保证原有功能的正确性；针对新功能运行测试保证新功能的正确性； 执行验收测试验证系统是否达到可交付的标准。 　　除1和2外，剩下的3个项目都与测试执行密切相关，如果依靠手工测试来进行这些项目，毫无疑问，测试会成为整个敏捷开发的瓶颈。而如果把这些项目中的测试建立在合适的自动化测试基础上的话，测试就可以和开发一起敏捷起来。从这个角度来说，把自动化测试描述成敏捷测试的基石毫不夸张。

任何一个领域都遵循从新人到熟手，从熟手到专家的路径。在成长过程中，DevOps人经常会陷入没人带，没人管，找不到职业方向的迷茫。 DevOps是在商业演进与企业协作的进化过程中诞生的一个全新职业，被很多人看成是一个“全栈”岗位，是能开发、会运维的复合型人才，但想要从事DevOps工作要从哪学起？如何入门？又该如何精进？ 我们对101名DevOps专家进行调研，问题只有一个：从入门到熟手，再从熟手到专家的成长路径中都看了哪些书？最终选出了39本推荐度最高的书籍，分成基础敏捷实战、敏捷测试、精益系列、技术工程、DevOps、教练、引导、大规模敏捷这8大部分，建议每一个DevOps从业者收藏阅读。 基础敏捷实战 《Scrum要素》 本书以一种轻松易懂、简洁精练的方式，介绍了Scrum 方法的核心要素。Scrum 入门级读物，内容精练，轻松易读，是帮助软件开发人员认识、初步了解Scrum 方法的佳作。通过阅读本书，可以厘清Scrum的相关知识和概念，为采用和实践Scrum 方法做好充分准备。 《敏捷革命：提升个人创造力与企业效率的全新协作模式》 本书由Scrum创始人写就，以讲故事的方式，讲述Scrum的由来，并逐步推进的过程。同样是入门级读物。 《Scrum精髓：敏捷转型指南》 如果想用Scrum来开发足以引爆流行的产品和服务，本书就是你梦寐以求的完全参考。

　 　转载自 LANCEYAN.COM 　　说起敏捷开发，并不是因为敏捷而敏捷。这几年的敏捷开发已经被很多敏捷咨询服务商神话了，这个东西并不是神器，实施了就可以解决所有软件公司的问题，而是要结合自己公司的特点和问题摸索出适合自己的一套模式。 　　大家都知道，创业公司刚开始需要研发出一款产品并且能够使公司赚钱的产品，不过大部分创业公司没有那么容易一下就能做出来，很多公司还没有成功的产品资金链就断掉了，公司也死掉了。我们公司是这样一个状况，有一条产品线可以维持公司开支并仅仅刚够盈余，要扩大高速发展还不够，一直维持就没有创业的意义。另一条线是做技术创新为未来能够开发一款人气爆棚的产品摸索着，但是又不能饿着肚子去开发。我们是如何结合自身的特点实施敏捷开发的呢？一个难题，很大的难题！ 　　我们技术团队人员是这样的配置：1名技术总监、2名资深开发工程师、1名高级开发工程师、2名潜力开发工程师、1名前端开发、1名测试。技术总监需要处理很多团队管理、客户管理的工作，能够参与项目的时间最多每天二分之一。2名资深开发需要负责给其他工程师做导师，参与新项目开发时间大概有80%。高级工程师要预留项目学习时间，参与项目的时间大概有90%。潜力开发工程师需要有一些时间学习技术和项目，但是基本可以做到70%的时间投入项目。前端开发和测试哪里有需要就在哪里革命，属于机动部队。 　　现在总共有六个老项目在维护

Dev(Developer) : 开发 TE(Test Engineer) ：测试 PM(Product Manager) ：产品 敏捷：快速的响应客户（需求），高效的完成开发，不断的追求完善。 TE 在敏捷中应该做些什么呢？ 流程 1- 故事分析 角色： Dev 、 TE 内容： 需求交接前夕， PM 将需求上传到文档管理区并邮件通知， Dev 、 TE 分析需求 初步制定测试策略与测试计划 初步安排测试任务 输出： 测试策略、测试计划 测试工作量初步评估 流程 2- 故事计划 角色： 整个 Team(PM 、 Dev 、 TE) 内容： 需求交接（宣讲），了解更多细节 确定测试工作量 更新测试策略各测试计划 考虑环境和并着手准备 输出： 测试策略、测试计划 测试工作量评估 流程 3-Story Kickoff 角色： Dev 、 TE 内容： TE 与 Dev 一起理解分析故事 列表疑虑点 Dev 拆分 task ，并思考设计思路 TE 列出测试要点 TE 各 Dev 一起就以上各点对 PM 和 Dev 进行反串讲（用例与设计评审） 输出： 测试用例 流程 4 - 故事开发 角色： TE 、 Dev 内容： TE 与 Dev 结对、实现自动化测试 输出： 自动化测试 PS: 关于这点，没有自然语言自动化体系支撑，无法达到实行标准 流程 5-Desk Check 角色： TE 、

敏捷项目测试策略文档模板 　　在一个敏捷工作环境种，我们的研发工作以冲刺期和高度迭代的形式展开。每一个迭代周期都关注少数的需求或者用户故事，所以在文档在敏捷项目种的数量和内容方面都倾向于轻量化。 　　对于测试计划这样的文档也是如此，不过我们也确实需要为敏捷团队去提供一个概要的敏捷测试策略，以供指导。 　　敏捷测试策略文档是为了给团队提供一个最佳的测试实践和一些形式的测试体系。记住，敏捷并不意味着没有体系。 　　下面我们来看一个敏捷测试策略文档，看看我们都应该包含些什么内容。 1.　　 一份测试策略中通常都会对于更宽泛的商业目的和目标做出任务说明。 　　 一个典型的任务说明可以是： 　　“通过快速反馈和缺陷预防，持续的交付可工作的，满足用户需求的软件，而不仅仅是缺陷发现” 　　细化以后： 　　“● 在定义完需求的接收条件/测试之后，代码才能进行编写。 　　 ● 接收测试不通过，一个需求就不能被判断为完成。” 　　在敏捷项目中，通常还会包含关于质量保证的提示： 　　● 质量保证是系统和可靠的保证产品满足用户需求的一系列活动。 　　● 在SCRUM（敏捷）中，质量保证是所有人的责任，而不单单是测试人员。在我们开发新产品的过程中，我们通过质量保证活动来确保正确的质量。　 　 2.　　 测试级别 　　 2.1　　单元测试 　　WHY : 确保代码被正确开发 　　WHO : 开发工程师

转载本文需注明出处：微信公众号EAWorld，违者必究。 引言： 随着敏捷软件研发过程的引入，敏捷测试也开始成为研发团队的重点关注对象。在行业内，有些企业正在做敏捷测试的尝试，有些也取得了不错的效果。 随着普元研发管理体系（iPALM）的不断演进，敏捷的开发过程加速了产品的市场响应。在普元DevOps平台的助力下，开始把质量构建进产品而不是在生产出来之后再进行测试。在软件产品部整体团队的群策群力下，敏捷的软件测试模式在研发过程中运行非常成功，测试团队也积累了一些宝贵的经验，很高兴有机会拿出来与大家一起分享。 目录： 1.对敏捷软件测试的理解 2.敏捷软件测试的核心价值 3.敏捷软件测试的经验分享 4.总结 1.对敏捷软件测试的理解 敏捷测试的定义 Wikipedia对敏捷测试的定义： Agile testing is a software testing practice that follows the principles of agile software development.1 译文：敏捷测试是一种遵循敏捷软件开发原则的软件测试实践。 这是通过一种敏捷的做事方法，可以让团队协作更紧密、工作效率更高，确保以可持续的速度频繁地交付客户所期望的业务价值。 敏捷测试与传统测试的区别 传统模式是把软件开发分为软件需求、软件开发（设计&编码）、软件测试、软件发布等阶段