SAP成都研究院姚瑶：软件质量保证工作的变迁
大家好，我是来自SAP成都研究院Revenue Cloud 团队的质量工程师 , yoyo。很高兴可以和大家分享我个人的工作体会。每个团队都有QE（Quality Engineer）, 相信大家对QE 的工作并不陌生，我也就不唠叨QE 的具体工作啦。作为从事软件质量保证工作十年的“老人”，我想就我个人的工作经历和大家探讨下软件质量保证工作的变迁。
当我们谈论软件产品的质量保证工作时，必然是基于某种软件开发模式上的。皮之不存，毛将焉附？脱离了软件开发模式，质量保证工作就是空中楼阁。相信大家都感受到，近十几年，软件开发模式不断涌现新的概念和词汇，Agile, Continuous Integration , Continuous Delivery, DevOps ，令人应接不暇。我们首先要理解软件开发模式的变迁，然后才能进行与开发模式匹配的质量保证活动。
1. 瀑布开发
传统的瀑布模式如下图：
在这种模式下，测试活动仅仅是线性开发活动的后期活动。质量保证严格依赖于各个文档（需求文档，设计文档，测试计划和测试报告）以及评审会议，自动化测试可有可无。
2.增量开发
团队把产品的需求，设计，实现以及测试放在若干迭代周期里完成，每个迭代结束的交付物视为产品的增量，不要求增量达到能交付的要求，但需要能够基本可以工作。产品的交付仍然发生在最后，如下图所示：
增量开发的核心就是持续测试和持续集成。对质量保证工作来说，分为了两类活动。 一是迭代中对增量的质量保证，二是发布前对整个产品的质量保证。由于增量和产品最终交付的要求是不一样的，所以通常在软件发布前团队要停止功能开发，进行全方位的回归测试和缺陷修复，从而保证产品质量达到交付要求。增量开发的优点很明显：
测试的计划，执行，评估不仅仅是基于每一个发布版本，而是细化到每一个迭代中。产品的质量在开发过程中进行了频繁的校验，质量的可见性更高，反馈更及时。
过程的质量更多的被考虑在了质量管理范畴中。质量管理人员深入到项目过程中，能观察到团队的整体运行情况，从一些实际质量现象和数据上反馈团队存在的问题，从而帮助团队识别风险，并相应调整开发和测试策略。
3.敏捷开发
实际上，运行的很好的增量开发已经具备了敏捷开发的雏形，它们都具有以下特点：
强调短时间的迭代
必须实现持续测试和持续集成
能响应频繁的需求变化。
那什么是敏捷开发?它的核心又是什么呢? 如下图所示，相对于“非敏捷”，敏捷开发在Continues Integration(CI)的基础上强调Continuous Delivery(CD),每个迭代的产出物要达到可交付质量要求，它的核心就是把发布（到客户的生产环境）也纳入到短时间的迭代中。
成都Revenue Cloud团队从2016年项目一开始就明确定义了这个方向，我们要一步步地实现真正的Continuous Delivery。负责Infrastructure 的德国同事们做了很多工作，搭建了支持持续交付的完整框架，包括持续集成，构建管理，配置管理，发布管理，我们称之为DWC (Dev With Confidence), 有兴趣的同事可以咨询我们组的Andy Ma和Vicky Chen 同学。
那么在这样的开发模式下，我们要怎样进行质量保证工作呢？以下是我个人的粗浅见解：
第一，团队的目标是交付。
随时随地，各种形式，各种方式，无所不用其极地强调我们的目标是交付。 当我们说某一个功能是不是完成，那一定是指这个功能是不是良好运行在产品环境（而不是本地或测试环境），并满足定义好的质量要求（功能，性能，安全性等等）。
第二，全员对质量负责，质量保证活动是日常开发活动的一部分。
当产品只有长周期，大版本的交付时，在日常工作中我们容易会把某些任务，特别是质量保证任务放到后期进行，质量债务趁虚而入。而如果实现的增量要快速交付，我们就不得不把质量保证任务融入到日常开发活动中。开发人员, QE, 产品经理以及团队的所有人都要进行相应的质量保证活动，让缺陷无处遁形。
怎样落实呢? 那就是定义我们的Quality Strategy 了， 保障每个角色(who)都清楚知道自己应该在什么时候(when)，什么环境(where)下如何进行(how)什么样(what)的质量保证活动。建议团队可以有一张图来指导大家。 这是Revenue Cloud 成都团队的质量保证活动的Overview Picture(出于安全考虑，landscape 被我打上马赛克啦)。
而Quality Strategy 绝对不是一成不变的，需求在变化，产品在变化，团队在变化，质量保证活动也应该随之变化。每运行一段时间，我们要收集反馈，无论是外部质量的反馈（比如来自产品团队的反馈，客户报告的缺陷或需求），还是内部质量的反馈，比如需求是否清晰，测试案例是否valuable, 代码质量是否足够好，自动化ROI(Return on Investment)是否可接受，等等。根据这些反馈，我们再来改进质量策略。
第三，预防缺陷
测试是一种基于后验的质量保证方法。另一个更为重要的先验方法，就是缺陷预防。也就是说在开发人员提交测试前预防缺陷的产生，包括:
在开发人员实现代码前，尽量确保需求清晰，Accept Criteria 和自测点清晰。
在产品功能实现过程中，开发人员, 产品经理, QE,UX ,UA密切沟通，确保需求，实现和测试点的正确性和全面性。大家都坐在一个办公室里面，不管是Daily Meeting还是直接面对面, 沟通是很容易的，关键在于大家有没这个意识和习惯。
在开发人员代码提交（从自己的分支提交代码到主线）前，除了通过所有的自动化回归测试，还需要按自测点来验证实现的新功能。在这点上，我们需要思考怎样帮助里开发人员更好更有效的做自测。比如，自测点Scope是否合适？是不是有些重要场景没覆盖或者场景定义太多？开发人员是否需要培养测试思维或方法？Planning时候是否没有预估自测时间？开发人员自测是否得到了产品经理/QE及时和正确的反馈？
第四，实施策略性的自动化测试
当我们的发布周期很长时，可能觉得自动化测试可有可无，作用也不是那么明显，但随着发布周期越来越短，自动化测试的重要性越来越明显。在Revenue Cloud ,我们除了季度的大版本发布，还有更短周期的feature发布，以及每天的patch发布。可以说，自动化测试是不可动摇的根本。然而实现自动化测试，必然有很多因素要考虑。谁来做？选什么工具？哪些测试被自动化？各个层面的自动化怎么组合？这个策略需要团队自己决定，尝试和改进，毕竟适合的才是最好的。但我认为有几点原则是共性的：
自动化测试绝不是QE 一个人的事情。自动化测试和功能实现一样，应该是整个团队的任务，和功能backlog一样，包括QE和开发人员在内的所有团队人员都可以领取自动化测试的任务 。测试代码也应和功能代码一样对待，要进行代码审查,以及代码维护。不要舍不得让资深的人员参与自动化测试，良好可靠的自动化测试终会让团队受益。
自动化测试的有效性比完备性更重要。如果自动化测试的“假失效”和“假通过”太高，对团队来说不仅没有帮助，反而是一种干扰。要保证测试的有效性，除了保障测试脚本实现的质量外，还有很重要的一点，不要放过自动化测试的每一个fail， 要分析清楚fail的原因，是产品实现层面的缺陷就改实现，是测试脚本的问题就改脚本，是环境问题就优化环境。如果以自动化测试不稳定为理由，不去深入分析，那它永远都不稳定，自动化测试结果也永远得不到信赖。
我们团队在刚开始做E2E(End-to-End)自动化测试时，测试总是不够稳定，但经过一段时间的结果监控，我们逐步总结并优化了遇到的一些常见问题 ：比如测试数据之间有依赖或冲突，identify UI 元素的ID不唯一，断言不准确，测试前置条件被其他自动或手动测试破坏，UI新的调整或实现导致测试失效等等。经过团队一段时间的努力，现在E2E测试的有效性大大提高了，团队所有成员都认可自动化测试的反馈。分析和优化的过程可能是痛苦的，甚至让你怀疑投入是否值得。但坚持下来，当自动化测试有效性得到保证时候，你会感受到它带给你的安全感。
多层面的自动化测试要综合考虑。自动化测试是多个层面的，在Revenue Cloud ,以功能测试为例，测试可以分为Unit Test, Integration Test, Contract Test, E2E Test。如下图所示：
我们既要避免某个层面测试薄弱，也要避免在多个层面进行重复的自动化测试。以成都团队为例，在开始的一两个release， 我们对Service Unit Test 的要求是覆盖率>80%, Service Integration Test 大致是覆盖60%的API测试用例, 然后E2E GUI Test覆盖核心业务场景, UI 的Integration Test并没有引入。后来随着项目的进行，我们发现API Integration Test 投入产出比最高。它比Unit Test 更接近service 真实行为，它比E2E GUI Test反馈更早更快，也更易实现。我们逐渐调整了策略，减少了Unit Test 的比重, 加大了Integration Test 的覆盖，目前我们API 的Integration Test 覆盖了>80%的测试用例。
再后来，随着产品功能的增加，我们发现E2E GUI 测试运行越来越慢，于是我们又再次调整了策略，一是引入是OPA5的UI Integration Test，把原来E2E GUI测试中纯UI 的逻辑完全挪到OPA5测试中,大大缩短了自动化测试的运行时间。二是减少了部分和Service Integration Test 的重复测试,使E2E GUI 测试更多的侧重于端到端完整的业务场景，而不仅仅是某个具体功能。 通过这两次调整，多层面的自动化测试能更高效的分工合作，为产品质量保驾护航。
以上三点是我认为定义自动化测试策略的重要原则。另外，我经常被问到一个问题： 你们项目采用什么自动化测试框架/工具呢? 在谈到多层面自动化测试的时候，我列出了Revenue Cloud 采用的自动化测试工具。对于Unit Test, Contract Test, Integration test 这些和技术平台/语言相关的测试，我们采用的测试工具并没有什么” 惊喜” 。Junit，Spring Contract Cloud, OPA5, Rest-Assured 都是大家耳熟能详的测试框架，在SAP 类似技术背景的项目中广泛应用着。我重点介绍下可能大家比较陌生的Nightwatch + SauceLabs 的E2E 测试方案吧。
SauceLabs 是一个云测试服务平台，在云上提供VMs运行多个测试，并提供了视频录制，截图和日志记录功能，很好地解决了多个自动化测试并行运行的设备问题。并且它支持不同浏览器，不同屏幕分辨率，可以应用到浏览器兼容性测试中。当然，这个是商业服务，申请的VM 越多，价格越贵。
Nightwatch(守夜人)，这是一个使用Selenium 2 (webdriver)实现的开源E2E 测试框架，对Selenium API 做了些封装，能更容易和简洁的实现测试脚本，但它不支持UI 操作录制。其实本质上，它和Selenium, Ranorex, Start 等工具没什么实质不同。就像江湖高手会根据自己的喜好、功夫的特点选择武器，我们也可以根据团队的技术特点和偏好，当然还有预算来选择工具。然而工具只是工具，就像决定比武结果的决定因素并不是武器一样，决定自动化实施成功的关键因素，从来不是工具，而在于我们自己的功夫修为本身。
第五, QE的角色定位。Revenue Cloud 成都团队从2016年建立，也曾经回归缺陷 比比皆是，也曾经有提交测试的功能连Smoke Test（冒烟测试）都跑不过。那段时间，QE其实很忙碌的，有各种测试要做，各种缺陷要回归测试，而且产品发版前还紧张的不行。但到现在，团队越来越成熟，质量意识越来越好，开发人员提交测试的backlog 一次通过率基本维持在80%左右。在整个项目交叉测试时候，其他组给我们提的缺陷越来越稀少，团队的交付越来越顺畅，而我作为QE， 不再淹没在基础测试中，可以有更多的时间做更有价值的事情。我也在团队的需求和帮助下，学习了自动化测试框架， 研究了SAP产品标准的Performance, Accessibility, GDPR 以及Fiori Guideline 等等，拓展了自身的技术领域。
因此，我最后特别想和大家分享的一点是QE 的角色定位。QE 不是充当警察的角色，站在大家对立面挑刺。QE也不是最后的质量安全防线，站在大家身后填坑救火。QE是和大家一起并肩战斗的战友。一方面，QE充当着质量教练，引导和帮助团队提升质量，建立成熟的质量文化。另一方面，和Agile团队的每一位成员一样，QE也需要在团队中不断学习和成长，不仅仅是加强QE技能，还要加强对业务的理解，对用户行为的认知， 甚至对具体实现技术的认识。
最后感谢大家阅读。关于SAP Revenue Cloud产品本身的更多介绍，请参考SAP官网：https://cx.sap.com/en/products/billing/revenue-cloud
更多阅读