DevOps 敏捷测试之道（上）

本文介绍企业在敏捷和 DevOps 的逐步转型过程中，测试如何应对挑战，有的放矢进行测试，建立适合产品自身发展阶段、产品特点的敏捷测试能力。

敏捷和 DevOps

敏捷和 DevOps 转型始终是被业务目标和客户需求驱动的。市场竞争环境越来越激烈，新商业模式的创新和变现时间窗口越来越短，催生更多的企业采取精益创业的方式，捕捉市场需求后，尽量缩短 TTM 产品面世时间，快速推出 MVP 产品并快速响应客户需求迭代产品。

以华为为例：

在 2008 年左右的时候，华为的项目还是采用传统的交付方式，例如在年初开始一个项目，在项目立项之初就会把客户的需求全部收集好，包括一些用户的反馈，并把需求做了全年的排序。

年中的时候发布产品给用户，两个月之后再出一个补丁，最终年底出一个正式的版本。

当时版本交付的节奏还是比较慢的，但是对质量要求比较强。因为产品发布给客户以后，下一个补丁需要两个月，如果用户在这个期间发现产品问题，他们只能再等两个月，而在这期间如果用户不接受我们的产品，会导致项目前功尽弃，所以就对产品的质量有严格的要求。

产品逐渐向敏捷方向发展，这时有一部分研发工具平台已经陆续转到云上去了，一些测试类的工具也需要转型。

之前产品的交付是半年、两个月发一次，转型之后变成一个月，甚至两周发一次，但这时的转变并不彻底，与客户的交付过程仍然存在一些问题。后来越来越多的工具向平台化、服务化方向转型，这个时候一些商业模式发生了根本性的变化，也就是说当需求上云了以后，用户更加快速的介入进来。

基于云平台，把一些功能快速的开发出来，然后频繁的和用户去商量，听取客户意见，牵引产品做快速迭代，这种交付方法使得交付周期一下变快了，之前是半年交付一次，现在是一周、两周，更有甚者，可能一两天就把功能发布出去了。从需求的角度来说发生了巨大变化，基本做到了小步快跑，快速试错。

测试债务

从瀑布到敏捷再到 DevOps，在开发和测试生产率和需求交付效率提升的过程中，不同的组织或多或少面临一些积压问题没有解决，影响测试能力和测试价值的持续提升。

从对测试的重视程度上看

有的公司存在重开发、轻测试的情况，测试人员职业发展受限；手工测试人员不熟悉编程，开发人员对测试重视不足；测试工作量高，但人员配比低。

从部门组织和流程和文化上看

测试人员对需求理解不足，测试和开发之间的部门墙导致信息不透明、沟通协作滞后和不足，质量向速度过分妥协，以及忽视敏捷文化和价值观的培养塑造。

从测试和产品技术和方法上看

产品耦合度高、可测试性差，测试过于依赖黑盒功能测试，测试策略、方法不恰当，测试环境部署时间长，频繁升级等。

测试的焦点：业务价值的质量

测试首先就是一个质量活动，做测试就是要保证质量，其次是一个工程性的活动，即在有限的时间、人力、资源投入内获得尽可能大的产出价值。质量有多个维度，需要有一个焦点，就是业务价值的质量，也就是产品“对客户呈现的价值”的质量。

测试围绕业务价值去做，确定质量在功能、安全性、性能、易用性、兼容性等多个维度上的权重和优先级，而不是说一个测试上来之后，就把测试相关的关系点、关联点全部做测试。

让我们来看几个例子：

例如现在正在做一个线上支付的功能，对这个功能最关心的方面肯定是安全，所以相关的测试用例关键点就应该围绕安全大做文章，一定把安全保证好。

再比如，现在要做一个线上商城，面向用户是老百姓，不仅要让年轻人会用，也要让老人都会用，那么就要关注易用性。

除此之外，电商举办大规模抢购促销活动，那就还需要关注性能。

所以测试要求瞄准了产品本身的业务价值，确定产品的目标，相应的制定质量关键点，制订相关的测试策略，然后实践落地。落地之后还要基于一些不良的效果不断的进行反馈、循环，校验整体的测试过程是否达到预期结果，这就是我们的测试焦点。

自动化测试金字塔

自动化测试金字塔最早是由 Mike Cohn 在 2009 年的著作《Succeeding with Agile: Software Development using Scrum 》（《Scrum 敏捷软件开发》）中提出。

最早提出来的时候是一个三层的金字塔，从上到下分别是 UI 界面/Service 服务/Unit 单元测试，随着敏捷测试的不断推进，测试金字塔出现一些变种。实际使用中不用太拘泥于每层的名字，在服务化软件架构中 Service 层也可以理解为 API 测试。

这种下宽上窄的三角形结构，代表在各层自动化的建议投入分配比例，越接近底层的单元测试建议的投入最多，接口测试居中，界面层建议的投入最少。

Martin Flower 关于测试金字塔有这样一段评论:

“

GUI 测试用例还很脆弱，如对系统的一些修正可能导致很多用例的失败，这时候你需要重新录制。

你可以放弃录制的方法来解决这个问题，通过写 GUI 测试代码，但是这样效率非常低。就算你已经很精通了 GUI 测试代码的编写，端到端的 GUI 测试用例也很容易出现不可预期结果的问题－一些用例成功一些用例失败，因此，基于 GUI 的自动化测试是脆弱、耗时（包括用例维护和执行）的。

所以测试金字塔要表达的是：底层应当有更多的单元测试和接口测试和逻辑测试，GUI 测试用例能覆盖到主业务流程即可。

”

测试金字塔中每层中涉及的测试技术均有自己的优势和局限性，由于上层 GUI 测试的脆弱（不稳定性）、耗时（执行效率）问题，以及问题表现位置（UI）和问题根因位置（代码）距离太远的问题，测试金字塔由关注测试数量转向关注测试质量，推荐增加底层的测试投入。

• 层次越靠上，运行效率越低，延缓持续集成的构建-反馈循环

• 层次越靠上，开发复杂度越高，如果团队能力受限，交付进度受影响

• 端到端测试更容易遇到测试结果的不确定性

• 层次越靠下，单元隔离性越强，定位分析问题越容易

原则上单元测试需要开发人员承担，很多团队中开发人手不足，优先保障功能的实现，在单元测试的投入不够，并且很多开发人员的单元测试经验不足，导致很多团队中不做单元测试或者被动执行流于形式，有人提出了金字塔结构的反模式：蛋筒冰激凌模式和纸杯蛋糕模式。

本文转载自华为云产品与解决方案站公众号。

原文链接：https://mp.weixin.qq.com/s/NQ65enngFnL-ParxbsaRFA