企业级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产品更新快这一挑战非常有效。关于配置管理业界讨论得比较多我就不详细展开,只重点强调一下对于测试数据集的配置管理。

我们的测试数据集来源有两部分:

运行整套测试用例集之前通过工具进行初始化填充。

测试用例内自行管理的测试数据。

因为之前关于如何维护测试数据集的定义是模糊的,在运行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产品最佳实践是:

基于成熟第三方测试软件开发适合产品需要的自动化测试框架,封装测试中遇到的疑难技术点,例如网页元素定位和判断异步加载成功。

采用数据驱动测试来应对多租户的挑战。

配备经验丰富的架构师参与测试框架设计,关键问题解决和经验总结。

加强配置管理,有效应对产品更新快的挑战。特别是测试数据集的管理,对于初始测试数据集保持只读;如果必须更改初始化数据,需要在用例退出时恢复原值;特殊的测试数据单独管理。

加强测试团队和技术团队的沟通,建立必要的跨团队沟通流程,得到研发团队的技术支持。

多地办公的团队有必要指定一对一联系人,肉身出差对于跨国团队沟通是最有效的办法。   

本文作者:李祎

来源:51CTO

时间: 2017-10-02

企业级SaaS产品自动化测试实践的相关文章

DockOne微信分享(七十九):基于容器技术构建企业级PaaS云平台实践

本文讲的是DockOne微信分享(七十九):基于容器技术构建企业级PaaS云平台实践[编者的话]企业级容器化PaaS平台旨在为企业应用提供底层支撑能力,覆盖应用开发.应用交付.上线运维等环节,包括代码的管理.持续集成.自动化测试.交付物管理.应用托管.中间件服务.自动化运维.监控报警.日志处理等,本次分享主要介绍基于容器技术构建PaaS平台所采用的相关技术.涉及的核心功能模块以及相关方案. 为满足以上需求,MoPaaS企业版基于Cloud Foundry及Kubernetes等开源技术框架和智能

资本寒冬和流量红利穷尽的大环境下,SaaS产品将何去何从?

中国云计算产业最具影响力的盛会之一--2016杭州云栖大会(https://yunqi.aliyun.com/)将在云栖小镇召开.连续举办七届的云栖大会一直是业界了解阿里云计算生态发展和应用趋势.体验前沿技术和产品的最佳平台,来自海内外的上万名开发者.创业者聚集于此,分享着他们对云计算的思考与实践经验.7年来,从产品发布到行业解决方案展示,从关注技术到技术与服务并重,从单一的客户到生态全景的展现,大会的核心内容一直在"进化",而2016年杭州云栖大会,则以"飞天・进化&quo

从0到1搭建SaaS产品运营体系

从0到1搭建SaaS产品运营体系 责任编辑:editor005 作者:GrowingIO |  2016-09-20 15:11:13 本文摘自:36kr   本文作者:揭发,GrowingIO 业务增长负责人.揭发曾任职 Cisco, Criteo 等公司,具有丰富的 SaaS .电商.在线旅游行业数据分析和解决方案经验.原文发于GrowingIO技术博客和公众号,授权36氪转载. 如果说2015年是SaaS的元年,那么2016年就是SaaS的爆发年!经过了一年多的爆发式发展,处在风口的Saa

DockOne微信分享(一一八):容器技术在企业级服务里的实践

本文讲的是DockOne微信分享(一一八):容器技术在企业级服务里的实践[编者的话]邻盛在做面向中小微企业做服务的时候, 实际遇到很多情况, 比如对方IT基础过于薄弱, 比如基础设施过于简陋, 比如产品要解决行业需求, 企业个性需求等等,经过几年积累目前摸索出了一套完整的产品方案.目前产品是以容器为核心的一套完整的PaaS平台+全新的微服务架构+底层能力构成的完整解决方案, 目前也进入到了几家传统大型制造企业协助他们完成新一代的信息升级. [深圳站|3天烧脑式Kubernetes训练营]培训内容

263企业通信:做企业级SaaS行业最专注的服务者

随着互联网+的深入发展,企业纷纷加快信息化建设的步伐,传统的办公模式及沟通方式已难以适应互联网时代企业内部高效率.多维度.多交叉的沟通需求,云通信的到来堪称通信困局下企业的福音.据iResearch数据显示,去年中国企业云服务市场规模超500亿元,今年全球SaaS市场预计增速将超过20%,在未来几年仍将保持约30%的年复合增长率. 263企业通信作为国内企业SaaS的龙头.领先的企业通信协作服务提供商,多年来深耕企业通信服务领域,在产品.研发.运营上形成了企业邮箱.企业网盘.电话会议.网络会议.

自动化测试实践经验和教训

序言:在部门做自动化有好一段时间了,经历了自动化从无到有,然后到框架,到现在的平台,以及持续集成,回顾发现由于自己之前经验太浅,走过的弯路太多,现在也还在谨慎的前进着,上次又回顾了一遍"软件测试经验和教训"里的自动化测试章节,发现早前很多懵懂的经验,现在稍稍清晰,于是想着结合自己的历程精简出一些经验吧.现在经验还是尚浅,如果有更深认识的朋友,互相讨论,谢谢 一.所谓自动化是为了软件发布服务的,并不只是为了测试服务 来源:自动化测试目标建设 以前一直怀疑自动化测试的用处,我们之前花费大力

在中国做了三年企业级 SaaS 的几点心得

随着消费类互联网市场(To C)的格局渐定,越来越多的创业者和资本将目光投向了企业级(To B),"风口猪论" 又起.有人大胆预测:2015年 将是企业级互联网服务的 "元年",未来几年内,国内企业级领域或迎来大发展的黄金岁月.摸准了,会诞生一批超过 10 亿美金的高价值公司. 从用户的接受度上看,确实可以称之为 "元年".但瞄准这个市场的先知先觉先行者却大有人在.从 2012年 起,就有一大批企业服务平台涌现,虽然亮出的旗号不尽相同,目标都是一

企业级SaaS与消费级SaaS有何区别

SaaS在企业级市场中举足轻重,但SaaS是否能在消费级服务领域取得成功? 新SaaS公司出现的速度正在放缓,但SaaS这种商业模式依然炙手可热.交付应用程序仍然是软件公司赚钱的首选方式. 在用户流失率可以接受,并且有稳定新客户来源的情况下,随着时间的推移,SaaS公司多半比采用传统模式销售的公司能够获得更多的收入与利润.企业级客户也对这种模式接受度越来越高,这就导致估值最高的SaaS公司们全都把目标放在扩大规模上. 虽然SaaS在企业用户中越来越流行,在消费级用户中是否也会出现类似的趋势?随着

企业级SaaS市场暗流涌动 风口之上谁能问鼎2016

40亿元,这是中国SaaS市场在2015年交出的融资成绩单.在过去的一年中,这个领域发生了近百起融资事件,SaaS也成为中国资本市场的当红炸子鸡. 据易观报告显示,2015年国内企业级SaaS市场规模将达到199.3亿元人民币,增长率高达69.7%,在企业高效运营管理需求.移动互联网应用条件不断成熟等多方因素推动下,市场规模仍将保持高速增长,预计2016年市场规模将超过300亿元人民币,. 业内人士表示,随着移动互联网.大数据.云计算等应用场景的成熟,企业级服务市场需求正不断增加,而2C市场上资