QTP自動化測試過程隨想(3)

　　5)寫完整個Case之后，需要察看整體的Report，是否容易看懂，整個Report就需要象一個故事一樣，上下文連貫。

　　6)在開發的尾聲，需要安排時間互相Review代碼，按照1)~5)去審查別人的代碼，這樣也會發現一些問題的。不僅如此，互相察看代碼有益于我們發現別人的長處，和一些自己沒有注意到的知識點。

　　7)代碼完成之后，切忌不可束之高閣，而要多運行幾次，并且在不同的電腦上運行，可以利用晚上的時間，相互運行代碼。

　　我覺得，6)和7)在開發階段是不可省略的步驟，我們之前總是說開發時間緊，就縮短或者省略這兩個步驟，導致我們正式運行時錯誤百出。

　　3、維護階段

　　總結我們經常出現的錯誤，有如下幾類：

　　1)環境問題 (如界面刷新，異常中止)

　　這些問題我們只能自認倒霉，但是總覺得可以再次優化，就是還沒有想到好辦法。會繼續摸索

　　2)QTP與IE沖突

　　由于QTP的某種操作，會導致IE的異常中止;或者由于IE的設置，導致QTP無法反映。此類問題出現的頻率不高，但是一旦出現會導致一連串的錯誤出現。

　　3)對象異常

　　有如下情況：

　　第一種是由于站點本身的升級導致對象的變更或邏輯的改變，此時需要修改代碼;

　　第二種情況，由于界面跳轉異常導致對象無法識別，在捕獲的圖片中可以看到。

　　還有一種情況，針對我們的框架下，對對象庫的加載，會有對象重復的現象，導致對象無法被識別。此時就需要對重復的對象進行處理，保證其唯一性。

　　最常見的是對象不唯一導致的無法識別，多出現在WebElement中，我們往往通過對某個 WebElement的value值判斷其成功與否，但是有時界面中會有許多隱藏的Webelement存在，如果恰巧WebElement的識別屬性用描述性編程，或者是正則表達式的話，就容易識別不到。需要加入 Index屬性去識別。

　　4)臟數據的存在

　　舉個例子，某個Case為：添加->查詢->刪除操作，如果第一次運行沒有執行到刪除就錯誤中止了，第二次運行時，之前添加的代碼就會存在，影響添加或查詢，我們可以這樣設計Case：刪除->添加->查詢->刪除

　　再如，A操作的前提需要B操作設置，但是B的設置會影響到A相關的其他操作，我們設置 Case：B config1 -> A Operate -> B config2，但是，如果該Case在B config2前異常中止了，則B的config1將被帶入到下一個Case中。針對這樣的Case，可以將Case放到最后一個執行，降低對其他代碼的影響幾率。

　　我們最后的測試報告都會由手動QA人員確認，并且察看Bug是否為系統的Bug，并且統計Bug發現的比率，

　　1)查看遺漏率 自動化發現的Bug / QA發現的Bug

　　這個需要察看QA發現的Bug是否在我們自動化測試的Case中，如果在，那是我們的問題，如果不在，我們就需要添加到Case中，這就可見在需求階段與QA確認的重要性，否則，人家不認可你的檢查點或者說你的Case 有遺漏，我們就很郁悶了

　　2)準確率 QA確認的Bug / 自動化發現的所有Bug

　　這個好有壓力阿，如果自動化發現10個Bug，結果有九個是腳本或者環境的問題，只有一個是真正的Bug， 我們自動化的效率就可想而知了。

　　版權聲明：本文為51Testing論壇會員1316016原創，http://bbs.51testing.com

原文轉自：http://www.uml.org.cn/Test/200912176.asp