UI自动化测试与软件测试开发工程师所面临的挑战

UI自动化测试与软件测试开发工程师所面临的挑战

在前面李敏的一位软件测试开发工程师的成长体验中, 她提到了微软的自动化测试. 在软件开发流程中, 这种开发一次、自动执行的测试方法被看作测试领域的尖端技术。 在Wikipedia中对其的定义是:

“Test automation is a process of writing a computer program to do testing that would otherwise need to be done manually. Once the testing has been automated, a large number of test cases can be validated quickly. 
“Test automation can be expensive, and it is usually employed in combination with manual exploratory testing. It can be made cost-effective in the longer term though, especially in regression testing.”

    对于任何一个需要开发有持久生命力软件的组织来说, 自动化测试显得必不可少。 比如像Windows这样的产品, 通常的生命周期可以长达10年以上。 试想一下, 没有自动化测试的话, 任何一次的产品改动、升级、补丁、导致的测试成本有多大。

    之所以说自动化测试是尖端技术, 原因在于自动化测试的技术难度, 特别是UI测试自动化。 跟软件产品一样, 自动化测试程序也讲究性能、稳定性、可伸缩性等指标。 测试程序除了要实现目标程序一样的功能才能够进行结果检验以外, 测试程序还要实现额外的功能去观察目标程序的行为。比如要自动化测试 “dir C:\*.txt” 这个命令, 测试程序除了要实现跟dir一样的文件读取, 通配符展开的功能外, 还需要读取dir命令的输出结果才能够进行结果的比对。同时也要支持跟dir命令一样的灵活性和扩展性。这使得自动化测试在实现起来有可能比其测试目标的实现更加困难。而对于UI产品的自动化，实现起来就牵涉到读取GUI的图像输出（比如检查是否正确弹出了MessageBox），模拟用户的鼠标键盘输入（比如模拟用户在保存文件的时候选择正确的保存路径），同步测试产品和用户的交流等等。这些技术门槛使得自动化测试成为一把双刃剑，成败不在于是不是去做它，而是有没有能力把它做好。 接下来的介绍会让你对微软的UI测试自动化和软件测试开发工程师（Software Development Engineer in Test以下简称SDET）有更深入详细的了解。 
举一个十分具体的UI自动化的例子：

1. 启动计算器程序(calc.exe) 
2. 模拟用户进行菜单输入，从普通模式切换到科学模式 
3. 模拟用户计算(4+6/2)的阶乘 
4. 检查计算结果是否正确 

   要求: 
1. 整个流程的执行在4秒以内完成 
2. 能够适应于不同分辨率和语言 (不同语言的菜单项文字是不同的！) 
3. 能够稳定执行，若非产品本身的确有bug，该序列不允许失败 
4. 如果下一版本的calc.exe修改UI风格 (Win7中已经修改了)，或者改为WPF实现，要求现有的测试代码仅做简单修改即可继续使用 

    对于刚入职的SDET来说，其实现难度已经足够大得让其宁愿去写一个calc.exe程序本身。无论是学校的教学还是课外的研究，针对UI自动化的资料几乎是零。上诉功能和需求，需要工程师结合已知的知识和技能，研究出解决问题的最佳办法。 

    UI自动化其实是一种进程与进程之间的通信。测试程序需要跟目标程序通过某种进程通信方式来获取目标程序的信息，包括UI元素的位置，显示的文字内容，然后再模拟用户的操作比如在特定位置点击鼠标。就进程之间通信方式来说，Windows平台上有很多选择，比如管道，TCPIP，Windows消息，共享文件，RPC等等。对于UI自动化，最容易想到的解决方案是Windows消息。通过Windows消息以及跟Windows相关的API可以获取计算器窗口，菜单和按钮位置。但真正开始用Windows消息来实现UI自动化测试的时候，就会发现Windows消息的一些不足，比如Windows消息无法用于WPF程序，无法获取Excel或者IE里面的UI子元素。

    所以，除了Windows消息外，工程师还需要更深入地考虑其它技术。其间就需要研究微软内部的各种UI Test Framework，了解不同Framework的实现技术，优劣以及和测试目标的匹配程度。在进行不断的摸索，尝试，原代码分析后，工程师才会对微软平台各种技术有深入的了解，整个过程是把基础的理论知识转换为产品相关的生产力的过程。 

    UI自动化对于SDET来说有两层含义。其一，对该技术的熟悉程序决定测试工作的质量。另外，由于UI自动化涵盖的技术范围和深度，使得该技术是锻炼SDET的一个很好的平台。微软对工程师的技术技能要求不是限制在某一固定领域的，而是要求工程师锻炼能够通用的核心竞争力。比如，作为SDET，通过2年的努力，在Visual Studio的界面测试上取得了90分的成功，那么，如果该工程师愿意换一个项目做SDE(Software Development Engineer, 即软件开发工程师)的话，比如到SQL Server开发存储过程的图形化设计，他在前两年所积累的技术技能，要能够确保他在新的项目和职位上，取得同级别的90分。而UI自动化，对于锻炼这样的核心竞争力是一个非常好的平台，因为它至少包括了：

1. 精通微软通用的开发工具和技术, 比如C#, .NET Framework, 多线程。把开发技巧运用到实际的项目中。 
2. 熟悉Windows平台的系统知识,比如进程间通信, Win32消息机制。站在微软工程师的角度，通过具体的项目和代码充分了解Windows平台。 
3. 锻炼在压力环境下解决实际问题的能力, 比如深入分析COM/DCOM，研究UI Automation Framework的底层实现来解决技术上的细节问题。 
4. 熟练掌握调试技巧。UI自动化的开发过程牵涉到测试程序和目标程序，在调试的时候需要处理两者的同步问题。同时，UI自动化的稳定性是比较难解决的问题。调试一个偶尔发生的错误是一个非常有挑战性的任务。 
5. 在自动化测试的开发过程中熟悉微软的项目流程，最后，给SDET带来的不仅仅是测试技能的飞跃，同时也让工程师更加熟悉所测试的产品，更好地保证产品质量。

    当一个SDET经历了UI自动化测试，武装上了上述技能，就意味着他熟知微软平台的开发技巧，体验过程序开发过程中通常是如何犯错，如何调试，工程师在怎样的情况下容易做出错误的判断和假设，那么，他就能够很轻松地破坏别人的程序，找出漏洞。这不仅仅对测试工作来说是一个很好的起点，这样的坚实技术背景还能够让工程师学习和发展其它技能的时候事半功倍。换言之，自动化测试对微软的产品来说，是保证其可以持续成功的重要技术；对于优秀的SDET来说，是一项必不可少的重要的技能；对于刚入职的工程师来说，亲身体验和研究自动化测试，特别是UI自动化，能够让你实现学生生涯到职业生涯的转变。 
   

    在后续的文章中，我打算介绍自动化测试和手动测试的比较，看看自动化测试所达到的效果是否等同于手动测试的录制和重复。同时，也会具体介绍UI自动化测试开发的有趣细节。

原文转自：http://www.ltesting.net