敏捷的 Web UI 自动化测试框架

揭示研发管理白金定律，分享那些激动人心的创新与变革，使得团队获得过多源动力与更大的推动力！

敏捷的 Web UI 自动化测试框架殷坤产品管理中心主任东软集团基础软件事业部


摘要案例简述

•敏捷的 Web UI 自动化测试框架案例背景

•敏捷需要自动化测试•艰辛的自动化测试之路

成功要素•像用户一样“测试”软件

最佳实践•用户化的测试脚本•灵活多样的断言机制•根据脚本自动生成用户化的报告

发展规划ROI 分析案例启示


案例简述—敏捷的 Web UI 自动化测试框架

案例简述

Web 开发时 UI 框架的广泛采用极大提高了开发效率和用户体验。然而 UI 框架自动生成的海量页面源码却让原本就举步维艰的 UI

自动化测试变得雪上加霜。为了有效解决常见自动化测试工具普遍存在的使用成本高、测试用例有效性低，以及对不同 Web 技术测试方案不统一等问题。我们需要提供一个测试框架，来跨越“技术”与“用户”之间的鸿沟，简化脚本及断言条件的编写和维护工作、提高对 UI 框架和业务编码规范的支持程度，从而降低成本、提升效率。

案例目标降低 Web UI 自动化测试的难度和成本，使更项目能真正实现Web UI 层面的自动化测试，从而让团队真正享受到自动化测试带来的收益：使及时全面的回归测试、稳定性测试、兼容性测试成为可能，为持续集成提供基础；便于重现（或校验）偶发性缺陷；将测试人员从日常大量的重复性工作中解放出来，可以把更多的精力投入到针对业务场景的测试设计、用户体验测试、性能测试、安全性测试等工作中。


案例背景—敏捷需要自动化测试

需求

测试

设计开发

交付…

快速原型设计尽早确认功能快速响应需求……

自动化测试用例都能在当天的版本上有效运行么？敏捷依赖自动化测试，但自动化测试本身够敏捷么？

可扩展的架构复用已有组件……

每日站会、迭代演示会快速开发工具持续集成……


案例背景—艰辛的自动化测试之路

学习成本高工具的操作使用、相关的脚本语言、测试过程的调试分析，是压在广大技术比较薄弱的测试人员身上的三座大山！

测试脚本维护困难业界的测试工具本质上还都是针对页面源码来编写（或生成）脚本的，与页面源码高度耦合、可读性差。页面的任何变化都极有可能导致测试脚本不可用，即使提供脚本录制工具，我们能做往往也是重新录制。

断言机制繁琐呆板测试脚本中的“断言”依赖手工插入。页面上蕴含大量的信息，潜在的断言对象如此之多、预期结果时常变化（甚至是动态的）、 UI 样式或 UI逻辑（比如，翻页图标灰显）也很可能出现错误。因此，“断言”可谓是测试人员的“噩梦”！

自定义扩展难度大测试是个系统的工程，自动化测试是中间的一个执行环节。与之关联的工作还有测试场景设计、测试结果分析、持续集成、版本控制、测试用例覆盖率统计、测试环境搭建，等等。自动化测试工具在扩展方面的局限性，破坏了测试管理的整体性和一致性。

业界有很多优秀的自动化测试工具，它们都有各自的优点，但也普遍存在的一些问题，让我们举步维艰……


案例背景—艰辛的自动化测试之路优秀 UI 框架 / 工具的采用大大降低了开发成本和难度……

测试脚本则要面对 UI 框架生成的海量源码……

用例回放的有效性大幅降低，自动化测试变得雪上加霜……页面 DOM结构非常复杂——所录制 / 编写脚本的复杂度变的更大、可读性变得更差；即使页面代码没有任何变化， UI 框架的升级也会导致 DOM结构的变化——脚本无效的风险变得更大；控件 ID是自动生成的，甚至可能随机变化——导致根据 ID 定位控件的策略无效；


成功要素—像用户一样“测试”软件

页面上的不稳定因素：

页面布局、页面样式、 UI 框架及版本更新……

用户只关注体验，不 Care 具体实现方案；

自动化测试人员为什么会纠结于此呢？


成功要素—像用户一样“测试”软件

用户操作时只关注页面上能“看”到的，而不用“查看页面源码”；

用户会更关注整体业务的正确性、稳定性，而不仅仅是每个孤立页面的功能正确性；

用户对页面样式、浏览器兼容性要求越来越高；

根据界面快速编写测试用例——敏捷应对需求的变化；

隔离对技术实现（ UI 框架、页面样式 /布局）的依赖——敏捷应对设计 / 开发的变化；

支持跨浏览器稳定回放——敏捷应对环境的变化；

“ 用户使用软件”与“自动化测试软件”之间目前存在一些重要差异……

如果能像用户使用软件一样进行自动化测试，我们会变得更敏捷……

敏捷的核心是响应变化，因此开发和测试都需要快速响应需求的变化；而测试额外还需要快速响应开发的变化；


实践 1— 用户化的测试脚本

当你在上述界面上进行操作时，你心里是否会默念：“账号”输入 *** 、“密码”输入 *** 、“姓名”输入 *** 、“性别”选择 *** 、“生日”输入*** 、

“国籍”选择 *** ，点击“保存”按钮。类似的，当我们日常使用各种系统时，心里还会默念：“ 展开 / 收拢”树（ Tree ）的某个节点、关闭某个 Tab 页、

数据表格（ Grid ）的下一页 / 上一页、选中数据表格（ Grid ）的某一行……

如果测试脚本就像这个样子，大家觉得怎样？


实践 1— 用户化的测试脚本基于界面上可以“看”到的内容定位对象，对象的操作按照用户习惯命名。

操作定义

对象类型

脚本示意



对象类型

操作定义

脚本示意

基于界面上可以“看”到的内容定位对象，对象的操作按照用户习惯命名。



对象类型

操作定义

脚本示意

基于界面上可以“看”到的内容定位对象，对象的操作按照用户习惯命名。



点击“业务角色列表”上的“新增”按钮

<event id="[titleButton] 业务角色列表 , 新增 " /> 输入“名称”和“描述信息”后点击“保存”

<event id="[input]名称 " name="setValue" value="TOP100 Test" /><event id="[button]保存“ />

选中“业务角色列表”中“ TOP100 Test” 对应的行<event id=“[gridRow] 业务角色列表 , TOP100 Test" name="check"/>

右侧切换到“应用菜单授权” Tab 页<event id="[tab] 应用菜单授权 "/>

展开“管理控制台”和“组织机构”树节点<event id="[treeNode] 管理控制台 " name="open"/>

<event id=“[treeNode]组织机构 " name="open"/>

选中“用户管理”树节点<event id=“[treeNode] 用户管理 " name="check"/>

点击“应用菜单授权”上的“保存”按钮<event id="[titleButton] 应用菜单授权 ,保存 "/>

结合“角色创建及授权”功能，看一下其对应的用户化测试脚本实例：


实践 2— 灵活多样的断言机制

断言对象页面信息量大，需要断言的对象多；需要在脚本中补充大量断言语句；

预期结果预期结果很可能发生变化；预期结果的值与脚本逻辑耦合度大；

断言机制未设定为断言条件的字段，如果发生错误，无法感知；UI 样式及部分 UI逻辑无法设为断言条件；

多变呆



页面控件值断言

业务逻辑断言

自定义断言

页面级 UI 断言

后台数据库断言

页面级数据断言




业务逻辑断言

自定义断言

页面级 UI 断言



在测试过程中，可以在任何位置增加断言事件，来判断页面指定控件是否存在、控件显示值是否为预期结果等。




业务逻辑断言

自定义断言

页面级 UI 断言



测试脚本按照业务流程组织并运行，如果某个步骤执行错误，则当前步骤或后续步骤会出现断言错误。

无需编写任何断言语句以及预期结果值，但测试设计要考虑业务逻辑顺序；不需要可对比的正确版本，通常适用于项目刚开发或样式做整体调整等情况；断言错误的位置不精准，可能延后；操作过程有截图备份，可以有效辅助定位准确的出错原因；鉴于回归测试的时候，通常大部分用例应该是可以通过的，

所以此类断言的投入产出比非常占优势！

测试用例在“增加”出错时可能的断言结果

增加记录 A

查询 A

修改查询结果

删除记录 A




业务逻辑断言

自定义断言

页面级 UI 断言



无需编写任何断言语句以及预期结果值；用于可提供预期正确版本的项目，在可持续构建或项目后期比较适用；能判断出样式、页面逻辑上的“非数据”类错误；对比绝对精准，导致可能存在误判，因此需要人工对差异图片进行排查；鉴于回归测试的时候，通常大部分用例应该是可以通过的，

所以此类断言的投入产出比非常占优势！

通过对比前（之前测试通过）后（后续持续发布）版本在相同测试路径和入参情况下的页面截图是否严格相同来断言结果。




业务逻辑断言

自定义断言

页面级 UI 断言



支持在用例执行过程中嵌入 SQL语句，以便从数据库中取实际结果，用于断言。




业务逻辑断言

自定义断言

页面级 UI 断言



通过提取页面 JS数据对象（或 JSON ）、获取格式化后的页面文本内容，来自动对比判断结果是否正确（无需编写断言语句）。

原始页面页面文本内容




业务逻辑断言

自定义断言

页面级 UI 断言



在测试过程中如果一些断言结果并不在前台显示，就需要自定义后台断言（操作移动设备、网络设备等），并插入到测试执行过程中。


实践 3— 根据脚本自动生成用户化的报告

传统的测试脚本

用户化测试脚本


实践 3— 根据脚本自动生成用户化的报告有效减少文档格式测试用例的维护成本，并保证用例和软件功能的及时同步。


实践 3— 根据脚本自动生成用户化的报告

传统的自动化测试报告（如上图）可读性很差，不能直观的体现整个测试过程。

用户化的测试报告（如右图），可以非常直观的充分还原整个测试过程。极大提升测试结果的分析效率，降低分析难度。


发展规划

与模型驱动开发工具结合，在模型生成实际页面的同时，生成用户化的测试脚本，并进行参数化。

在基于产品线开发模式的项目中，支持在装配软件特性的同时，装配测试用例。

与云计算资源管理工具打包，形成完整的

企业私有测试云解决方案。


案例 ROI 分析投入工作量备注

测试框架研发成本 >6 人月一次性投入，具体视功能范围而定

测试脚本语法实现 5 人天一次性投入，可复用于相同 UI 框架开发所有项目

测试脚本语法学习成本 <0.5 人天掌握基本用法，不含在用例设计方面的经验积累

覆盖基本流程的测试脚本开发工作量相对功能开发而言，几乎可以忽略不计；脚本维护、运行及结果分析总工作量降低至原来的 1/10左右，回落到可控范围；降低自动化测试专业技能要求，团队任何成员都可以完成；界面可自动化测试的时机提前，不必等到功能稳定之后，有力保障项目过程中每日构建工作的开展；断言成本降低，准确率提升，有助于发现样式瑕疵、用户体验差、内存泄露等容易被忽略的缺陷；其它附加回报提高自动化测试实施成功几率、降低文档格式测试用例维护成本、扩大用例复用范围赢得其他团队支持……

回报


案例启示

技术的发展是为了让人类生活变得越来越轻松。Web 技术发展至今已经可以让开发人员很容易的实现交互性强、展现效果绚的界面，用户也从中得到非常好的使用体验。

众所周知，“优秀的测试人员一定要有用户视角”。为什么用户感觉很易用的软件，实施自动化测试时却不能像开发时那么便捷？主要原因是“自动化测试”并没有“用户视角”。本方案的核心思想就是“像用户使用软件一样的进行自动化测试”。

www.top100summit.com


Documents

敏捷的 Web UI 自动化测试框架