项目背景
奥博杰天中国测试团队负责一套云端人力资源管理产品的自动化测试，产品简称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产品更新快这一挑战非常有效。关于配置管理业界讨论得比较多我就不详细展开，只重点强调一下对于测试数据集的配置管理。
我们的测试数据集来源有两部分:
运行整套测试用例集之前通过工具进行初始化填充。
测试用例内自行管理的测试数据。
因为之前关于如何维护测试数据集的定义是模糊的，在运行UI测试和API测试用例时都会对这两部分数据集发生CRUD操作，造成了我们对于上述测试数据集的完整性无法保证。
针对这个情况， 我们加强了对数据集的配置管理，要求测试团队应严格遵循以下规则：
将初始化测试数据视为只读。
如果必须更改初始化测试数据，我们应该在测试用例退出之前改回原来的值。
将测试用例自己管理的数据视为例外情况，单独管理这些测试用例。
优化测试开发流程和团队沟通流程
在新的沟通流程中(如图)，我们主要做了以下改进：
和每个研发团队指定点对点的联系人，建立更紧密的联系，获得必要的技术支持。
在Git中增加Accept分支，测试用例开发完成后在测试团队内部进行review，通过后提交到Git的Accept分支，研发团队每周定期review，接收开发好的测试用例并Merge到Main分支用于生产。
实施过程
从4月开始，我们按计划进行了为期4周改变，具体的做法有：
一，加强例框架研解决疑难技术点。例如在网页上查找employee元素，如果employee元素不在屏幕内，这时定位就会报错。 开发团队使用WebDriver JavaScriptExecutor的executeScript方法进行滚屏操作，很好的解决了这一问题。现在只需要调用getEmployeeNameDiv()方法，传入employeeName，就可返回要查找的employee元素：
二，采用数据驱动测试的方法解决多租户测试需求。使用CSV来管理不同的测试数据集，只需装载一次测试数据文件，就可使用不同数据集多次执行测试用例，简化了用例开发量。例如切换租户只需要执行如下代码：
三，增派架构师参与到测试框架设计工作中，处理诸如异步数据加载等技术挑战， 同时指导测试数据管理，验证方法抽象和经验总结。
四，重新设计测试开发流程，增加架构师或业务分析师对测试用例的业务流程进行Review， 测试用例在本地的CI/CD环境进行daily run。并将新的流程对测试团队进行培训。
五，对测试人员进行技能培训，例如：Git使用，测试数据管理，与异步数据加载相关的Web元素的最佳做法，和代码审查清单等。
六，派专人出差到国外和各个组件团队面对面沟通，就产品，API以及疑难的测试需求进行了深入的沟通。指定一对一的联络人，加快沟通的响应速度。
七，针对我们之前开发的623个测试用例进行了重构。
经过上述改变，测试用例集回归通过率从4月底的50%提升到了80%。未通过的用例进行人工维护更新。大部分是系统更新引起的变化，一次性调整测试框架就能解决大部分。新的测试策略大大提高了CI/CD的可重用性，做到了SaaS产品自动化测试用例的高可用性。
总结
对于企业级SaaS来说，在自动化测试领域会有如下新挑战：
除了页面自动化测试的技术挑战，还要考虑SaaS产品多租户对测试用例设计带来的挑战。
SaaS产品迭代周期快， 对自动化用例的开发效率，用例的通过率都带来很大挑战。
企业级SaaS产品研发团队经常跨地域的特点，给处在不同地域的技术团队带来更大的沟通挑战。
奥博杰天中国测试团队在实施WHMC的自动化测试项目中得到的企业级SaaS产品最佳实践是：
基于成熟第三方测试软件开发适合产品需要的自动化测试框架，封装测试中遇到的疑难技术点，例如网页元素定位和判断异步加载成功。
采用数据驱动测试来应对多租户的挑战。
配备经验丰富的架构师参与测试框架设计，关键问题解决和经验总结。
加强配置管理，有效应对产品更新快的挑战。特别是测试数据集的管理，对于初始测试数据集保持只读;如果必须更改初始化数据，需要在用例退出时恢复原值;特殊的测试数据单独管理。
加强测试团队和技术团队的沟通，建立必要的跨团队沟通流程，得到研发团队的技术支持。
多地办公的团队有必要指定一对一联系人，肉身出差对于跨国团队沟通是最有效的办法。
