在 GUI 自动化测试系列的文章中，我围绕着 GUI 自动化测试进行了各种讨论：从最原始的 GUI 测试谈起，逐渐引入了脚本与数据的解耦，并谈论了页面对象模型，以及在此基础上的业务流程模型，接着分享了一些 GUI 自动化测试过程中的新技术，最后和你讨论了 GUI 自动化测试的稳定性问题。

今天，我会再和你聊聊 GUI 自动化测试过程中另外一个很实用的部分：GUI 自动化测试报告。

GUI 测试报告是 GUI 自动化测试的重要组成部分，当有任何的测试用例执行失败时，我们首先就会去分析测试报告，希望从中看到测试用例到底是在哪一步出错了，错误发生时被测系统是在哪个页面上，并且前序步骤又是哪些页面等等。

早期的基于视频的 GUI 测试报告

为了分析测试用例的执行过程与结果，早期就出现了基于视频的 GUI 测试报告。也就是说，GUI 自动化测试框架会对测试执行整个过程进行屏幕录像并生成视频。

这种基于视频的测试报告可以提供清晰的 GUI 测试执行上下文，看起来也很不错。但是，这种方式主要的问题是：

  1. 报告的体积通常都比较大，小的几 MB，大的上百 MB，这对测试报告的管理和实时传输非常不利。
  2. 分析测试报告时，往往需要结合测试用例以及服务端的日志信息，视频报告这一点上也有所欠缺。

所以，理想中的 GUI 测试报告应该是由一系列按时间顺序排列的屏幕截图组成，并且这些截图上可以高亮显示所操作的元素，同时按照执行顺序配有相关操作步骤的详细描述。

但是，早期的商业 GUI 自动化测试软件也只是具备最基本的顺序截图，并不具备高亮所操作元素的功能，后来商用工具厂商根据用户的实际使用反馈，逐渐完善和改进。

目前，商业的 GUI 自动化测试软件，比如使用最为广泛的 UFT（就是以前的 QTP），已经自带了截图以及高亮显示操作元素功能。也就是说，使用 UFT 执行一个 GUI 自动化测试用例，你无需做任何额外的工作，就能得到一份比较理想的 GUI 测试报告。

开源 GUI 测试框架的测试报告实现思路

但是，如果你使用的是开源软件，比如 Selenium WebDriver，那就需要自己去实现截图以及高亮显示操作元素的功能。实现的思路通常是：

利用 Selenium WebDriver 的 screenshot 函数在一些特定的时机（比如，页面发生跳转时，在页面上操作某个控件时，或者是测试失败时，等等）完成界面截图功能。

具体到代码实现，通常有两种方式：

  1. 扩展 Selenium 原本的操作函数；
  2. 在相关的 Hook 操作中调用 screenshot 函数。

下面，我会分别针对这两个实现方式，给出具体的示例，帮你理解并实现这个功能。

第一，扩展 Selenium 原本的操作函数实现截图以及高亮显示操作元素的功能

既然 Selenium 原生的 click 操作函数并不具备截图以及高亮显示操作元素的功能，那我们就来实现一个自己 click 函数。

当自己实现的 click 函数被调用时：

  • 首先，用 Javascript 代码高亮显示被操作的元素，高亮的实现方式就是利用 JavaScript 在对象的边框上渲染一个 5-8 个像素的边缘；
  • 然后，调用 screenshot 函数完成点击前的截图；
  • 最后，调用 Selenium 原生的 click 函数完成真正的点击操作。

那么，以后凡是需要调用 click 函数时，都直接调用这个自己封装的 click 函数，直接得到高亮了被操作对象的界面截图。

如图 1 所示，就是用这种方式产生的界面截图，图中依次显示了登录过程中每一个操作的控件，第一张高亮了“Username”的输入框，因为自动化代码会在“Username”框中输入用户名；第二张高亮了“Password”的输入框，因为自动化代码会在“Password”框中输入密码；第三张高亮了”Sign in“按钮，因为自动化代码会去点击这个按钮。

图 1 GUI 界面的时间顺序截图示例

第二，在相关的 Hook 操作中调用 screenshot 函数实现截图以及高亮显示操作元素的功能

其实使用 Hook 的方法比较简单和直观，但是你首先要理解什么是 Hook。

Hook 中文的意思是“钩子”，直接通过定义介绍什么是“钩子”会有些难以理解，那么我就通过一个实例来跟你解释一下。

当执行某个函数 F 时，系统会在执行函数 F 前先隐式执行一个空实现的函数，那么当你需要做一些扩展或者拦截时，就可以在这个空实现的函数中加入自定义的操作了。那么这个空实现的函数就是所谓的 Hook 函数。

这样的例子有很多，比如 Java 的 main 函数，系统在执行 main 函数之前会先在后台隐式执行 premain 函数；JUnit 和 TestNG，都有所谓的 BeforeTest 和 AfterTest 方法，这些都是可以在特定步骤的前后插入自定义操作的接口。

说到这里，你可能已经知道要怎么做了：我可以在这些 Hook 函数中添加截图、元素高亮，以及额外的任意操作，比如更多的详细日志输出等等。

另外，我在前面的文章中分享了基于业务流程的脚本封装，你可以再思考一下，如何在 GUI 报告中体现出业务流程的概念，这样的测试报告会具有更好的可读性。

比如，图 2 所示的 GUI 测试报告就显示了具体的 Flow 名称。这个功能，就是通过 Hook 函数实现的。

具体的实现逻辑也比较简单的，就是在 Flow 开始的第一个 Hook 函数中调用增加报告页的函数，并在这个新增的报告页中输出 Flow 的名字。

图 2 在 GUI 测试报告中体现业务流程

上面所讲的 GUI 测试报告都是针对一个国家的，当面对多个国家站点的 GUI 测试时，事情就会变得更加复杂，你就必须去考虑全球化 GUI 测试报告应该如何设计。

全球化 GUI 测试报告的创新设计

所谓全球化测试是指，同一个业务在全球各个国家都有自己网站。比如，一些大型全球化电商企业在很多国家都有自己的站点，那么对这些站点的测试除了要关注基本的功能，以及各个国家特有的功能外，还要去验证界面布局以及翻译在上下文环境中是否合适。

早期的做法是，雇佣当地的测试工程师，由他们手工执行主要的业务场景测试，并验证相关的页面布局，以及翻译内容与上下文中的匹配度。在当地专门雇佣的这些测试工程师，被称为 LQA。

显然，聘请 LQA 的效率非常低，主要原因是：全部测试工作都由 LQA 在项目后期手工执行，执行前还需要对他们进行业务培训；同时，我们需要准备非常详尽的测试用例文档，LQA 也要花很大的精力去截图并完成最终的测试报告。

为了解决这种低效的模式，最好的解决方法就是：利用 GUI 自动化测试工具生成完整的测试执行过程的截图。这样，LQA 就不再需要去手工执行测试用例了，而是直接分析测试报告中业务操作过程中 GUI 界面截图就可以了，然后发现页面布局问题或者是不恰当的翻译问题。

这个方案看起来已经比较完美了，LQA 的工作重点也更清晰了，但这并不是最优的方案。因为这些 LQA 在实际工作中，还会有以下三个比较痛苦的地方：

  1. 需要经常在多个国家的测试报告之间来回切换去比较页面布局；
  2. 需要频繁切换到美国网站（也就是主站）的报告，去比较翻译内容与上下文的匹配度；
  3. 发现缺陷后，还是需要从 GUI 测试报告中复制截图，并用图像软件标注有问题的点，然后才能打开缺陷管理系统递交缺陷报告。

为了解决这三个问题，我建议你建立以下形式的测试报告。这里有一张图片展示了一份包含多国语言比较报告的示例，听音频的用户可以点击文稿查看如图 3 所示。

图 3 多国语言比较报告

报告的横向，是一个国家的业务测试顺序截图，比如图中第一行是英国网站的登录业务流程顺序截图，第二行是德国网站的登录业务流程顺序截图。报告的纵向，展示的自然就是同一界面在不同国家的形式了。

整个报告可以用键盘上下左右依次移动。可想而知，这样的 GUI 测试报告设计一定可以大幅提高 LQA 的效率。

同时，由于这个 GUI 测试报告是基于 Web 展现的，所以我们可以在测试报告中直接提供递交缺陷的按钮，一旦发现问题直接递交缺陷，同时还可以把相关截图一起直接递交到缺陷管理系统，这将更大程度地提高整体效率。

那么，怎么才能在技术上实现测试报告和缺陷管理系统的交互呢？其实，现今的缺陷管理系统往往都有对外暴露 API 接口，我们完全可以利用这些 API 接口来实现自己的缺陷递交逻辑。

这种测试报告的形式就是 eBay 在全球化站点测试中采用的方案，目前已经取得了很好地效果，降低了工作量的同时，还大幅度提高了全球化测试的质量。

总结

好了，希望上面的测试报告设计方法可以让你有眼前一亮的感觉。接下来，我总结一下今天的主要知识点。

早期基于视频的 GUI 测试报告由于体积较大，而且不能比较方便地和日志适配，所以并不是最好的解决方案。理想的 GUI 测试报告应该是由一系列按时间顺序的屏幕截图组成，并且可以在这些截图上高亮你所操作的元素，同时按照执行时序配有相关操作步骤的详细描述。

商业 GUI 自动化测试框架的 GUI 测试报告已经做得非常成熟，通常不需要做额外的定制或者开发。但是开源 GUI 自动化测试框架的 GUI 测试报告往往需要自己来开发，主要使用了扩展 Selenium 原本的操作函数的方式以及 Hook 函数来实现。

最后，我介绍了 eBay 面对全球化测试过程中 GUI 测试报告的创新设计，希望你也可以借鉴这种方法。

思考题

如果自己去开发 GUI 测试报告的功能，你还能想到其他更多实用的功能吗？你又是如何实现这些功能的？

欢迎你给我留言。