?當我們向人們介紹OneNote的自動化時，有一個問題被相當頻繁地提到，擔憂我們的自動化框架中UI層面測試偏少。

我不喜歡基于UI的自動化。我知道在市場上有許多的自動化系統都是基于UI的自動化（點擊按鈕以及類似的），甚至在我們自己的辦公室中，我們也有幾個相似功能的工具在維護。我了解這些工具的優勢，因為它們讓自動化更準確地模擬真實用戶的行為。但在這種自動化運行時，我總覺得似乎太不可靠-有可能是一個窗口突然冒出來再干擾到焦點；有一些工具自身的缺陷，會導致Windows消息丟失。你可以想像每天都有成千上萬的測試運行，自動化系統的間歇性缺陷所造成“煩人”的失敗，會使我們依賴的自動化系統不再可靠。此外，這些工具都需要考慮時間因素-可以執行測試之前，整個UI都需要重新渲染。如果測試的目的是為了驗證一些并不需要UI正常工作的場景（文件IO或同步就是和很好的例子），甚至不需要UI??。

所以我們在OneNote中大致是這么做的：

啟動OneNote

加載onmain.dll到內存中

加載我們的測試系統/工具(Loadourtestharness)

我們的測試工具通過.NET的反射加載onmain.dll，并引用方法(referencetheactions)。說得非常簡約，但只能是這種程度的討論。

現在把onmain.dll中所有的方法(theactionswithintheonmain.dll)都暴露給我們測試工具。

最后，我們可以從我們測試工具里調用我們想調用的任何方法。

換句話說，如果我想模擬用戶單擊"粗體(Bold)"按鈕，使文字變成粗體，我并不需要"粗體"按鈕是可見的。我就可以調用"粗體"按鈕事件(clickevent)，立即運行代碼。

這種方式還是有些不足。首先，任何UI測試所覆蓋的可能會丟失。例如，假設有一個缺陷-粗體按鈕一直都是不可用的。我的自動化測試將發現不了這個缺陷。第二，我必須要小心上下文。雖然我可以調用當用戶點擊粗體按鈕后運行的代碼，我需要確保在調用之前，讓光標放在一個頁面上。

但是，因為我們使用這種方式，使得我們的自動化系統變得更加可靠，與此同時當我們測試人員學習使用這套系統之后，我們得到更高的覆蓋率。