转载本文需注明出处：微信公众号EAWorld，违者必究。
引言：
随着敏捷软件研发过程的引入，敏捷测试也开始成为研发团队的重点关注对象。在行业内，有些企业正在做敏捷测试的尝试，有些也取得了不错的效果。
随着普元研发管理体系（iPALM）的不断演进，敏捷的开发过程加速了产品的市场响应。
在普元DevOps平台的助力下，开始把质量构建进产品而不是在生产出来之后再进行测试。
在软件产品部整体团队的群策群力下，敏捷的软件测试模式在研发过程中运行非常成功，测试团队也积累了一些宝贵的经验，很高兴有机会拿出来与大家一起分享。
目录：
1.对敏捷软件测试的理解
2.敏捷软件测试的核心价值
3.敏捷软件测试的经验分享
4.总结
Agile testing is a software testing practice that follows the principles of agile software development.
1
译文：敏捷测试是一种遵循敏捷软件开发原则的软件测试实践。
这是通过一种敏捷的做事方法，可以让团队协作更紧密、工作效率更高，确保以可持续的速度频繁地交付客户所期望的业务价值。
传统模式是把软件开发分为软件需求、软件开发（设计&编码）、软件测试、软件发布等阶段，一般利用里程碑的方式对各阶段进行明确定义。软件测试是研发过程中的一个阶段，而且一般都属于项目的最后阶段；测试团队都是立场比较明确，与团队之间的沟通以正式为主；测试以需求为依据，要求有需求规格，自动化测试不作为要求；测试计划做得比较详细，对测试活动都会做好周密的安排；需求方确定需求后，中间环节参与较少。
在敏捷模式里，相对传统模式，软件测试不再是一个独立的阶段，测试是融入在软件开发过程中的一个组成部分，发生在每一次迭代中，也包含所有类型的测试，如单元测试、集成测试、系统测试、验收测试等。测试人员与开发人员工作更紧密，非正式的直接沟通成为了一种常态；测试以最终用户为准，辅以用户场景或用户故事作为测试的依据；测试追求快速高效，自动化测试在测试中扮演了及其重要的角色，敏捷测试人员辅以探索性测试跟踪核心业务场景；敏捷测试拥抱变化，测试计划比较灵活，按业务价值交付顺序执行；需求方需求定义后，参与每一次产品演示，确认每一次迭代产物，全程参与项目。
在敏捷的软件开发过程中，敏捷测试人员利用他们的专业知识从客户那获取需求所包含的业务行为，与开发团队协作，将这些行为转化为指导编码的可执行规范。
敏捷测试人员参与用户故事拆分，遵循比尔·维克(Bill Wake)的INVEST原则，即一个合适的用户故事应该是独立的(Independent)、有价值的(Valuable)、可讨论的(Negotiable)、小的(Small)、可估算的(Estimable)和可测试的(Testable)。
2
测试人员参加需求说明会和计划会：产品经理给项目人员串讲用户故事，在这个过程中项目人员提出自己的建议和想法，并充分讨论。需求讨论清楚后，大家用敏捷牌估算工作量
参与每日站会：开发过程中每天早上有一个大约15分钟的每日站会，告知各自完成的工作、遇到的问题及接下来的工作
测试人员组织产品演示会：对每次迭代的产物提交评审，向需求方进行演示，对需求进行确认
参与每次迭代复盘会议：对整个迭代过程进行总结，并举行评优及奖励
很直接的原因，整个项目都在采用敏捷的开发模式，你还想申请一段独立的时间来执行测试，领导会答应吗？本来要快速响应需求，没有更多的时间留给你做测试，所以领导是不会同意这么做的，因此测试需要前移，要与团队进行协作，才能更好的适应这种小步快跑的敏捷开发模式。
再者，当测试发生在项目的尾端时，有时可以牺牲时间和质量来满足关键的进度和预算限制。随着开发和测试反馈之间的时间缩短，成本预计会下降。反馈循环越短，由于开发人员在处理新问题和项目时花费的时间更少，因此缺陷修复和改写所需的时间更少。
ISTQB在调查中发现，敏捷方法论的普及率最近几年增长显著，这也表明软件行业对敏捷测试过程和技术的需求越大。
开发团队通过提供最小化可用产品获取用户反馈，并在这个最小化可行产品上持续快速迭代，直到一个相对稳定的阶段产品。在此过程中，敏捷测试人员快速验证团队的目标，快速试错。
降低软件质量风险
敏捷测试要求测试人员尽早进入测试，与开发人员形成统一战线，尽早发现系统缺陷及其它问题，避免大量问题在项目后期才发现，形成质量风险不可控的结果。
启用日构建，通过BVT进行持续测试，让每天的迭代代码都能得到验证。
敏捷测试人员以专业的能力，引导项目全体成员开展测试，编写自动化测试用例，关注自动化测试执行结果，以稳定的每次编译及测试均未发现缺陷为目标。
敏捷开发偏向项目型的组织架构，测试人员与产品经理、程序经理、需求人员、开发人员等构成一个团队，采用扁平化的方式进行管理，构建一种和谐的工作氛围，共同为交付价值而努力。
加速个人能力提升
在一个敏捷迭代周期里，一般团队规模7~8人，敏捷测试人员至少2~3人，测试工作不在是一个萝卜一个坑，每个人承担的事情种类较多，要求的知识面更广泛，个人技术栈会越来越丰满，独挡一面的能力更强。
经过普元多年敏捷测试的项目实施，要支持产品的快速迭代，达到敏捷测试的预期效果，我们重点在以下几个方面开展了工作。
组织文化的改变
公司研发采用扁平化的管理模式，在敏捷的组织文化中，相比于流程，敏捷更关注人，所以敏捷测试组织是应该是以人为导向、自组织、协作式的一种文化氛围。
作为领导，工作中与大家一起共同进退，组织团队建设，发展团队成员间的友好关系。
从项目特点来看，敏捷是属于“强项目型”管理的方式，但敏捷人员可以在自于静态的职能组织或将测试人员整合到敏捷项目中。
无论人员来自哪里，在敏捷团队中，测试和开发同属一个项目，大家的目标是一致的，敏捷测试人员在质量思想方面影响团队的其他成员。如测试人员可能会帮开发人员评审代码，开发人员也会帮测试人员进行测试，人员角色的职能可以模糊化。
敏捷测试团队还需要把客户纳入到组织中，学会一起工作并建立起彼此间的信任，一起做好软件的质量保证。
任何一个改变要想实施成功，都离不开领导层的大力支持。敏捷测试也强调领导的作用，从领导层的角度需要提供一个宽松的环境，让整个敏捷测试团队能够形成自组织的模式。当遇到问题时不是进行追责，而是给予足够的信任和支持，协调资源帮助团队解决问题，陪伴团队成长。
领导制订一些KPI考核指标，制定一些奖励办法，提高大家工作的积极性。
测试人员需要了解敏捷，掌握敏捷的基本知识和原则，从而才能在整个敏捷体系中更快的融入到敏捷环境中，从而更好的开展整个测试工作。
测试工作不再是软件功能实现后再进行，而是测试工作前移，功能实现前就已经对测试做好规划，做好测试用例的设计及准备，等待测试的执行。
敏捷测试人员需要与需求人员、开发人员保持沟通，建立一种相互合作的氛围。传统测试不同角色之间的接口可能主要是文档，在敏捷测试过程中，我们在弱化文档，不为文档而文档，主要还是以沟通为主，做为敏捷测试人员我们需要去变被动为主动，积极去做些改变。
为了取得更好的沟通效果，敏捷测试过程中的沟通方式不拘一格，可以实行正式的沟通和非正式的沟通，正式沟通的形式可以是邮件或会议，非正式的沟通工具可以是面对面、电话、Wiki、微信等。
敏捷测试要取得好的效果，CI、CD及CT
3
是必不可少，缺少任何一项，整个流程就会不顺畅，效果也就大打折扣。
但要做好这CI、CD和CT，除了需要合适的工具提供支撑，还需要项目整体团队紧密协作。测试团队还需要具备一定的技术能力，在过程中提供驱动力，推动整个过程有序进行。
敏捷研发过程中，测试的版本更换比较频繁，要求代码集成要快，整个构建一般需要控制在15分钟，构建的项目较多，我们采取并行及分布式执行。
编译构建产物存放介质仓库，支持通过Web方式下载，供项目组成员取用。在我们的敏捷研发过程中，主要基于普元的DevOps平台实现持续构建。
配置与介质分离，按不同环境进行组合，使用普元DevOps平台标准化的部署流程，快速部署程序包并启动，定时进行健康检查。
使用DevOps进行测试环境的部署，可以解决一些关键问题，如部署目录的规范化、部署行为的规范化、部署过程的透明化、对部署结果进行初步检查以及支持部署异常的快速回滚。
通过DevOps平台的支持，可以避免无关人员获得敏感配置值，避免无关人员操作无关进程，通过页面交互方式，可以方便快捷搭建好所需环境，也大大减少了手动部署带来的压力。
在我们的敏捷过程中，主要是基于普元的DevOps平台实现发布部署。
在敏捷开发这种极短的交付周期内，如果仅仅靠手工测试，则非常难以满足快速发布要求的。所以自动化测试是必不可少的一种手段。
另外这里谈到的自动化测试不仅仅只是指功能的自动化测试，还包括单元测试、静态质量扫描、性能测试、安全扫描等，也涉及自动化测试如何集成在整个交付管道中，缩减整个交付时间，最终给项目带来价值。
在普元产品的敏捷测试中，我们主要是基于普元统一测试平台UTP完成自动化测试，它不仅支持微服务接口的自动化测试、Web UI的功能测试、移动App的兼容性测试等。
回到测试的本质，作为敏捷测试人员需要做好敏捷测试的知识储备，无论是测试基础知识还是测试的技术技能，个人都需要考虑提升，组织上需要为个人提升打开空间，组织相关的培训，与行业先进测试理念接轨。
团队内部要经常进行团队分享，需要传道。对于敏捷测试的新思维，如果没有进行相关培训和了解，会让具体执行人觉得没有底气。同样，敏捷项目中测试人员在进行测试前也需要接受敏捷知识的培训。如果可能的话，最好是由具有丰富经验的敏捷测试教练帮忙进行指导，避免走错方向。
敏捷软件测试不是独立存在的，它依赖敏捷的软件开发过程，强调的是敏捷项目团队的整体对质量的负责，测试团队不再是质量职责的全部。但敏捷测试团队需要以专业的知识驱动团队的质量意识，通过团队之间的紧密合作，实现敏捷研发的过程，快速推进业务价值的交付。
参考材料
1、维基百科的敏捷测试定义：
http://wikipedia.moesalih.com/Agile_Testing
2、Bill Wake INVEST规则：
https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
3、CI：Continuous Integration（持续集成） CD：Continuous Deployment（持续部署）CT：Continuous Testing（持续测试）
精选提问：
问1：单元测试是应该由测试人员写，还是开发人员写？测试人员需要写代码吗？
答：如果测试资源配备充足，具备白盒测试的能力，可以由测试人员配合开发写单元测试，否则就由开发自己完成。测试人员最好有代码能力，但是否写代码实现自动化测试，取决于自动化测试的方式及工具。
问2：我们公司的测试人员只会鼠标点点点，是正常状态吗？自动化测试做不起来， 因为需求老是变怎么办？
答：每个公司都需要有手工测试人员，但当需要做敏捷开发，要快速发版的时候，执行自动化测试是一种比较好的实践。基于需求的频繁变化，实施自动化测试的策略需要重点考虑，稳定的功能优先做自动化，开展接口的自动测试的业务价值更高。
问3：一般用哪些自动化测试的工具？
答：行业内自动化测试工具比较多，开源的有类似Selenium、Appium、TestNG等，商业的如普元的UTP，支持UI、接口、移动App等功能的自动化测试。
问4：移动自动化测试一般是什么方式？开发人员有必要在开发Android/iOS过程中编写单元测试用例吗？
答：移动的自动化测试包括前端和后台的，前端的单元测试一般移动开发平台会提供，如普元的移动开发平台，具有调试客户端，无论是Android还是iOS，所见即所得，开发的功能即时更新，即可查看效果。后台的测试即使针对接口的测试，使用一般的开源工具也可以做到，普元也有类似的自动化测试平台，如UTP。
问5：请问测试人员、开发人员配比如何配？一般的软件公司、较大的公司、普元又是如何配置？
答：测试人员、开发人员配比取决了公司对软件质量的重视程度，一般来说，测试也是无穷尽的，也是需要考虑投入产出比。有关配比也没有统一的标准，国内开发与测试一般在5:1~3:1左右，普元对软件测试还是比较重视，从2006年就开始实施自动化，人员配比超过国内行业平均水平。
问6：请问测试人员怎么才能提高技术，该如何入手？
答：提高技术的方式挺多，途径包括参加培训、自学（包括线上文章、视频等），工作时可以多请教高人，参与一些群（包括QQ、微信），对于之前没有技术背景的同学，最重要的是制定一个计划，主要还是要围绕自己的工作展开，因为身边的资源也比较多，好多都是自己的导师，坚持下去，你就能成为测试专家，祝你成功。
关于作者：小道圣，现担任普元统一测试平台产品经理，全面负责测试产品研发、售前咨询、项目实施等工作。十多年的开发与测试工作经验，一直专注于持续集成与自动化测试领域的技术的研究，对测试体系建设、测试管理具有丰富的实战经验。
关于EAWorld：微服务，DevOps，数据治理，移动架构原创技术分享。长按二维码关注！
关于作者：小道圣，现担任普元统一测试平台产品经理，全面负责测试产品研发、售前咨询、项目实施等工作。十多年的开发与测试工作经验，一直专注于持续集成与自动化测试领域的技术的研究，对测试体系建设、测试管理具有丰富的实战经验。
关于EAWorld：微服务，DevOps，数据治理，移动架构原创技术分享。长按二维码关注！
