另一個(gè)例子是關(guān)于如何避免基于 WEB 軟件的 GUI 自動(dòng)化測試。采用 GUI 測試工具可以通過(guò)瀏覽器操作 WEB 界面。 WEB 瀏覽器是通過(guò) HTTP 協(xié)議與 WEB 服務(wù)器交互的，所以直接測試 HTTP 協(xié)議更為簡(jiǎn)單。 Perl 可以直接連接 TCP/IP 端口，完成這類(lèi)的自動(dòng)化測試。采用高級接口技術(shù)，譬如客戶(hù)端 JAVA 或者 ActiveX 不可能利用這種方法。但是，如果在合適的環(huán)境中采用這種方式，你將發(fā)現這種方式的自動(dòng)化測試比 GUI 自動(dòng)化測試更加便宜更加簡(jiǎn)單。
我曾經(jīng)受雇在一家公司負責某個(gè)產(chǎn)品 GUI 相關(guān)的自動(dòng)化測試，該產(chǎn)品也提供命令行接口，不過(guò)，他們已經(jīng)實(shí)現了 GUI 的自動(dòng)化測試。經(jīng)過(guò)一段時(shí)間的研究，我發(fā)現找到圖形界面中的 BUG 并不困難，不過(guò)，用戶(hù)并不關(guān)注圖形界面，他們更喜歡使用命令行。我還發(fā)現我們還沒(méi)有針對最新的產(chǎn)品功能(這些功能即可通過(guò) GUI 的方式，也可以通過(guò)命令行的方式使用)實(shí)現自動(dòng)化測試。我決定推遲 GUI 自動(dòng)化測試，擴展命令行測試套，測試新增的產(chǎn)品功能�，F在回過(guò)頭看這個(gè)決定，我沒(méi)有選擇 GUI 自動(dòng)化測試是最大的成功之處，如果采用了 GUI 自動(dòng)化測試所有的時(shí)間和努力都會(huì )浪費在其中。他們已經(jīng)準備好做 GUI 自動(dòng)化測試了，并且已經(jīng)購買(mǎi)了一套測試工具和其他需要的東西，但我知道在開(kāi)展具體的 GUI 自動(dòng)化測試活動(dòng)中，會(huì )遇到各種各樣的困難和障礙。
無(wú)論你需要支持圖形界面接口、命令行接口還是 API 接口，如果你盡可能早的在產(chǎn)品設計階段提出產(chǎn)品的可測試性設計需求，未來(lái)的測試工作中，你很可能成功。盡可能早的啟動(dòng)自動(dòng)化測試項目，提出可測試性需求，會(huì )使您走向自動(dòng)化測試成功之路。
步驟五：具有可延續性的設計
在開(kāi)篇的故事中，我們看到由于自動(dòng)化工程師把注意力僅僅集中在如何使自動(dòng)化運轉起來(lái)，導致測試自動(dòng)化達不到預期的效果。自動(dòng)化測試是一個(gè)長(cháng)期的過(guò)程，為了與產(chǎn)品新版本的功能和其他相關(guān)修改保持一致，自動(dòng)化測試需要不停的維護和擴充。自動(dòng)化測試設計中考慮自動(dòng)化在未來(lái)的可擴充性是很關(guān)鍵的，不過(guò)，自動(dòng)化測試的完整性也是很重要的。如果自動(dòng)化測試程序報告測試用例執行通過(guò)，測試人員應該相信得到的結果，測試執行的實(shí)際結果也應該是通過(guò)了。其實(shí)，有很多存在問(wèn)題的測試用例表面上執行通過(guò)了，實(shí)際上卻執行失敗了，并且沒(méi)有記錄任何錯誤日志，這就是失敗的自動(dòng)化。這種失敗的自動(dòng)化會(huì )給整個(gè)項目帶來(lái)災難性的后果，而當測試人員構建的測試自動(dòng)化采用了很糟糕的設計方案或者由于后來(lái)的修改引入了錯誤，都會(huì )導致這種失敗的測試自動(dòng)化。失敗的自動(dòng)化通常是由于沒(méi)有關(guān)注自動(dòng)化測試的性能或者沒(méi)有充分的自動(dòng)化設計導致的。
性能： 提高代碼的性能往往增加了代碼的復雜性，因此，會(huì )威脅到代碼的可靠性。很少有人關(guān)心如何對自動(dòng)化本身加以測試。通過(guò)我對測試套性能的分析，很多測試套都是花費大量的時(shí)間等候產(chǎn)品的運行。因此，在不提高產(chǎn)品運行性能的前提下，無(wú)法更有效的提高自動(dòng)化測試執行效率。我懷疑測試自動(dòng)化工程師只是從計算機課程了解到應該關(guān)注軟件的性能，而并沒(méi)有實(shí)際的操作經(jīng)驗。如果測試套的性能問(wèn)題無(wú)法改變，那么應該考慮提高硬件的性能;測試套中經(jīng)常會(huì )出現冗余，也可以考慮取出測試套中的冗余或者減少一個(gè)測試套中完成的測試任務(wù)，都是很好的辦法。
便于分析： 測試自動(dòng)化執行失敗后應該分析失敗的結果，這是一個(gè)棘手的問(wèn)題。分析執行失敗的自動(dòng)化測試結果是件困難的事情，需要從多方面著(zhù)手，測試上報的告警信息是真的還是假的?是不是因為測試套中存在缺陷導致測試執行失敗?是不是在搭建測試環(huán)境中出現了錯誤導致測試執行失敗?是不是產(chǎn)品中確實(shí)存在缺陷導致測試執行失敗?有幾個(gè)方法可以幫助測試執行失敗的結果分析，某些方法可以找到問(wèn)題所在。通過(guò)在測試執行之前檢查常見(jiàn)的測試環(huán)境搭建問(wèn)題，從而提高測試套的可靠性;通過(guò)改進(jìn)錯誤輸出報告，從而提高測試自動(dòng)化的錯誤輸出的可分析性;此外，還可以改進(jìn)自動(dòng)化測試框架中存在的問(wèn)題。訓練測試人員如何分析測試執行失敗結果。甚至可以找到那些不可靠的、冗余的或者功能比較獨立的測試，然后安全地將之刪除。上面這些都是減少自動(dòng)化測試誤報告警、提高測試可分析性的積極有效的方法。另外，有一種錯誤的測試結果分析方法，那就是采用測試結果后處理程序對測試結果自動(dòng)分析和過(guò)濾，盡管也可以采用這種測試結果分析方法，不過(guò)這種方法會(huì )使自動(dòng)化測試系統復雜化，更重要的是，后處理程序中的 BUG 會(huì )嚴重損害自動(dòng)化測試的完整性。如果由于自動(dòng)化測試本身存在的缺陷誤把產(chǎn)品中的正常功能視為異常，那該怎么辦?我曾經(jīng)看到測試小組花費開(kāi)發(fā)測試自動(dòng)化兩倍的時(shí)間來(lái)修改測試腳本，并且不愿意開(kāi)展培訓過(guò)程。那些僅僅關(guān)注很淺層次測試技術(shù)的測試管理者對這種方法很感興趣，他們排斥采用隱藏測試復雜度的方法。
綜上所述，應該集中精力關(guān)注可以延續使用的測試套，從以下幾方面考慮，測試的可檢視性、測試的可維護性、測試的完整性、測試的獨立性、測試的可重復性。
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
