【译】浅谈微软OneNote的自动化测试工具

当我们向人们介绍OneNote的自动化时,有一个问题被相当频繁地提到,担忧我们的自动化框架中UI层面测试偏少。

我不喜欢基于UI的自动化。我知道在市场上有许多的自动化系统都是基于UI的自动化(点击按钮以及类似的),甚至在我们自己的办公室中,我们也有几个相似功能的工具在维护。我了解这些工具的优势,因为它们让自动化更准确地模拟真实用户的行为。但在这种自动化运行时,我总觉得似乎太不可靠 - 有可能是一个窗口突然冒出来再干扰到焦点;有一些工具自身的缺陷,会导致Windows消息丢失。你可以想像每天都有成千上万的测试运行,自动化系统的间歇性缺陷所造成“烦人”的失败,会使我们依赖的自动化系统不再可靠。此外,这些工具都需要考虑时间因素 - 可以执行测试之前,整个UI都需要重新渲染。如果测试的目的是为了验证一些并不需要UI正常工作的场景(文件IO或同步就是和很好的例子),甚至不需要UI​​。

所以我们在OneNote中大致是这么做的:

  1. 启动OneNote
  2. 加载onmain.dll到内存中
  3. 加载我们的测试系统 / 工具(Load our test harness)
    1. 我们的测试工具通过.NET的反射加载onmain.dll,并引用方法(reference the actions)。说得非常简约,但只能是这种程度的讨论。
    2. 现在把onmain.dll中所有的方法(the actions within the onmain.dll)都暴露给我们测试工具。
  4. 最后,我们可以从我们测试工具里调用我们想调用的任何方法。

换句话说,如果我想模拟用户单击"粗体(Bold)"按钮,使文字变成粗体,我并不需要"粗体"按钮是可见的。我就可以调用"粗体"按钮事件(click event),立即运行代码。

这种方式还是有些不足。首先,任何UI测试所覆盖的可能会丢失。例如,假设有一个缺陷 - 粗体按钮一直都是不可用的。我的自动化测试将发现不了这个缺陷。第二,我必须要小心上下文。虽然我可以调用当用户点击粗体按钮后运行的代码,我需要确保在调用之前,让光标放在一个页面上。

但是,因为我们使用这种方式,使得我们的自动化系统变得更加可靠,与此同时当我们测试人员学习使用这套系统之后,我们得到更高的覆盖率。

一往如旧地欢迎各位的问题,意见,疑虑和批评。
John

原文地址:http://blogs.msdn.com/b/johnguin/archive/2013/09/10/a-little-about-our-ui-less-test-harness.aspx

你可能感兴趣的:(自动化测试,译,自动化测试,测试工具,自动化,test,harness,OneNote)