研发效能 多语言检测工具实践

酷家乐质量效能 · 2020年12月04日 · 最后由 Jerry li 回复于 2022年12月28日 · 6285 次阅读

一、产生背景

众所周知,酷家乐是国内首屈一指的大家居全案设计平台及生态解决方案提供商,致力于为数字化升级提供一站式的解决方案,客户多是以中文为主的公司。虽然有英文版,但是实际使用上还是会遇到很多问题:

  1. 语言问题:酷家乐以中文为主,英文版支持不够完整,且无其他语言。
  2. 部署问题:酷家乐没有全球部署, 在海外服务的加载和访问速度会受限制
  3. 模型问题,酷家乐的模型库模型受众主要是国内的,非海外本地审美。 由此诞生了海外版本--coohom。 目前 coohom 线上共支持 7 种语言,受众最大的是英语客户,并且他们也最接受不了中文的存在。coohom 的功能基本上都是从酷家乐延伸的,有些模块甚至是双发的(酷家乐发布新版,coohom 自动更新),这就导致酷家乐一旦新增或者修改某个功能,都有可能影响到 coohom,导致在线上出现中文。 因此存在以下中文的痛点:
  4. coohom 对接用户线较多,云图,定制,硬装,快搭等,这些细节问题采用人肉测试,效率太低,需要有自动化的检测工具辅助测试;
  5. 工具每周发布回归,周期短,迭代快,工作量大,上线时间紧,测试资源有限,一些细小的问题(如商品类目,名称等)不会一个个去看,因此急需一种自动化工具帮助回归检测;
  6. 由于 coohom 现在主要语言是英语,而且出问题比较多的是英语中混有中文,因此先检测英文环境下是否含有中文的问题。若检测有效,再推广到其它语言。
  7. coohom 目前没有独立的模型库/素材库,跟酷家乐使用一套数据,且模型以及素材都是运营手动添加,不会过多考虑多语言,因此时常有模型/素材未翻译的问题。

二、实现方案

多语言检测方案主要分为三个部分:爬取文案、检测文案以及文案信息展示。
第一步:文案爬取分为静态网页文案爬取和动态网页文案爬取,静态文案可以直接通过 html 获取,获取比较容易,但是动态文案就比较麻烦了,虽然在浏览器中可以看到,但是在 html 源码中却发现不了,调研选择了两种方案,分别是 “使用自动化测试工具对网页进行模拟访问” 以及 “直接 Ajax 请求,得到返回的 json 数据”,通过分析对比,采用模拟 ajax 的方法去获取动态文案。
第二步:由于前期只是检测英文中是否有中文存在,所以文案检测部分就相对简单一点,可以通过中文的 unicode 编码范围进行检测。
第三步:文案信息展示,主要是定时检测发送邮件。

三、文案爬取

3.1 静态文案爬取

前端代码直接展示的文案,包括鼠标 hover 的文案、弹窗的文案、按钮的文案可以直接通过 html 源码中的” window.PUB_LANG” 关键字获得
以工具为例,红框处的文案为静态文案

可以直接通过” window.PUB_LANG” 获取各个插件的静态文案,以 “yundesign_kaf_plugin” 为例,只需要看每个 key 对应的值是否为中文

实际的获取方法如下:

3.2 动态文案获取

目前抓取动态文案主要有三种方法:
1.使用自动化测试工具对网页进行模拟访问:
在抓取阶段,在爬虫中内置一个浏览器内核,执行 js 渲染页面后,再抓取。常用的工具为 Selenium、HtmlUnit、PhantomJs、Puppeteer 等。如下图所示,通过 webdriver 模拟登陆是可以拿到对应的文案的。

该方案需要知道控件的 xpath,模拟手工操作,由于渲染的时间无法预估,所以存在一定的效率问题,同时也不是那么稳定。好处是编写规则同静态页面一样。该方法适用于一次性或者小规模的需求。
2.直接 Ajax 请求,得到返回的 json 数据(有些数据是加密过的,需要解密):
因为 js 渲染页面的数据也是从后端拿到,而且基本上都是 AJAX 获取,所以分析 AJAX 请求,直接拿到对应的数据,也是比较可行的做法。

相对于页面样式,这种接口变化可能性更小。缺点就是要找出所有的接口,并进行模拟,是一个相对困难的过程,也需要相对多的分析经验。比较适用于长期性的、大规模的需求。
模拟访问法和 ajax 请求法各有优缺点,由于前者需要依据 xpath,根据 coohom ui 自动化的经验,各个控件的 xpath 会经常变化,需要定期去维护;而且如果要爬取整个网站,如果去整理每一步的 xpath,将会是一个很庞大的工程;
模拟 ajax 请求法虽然要整理所有的接口,但是目前已有接口整理文档 (参考 cemon 巡检),而且接口相对于 xpath 来说,不仅数量小的多,而且变化的可能性也更小,更容易维护。
因此,本次采用模拟 ajax 的方法去获取动态文案。
3.Ajax 请求法
现采用开源的工具包 selenium+browsermob-proxy 模拟浏览器访问,来自动获取接口信息。
browsermob-proxy 是基于 Java 的代理服务,它的具体流程有点类似与 Fidder 或 Charles。即开启一个端口并作为一个标准代理存在,当 HTTP 客户端(浏览器等)设置了这个代理,则抓取并有能力修改所有的请求细节并获取返回内容。调用方式如下

3.3 异常文案获取

目前异常文案是根据 unicode 编码来获取的,目前只是考虑中文,中文的编码范围是 [\u4e00-\u9fa5](不考虑中文标点之类的)
调用方法如下:

四、检测方式

目前前端主要有 3 种检测方式,分别是 URL 检测,API 检测以及回归检测

4.1 URL 检测

该检测方式主要是根据输入的 URL 爬取静态文案,使用 Ajax 请求法爬取动态接口文案,最后根据 unicode 编码抓取出匹配的异常文案(中文)并在前端展示。
适用范围:coohom SAAS 后台的所有链接,不适用于工具

4.2 API 检测

该检测方式主要是根据输入的接口爬取接口返回文案,最后根据 unicode 编码抓取出匹配的异常文案(中文)并在前端展示。
适用范围:目前只支持 GET、POST 接口,包括 coohom SAAS 后台以及工具
为了辅助定位问题,会把异常文案的接口,所在字段以及一些相关的 id 属性都会打印出来

4.3 回归检测

先预置 url 以及接口信息在数据表中,检测时根据所选的模块分别调用去爬取数据检测
saas 后台主要是 url 信息,检测方式按照 4.1,其余都是接口信息,检测方式按照 4.2,也可以选择全量检测所有,回归检测时传入的 url 和接口太多,一次性跑完需要时间较长,会导致前端超时或者一直处于 loading 状态,显示很不友好,现采用多线程 +redis 存储机制解决。

五、信息显示

第 4 节中已经包含了前端页面的展示部分,但前端页面的展示每次都需要人为去前端操作才能获取,想要有任务可以按时间每天自动去检测并且发送邮件,因此开发了定时自动检测功能。
1.coohom saas 后台自行维护,文案相关改动较小,属于可控范围
2.工具是每周集成 kujiale 的,并且运营会上新一些新的模型以及素材,会导致模型名称以及品牌等为中文的情况
基于以上,自动检测拿的是回归检测中的工具的 api 接口的部分,检测内容以及检测流程在第二部分已经具体描写了,这里主要是定时检测并发邮件
定时任务比较简单,就是基于注解@Scheduled,使用 Cron 表达式来创建定时任务。
邮件内容采用以下方式:
用 freemarker 模版来确定邮件格式

具体框架图如下:

3.邮件成品

六、小结

成果:

  1. 对于新加的页面,输入 url,一键检测中文,例如新增的快搭,定制商家后台等迁移过来的功能。
  2. 对于模型/素材数据,检测到中文,并获取相应的路径以及 id,以方便运营修改。
  3. 覆盖 saas 后台以及工具端,使用灵活,既能检测页面也能检测接口。 4.回归检测每日定时运行,无需手动执行,省时省力

展望:

  1. 由于回归检测目前接口都是手动预先填的,需要探索自动获取接口的方法。
  2. 模型/素材名称等中文问题,支持自动翻译修复,解放运营。
  3. 对 KA 客户使用语言,例如韩语,增加检测项。

想了解更多关于酷家乐技术质量的文章,欢迎关注我们的公众号

共收到 7 条回复 时间 点赞

感觉楼主这种多语言检测测试的方式还是太粗放了,或许是你们对国际化多语言的要求并不高。
我们的多语言实现要求:

  1. 每一个文案,都需要有对应语言的翻译。
  2. 切换到对应语言之后,需要所有文案都展示正确的翻译信息。

常见的问题:

  1. 部分文字没有进行翻译。
  2. 翻译匹配错误,导致文案在某些语言下的实际含义错误。
  3. 统一文案在不同翻译情况下长度是不一致的,页面可能会出现文字超出控件范围,或字体大小不一致,或文案之间存在重叠的情况。

我们怎么测试?

  1. 确保每个元素对应的文案 key 值准确。
  2. 通过自动化脚本,在不同语言下获取每个元素对应的文案是否匹配对应的翻译。并在每个页面自动截图。

如何优化?

  1. 维护一份统一的多语言翻译 Excel 表格,通过文案 key 值和对应的语言可定位到对应翻译的单元格。
  2. 要求开发使用统一的文案转换工具,从统一的翻译文档中生成不同语言的配置文件。
  3. 只要开发按规范使用文案转换工具来生成配置文件,则只需要其中一种语言全量测试通过,则代表元素的 key 值配置正确。
  4. 所有测试用例,添加对文案的检查,并使用 key 值和语言类型作为变量传人,使同一套测试脚本可在不同的语言下快速执行。
  5. 测试脚本执行完成后,增加对截图进行快速浏览,检查是否存在个别文字未正常显示的情况,如个别语言下翻译过长导致 UI 显示错乱,或是否存在重叠等情况。

海外版没有专人做功能测试吗?

徐汪成 回复

现在确实比较投入比较少,主要还是让用户自己测试为主!明年开始投入较多的资源,我们的客户是好客户,兢兢业业的为酷家乐的国际化提出各种问题

Jerry li 多语言的自动化有比较成熟的方案吗? 中提及了此贴 01月18日 07:43

比较赞同
@Jerry li 的一些观点,楼主提供的解决方案 估计并没有从根源上解决问题。多语言字符串的管理,是否可以独立出来,如同下图:

此字串需通过转换工具转换成多语言目标文件,前端网页可通过配置或接口调用这些文件中的内容,这样每增加新功能的字串可以直接修改此表,软件的前后端实现逻辑不用改变。降低测试与运维人员成本。具体实现细节@Jerry li 也有提到。

Jerry li 回复

大佬求问,我目前也是正在做类似的项目,使用的是@pytest.mark.parametrize。有一个用例,不同语言可能断言不同,我想根据网站语言自动判断来取不同的断言,我应该怎么实现?

Linkkk 回复

你要先确定测试点是什么: 语言是通过什么规则来展示的? 一般来说是分两种方式:

  1. 系统中用户设置的语言。
  2. 浏览器或者操作系统设置的语言。

无论是哪种情况,都要覆盖设置了不同语言下的展示是否正确。简单来说,就是不存在自动判断,而是有业务逻辑控制的,你要针对对应的逻辑去测试。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册