众所周知，DevOps这几年很火，很多公司都在如火如荼地实施。但是，大家有没有想过，开发模式的不断创新对测试从传统到敏捷再到DevOps带来的挑战？最近我们的项目正在实施DevOps，所以想趁热打铁，谈谈如何在DevOps模式下进行测试谈谈自己的感悟。一、DevOps的特点是什么DevOps是一系列的软件开发实践，强调开发人员（Dev）和运维人员（Ops）之间的沟通与协作，通过自动化的流程，使得软件的构建、测试、发布更快，更频繁，更可靠。1.DevOps强调一种文化在很多企业中，开发和运维人员通常属于不同的部门，工作环境不同，采用不同的沟通方式，使用不同的开发或运维工具，业务目标也不同，这使得一个他们之间是坚不可摧的墙。DevOps其实是一种文化变革，强调开发、运维、测试等各个环节之间的沟通与协作。目的是帮助这些人朝着共同的目标努力：为公司提供尽可能多的价值。为了支持这种合作，需要在团队内部文化和企业组织文化两个层面下功夫。2.DevOps是一种实践。所谓DevOps就是将敏捷的方法延伸到Production！DevOps主要是将敏捷开发实践延伸到运维阶段，进一步完善软件构建、验证、部署、交付等流程，让跨职能团队完成从设计到生产支持的工作。3.DevOps包含了一系列的工具链DevOps是一种结合了一系列基本原则和实践的方法论，从这些实践中衍生出各种工具。这些工具存在于软件开发和交付过程的不同阶段：Coding：代码开发和审查、版本控制工具、代码合并工具Building：持续集成工具、构建状态统计工具Testing：通过测试和结果确定性能的工具Packaging：成品仓库、部署前的应用暂存发布：变更管理、发布审批、发布自动化配置：基础设施配置和部署、基础设施即代码工具监控：应用性能监控、最终用户体验二、DevOps对测试提出什么挑战什么时候刚开始工作，我参与了一款奥迪汽车电子的软件开发，采用传统的瀑布式开发模式。在整个项目生命周期中，前半部分用于设计和编码，后半部分用于测试。然而，我在公司工作了两年，却一直没能等到产品交付给用户。直到去年我们的软件才量产上市。在这4年里，产品从未到过用户手中，因此无法验证其带来的价值，也没有机会获得用户反馈以适应变化。后来，我参与了一个银行项目。我们采用敏捷开发模式，全功能团队，并行开发和测试，每2-3周交付一个版本。但是由于还没有发布到生产环境，我们还不能及时得到用户的有效反馈。现在，我们采用DevOps的最佳实践，其中开发和运营协同工作。每次迭代完成，或者每修复一个线路缺陷，立即部署到生产环境。这样，我们可以快速获得用户的反馈并快速响应。通过参与传统的、敏捷的和DevOps的项目，我深刻感受到流程的改进对团队和项目的产出和质量带来的变化。那么，这些变化会给测试带来什么样的挑战呢？我认为有以下几点：1.频繁部署采用DevOps后，我们可以根据项目的具体情况一天甚至一天部署多次。经常在生产环境中部署软件，最大的挑战就是测试。以前，测试主要在开发阶段之后和产品上线之前完成。但是现在，已经没有足够的时间留给QA团队去发现问题，然后丢给开发团队去修复了。因此，速度成为测试的一大挑战。2.AutomatedDevOps强调流程自动化，而测试作为重要环节之一，势必实现大规模自动化。因此，测试人员的自动化编码能力面临着极大的挑战。3.实践与反馈敏捷提倡我们拥抱变化，更重要的是适应变化的需求。有些功能需求虽然明确具体，但我们很清楚用户想要什么，所以很容易测试。但是，也有一些非功能性需求的验收标准不太明确，例如：提高应用程序性能以实现良好的用户体验。如何验证用户体验是否真的好？仅通过性能指标？当然不是，会议指标只能说明部分问题，只有真实的用户数据和反馈才是最可靠的。4.协作敏捷强调全功能开发团队的共同协作，但这仅止于开发阶段。DevOps专注于Dev、Ops和QA组之间的密切协作。因此，良好的角色定位可以帮助测试人员发挥最大价值。3.我们如何做测试Laurent曾经在Hiptest上发表过一篇博文《Shift left and shift right: the testing Swing》，提出了一个有趣的测试矩阵，从四个维度进行分析，描述了软件开发模式从瀑布到敏捷，再到DevOps的转变，测试是如何进行的响应变化。Laurent提出了一个左测试和右测试的概念：左测试是指在开发阶段之前定义测试。将测试右移就是在生产环境中直接监控，实时获取用户反馈。在敏捷开发的生命周期中，我们通过每一次迭代来丰富和更新产品，使其最能满足客户对系统的需求。当时测试的重心基本停留在开发阶段，确保产品符合线上标准。引入DevOps后，我们不仅需要关注产品质量是否达标，还需要及时验证价值假设。因此，我们不仅要将测试左移，验证功能在开发环境中的可用性，还要将测试右移，通过监控产品在生产环境中的运行情况，验证其价值并获得反馈，从而不断改进。基于这些认识，我对该项目进行了初步的尝试，并取得了不错的效果。我将这些尝试和做法归纳为以下几点：1、如何保证新功能落地？在开发环境中，我们开发新的功能，并通过测试确保它们满足产品验收标准。首先，使用BDD（BehaviorDrivenDevelopment，BDD）定义用户需求，让用户行为可以用特定的语言来描述，让各个角色（测试、开发、产品负责人、市场等）达成一致的理解的商业价值，使其能够从需求到最终的测试验证进行高度的协作和沟通，最终交付最有价值的功能。同时，QA可以提前审核故事卡并补充验收标准。另外BDD方式的用户需求可以直接指导测试，这个我会在后面写到。其次，使用单元测试来验证最基本的代码逻辑。在编写单元测试时，建议Dev和QAPair一起工作。单元测试可以认为是编码的一部分，需要对系统的代码逻辑有深刻的理解。因此，Dev是最合适的人选，而QA可以帮助测试覆盖更全面。最后，每个功能都要严格按照故事卡的AC（AcceptanceCriteria）进行验收，采用探索性测试的方式，无死角地测试新功能。2.如何验证新函数的值？我们将新功能部署到生产环境后，下一步就是衡量业务价值是否达到预期。验证预期的一个好方法是衡量用户行为的变化。例如：在上传图片功能后添加了一个预览按钮，但用户很少使用，可能是因为用户根本不需要这个按钮，或者按钮放置在不合适的位置，导致用户使用起来不方便使用，或者是按钮样式不够友好，导致用户没有使用欲望。这个时候按钮的商业价值还没有真正发挥出来，是时候调整一下了。3、如何保证现有功能不被破坏？在软件开发中，任何代码都不可能完全独立存在，改动一行代码就可能导致系统彻底崩溃。那么，如何保证在开发新功能的同时不破坏已有功能呢？或者说，如何实现全面的回归测试？人力是成本最高的，也有实际的局限性。比如没有足够的人力重复同样的事情会让人变得烦躁，手不够快造成效率低下等等。因此，自动化测试是唯一的选择。将BDD需求直接转化为自动化测试用例。每个测试用例都应该讲述一个关于应用程序的故事。当使用一致的业务术语定义测试用例时，它更具可读性和易于自动化。同时，上一次迭代的用例可以快速转化为基线，用于下一次迭代的回归测试。支持BDD的工具有很多，比如：Cucumber。举个简单的例子，如图：BA用BDD定义用户需求，QAReview补充AC，然后写成自动化测试脚本。如果QA的coding能力较弱，可以请Dev协助完成代码实现。这也充分说明了协作的重要性。最后，也是更重要的部分，测试应该集成到CI中。每次构建或每天都会执行测试，以验证现有功能是否完好无损。这将对意外更改引起的问题提供快速反馈。另外，做一些性能测试、兼容性测试、安全测试等。4、如何验证产品的可靠性？有时，有些缺陷不是代码错误引起的，而是用户体验不好，或者只有在数据达到一定数量时才会出现，而测试人员无法模拟这种不同类型的测试，因此直接在生产环境中进行监控变得高效可靠。通常我们需要监控两个特性：性能和可用性。使用工具不断获取用户数据，或者使用日志不断获取性能信息。这有助于监控产品在部署到生产环境后的正确行为。快速启用一个功能，在生产环境中实时监控和验证其商业价值，获得有效快速的用户反馈，并具备持续部署的能力，让我们在出现问题时能够快速响应，从而让我们的产品更加可靠。《QA in Production》的概念其实也融入了这里。如今，有许多工具和方法支持在生产环境中进行测试。篇幅太长，这里就不细说了，请参考原文。至此，我们再回顾一下我们的修行是否真的有效。使用BDD来定义用户需求和编写测试有利于不同角色之间的一致理解和协作。自动化测试解决了频繁部署的挑战，同时确保产品的整体功能不断回归和验证。在线监控可有效验证不确定需求，分析生产数据并预警问题，快速获取用户反馈及时调整。另外，这也充分体现了Dev、QA、Ops的协作。像监控这样只能由Ops完成的事情现在可以由Dev或QA完成。4.写在最后测试是一个活动，我们用它来验证产品是否符合在线标准。现在在DevOps模式下，我们需要在各个阶段不断进行测试活动，以实现产品质量的持续提升。而QA（Tester）只是一个进行更多测试活动的角色。敏捷一直强调“团队对质量负责”，测试不再是QA（Tester）的专属。DevOps模式对测试尤其是自动化测试提出了更高的要求，对QA的编码能力提出了极大的挑战。作为团队成员，每个人都有责任了解开发流程，提高测试技能，做好测试工作。然而，测试活动是QA（Tester）的主要职责之一，提高自动化测试技能是每个QA（Tester）最紧迫、最重要的事情。【本文为专栏作者“ThoughtWorks”原创稿件，微信公众号：Thinkworker，转载请联系原作者】点此查看该作者更多好文
