基于WEB UI接口的輕量級軟件自動化測試框架及實施方案(2)

　　2.3 結果驗證

　　結果驗證按照業務系統的特征，現在支持以下幾種：對接口返回的內容直接做對比驗證;對數據庫update后的內容做驗證;將接口返回的json做處理后做驗證。

　　2.4 測試數據

　　對業務系統自動化測試來說，業務測試數據非常關鍵，因為它需要符合一定的業務規則;如何構造數據有幾個爭議的地方：

　　1. 數據(包括DB，server文件，樁文件)一次性構造好放那不動，無法保證數據不被污染，且移植性受限;

　　2. 如果能做整個環境的備份還原則不怕污染，但是case與case之間可能會互相干擾數據

　　3. 自動化case是否嚴格要求數據的隔離，如果要求，則每個case都自己負責生命周期內的數據準備和清理;如果不要求，則需要case設計時刻意避免數據的使用混亂

　　不同業務系統在設計上各有千秋，哪一種數據準備的方案都是有不同的代價，結合筆者所處產品線的特征，認為自動化case自己負責生命周期內的數據準備與清理，是綜合效果比較好的模式：1個獨立的case，能有自己生命周期內的數據準備和清理，則最大程度上保證了case運行的穩定性和可靠性，避免case之間互相因為數據發生干擾!

　　2.5 擴展性

　　itest在擴展性方面，通過“以文件后綴作為識別標簽，新的功能需求，約定一種新的文件后綴”，itest維護人員在框架內開發相應的分支邏輯，而case編寫人員則只需按照文件約定格式設計文件即可。如下為目前支持的不同文件，以及相應的不同邏輯功能：

原文轉自：http://qa.baidu.com/blog/?p=726&qq-pf-to=pcqq.c2c