SaaS产品自动化测试实例分析

　　【摘要】本文讲述某个企业级SaaS产品自动化测试项目的实践过程。文章介绍了项目遇到的挑战、应对策略和实施过程，最后总结了企业级SaaS产品给自动化测试带来的新挑战和项目的六点实践经验。

　　项目背景

　　奥博杰天中国测试团队负责一套云端人力资源管理产品的自动化测试，产品简称WHMC （Workforce Management and HCM Could Solution ）。 该产品帮助大型企业管理员工考勤、排班优化，以及缺勤等复杂业务逻辑。它的客户包含制造商、零售商、医疗机构、服务机构、交通运输和物流等全球数千家各种规模机构。由于业务复杂，WHMC被拆分成15个组件，每个组件配备10-20人的研发团队。 研发团队以项目为单位分布在美国，加拿大，印度和中国多个不同的城市。WHMC作为一套SaaS云端解决方案，支持客户按月购买服务， 同时也支持整套解决方案驻场部署在客户的机房内。该产品在研发上有以下几个特点：

　　作为企业级SaaS，产品的功能组件多、集成和测试难度大。

　　国际化特征明显，研发团队分布全球，沟通交流不便。

　　产品迭代更新快，每个研发团队都有自己的进度，测试团队无法控制研发团队的工作安排。

　　面临的挑战

　　保证自动化测试用例集可持续运行是企业级SaaS产品进行持续集成和自动化部署（CI/CD）、实现敏捷开发的核心。这一挑战由奥博杰天的测试团队来担当。我们的测试团队虽然之前做过很多国外大型项目的自动化测试，但是对测试功能点多、项目干系人分散、交付质量要求又高的企业级SaaS还是第一次碰到。用之前的项目经验去实施项目碰到了不少挑战，主要集中在以下三方面：

　　测试技术的挑战

　　自动化测试用例集分为UI 测试， API 测试， 和混合场景测试。我们使用TestNG （版本6.8.8）、Selenium （版本2.53.0） 的WebDriver、REST-Assured（版本2.9.0）作为测试框架的核心工具。开发完成的自动化测试用例上传到Git仓库进行版本管理，由Jenkins进行CI/CD。测试用例生命周期及测试结果通过惠普的ALM （Application Lifecycle Management） 进行管理。 整体测试框架如下图：

　　其中开发和执行UI测试用例有两个技术难点：

　　一、Selenium判断异步加载的网页元素是否完成和如何定位网页元素。

　　这是Selenium 的WebDriver进行UI测试的经典技术问题。WHMC的很多网页数据是通过Angular JS异步加载的，测试用例有时很难判断待检查网页元素是否装载完毕，造成超时或执行失败。例如，在计算工资的页面，我们需要等员工的工时加载完然后点击“计算”按钮来计算应付工资。由于工时的表格会动态刷新，则可能计算错误。

　　还有就是定位网页元素，我们使用XPath定位，最常使用的是网页元素的属性值定位元素实例，例如div标签的ID、 img标签的href，input标签的type等属性值。但是这些属性在新版本中可能变化，造成查询条件不稳定。

　　二、SaaS模式下的多租户测试。

　　SaaS产品不同租户能使用的功能、 API限制、和数据隔离等方式等都不完全相同，多租户测试场景有别于传统自动化测试项目。

　　产品更新快带来的挑战

　　WHMC的 15个组件都有自己的开发计划，开发团队没有及时通知到测试团队，测试团队也很难去控制这些变化。组件发生变化后，其API文档更新不及时或非常有限，很多变化的接口只有API的定义没有参数说明，测试团队在理解和修改API测试用例时遇到很大麻烦。

　　另外，因为测试框架是和测试用例开发同步进行的，测试框架发生的变化也对测试造成影响。测试框架新增了功能，意味着需要对已开发的测试用例进行更新。 频繁更新的测试框架，对发现测试用例失败的原因也带来新的不确定因素。

　　多团队跨国沟通的挑战

　　由于研发团队分散在不同的国家，项目的测试流程和沟通流程都存在不足。如图：

　　测试用例的需求沟通完全通过ALM（Application Lifecycle Management）获取。一些测试用例需求都写得比较模糊，测试团队需要花费很长时间和各组件负责人在ALM系统中来回澄清细节。

　　由于研发团队都在国外，我们很难得到关于产品的技术支持。在测试用例开发过程中，一些测试用例执行失败的原因需要技术团队确认，只能通过邮件，对方回应不及时。

　　开发完测试用例，需要需求方review并接收。需求方确认不及时造成大量已完成的测试用例停留在待提交状态不能提交到Git进行代码管理，大量积压的测试用例产生版本冲突。

　　项目从2017年1月开始启动，经过3个月的实施，上诉问题带来的结果是每次回归的通过率徘徊在40-50%；测试用例的产出效率很低，近40人的团队每天只能产出平均1个合格的自动化测试用例；因为得不到研发团队的支持和理解，测试团队士气低落，内部弥漫着失败的气息。

　　应对策略

　　测试团队意识到按照现有的流程再继续下去是行不通的，于是在4月初果断停止了所有进行中的任务，商量应对方法。 在总结了前述的各种的挑战后， 提出了如下应对策略：

　　测试框架对常见的测试难点进行封装

　　对于异步数据加载问题，我们将问题分为不同的场景，提供一个示例来描述问题的细节以及我们如何处理它的当前方式。 同时负责测试框架的小组系统地了解这些场景，并封装成标准方法，并为每个场景设置最大延迟时间，如果到时不返回期望值，则抛出异常。

　　对于Web元素定位器问题，我们列出典型的情况，并与测试框架小组和国外各组件研发团队合作，将稳定的查询条件封装成一个明确的查找方法。测试人员调用统一的方法进行测试。

　　加强配置管理

　　包括：正确使用git工具和提交流程；使用JIRA配合AML对需求进行管理；测试团队内部代码审查等。加强配置管理对于解决SaaS产品更新快这一挑战非常有效。关于配置管理业界讨论得比较多我就不详细展开，只重点强调一下对于测试数据集的配置管理。