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

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

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

这使得自动化测试在实现起来有可能比其测试目标的实现更加困难。而对于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自动化的资料几乎是零。上诉功能和需求，需要工程师结合已知的知识和技能，研究出解决问题的最佳办法。

所以，除了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自动化，能够让你实现学生生涯到职业生涯的转变。