一、 生成“伪视频”来丰富自动测试的日志系统
GUI自动测试的必要性
GUI 即 Graphical User Interface， 图形用户界面；GUI测试，顾名思义，是对图形用户界面进行测试。由于人机交互界面对于大部分应用软件产品都是必不可少的，而且软件的显示和功能也基本上是通过人机交互操作来体现和完成的，所以软件产品的GUI测试在整个产品测试中占有非常重要的地位。
GUI测试我们可以采用手工和自动化的测试方法。对于一个带有较多功能和较复杂界面的软件产品，单调繁琐的回归测试会让手工测试人员而感到十分枯燥和疲惫，进而影响了测试的准确度和效率；相反，使用自动化方式进行功能测试则会使情况大为改观：机器在进行步骤简单、较少互动的测试操作时，无论是效率还是准确度，都比手工测试更加优越。随着自动化测试功能的延伸和适应性的增强，它在GUI测试中所覆盖的工作范围，也在日趋扩大。
基于Rational Functional Tester构建自动测试框架
IBM Rational Functional Tester是由IBM推出的针对Java，.Net和Web应用程序的自动化测试工具，拥有功能强大的编辑器并支持多种脚本语言，还集成了ScriptAssure 技术、模式匹配、及数据驱动等高级特性，以增强测试脚本的灵活性。借助这一工具，测试人员可以轻松地录制或编写脚本来进行自动化测试，测试效率得到显著提高，因而受到广大功能测试人员的青睐。
Rational Functional Tester作为一款通用的功能测试工具，除了提供基本功能外，同时向广大使用者开放了一组API工具包供扩展使用（可参阅IBM Rational Functional Tester的联机帮助文档）。针对具体的被测应用软件，测试人员可以拓展、包装RFT的API，或引入其它工具，以实现必要的辅助功能。通常情况下，为了更好地执行GUI自动测试，一个基本的测试框架还需要加入以下辅助功能：测试数据的导入、测试环境的定制、测试执行日志、测试结果的生成和分析等等。
由于自动测试的运行无需人工干预，日志系统作为记录运行过程的载体，对于测试成功与否的判定、错误的跟踪与分析都有着非常重要的作用，是自动测试框架中不可或缺的组成部分。
二、 日志系统的改进
传统日志方案介绍
我们常见的日志方案简单说来就是：“出错后截图＋文本日志”。随着自动测试的运行，模拟生成的各种鼠标、键盘操作也会被记录在文本日志文件中，标明鼠标点击了某某按钮、在某文本框内输入了某些文字等等。当用户界面的表现与预期情况不一致时（通常预示着该测试用例失败，但也有可能是由于测试脚本的不完善所致），测试框架会抓下当前屏幕的内容，以图片形式保存，作为检查和回溯时的依据。
文本日志和出错后的截图可以基本反映自动测试的过程；通过截图，测试人员还可以了解到出错时的软件界面场景，对错误进行分析和纠正。如果是软件缺陷导致的，表示测试用例失败，需要及时撰写测试报告，向开发人员反馈测试结果；如果是由于测试脚本的不完善所致，测试人员还需要对自动测试脚本进行修正，避免在日后的自动测试过程中，产生不必要的错误。
传统日志方案的不足
但传统日志方案也有其明显的不足之处，主要体现在：
信息有限；
只有简单的文本和截图。
学习曲线陡峭，可用性差；
利用有限的文本日志和少量截图，测试人员需要结合以往经验来推测错误成因，可靠性不高，而且非常吃力；新手则需要经过很长时间的实践积累才能具备这一技能。
难以发现部分隐藏的错误原因；
部分错误往往是由一段时间前的操作导致，原因隐藏得较深，有一个积累的过程；出错后的截图并不能反映过程相关的信息。
改进思路
针对传统日志方案的不足之处，我们可以有的放矢，根据它的不足提出改进方案。主要思路有以下两点：
体现错误发生的过程，而不仅仅是结果；
以更简单的方式来表达出更多的信息；
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/