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