共计 5408 个字符，预计需要花费 14 分钟才能阅读完成。
在 Jerry 还在本科进行计算机理论知识学习时，我曾经把软件开发里的质量工程师 (Quality Engineer) 理解成是每天只是简单地做着运行开发人员编写好的软件，如果发现问题，通知开发人员去修改这种机械的体力活。后来进入 SAP 后，观察团队里的质量工程师每天做的事情，才知道我当初简直是很傻很天真。
我的两位同事，姚瑶和郑晓霞，之前已经就她们在 SAP 质量工程师这个岗位上工作的一些体会做了分享：
SAP 成都研究院姚瑶：软件质量保证工作的变迁
SAP 成都研究院郑晓霞：Shift Left Testing 和软件质量保证的一些思考
今天，由 Jerry 的另一位同事，Tang Minna 继续给大家带来 SAP 标准产品质量控制方面的分享。
*
大家好，我是唐敏（Minna Tang），目前是 SAP 成都研究院 C4S(Cloud for Service)团队的质量工程师。除了本职工作以外，我喜欢烹饪苏菜——少了川菜的热烈与厚重，却多了一份自然与纯真；喜欢在图书馆里拜读名人传记——看尽红尘故事之后，静静地感受时光的流逝；闲暇时也喜欢尤克里里——跟随跳动的音符，感受人生的起起落落。
今天我想基于目前 C4S 产品的现状和自身的技术背景，简单聊聊自动化这个动人心魄、让人又爱又恨的话题。
相信任何一个软件开发团队的每位成员，听到“自动化”一词，都会抱有热烈的期待。对于老板来说，这个词意味着成本的下降及更高的 ROI(Return On Investment，投资回报率)；从开发工程师的角度，自动化有助于更早地检测到代码变更对原有功能的影响；测试工程师当然是全力支持自动化的，因为省心和省力；产品经理自然也不会拒绝自动化，因为它能够带来更高效的交付和更快速的迭代。
然而，我们身边也不乏自动化实施失败的团队。2013 年在我前一家工作的公司里，我曾参与某核心系统项目的开发工作，这个业务系统从需求到完整上线共耗时一年半，核心功能的开发更是耗时大半年之久。面对如此庞大的业务测试成本和强需求，PMO(Project Manage Office)在项目开发之初就启动了自动化测试需求，然而在业务功能不稳定，产品需求、开发与测试基本属于赶工状态的情况下，与人工回归相比，自动化所带来的收益基本微乎其微。所以选择适当的自动化时机和策略，是自动化成功与否的重要因素之一。
众所周知，SAP 众多产品都在使用自研的 ABAP 进行开发。当我加入 SAP 后，我了解到这些运行在 ABAP Netweaver 之上的产品，均有完备的自动化测试。对于 ABAP 后台功能代码，主要是开发人员为核心功能编写完备的，覆盖率高的单元测试，然后用事务码 SUT 调度成后台作业定期执行，如果自动化测试执行时发现故障，会自动发邮件通知相关人员。
前台 UI 代码，无论是原生的 Fiori 应用还是 CRM Web Client UI 这种加了一层皮肤的类 Fiori 应用，都能通过 Selenium 来进行 UI 的自动化测试。
当然，SAP 成都研究院也在进行众多基于微服务架构的云产品开发，主要使用 Java 编程，那么自动化测试的实现也更加容易，Spring 系列框架里有大量成熟和流行的自动化测试套件可供使用。
从迭代发布的角度讲，C4S 产品的发布周期为一个季度一次，每个季度中有三个周期：前两个周期主要完成新功能开发，第三个周期需要团队成员既完成新功能测试，也需要回归系统原有功能。与此同时，每个季度中还有 5 次补丁的发布，每一次都需要完成原有业务的回归测试。夹在产品新特性测试和回归测试之间的，是一望无际的工作量和对高效率、高质量测试的需求。
我为所在团队负责的功能制定的自动化的策略是: 接口 + UI 自动化覆盖。也许您会问，作为一个请求的最前端，既然 UI 的测试都能覆盖了，那自动化测试为什么还需要接口的覆盖？工作量是否存在重复？从功能的角度来讲，确实有些重复。但从收益的角度来讲，对接口的自动化测试进行投入，收益远超成本。
1. 对于任意一个系统，接口的稳定性在整个系统中的重要地位不言而喻。相对于后置的 E2E（端到端）测试，接口测试能够从基础层减小变更对整个应用及下游业务调用方的影响范围。
2. 同时，接口的测试也能为 UI 自动化实施提供基础数据。
UI 自动化为了完成某个场景的测试，通常会有很多前置业务数据的依赖。这些 UI 自动化需要的测试数据如何生成? 有同事建议可以提前手工造数据。如果自动化测试的数据都要依靠手工来维护，在我看来，这个自动化不要也罢。通常，在接口测试完成之后会将已测试通过的接口封装成工具类，供后续 UI 自动化的工程化调用，这样既减少了 UI 自动化的数据依赖，对接口测试通过率也提出了更高的要求。所以一般的接口工程必须 100% 通过，才能完成触发后续 UI 自动化的作用去执行功能测试。
3. 为性能测试准备打下坚实的基础。
通常准备性能测试之前，接口测试的响应时间会成为反馈接口性能的重要依据。我们在制定接口性能的 SLA(Service-Level Agreement)时，其基本数据来源就是接口测试。而很多互联网公司，相对于端到端的响应时间，他们更注重接口的响应时间，因为接口更底层。尤其针对多层接口依赖的系统，每年 618，双 11 之前的线上大促压测，接口全链路测试必定是重中之重。
我在 C4S 推荐使用的接口测试框架为 Spring + Maven + Testng，语言为 Java，被测对象为 C4S oData 服务提供的 HTTP API。其中 Spring 框架主要负责通过注解方式完成对象注入，Maven 负责工程结构和 Jar 包管理，Testng 负责具体的测试工作。对于不熟悉 Java 的朋友来说，借助现有工具诸如 Postman 也能很好地胜任这项工作。
1. 工程结构及说明
接口主体工程以 Maven 规范工程为模板，所有的代码和相关资源文件均放置在 src/test 目录下。工程模块主要分为 4 部分：测试代码、枚举对象、工具类及相关资源文件。
测试代码：这是测试代码的主要存放目录。通常根据业务的不同，我们将每一个接口的测试案例按照业务测试和参数测试分别编写。
所谓业务测试，是指测试案例中涉及业务规则的部分。比如，某接口中存在一个 channel(渠道)字段。业务规则定义：当 channel 为 all 时，创建全渠道使用的数据；当 channel 为特定值时，创建的数据只能适用于特定的场景。则业务测试的案例有 2 个：
o Channel = all
o Channel = 特定数据
参数测试：主要测试接口参数字段是否为必填项。比如，某接口中存在一个 channel 为必填字段且必须为指定枚举类型字符串，当传入接口为 null 或 blank 或非枚举值时，框架返回 HTTP 400 参数错误，同时提示错误信息。此时参数测试案例有 3 个：
o Channel = null
o Channel =“”（blank）
o Channel =“XXXX”（XXXX 为非枚举值）
枚举对象：此部分是将业务中经常用到的固定参数使用枚举的方式列出，方便整个工程使用。见下图中 httpEnum 文件夹中的类。
工具类：包括基本工具类和业务工具类部分。业务工具类是将特定接口进行封装，方便下游接口调用使用。
资源文件：包括 Spring 相关配置，properties 文件以及参数测试中的数据来源文件等。
2. 案例编写
此处以实现 oData 的 SocialMediaActivity 接口的自动化测试为例来进行说明。
我们借用颜值大师——李晓刚老师画的图来大致了解 SociaMediaActivity 在 C4S 微信集成架构中的作用：
由上图所知，C4S 通过暴露 SocialMediaActivity 接口来方便 Agent 调用。
在 C4S 和 Social Media 集成的相关场景中，用户可以通过关注微信公众号来绑定一个特定的 BusinessPartner(以下简称 BP), 从而达到通过用户在系统中自定义的微信 Channel 来直接与 C4C 服务模块中的工作人员直接交互的目的。而 Activity 是针对指定的 BP 所进行的活动，例如创建 ticket，点赞，回复等。故而完整的业务流程如下：
获取系统 token
获取已关联的 BP 信息
创建 ticket 信息
评论 / 点赞 / 回复操作
数据清理
BeforeClass：执行获取 token 的准备工作。
BeforeMethod：创建 / 获取已关联的 BP 信息。
Test: 特定业务的测试案例。本处对 Activity 的层级和操作内容进行检查，因此有 2 个测试方法。
AfterMethod：清理已创建的 Activity。此处需要重点说明是，为避免后台错误数据对应用正常使用的影响，每一次执行都需要对增量数据进行清除处理，保持环境干净整洁。
AfterClass：清理创建的 BP 信息。
3. CI(Continuous Integration, 持续集成)
基于 Maven 工程的集成，本例中使用 Jenkins 进行示例，与此同时项目工程中需要使用 surefire-plugin(一个用来执行测试用例的 Maven 插件)来配置相关的测试案例范围。
在 pom.xml 中配置 testng.xml 文件：
testng.xml 文件内容示例：
使用 Maven 的好处再次体现，只需要简单配置即可使用：
在 Jenkins 中加入 testng report plugin 展示，然后 build 即可。
虽然我更擅长使用基于 Java 的 Selenium 这个 UI 自动化框架，也明白接口测试完成之后，对 UI 自动化的巨大帮助，但由于 C4S 在印度和美国团队内都使用现有的成型产品 SAHI，所以这里我只介绍 SAHI 在 C4S 的应用。
SAHI 是 Tyto Software 旗下的一个基于业务的 Web 应用自动化测试工具, 通过注入 JavaScript 来访问 Web 页面中的元素。相对于 Selenium 等自动化测试工具，SAHI 在动态 ID 元素查找和隐式页面等待处理等方面具有一定的优势。感兴趣的同事可前往官网进行尝试。
1. 工程结构及说明
此处以 Social 案例为例：
DD_CSV: 案例运行的的数据来源
Function_Library: 该目录中存放已封装的基本共用函数，如登录、登出、工作中心访问、表格访问等。更加细致的封装则是将页面元素抽象到 Library 中的 IDS 下，便于统一管理, 如下图:
SCRIPTS：特定的 UI 测试案例。
SUITE：测试案例运行的范围。
2. 案例编写
此处以 RUI 项目中 SingleTab 功能为例进行说明。
MultiTab 和 SingleTab 功能是指在 C4S 产品中，当用户在全屏模式下打开某一个或多个工作视图时，系统会将多个工作视图以 Tab 的形式显示在工作区中；但是当用户修改浏览器大小到一定尺寸后，工作区中将只显示活动的那个 Tab。
MultiTab 显示时，有活动与非活动 Tab 之分，同时要适配多个 Tab 的鼠标操作切换和通过功能菜单的切换。如下图所示：
SingleTab 显示：只显示当前活动的 Tab，在显示数据和形式上与 MultiTab 有差别，同时也要适配通过功能菜单的 Tab 切换。
与此同时，该特性需要测试系统在不同的主题、字体大小下此特性也能正常工作。因此测试案例的流程如下（可参考代码注释部分）：
(1) 重置相关特性：浏览器大小，主题，字体大小，视图类型，页面默认过滤器
(2) 访问特定的工作视图并显示特定数据，验证全屏模式下活动状态的 / 非活动状态的 MultiTab 的显示和 Tab 上数据的正确性
(3) 缩小浏览器大小：
验证 Tab 上数据正确性
修改系统主题，验证 SingleTab 的显示
修改字体大小，验证 SingleTab 显示
3. CI 集成
基于 Jenkins 的强大的插件功能，C4S 通过将 Jenkins 与 GTP(内部缺陷管理平台)的集成完成 CI 调度和运行。
UI 自动化的 CI 集成，使得 C4S 产品的回归测试的效率大大提升。以今年 8 月份发布的版本为例，手工回归的测试案例目前已接近 7000 个。如前文所述，诸多的测试案例在每个迭代中持续的回归测试，则是一项耗时又耗力的工程。而且这仅仅只针对回归测试所执行的案例。
从手工回归测试案例的数量不难看出，快速反馈系统功能状态机制在持续交付链中的重要性。而在对接口进行全覆盖测试之后，对 UI 自动化覆盖回归测试主流程的需求也愈加强烈。
在 C4S，我们借助 Jenkins 并行测试完成 UI 自动化，并使用邮件通知测试结果。在节省人工回归成本的同时，使得产品管理团队能够在短时间内快速、全面了解系统功能的运行情况，并给与团队成员质量的信心。与此同时，在出现模块功能失效甚至是系统宕机时，这种快速反馈链的建立为开发人员尽早尽快修复问题争取了时间，减少了后续修复的时间成本。
就目前的测试覆盖需求而言，由内到外的接口覆盖及端到端的 UI 覆盖，在满足底层稳定可靠的同时，也保证前端功能的可用性。对于 SAP 质量工程师而言，工作内容远非测试工作这一项内容，从团队成员质量意识的提升到单元测试覆盖及检查；从测试工作到团队质量反馈，都是 SAP 质量工程师在每日工作中需要去花心思琢磨的。而从团队利益着手，考虑每一项质量活动的价值和意义，对质量工程师来说是一项全局观的考验，也是一场质量与效率的平衡。
以上就是我今天关于 C4S 自动化的分享，如有疑问或进一步探讨，欢迎联系我们，感谢阅读。
相关阅读
SAP 成都研究院姚瑶：软件质量保证工作的变迁
SAP 成都研究院郑晓霞：Shift Left Testing 和软件质量保证的一些思考
要获取更多 Jerry 的原创文章，请关注公众号 ” 汪子熙 ”:
