敏捷开发的概念已经火了有很多年了，笔者从2012年接触敏捷测试理论，先后在电信行业和国内互联网企业，在敏捷开发团队中从事测试工作。敏捷团队中的研发和测试融合到一个团队，也时常会遇到瓶颈，最常见的就是测试资源紧张，瓶颈到测试资源，自然而然会想到开发人员和测试人员的配比，按照系统特点和质量要求不同，这个配比是不同的，不会有统一的答案，比如曾经所在的电信级网管项目来说，开发和测试人数配比大概接近2:1， 这只是做新特性测试的人员，另外还会有专门的系统测试团队，负责feature交付后的回归测试和系统测试。这是对于质量要求高的和系统复杂度高的系统而言，国内的互联网团队，开发和测试人员配比大概6:1，或者更高9:1，这是目前的现状，但是是不是最优最合理，这个是值得大家去讨论的，本着对交付质量负责，对客户体验负责，鼓励测试人员和开发人员从技术角度有更多的尝试，用技术去解决更多的资源问题，本文大体介绍下我们所在的敏捷团队，商家端产品的业务敏捷测试提测质量卡点的实践以及近两年敏捷测试实践的持续演进的过程。
敏捷开发模式是按照SCRUM框架来指导工作的，Scrum模型下的流程介绍大致如下。
敏捷测试的概念是敏捷开发概念的一种延伸，敏捷测试不独立于敏捷开发存在，是在敏捷开发过程中的传统测试方式的一种改良和转变。本质是将测试过程融入到研发全过程中。倡导团队成员(SM,产品，开发，测试)共同关注质量，质量不再是测试自己的事情，而是团队共同的事情，事实上SCRUM框架下的流程设置其实也是以质量为主的，包含3个大的质量里程碑，DoR,DoD1,DoD2。
DoR，全称Definition of Ready 是需求满足开发条件，进入到迭代池
DoD1全称是Definition of Done, 需求满足提测质量，进入到测试环节
DoD2 全称是Definition of Done，需求测试完成，进入到上线环节
测试人员需要参与到DoR的评审中，站在用户的视角对需求提示3W的提问，Who,What,Why, 用户是谁，需求是什么，需求的价值是什么，看似形式和PRD评审没有区别，但是实际不同于传统的PRD评审，评审的目标更加聚焦到用户故事，从给定的角度，注重用户体验用户价值，测试的立场代表用户的立场，可以看到测试人员的声音会被产品和开发人员重视。这也是敏捷测试赋予测试人员的权利。
举个栗子，DoR的阶段性产出包括提供PRD文档已经提出，涉及页面提供原型,明确上下游依赖，是否已经具备，相关用户故事是否已经和业务部门澄清确认，提供研发对接人和接口，满足这些条件才能进入迭代池，进入开发阶段，还有一些开发的细节实现逻辑是否能符合需求的要求，还有是否有业务风险，涉及到的历史数据和当前数据如何处理等等，从需求价值，需求完整性，业务风险等维度，需要测试参与进来，起到积极的组织，澄清，从一开始就划清业务边界，控好业务需求的质量。
DoD1是开发提测的环节，那么这一环节，需要开发做需求演示，完成自测，交接单元测试用例，接口测试用例或者自测用例，满足这些提测准入的条件，涉及到的开发的相关人员和测试一同召开，DoD1评审会，除了检查上面说的这几点，会督促开发举行代码评审和质量评审，开发人员重点关注代码评审这块，测试人员更加注重质量评审，角度不同，能提前发现很多问题，质量评审通常包含这几个部分：
- 需求完整性检查，检查是否都覆盖到了用户故事的功能点
- 回归检查，新需求代码是否影响现有的功能，是否能兼容当前的逻辑
- 关联性检查，新需求代码是否影响相关的功能模块，关联点需要梳理出来
- 是否有兜底方案，分布式系统的上下游风险的应对，异常的处理，系统异常不能阻断业务
当然DoD1质量评审会需要的一些输出，是可以定制化的，这里举个栗子是按照供应商B端业务来举例，如果是中心类业务系统，中间件等那么要求和输出则不尽相同，需要业务线敏捷团队自己灵活设置，前提是和开发要达成一致，对我们的质量中间结果负责。
DoD2阶段，就是测试完成，邀请产品和业务进行验收，UAT验证阶段，这个部分也会有一些阶段性的产出,不同的业务线可以定制，但也有通用的比如测试报告，测试用例，缺陷分析等等。上线预案，开发上线checklist，线上历史数据处理等等，针对线上业务，测试同事也会组织进行特定功能点的商家体验走查，通过UAT，需求的ROI反馈，体验走查等活动，进一步提高上线需求的质量，指导当前的测试。
通过以上的实践举例，实际上敏捷开发的模式极大的拓宽了测试人员的活动的边界，同时也对测试人员提出了更高的要求，从DoR，DoD1，DoD2，没有最好只有更好，只有测试人员站在用户角度，业务角度，深刻全面的理解业务，才能帮助团队做好DoR，既要有业务架构的意识，也要细节导向，技术基础设施建设也要能帮助测试和开发一同做好DoD，提高测试效率，也提高了研发效率。
笔者所在敏捷团队今年又对质量保障环节进行了演进和加强。主要夯实了自动化测试建设，丰富了提测质量检查的手段。
新增了TRD文档，技术需求文档，类似PRD，产品需求文档，TRD更多的是从开发的角度阐述需求开发的影响范围。比如对于评估需求超过2天的输出TRD文档，这份文档由几部分组成，所做的需求概述和背景，系统的整体解决方案，包括整体的架构图，子系统和应用，服务或者功能模块之间的依赖关系，业务行为设计，包括领域能力类图，UML图，对现有功能的影响，测试验证的范围，上线后的降级方案，回滚方案等等。TRD文档贯穿开发工作的由始而终，从开发的角度阐述设计实现及预案。测试人员在需求上线的时候，可以提醒开发人员提供TRD。所以TRD可以描述为是开发设计文档再加上开发者质量文档。完善的流程保障了需求有质量的交付。同时也对测试人员提出了新的要求。
要求一、测试人员如何在有质量交付的同时，做到高效的交付。
要求二、测试人员如何在保障高效交付的同时，如何扩大测试范围，最大程度的保证业务交付质量。
针对新的要求，笔者所在团队持续进行效能提升措施和实践，大概总结一下和大家分享，或者看看有没有更好的最佳实践，能够帮助敏捷团队显著的提效。
总的方法还是通过全流程把控和测试左移的方法提高DoD1的质量标准，再通过加强自动测试测试覆盖范围缩短DoD1的交付时长，保障DoD2的交付质量。同时检查各环节输出。
提高代码的提测质量。开发提测之前需要做代码评审，评审通过后才能进入提测阶段。提测之前开发人员给测试人员做演示，冒烟测试需要通过。通过后才能提测。只有提测质量提高了，才能降低开发环节对于测试的依赖，减少后期返工和重大缺陷产生。开发加强自测的同时，测试人员也需要提升提前识别隐藏缺陷的能力，提高测试敏感度。同时加强自动化测试的覆盖，通过参与代码评审进行代码级测试。
如下图，代码级测试，现在拆出的模块包括，代码扫描，代码走查，单元测试，接口测试，代码扫描模块可以从开发阶段就可以执行，在和开发就代码扫描的规则达成一致后，就可以在开发阶段持续进行代码扫描，扫描关键bug，驱动开发解决，通常NPE问题居多，代码走查可以在开发提测阶段，测试参与到开发的code review活动，针对业务系统特点，提出合理化质疑，通常包括需求完整性检查，评审过程回顾需求，识别需求实现的完整性，新增功能是否影响现有功能，现有功能更新是否影响关联模块，提前识别的过程中，自然会对手工测试需要覆盖的范围有了一定的了解。
测试评审规范，上面已经提到过，不再赘述，可以根据实际情况进行增删。
单元测试目前由开发负责来做。主要是service层的单元测试用例为主。以行覆盖率做为指标来统计。接口测试，分为后端接口测试（前后端分离），JSF接口测试。接口回归测试也可以在开发阶段持续进行，测试人员通过单元测试覆盖率指标做为质量门禁。个性化的需求通过开发单元测试辅助分析工具来实现统计和驱动，比如扫描指定工程文件，统计应用单元测试新增用例数，用例覆盖到的类，统计单测执行人erp等，提高单元测试的覆盖率。
自动化测试能力： 比如商品发布业务线，针对业务应用的实现特点，分层实施自动化测试。分层自动化测试设计：
先看看业务系统的实现结构，商品portal,商品service,商品BFF，商品审核端
结合业务系统的结构，自动化测试设计拆分成几个模块，UI自动化重点测试商品发布页面的交互，覆盖一部分的关键业务流程，比如商品的发品，商品草稿的编辑等，接口自动化覆盖商品BFF适配层和商品服务层两层，BFF适配层是前后端分离的架构改造引入的，所以针对这一层覆盖了一部分的http接口自动化测试，商品服务层做为商品最原始的服务有一部分的JSF接口覆盖，还有一部分对外提供的宙斯接口，通过宙斯接口自动化覆盖。
分层自动化设计遵循自动化测试的金字塔原则。
做到关键场景须有一条自动化测试用例覆盖。用例尽量保持精简。
应用分层自动化测试的同时加强自动化测试覆盖分析：
- 干净的自动化测试环境，专用的测试数据
- 复杂场景的拆分，颗粒度把握
- 链路服务治理及单元测试
以下举个例子，比如链路分析
通过自研工具将场景从UI，接口，后台服务进行链路跟踪和采集。自研工具通过实现MethodInterceptor拦截器，应用导入工具jar包，配置AOP切面，即可收集方法调用数据，实现一次WEB请求，从UI到接口到API级别的方法调用数据提取。
进行灰盒级别的分析。结合采集到的数据，对场景逆向分析产出场景和JSF接口的对应关系。
http接口自动化测试用例的实现
前后端分离模式下，将后端接口实现接口自动化测试覆盖，开发和测试应用swagger文档进行协作，后端开发人员实现接口后，会自动注册swagger出接口文档，前端开发依据此文档开发前端页面，测试人员也依据此文档进行接口自动化用例的提前维护或者后期维护。swagger端上调试通过后。录入自研的接口自动化平台，持续的进行用例沉淀。
UI自动化测试用例，应用cypress框架实现新版发布页面的关键脚本，梳理发布页场景，比如自营商品发布页面，京喜拼拼发布页面。编写好自动化测试用例后接入UI自动化测试平台JDTC，JDTC可以同时支持WEB UI，APP UI自动化测试用例的接入。测试人员可以灵活选择cypress框架和或者平台提供的selenium框架开发自动化测试脚本接入到平台执行。
将自动化测试应用于回归测试阶段，上线前验证
UI自动化测试，所在团队正在实现应用UI录制引擎录制UI脚本，降低UI自动化的是实现和维护成本，后续会继续分享这块能力的持续演进。
最后再总结下，敏捷开发模式下测试能力提升的实践，通过代码级测试，提前介入识别测试风险，比如参加开发代码评审，驱动开发单元测试或者code review，通过自动化测试方法，扩大测试覆盖，提升发布信心。
测试能力的持续演进是个比较大的命题，涉及方方面面，比如环境，流程，文化等等，本问就先抛砖引玉到这里。也期待大家的分享，共同探讨敏捷测试。
