在数字化时代背景下、无论您身处哪个行业、作为哪一种IT角色、你都能深刻的感受到IT组织向敏捷转型的迫切需求。随着敏捷开发模式的大规模应用和推广、敏捷测试这个话题被不断的赋予新的内涵。同时、敏捷开发模式对质量保障和测试活动也提出了新的挑战。首先、2-4周的冲刺交付周期、使得我们不可能再像过去那样去获得完整的、充裕的测试时间。其次迭代式的交付模式使我们需要持续扩大每轮冲刺交付的回归测试工作量、手工测试根本无法满足要求；第三、敏捷开发重交付轻文档的特点、使我们在测试之前无法获得完备的文档输入；没有需求规格说明书、没有详细设计、似乎测试工作变得无规则可循；最后、数字化时代是用户体验为王的时代、好的质量是否就意味着好的用户体验呢；好的质量不一定能带来产品的竞争力。

面对新的开发模式、我们的测试组织、测试人员准备好了吗？我们测试人员的技术能力能不能适应敏捷开发模式？测试组织如何管理和支持被打散到各个敏捷团队的测试人员？测试工作如何融入到DevOps自动化交付流水线?

将测试活动前置

敏捷开发模式已经重新定义了研发生命周期的各项活动、我们也需要重新调整测试策略、管理方法以及技术手段去适应这种新变化。缺少完备的文档传递、测试窗口这么短、回归测试工作这么大。将测试活动前置是我们主要的选择、也是敏捷测试最主要的特征。

测试人员甚至需要参与到迭代0的过程中、不仅要参与研究用户的行为模式、挖掘质量需求、从测试的视角去全面把握需求和设计细节、并且在规划和前期架构阶段就制定好总体的测试策略和验收标准。在当迭代开始后、测试人员需要帮助开发人员去逐步完善用户故事、明确所有用户故事的验收标准和规格细节。制定故事的验收标准甚至超过了用户故事本身的描述、它能够很好的帮助业务和开发人员形成对需求真实意图的共识。争取第一次就要把事情做对、预防缺陷。当迭代进入编码环节时、测试人员要参与代码和单元测试评审、实践测试驱动开发、目的就是为了尽早发现问题、将质量内建在编码的阶段。当然、测试人员也需要同时完成新开发的用户故事案例的编写以及维护回归测试案例和脚本。在验收阶段、进一步明确本轮冲刺的测试要点及精化测试策略、并且尽可能的将测试过程自动化。在投产上线前、除了必须要完成的自动化回归测试以外、开展探索性测试和用户体验测试是提升产品竞争力的重要手段。我们可以看到在敏捷开发模式下、不仅测试策略和方案、方法需要进行重新调整、对每个测试人员也有了前所未有的综合技能要求。

在瀑布开发模式下、我们强调测试活动必须提前、但是它还处于一种静态的、彼此依赖的状态。而在敏捷开发模式下、测试活动的前置、已经变成了一种动态的、高度融合的状态。因此、测试人员作为团队的重要成员必须和产品经理、开发人员甚至是DevOps团队进行紧密的协作。首先、测试人员是PO最重要的助手、肩负着一部分BA的职责、与PO充分的讨论和分析需求、产品走查、并且将测试结果及时反馈给PO。其次、测试人员应该与开发人员共同讨论和推导功能设计、参与代码审查、对缺陷进行分析、总结规律、帮助开发人员建立良好的习惯。必要的情况下、两者甚至需要进行角色互换。在很多敏捷项目中、测试人员往往还肩负着DevOps实践的责任、帮助DevOps团队共同构建持续交付环境。从整个team来说、测试人员的活动无所不在、从个人来说、积极去调整和其他角色的协作关系。

推动测试驱动开发（TDD&ATDD）实践

实现测试驱动开发（TDD）是敏捷测试的最核心的技术实践。TDD貌似是一个简单的想法：在写代码之前先为代码写测试。但，TDD对业界关于测试目的提出了挑战，测试不再是为用户预防和消除缺陷，而是帮助团队理解用户需求的特性，并可靠、可预测地交付这些特性。每个特性都从编写单元测试代码开始，在测试代码的驱动下，逐步的推到代码设计和实现，直到把测试程序通过。同时、由于敏捷开发需要快速完成一次代码交付，这样的代码通常质量会比较低，随着特性的积累以及对业务需求的理解，需要通过持续重构的过程，逐步的完善代码。因此当我们有了测试套件，无论我们如何重构代码、总是能保证最后交付的结果是符合特性要求的，这也是TDD为何能提高交付质量的最重要的原因。通过TDD的过程、我们可以输出一套完备的单元测试或者组件测试套件、从而在代码阶段实现质量内建。

TDD更确切的说应该是UTDD、就是单元测试驱动开发。TDD由于它的应用通常在编码阶段、所以非常容易丢失对客户需求的聚焦。而验收测试驱动开发首先强调的就是从用户需求出发、通过需求研讨会、由测试人员在初期就将业务需求转化具体的数据实例、确保清晰的表达我们希望系统做什么、同时与所有人达成一致。

然后在开发阶段借助更友好的测试框架、基于实例先于产品代码之前、编写出测试脚本。验收测试驱动开发（ATDD）方法并不依赖实际的用户界面、而是从GUI中抽象出实例背后的业务特性来进行测试验证。同时嵌入TDD方法来完成单元测试代码和产品代码编写。在整个过程中、ATDD不仅可以有效的驱动代码生成、同时能够推动发现领域模型和设计推导。目前基于文本语言的ATDD开源测试框架已经日渐成熟、像cucumber、fitness、robot Framework都可以提供快速构建ATDD的能力。

不管是TDD还是ATDD都已经不再是单纯的测试方法、它们更多的是融入了开发设计方法、所以敏捷测试人员和开发人员之间必须密切协作、结对完成工作。

尽可能实现测试自动化

敏捷测试的基础就是使测试尽可能的自动化；敏捷测试甚至可以侠义的概括为一句话就是具有良好的自动化测试框架支撑的快速测试。过去、自动化测试的活动往往在整个应用研发生命周期中相对靠后、主要以上线前的回归测试为主。自动化测试的投入往往不能很好的收到收益、仿佛成为一种鸡肋。敏捷开发的快速迭代，给自动化测试带来了更大挑战。这就要求我们必须使用自动化手段去代替手工测试。

不仅如此、自动化测试活动必须提前到应用开发的前期、而不是一定等到应用系统构造完成后再启动自动化。

因此建立覆盖开发各个过程的分层自动化测试体系才能满足敏捷开发转型的要求。分层自动化测试是按照应用构建的顺序来逐次开展自动化测试。底层：强化单元测试和组件测试、实践测试驱动开发；中间：实现接口自动化测试、完成用户故事级别验收测试、实践验收测试驱动开发；最上层：UI测试：实现特性级别、基于业务流程的UI回归测试。当然构建一个好的分层自动化测试体系需要一个好的自动化测试平台去支撑。一个好的自动化测试平台不仅是要让每个测试人员能够轻松驾驭、而且要让更大范围的开发人员认可它的易用性、场景通用性和运行的可靠性。

自动化测试同时也是DevOps实践中非常重要的一环、我们现在很多DevOps团队在谈到构建自动化交付流水线中、往往会把自动化测试的集成给弱化；这一方面是由于DevOps环境的构建缺少测试人员的参与、但是另一方面构建一个实用、可靠的自动化测试平台的投入远远比构建一个持续集成、持续部署环境要难得多。测试人员应该根据自己的规划和现状、尽可能将已经实现的自动化测试套件充分的融合到交付流水线之中。在统一集成环境中、单元测试套件应该被融入到持续集成过程中、每一次代码提交的同时应该自动运行配套的单元测试；在统一测试环境中、基于接口的测试套件应该在每一次验收提测前就自动运行、通过后再启动新用户故事的验收测试。在预生产环境中、我们把覆盖全业务流程的自动化测试套件集成到版本发布的过程中、确保所有的上线版本都是已经完成回归测试的。自动化测试理应成为构建快速交付流水线的质量基础保障。

推动用户体验测试

数字化时代下、当我们的应用需要直面最终用户、直面市场博弈、好的应用质量只是基本保障。好的用户体验才是产品形成竞争力的关键。因此推动用户体验测试应该作为敏捷测试的重要实践补充。用户体验测试的测试方法与传统测试方法存在比较大的差异。首先、体验测试当然就是选取真实的用户的业务场景、需要特别注意的就是测试人员并不是真正的用户、我们不能想当然的认为自己就是用户；如何找到用户、找到真实的用户使用场景；需要通过用户访谈、用户观察、竞品分析、数据分析、角色模型等一系列方法去完成。其次、就是对用户主观体验进行分析、好的用户体验其实概括起来就是三点：有用、易用、好用；具体来说主要包括感官体验、浏览体验、交互体验、性能体验、情感体验等几个大的方面。需要为每个产品建立用户主观体验的分析模型。然后就是建立测试人员所熟悉的可以定量分析的业务质量指标KQI和服务性能指标KPI；这些定量指标应该与我们的测试方案设计直接相关。最后就是将用户的主观体验与KQI和KPI进行相关性映射和分析、并实现用户体验问题的定位和持续的改进优化。当然、用户体验测试通常还会结合可用性建模分析、业务流程评测、业务效率评测、数据可用性的评测等方法；

当我们不依托任何方法论、其实我们只需要三个基本原则：与用户同在、不断聆听用户的反馈、比竞争对手好一点。

企业敏捷中的测试管理转型

前面我们所谈到的、测试人员如何融入敏捷团队开展敏捷测试实践、改变测试活动、方法、技术以外、我们的测试管理工作如何来开展、测试组织的职能是不是也应该进行相应的调整呢？在推动企业级大规模敏捷实践过程中、测试组织的职能一方面应该体现在项目群管理层面、包括以下几点：1.完成特性验收测试、以及端到端的全业务流程测试、确保整体交付业务价值。2.负责用户体验测试以及探索测试以及非功能测试。3.确保测试技术平台与测试管理平台、敏捷&DevOps工具链的集成。另一方面在团队管理层面，需要做到以下几点1.提供敏捷测试的规范和方法；2.提供统一测试技术平台的支撑3.协作各个团队快速构建持续测试环境；

结束语

测试变革之路应该说是任重而道远。测试活动与开发活动已经开始深度的融合、无论是在测试人员的技术能力、测试组织的管理能力、还是测试工具的自动化和集成能力都提出了更高的要求。敏捷正在深刻的改变着测试。