动态模板自动化测试探索

背景

什么是动态化 ?

动态化，是指跨平台的动态模板引擎技术方案，双端可使用同一套模板渲染 UI，实现业务需求。

动态模板引擎 (后面统称GaiaX) 是阿里巴巴优酷技术团队研发的一套轻量级的纯 Native 动态化卡片跨端解决方案。

GaiaX 是为了解决多端卡片化UI组件的研发效能瓶颈问题孵化而来的 GaiaX官方介绍。

模板，是指页面 UI 的抽象，最终落地为模板文件，包含布局、样式、数据、事件。当任一客户端完整实现了对这个模板文件的解析与渲染，便可完成 UI 的绘制工作，从而实现跨端。示例:

动态化方案特点?

• 可视化工具模板搭建：
• 提供Sketch插件、模板可视化搭建Studio两个配套研发工具，通过可视化的方案快速完成模板导出、搭建、编辑等工作，同时配合扫码预览工具快速完成模板预演，以及视觉验收等工作。
• FlexBox布局：
• 基于StretchKit实现FlexBox来作为引擎的布局方式，底层采用rust语言保证了整体方案的高性能和跨平台特性。
• 跨端解决方案：
• 保证多端技术体验一致性，实现一套模板、多端渲染，全面提升研发效能 。
• 纯Native渲染，保证客户端体验：
• 保证客户端渲染成功率，通过视图拍平等优化提升页面的滚动帧率 。

为什么需要动态化?

• 开发环节降本增效，理想情况双端工作可由单端开发实现，提高需求吞吐率。
• 低代码开发平台，可支持产品或者运营,在一定指导下完成轻量级需求的开发上线。
• 上线环节节奏灵活，理想情况无需跟随客户端发版，可快速上线，降低试错成本。
• 保证双端一致的产品体验和技术实现。
• 纯 Native 渲染，保证客户端体验。
• 线上 UI 问题可动态修复，及时上线，降低影响范围。

动态化应用场景?

动态化比较合适卡片化UI组件的场景，在知乎客户端中有很多卡片形式的场景，比如: 热榜、想法、短容器。

当然，在业务使用层面还在不断的探索和挖掘。

动态化技术体系

动态模板技术体系以跨端动态化SDK为中心，通过在设计阶段、研发阶段、联调阶段降低对接、开发、调试等核心工作的技术成本，从而真正实现研发提效。

目前整个技术方案包括画眉跨平台动效解决方案、智能化设计平台 GaiaSketch、跨端模板动态化方案GaiaX、动态模板可视化少代码搭建平台 GaiaStudio 、辅助调试工具快速预览 FastPreview。

动态模板技术方案将客户端研发链路实现了串联，通过完备的工具化支撑体系，让开发者可以高效完成组件由原始设计稿到可运行代码的最短通路。

如下图，动态化分层设计架构:

动态化基础能力是 动态化中间层 + SDK能力层 + 模版管理提供的通用能力，包含功能: 下载模版、加载模版、渲染模版。

动态化提供底层基础能力 → 业务方开发业务模版 → 通过模版管理平台上传和下发模版。

如下图，动态化分层设计架构:

质量保障方案

首先从项目测试流程中，我们期望是可以有一个完备、明确的流程，需要同产品、研发达成共识。

整体测试流程包含:

备注: 标红处需要特别关注

• 申请测试资源
• 涉及到 动态化底层能力改动 的需求务必项目启动前周知 QA ，需要走走产研需求。
• 需求KO：
• 如果是是纯技术改动，可把需求KO和技术KO合二为一，务必技术文档写的清晰易懂。
• 邀请评审：
• 邀请相关 QA 参加需求评审和所有技术 RFC 评审，涉及改动的范围: 务必具体详细到页面功能页面基本和功能入口等，避免无效全量回归测试。
• 制定计划：
• 制定测试计划，明确排期、测试范围、测试数据、测试环境、测试方法等。测试范围划分依据各业务模块职责。
• 设计用例：
• 整体负责测试用例设计和评审，协调各 QA 团队完成各自模块的用例设计和评审，输出冒烟测试用例交付给研发团队，需要研发提测前完成自测用例，如果冒烟不通过则打会需求。
• 同步进度：
• 定期和相关 QA 同步开发进度，若提测有延期风险，需要及时反馈给相关事业部的 QA Leader，并重新确定排期。
• 反馈问题：
• 测试过程中任何资源短缺问题，及时找业务线 QA 负责人沟通，如无法解决，及时与自己的 QA Leader 反馈，需要研发老师在提出问题后尽快修复。
• 发布报告：
• 测试完成后，汇总测试数据并发布测试报告。
• 总结复盘：
• 推动各业务团队总结复盘。
• 整理用例：
• 整理回归测试用例，并明确后续版本负责回归相应功能的 QA 团队。

自动化测试方案

从动态化的架构分层，主要可以分为三层:

• 业务层: 比如: 短容器。
• 中间层: 给业务层提供模版，和模块服务交互模块数据。
• 模块管理: 下载、加载模版。

在实际工作中，在动态化中间层和底层SDK如果有升级或者代码变更，需要在 业务层看测试效果，比如: 短容器和热榜，但是这样测试在实际中有几点问题:

• 底层能力升级需要遍历所有的业务场景测试
• 业务场景需要配置白名单及需要了解业务
• 大量的功能回归测试
• 后端服务改动无法被测试到
• 模版层表达式如何测试

基于上面的测试痛点，我们希望在动态化业务中引入自动化测试手段，可以主要划分为三种自动化测试手段:

• 服务层: 通过接口自动化测试，可以保障接口层流程、字段的正确性。
• 中间层: 通过Debug UI 实现 UI层自动化测试，保障中间层UI布局、标题、文案的效果质量。
• 模版层: 通过单元测试的方法，保障表达式测试质量。

UI自动化测试

目的是对于中间层和底层SDK可以进行基于Debug UI页面进行定向测试，对于Debug UI的目的是:

在动态化落地不同业务场景的过程中，研发和测试同学对于开发和测试动态化模板基础能力的要求越来越强烈，

为了完善客户端动态化项目的生态建设，所以提出本次需求，后续给研发和测试提供便捷的 debug 页面方便开发和测试模板。

• 对外：支持业务方动态化能力需求落地，降低业务方研发成本，减少动态化落地阻力。
• 对内：完善动态化能力生态，降低研发和测试同学的使用成本，不依赖业务场景能够进行动态化基础能力的开发和测试。

Debug UI是实现效果如下: 可以使用MR包和集成包跳转到调试中心查看。

单条页面的展示效果如下，这个页面是基于热榜渲染的卡片，如果卡片渲染成功(图片、文字、布局等)，说明动态化底层渲染能力正常。

测试方法 & 方案设计

单条数据测试重点

• 卡片正常加载
• 卡片可点击跳转

多条数据测试重点

• 卡片正常加载
• 列表卡片可滑动
• 卡片可点击跳转

测试流程如下:

上述方案会基于UI自动化脚本实现，并把每次执行的测试结果上传的测试平台中存档，包含: 测试步骤、测试截图、图片对比截图

图片Diff(相似度)测试

1)、相关概念:

图片diff主要解决本次测试的图片和基线测试图片的相似度，如果下发数据一样的话，两者的相似度应该在100%

图片相似度对比有两种方式：

1、第一种: 直观的像素差异比对

就是对两个图片进行灰度差值，这种比较适用于两个图片很接近，甚至源自同一张图片，只是做了部分修整的情况，这样可以比较出具体修改了哪部分。

2、第二种: 使用专业算法来评估两个图片的相似度

这种经常应用于各大网站进行图片搜索等功能，个人直接接触这类算法的机会较少，而且如果只是计算出两个图片的相似度值，对普通用户应用场景有限。

专业算法原理包括两种：

一部分算法是定义一个相似性评估指标，该值计算出来的大小代表了相似度的大小。过程大致包括：尺寸处理、灰度化处理、计算像素均值、哈希值计算、距离计算/结构相似性计算。

还有一类是基于神经网络算法的计算方法，需要训练样本来进行学习，模拟人类在学习识别物体的过程，经过不断的学习、反馈，最终形成对特定图片相似度识别的网络。

如何对比图片的相似度

对比选用和 基线图片 对比的方式，因为每个机器的屏幕尺寸不太一样会有影响因素，可以在项目工程中内置每个设备的 基线图片。

执行策略

在 jenkins 创建任务定时任务，每周集成测试阶段执行。

点击 Alluer Report 可以查看报告报告中包含本次执行截图和基线图表，测试结果会发送到企业微信。

表达式自动化测试

Android 端的单测仅仅针对表达式解析逻辑，不会涉及到 ZHGaiaX SDK 其他的逻辑。Android 端单测基于 AndroidTest 环境，依赖 Android 平台，目前测试用例使用 Kotlin 编写。

iOS 端的单测覆盖面比较广一些，不仅有仅仅测试表达式解析逻辑的单测，也有 ZHGaiaX SDK 其他逻辑的测试，比如模版加载、解析、view 创建等等。

iOS单元测试流程:

• 使用 Xcode 打开 GaiaX/GaiaXiOS/GaiaXiOS.xcworkspace 工程
• 选择 Scheme：GaiaXiOSTests，然后长按运行按钮选择 「Test」，单测就可以跑起来

• 修改或增加测试用例：修在 GaiaX/GaiaXiOS/GaiaXiOSTests/TestCase 下的文件
• 表达式解析的测试：GXExpressionTest.mm
• 加载模版的测试：GXTemplateTest.mm
• 渲染引擎相关接口的测试：GXEgnineTest.mm
• 查看单测覆盖率
• 配置选项

• 运行测试并查看覆盖率

接入自动化测试流程:

自动化测试的目的是能在代码变更的时候自动化触发测试，更早的发现问题。所以，我们把上面的人工测试进阶成自动化测试。

自动化测试主要依托了Jenkins服务及第三方插件来完成全链路自动化测试。

Jenkins

• Jenkins 是开源 CI&CD 软件领导者，提供超过1000个插件来支持构建、部署、自动化， 满足任何项目的需要。
• Jenkins 支持各种运行方式，可通过系统包、Docker 或者通过一个独立的 Java 程序。
• Jenkins 依赖 Java 环境，需要安装 jdk 相关。

slather

slather是为 Xcode 项目生成测试覆盖率报告并将其挂接到 CI的一个工具。

slather地址: https://github.com/SlatherOrg/slather

安装方式:

sudo gem install slather           

命令中使用方式:

slather coverage -s --scheme YourXcodeSchemeName path/to/project.xcodeproj           

ocunit2junit

OCUnit2JUnit是将OCUnit或Kiwi的输出转换为JUnit使用的格式的脚本。主要目的是能够解析基于Java的构建服务器（如Jenkins）上的Objective-C（OCUnit）测试用例的输出。

github地址：https://github.com/ciryon/OCUnit2JUnit/

安装方法：

sudo gem install ocunit2junit           

HTML Publisher

HTML Publisher 插件可用于将构建生成的 HTML 报告发布到作业和构建页面。它旨在与 Freestyle 项目以及 Jenkins Pipeline 一起使用。

可以在本地Jenkins的插件管理 ，安装路径：Jenkins -- 系统管理 -- 插件管理 ，搜索 HTMLPublisher 直接安装。

集成到 Jenkins 中

1、新建job，这里取名ios_unit_test，注意这个job的名字不要重复。

2、在源码管理中配置 gitlab 的地址和代码分支。

3、增加构建步骤，选择 Execute shell 脚本

配置脚本如下：

#!/usr/bin/env bash
 
source ~/.bash_profile
 
#pod可能失败的全局参数设置
 
export LANG=en_US.UTF-8
export LANGUAGE=en_US.UTF-8
export LC_ALL=en_US.UTF-8
 
pod install
 
xcodebuild test -workspace xxxx.xcworkspace -scheme xxxxiOSTests -destination 'platform=iOS Simulator,name=iPhone 11 Pro' -enableCodeCoverage YES 2>&1 | ocunit2junit
 
# 清除上次运行生成的文件
 
rm -rf html
 
# 可视化查看覆盖率
# --html：创建 html 静态页面，并默认创建 html 文件夹；可以通过 --output-directory 指定存放路径
# --show：打开浏览器展示 html 的内容
 
# 创建 xml 报告，默认 xml 报告保存在当前目录 test-reports 文件夹
 
slather coverage --scheme xxxxiOSTests --workspace GaiaXiOS.xcworkspace xxxxiOS.xcodeproj
 
# 创建 html 报告，默认 html 报告保存路径为前目录 html 文件夹
 
slather coverage --html --scheme xxxxiOSTests --workspace xxxxiOS.xcworkspace xxxxiOS.xcodeproj           

项目包含 xcworkspace 要指定 -workspace UnitTest.xcworkspace。 -scheme 为当前测试的 scheme，如果不知道，可以在xcworkspace 目录下执行命令 xcodebuild -list ，可以看到所有的 scheme。

slather 默认生成为 xml 报告，在当前目录的 test-reports 文件夹中。slather 添加了 --html 后会生成 html 报告，在当前目录的 html 文件夹中。

4、配置构建后操作

在构建后操作的的地方配置测试报告展示，可以通过 Jenkins 地址看到覆盖率报告结果。

HTML directory to archive是测试报告存储的文件路径，Index page 是测试报告名称。

执行完成后，点击 HTMLReport 查看测试报告。

如下单次执行的覆盖率报告。

总结

以上就是动态模板自动化测试探索是实践心得，可以看出在新技术及新框架诞生以后，都是对测试工程师的一次质量保障挑战。

如何让测试效率更高效、测试质量更可靠，这是对测试工程师的职责所在。可以在项目中适度引入自动化手段，它可以提高测试效率、减少测试成本、增强测试可靠性和一致性。

当然，自动化测试不是万能的。它不适用于所有测试场景。有些测试任务需要手动测试，因为需要人的判断和感性经验。

自动化测试需要投入一定的时间金，包括测试工具购买和培训、测试脚本编写和维护以及测试执行和监控。但是，投资在自动化测试上是值得的，因为它会为项目带来优势和回报。

作者:信希

出处:https://zhuanlan.zhihu.com/p/612566879