圍繞自動化測試開展持續集成(2)

　　兼容性測試

　　現在軟件需要兼容的環境越來越多，包括操作系統、應用服務器、數據庫、瀏覽器，像上面案例中的產品還要兼容主流虛擬化服務(比如，VMware 、XenServer、KVM)的各種版本。如果全靠人工測試來保證兼容性，是不太現實的事情。

　　兼容性測試有個特點，就是如果不兼容，往往在一些主要流程上就能明確的體現出來，一般不用深入到每個業務細節，也不用靠人來主觀分析。因此也非常適合通過自動化測試來完成。

　　下面分享一個筆者在撰文的前一天剛剛遇到的實際案例(如下圖所示)。

　　這個一個最基本的用戶維護界面，里面包括必填信息和可選信息(比如，生日)。在一次自動化測試中，Web UI層面的“用戶信息修改”用例出現了如下異常：

　　Caused by: com.mysql.jdbc.MysqlDataTruncation: Data truncation: Incorrect datetime value: '' for column 'ext_date' at row 1

　　這個功能后臺業務接口是有單元測試用例對應的，并且也做了一些邊界值測試(比如，“生日”屬性為空)，但遺漏了另外一個邊界條件(空字符串)，而恰恰如果界面不選擇“生日”，傳到后臺的就是空字符串。Web UI層面最基本的測試用例恰恰彌補了這個缺憾。

　　寫到這里，可能會有敏銳且尖銳的讀者繼續提出質疑：“這么表面的缺陷在手工測試階段一定會發現的，怎么會輪到通過Web UI自動化回歸測試來發現呢?”

　　我們來回顧一下上面的異常信息“Caused by: com.mysql.jdbc.MysqlDataTruncation…”。是的，這個缺陷只有在使用MySQL數據庫時才出現，而日常開發和手工測試使用的都是Oracle數據庫。

　　我們把在各種組合環境下的兼容性測試交給自動化用例來完成。因此，如果有兼容性方面的Bug，也是“得來全不費工夫”!

　　穩定性測試

　　穩定性測試可以分為“服務端穩定性測試”和“客戶端穩定性測試”。其中服務端(比如，應服務器、數據庫等)的穩定性測試是最常見的，筆者這里不做贅述。

　　RIA(Rich Internet Applications)技術的廣泛應用為Web用戶提供越來越贊的使用體驗。與此同時，也比傳統應用占用更多的客戶端(瀏覽器)資源。所以對此類應用的客戶端穩定性測試也是非常關鍵的。

　　驗證客戶端的穩定性需要兩個條件：長時間的不間斷操作、監控瀏覽器資源占用。

　　我們通過對Web UI自動化測試用例的循環執行可以模擬長時間的不間斷操作。另外，在自動執行的同時，自動獲取并記錄瀏覽器資源占用，就可以達到驗證客戶端穩定性的目的。

　　如果系統前端代碼出現內存泄露(比如，彈出頁面關閉后未銷毀生成的DOM對象)，Web UI自動化用例長時間運行后生成的瀏覽器內存占用報告就會如下圖所示：

　　而正常應該是整體呈水平趨勢的鋸齒狀圖形。如果出現上述情況，其表現出來的現象是用戶感覺操作響應越來越慢，嚴重的情況下會導致瀏覽器宕掉。

　　至此，本系列文章就結束了。下面用三句短話總結一下本系列的主要內容：

　　Web自動化測試困難的根本原因是什么;

　　如何才能更容易的成功實施Web自動化測試;

　　要么不斷提升、持續證明自動化測試的價值，要么就變成雞肋!

　　最后分享筆者這幾年在實施自動化測試和持續集成工作中的一些心得體會：

　　在設計某個功能“自動化測試應該怎么實現”之前，一定要先全面、仔細的分析“手工測試時是怎么做的”;

　　當提到自動化測試的“測試設計”時，不光要考慮“測試用例設計”，一定還要考慮“自動化測試方案或框架的設計”

　　敢于面對各種質疑和挑戰，并用持續的改善作為回應;

　　對于開發團隊來說“不改善，尤可活”，對自動化測試來說“不改善，就等死”;

　　不斷發掘自動化測試對各個團隊的附加價值，只有這樣才能得到來自四面八方的支持;

　　自動化測試的目的是節省成本，所以如果發現某個項目、模塊或功能在進行自動化測試時的投入產出比還不如人工測試，就應該果斷暫停;

　　當有人用“自動化測試的返工成本”來刻意刁難測試團隊時，不妨請他考慮一下研發階段的返工吧;

　　對測試用例失敗的原因進行歸類(比如，缺陷、環境錯誤、用例未更新等)，并據此生成測試報告，非常有助于提高測試結果分析的效率;

原文轉自：http://www.infoq.com/cn/articles/develop-continuous-integration-around-automation-test?utm_source=infoq&utm_medium=related_content_link&utm_campaign=relatedContent_articles_clk