QTP自動化測試過程隨想

　　我之前做過短暫的開發，后來主要是測試，豐富的測試經驗(但僅限于黑盒)，并且有帶領團隊半年時間，期間和老板學習了6-Sigma(黑帶)，也做過幾個專利，所以很有流程，改善，和客戶需求方面的sense, 并且感覺很有創新的意識，現在專職作QTP自動化開發，一個項目剛剛結束了，于是把隨想發出來，共同討論。

　　回顧整個項目過程中各階段操作，作出以下總結：

　　1、需求確認階段

　　此時需要手動測試人員的大力支援，并且建立良好的溝通，提升我們熟悉業務效率，溝通包括：

　　1)需求提出：與手動測試接洽人確認自動化實施的策略是什么.

　　將老板與客戶的想法作為大的方向，結合手動測試實際需求，并考慮到自動化實現的現狀，共同擬定出項目的Scope。

　　提出需求的絕不可以是自動化Team的“一廂情愿”。當然，現實中有時是由自動化方提出的更多一些，但是這個根本的原則是，要得到手動的認可與確認，否則當東西做出來后，他們說一句這不是我想要的東西時，我們自動化Team將全體暈倒……

　　2)需求確認與熟悉：自動化Team對提出的需求進一步分析，制定出自動化的Auto-Test Case。

　　分析的前提是，熟悉業務，即看懂test case并可以實際測試。原則上講，作自動化的人應該是對所做業務非常熟悉的人，至少要有手動測試經驗的。但實際上，我們不可能熟悉所有的項目，于是如何快速掌握業務操作流程就頗為重要。此時最捷徑的方式就是與手動測試人員溝通，溝通的效果越好，則此處所用的時間就越少。

　　PS：在我們的上一個項目中，我們在需求確認階段，看完了所有手動Test Case，將其分類出我們需要的，然后與之確認，說實話，有點耽誤時間。

　　2、開發階段

　　如果說需求確認階段我以前有過經驗的話，開發階段對于我來說可算是全新的。以前我們自動化項目，對于開發階段，代碼變化很少，其重點是如何將多個設備或者 PC的并行操作串聯起來?？墒沁@里的項目不一樣，需要很強的編程能力，需要對QTP很熟悉，這也是我比較薄弱的地方。正應為如此，我在這個階段學習到的東西也是最多的。

　　首先，很好的Frame框架，為我們的編碼及維護帶來很大的方便。

　　其次，編碼方面，對于常用的函數，以前都需要看Help的規范后才可以編寫，現在非常熟悉，可以直接快速編碼。學習了許多新的編碼技巧，如：

　　1)Dictionary Object使用，這個以前聽都沒聽過，汗~~

　　2)描述性編程的實際應用，以前只是看過相關的概念

　　3)時間函數的應用，如Sync方法，WaitProperty屬性，或者自編輯一個For循環，動態等待時間。

　　再次，協同編碼保證代碼同步。

　　通過SVN管理我們的代碼，其缺點在于可以同時有許多人編輯同一個文件。這樣的開發模式似乎在各件開發中很常見，但是我的純開發經驗并不多，加之管理工具的變更(之前用的是VSS)，開始的時候我連Check in，check out都不會，學會這樣的操作不難，難的是如何在思想上建立這樣的協同操作模式，如何在資源共享的前提下，不會因為一個人的修改，導致別人的不便。我們 Team達成共識，提交代碼前先看服務器上是否有更改，Update之后再提交，如果這樣還不行的話，只能比對文件差異。但針對對象庫的管理中，由于存儲數據特殊，無法比對，則在修改前需要與文檔的創始人說明，之后再作更新。

　　3、整體項目管理

　　我認為在這次我們的項目過程中，沒有融入所謂的項目管理，由于人員還比較少也有一定經驗，我們完全憑借自覺性與經驗去跟進項目進度，這樣是很危險的，下一步如果我們擴展團隊，并且加入些經驗不足的人參與編碼，項目風險就會很大，所以我們要啟用一個項目監管的機制。

　　1)資源調整

　　未來我們人力充沛的前提下，可以試著安排一個人到手動測試組學習，當然他要有自動化的概念，“臥底”到那里去學習測試，了解需求，這是小組間的調整。

　　在自動化測試組內，我們可以通過開展定期的經驗分享，來共享我們的信息，并且有了問題積極主動去問別人，我們可以算一筆賬，假如我遇到一個問題，如果自己解決或者上網查資料，假設要半個小時，但是如果我詢問下周圍的人，可能只需五分鐘就完成了，兩人各耽誤五分鐘，也就是用十分鐘完成了半小時的事情，何樂而不為?你也可能說，對于我來講，我是用五分鐘完成了半小時的事情，但對于答疑的人來說呢??他是白白浪費了五分鐘，沒有人愿意這么做的……但是，這件事情還有可能反過來，也就是我用五分鐘解決那個人需要半小時的問題，此時我們是雙贏，這樣的循環，我們的效率能不高嗎??我們現在是團結協作的時代，不是考驗個人獨立學習的時代，所以，不要把這種資源共享，當作是一種沒有獨立解決問題能力的表現。在和手動測試談論需求時，我們也要充分利用這樣的 Support，而不是自己在家啃Test Case。

　　2) 事務優先級

　　針對自動化開發的在各公司尷尬的現狀，分清主次更為重要。這體現在我們篩選Test Case中。我們遵循20-80法則，我們要勇于將耗費80%時間完成的20%Test Case剔出出去，除非手動測試有特殊的需求，這與自動測試的本質并不違背。自動測試的宗旨并不是將所有手動測試的Case都實現自動化，而是要將那些變化不大的，流程邏輯較為簡單的，測試頻率高的Case實現自動化即可，我們不可為了一味地追求自動化比例而將那些無謂的Case加入。

　　3)事務監督

　　下面將以問答的形式來討論該問題：

　　a. 問：如何定制合理的項目進度表? 讓組員們工作不是很輕松，也不用每天加班完成?

　　答：這需要我們了解所有資源的配置情況，掌握每一個操作環節最平均的時間，并且了解該環節80%可能用的時間范圍(置信區間，作為輔助決策。

　　b. 問：如何掌握項目進度?即：項目負責人如何保證項目是On schedule的?項目經理或者更高的主管如何了解項目的進度?

　　答：定期Meeting，請組員們匯報工作進展，并討論遇到的問題。

　　以每周一報為例，會議的內容為：組員介紹本周具體工作內容(有點像TimeSheet的填寫)，與上周預計內容比對是按時完成還是有延誤，延誤的原因是什么??項目負責人對下周工作安排。

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