另 一個例子是關于如何避免基于 WEB 軟件的 GUI 自動化測試。采用 GUI 測試工具可以通過瀏覽器操作 WEB 界面。 WEB 瀏覽器是通過 HTTP 協議與 WEB 服務器交互的，所以直接測試 HTTP 協議更為簡單。 Perl 可以直接連接 TCP/IP 端口，完成這類的自動化測試。采用高級接口技術，譬如客戶端 JAVA 或者 ActiveX 不可能利用這種方法。但是，如果在合適的環境中采用這種方式，你將發現這種方式的自動化測試比 GUI 自動化測試更加便宜更加簡單。
我曾經受雇在一家公司負責某個產品 GUI 相關的自動化測試，該產品也提供命令行接口，不過，他們已經實現了 GUI 的自動化測試。經過一段時間的研究，我發現找到圖形界面中的 BUG 并不困難，不過，用戶并不關注圖形界面，他們更喜歡使用命令行。我還發現我們還沒有針對最新的產品功能(這些功能即可通過 GUI 的方式，也可以通過命令行的方式使用)實現自動化測試。我決定推遲 GUI 自動化測試，擴展命令行測試套，測試新增的產品功能�，F在回過頭看這個決定，我沒有選擇 GUI 自動化測試是最大的成功之處，如果采用了 GUI 自動化測試所有的時間和努力都會浪費在其中。他們已經準備好做 GUI 自動化測試了，并且已經購買了一套測試工具和其他需要的東西，但我知道在開展具體的 GUI 自動化測試活動中，會遇到各種各樣的困難和障礙。
無論你需要支持圖形界面接口、命令行接口還是 API 接口，如果你盡可能早的在產品設計階段提出產品的可測試性設計需求，未來的測試工作中，你很可能成功。盡可能早的啟動自動化測試項目，提出可測試性需求，會使您走向自動化測試成功之路。
5. 具有可延續性的設計
在開篇的故事中，我們看到由于自動化工程師把注意力僅僅集中在如何使自動化運轉起來，導致測試自動化達不到預期的效果。自動化測試是一個長期的過程，為了與產品新版本的功能和其他相關修改保持一致，自動化測試需要不停的維護和擴充。自動化測試設計中考慮自動化在未來的可擴充性是很關鍵的，不過，自動化測試的完整性也是很重要的。如果自動化測試程序報告測試用例執行通過，測試人員應該相信得到的結果，測試執行的實際結果也應該是通過了。其實，有很多存在問題的測試用例表面上執行通過了，實際上卻執行失敗了，并且沒有記錄任何錯誤日志，這就是失敗的自動化。這種失敗的自動化會給整個項目帶來災難性的后果，而當測試人員構建的測試自動化采用了很糟糕的設計方案或者由于后來的修改引入了錯誤，都會導致這種失敗的測試自動化。失敗的自動化通常是由于沒有關注自動化測試的性能或者沒有充分的自動化設計導致的。
性能： 提高代碼的性能往往增加了代碼的復雜性，因此，會威脅到代碼的可靠性。很少有人關心如何對自動化本身加以測試。通過我對測試套性能的分析，很多測試套都是花費大量的時間等候產品的運行。因此，在不提高產品運行性能的前提下，無法更有效的提高自動化測試執行效率。我懷疑測試自動化工程師只是從計算機課程了解到應該關注軟件的性能，而并沒有實際的操作經驗。如果測試套的性能問題無法改變，那么應該考慮提高硬件的性能;測試套中經常會出現冗余，也可以考慮取出測試套中的冗余或者減少一個測試套中完成的測試任務，都是很好的辦法。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
