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

　　經過幾次的計劃->實施->修正計劃，對每周的工作進度就會比較了解，從而有利于對整理項目進度的預估。

　　c. 問：如何驗收我們的項目成果?

　　答：每個人對“完成”這個概念的理解不同，有的人認為Complete即可，有的人認為Good，而有的人追求的是Perfect。為了保證我們的項目完成之后的一致性，可以建立一個完成的CheckList，將“完成”的概念量化，如驗收test case script的完成，我們可以定制如下的CheckList驗收。

　　4)檢討審查

　　也就是在項目結束之后，對項目進行總結，調節。并通過事后諸葛亮式的檢討分析，找出改進的方案，對下一個項目的進展是很有幫助的。

　　經過了兩輪的開發，到了代碼維護階段。以前覺得“需求->開發->維護”三步驟中維護是最容易的，但是現在卻讓我們最撓頭。

　　這幾次Run出結果之后，所有的人見面第一句話都是：“呃，在我電腦上是Pass的，怎么現在就Failed了?”

　　靜下心來檢查代碼，總有一些讓我們忽略的問題被查到，但還是有許多頑疾存在著，尤其是界面刷新不及時或者莫名其妙的問題真的讓我們很惱火。開發是一件創造性的事情，測試是一件破壞性的事情，無論二者都有成就感可言，但是維護或者說是擦屁股的事情搞得我們每個人都心煩意亂?？偨Y我們的需求，開發，及運行經驗，還有最近維護時遇到的問題，總結一下：

　　1、需求分析階段，編寫AutoTest Case時，步驟詳略得當，不可以太簡單，也不必太過繁復，多用項目的專業用語(閱讀此文件的人都是對項目有一定熟悉度的人)，這樣有利于維護人員，或者后期手動測試人員了解Case的測試內容。

　　2、開發代碼時：

　　1)腳本內的注釋寫清楚

　　2)對象庫及對象命名盡量有意義

　　3)中間步驟(如頁面的跳轉，某些重要的Button或Link)要寫清楚，最好寫到Report中

　　4)檢查點的判斷，要直觀，并且寫清楚輸入，輸出的值，及期望的輸出，如，查詢功能失敗，要寫明輸入什么樣的條件使得查詢失敗，否則QA可能輸入另一組數據查詢，結果為成功

　　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放到最后一個執行，降低對其他代碼的影響幾率。

原文轉自：http://www.anti-gravitydesign.com