浅谈SAP Cloud for Sales 自动化

在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的原创文章，请关注公众号"汪子熙":