我是如何做軟件測試項目的?

最近公司剛完成了一個比較大的項目-單品頁模塊化,即使用現在比較流行的Twitter Bootstrap進行前端開發。說其大是因爲工作量大,開發前期投入約80人日,包括前端開發及PHP開發,且不包括修復bug的時間,測試投入約48人日,同時也是非常重要的項目,直接關係到轉化率,稍有差池就會導致轉化率的下降。而我有幸成爲該項目的測試負責人,此文即介紹我自己是如何帶這個項目的。

 

1. 人員分工合理,老人帶新人

其實這次項目中,人員分配是3個老人(工作也不到2年),2個新人(工作不到1年),2個實習生,加上我自己共8個人負責功能相關測試。通過把功能及測試內容進行拆解,並對子功能評估工作量,測試難度及影響範圍,與參與的人中最熟悉的人一起評估大概工作量,結合項目計劃,投入參與的人員,制定出最終的測試工作量評估,當然,在評估的時間上加上buffer時間將風險得以降低。秉承以下原則進行分配工作:

1)最核心的內容讓最熟悉的人來做;

2)新人負責邊緣一點的功能,邊做邊學;

3)在其中挑出一個能承擔較多的人,以減少“巴士因素”;

4)其中1個或2個人工作內容相對少點,方便靈活調配去協助其他人;

5)讓細心的人做更多頁面測試,讓邏輯思維強的人做更多業務邏輯性測試,充分發揮各自優點。

 

2. 做好計劃,一切心中有數

一份好的計劃具有指導意義,可以回答何時能發佈的問題。所以爲了制定一份靠譜的計劃,需要充分理解項目內容,項目人員情況,其餘版本代碼合併時間及可能的風險,需要進行哪些內容的測試,何時開展性能測試,需要做怎麼樣的兼容性覆蓋,哪些功能需要做安全性測試等等。其實我覺得可能並不一定要撰寫一份完整的長篇計劃文檔,只要在一兩頁能列出以上內容,說明了測試計劃最關鍵部分,其餘的都是形式。

 

3. 嚴格控制其餘需求加入及本需求變更

影響項目計劃的三大殺手鐗:開發未按時提交代碼,開發質量差及需求變更。需求變更可能會導致對之前的代碼架構重設計,測試人員重新測試,嚴重影響項目計劃,在進行該項目時,就與項目管理及PM達成一致,爲了保證按時上線,控制其餘需求加入,並不再對本次需求進行優化,保證該項目的優先級,預計的項目人員及項目資源。

 

4. 明確測試用例,做好評審

任何一個項目,一份考慮較周全的用例可以大大降低項目風險,增強測試人員乃至整個項目組的信心。這個項目也毫不例外,因爲沒有新的業務邏輯及功能,所以前期我們只需整理之前的用例,並再次與開發人員及PM評審,並列出冒煙測試用例,而它將作爲冒煙測試運行之用例,也用於開發人員自測使用,畢竟是經過評審過的,所以大家都認可。

 

5. 保持測試與開發環境獨立

開發環境與測試環境的獨立其實並不是從這個項目開始的,而是一直以來都是這麼做的。畢竟每一輪次代碼及環境的穩定性會影響到所有測試人員的進度,誰都不想讓開發人員在測試環境任意調試,修改配置,或直接進行開發,如果遇上非要在測試環境來複現某個問題時,也要等到環境沒人用時進行。這麼做也是爲了讓我們每一輪次的測試結果都是可信的,而不會因爲環境的變化,讓剛纔測試通過的用例又執行失敗,讓剛剛報的一個bug突然變成了NOT A BUG。

 

6. 每輪次冒煙測試,督促提高開發質量

每一輪次的系統測試,都要進行冒煙測試,同時越到項目後期,越要提高冒煙標準。這麼做的意義也是爲了督促開發人員多自測,讓團隊一起爲產品質量及發佈齊心協力。所以,在一開始冒煙測試時,可能就把影響流程性的會block其他很多case(比如10條及以上)的case作爲冒煙測試用例,因爲第一輪次的測試都是覆蓋性的,而往後,可能就是多回歸信心不太足的模塊,迴歸bug等,那麼,在後期的冒煙測試時,對於多次反饋仍未修復的較嚴重的bug和bug重災區的核心功能及流程也有必要作爲冒煙測試範圍。每一輪次的測試結果都在郵件中抄送給各個團隊負責人及CTO,開發團隊每個Q進行的績效考覈也將考慮冒煙的情況,督促提高開發質量。而且若因開發質量不夠好冒煙測試不通過而導致的項目延期,則不再屬於測試團隊的責任。

 

7. 彙總以往出現過的嚴重或典型缺陷,在該項目驗證

每一次較大型的發佈,都讓測試人員頗爲擔心,害怕出現遺漏bug,但是總會有未考慮周全之處,每次大型發佈之後,或是被公司內部的人發現或是被我們的用戶發現,我們需要對以往的經驗進行總結,彙總出以往項目從眼皮底下溜走的bug,他們發生的原因及如何避免,這些都是教訓及經驗談。在這個項目中,一樣是把之前遺漏過的bug告訴大家,一定多加註意。

 

8. 進行每日項目會議,掌握項目進展情況

每天抽出半小時,把大家召集到一起,瞭解每個人的進度,遇到的問題,讓大家積極發言,進行頭腦風暴,這個時候的碰撞往往能事半功倍,我也會把我自己的想法告訴給大家,哪些功能間需要加強協調測試,比如在UI上有交互的,在某一個標籤處顯示2個內容而恰好屬於不同人測試,在數據上都有讀取或修改的,讓功能間有依賴的人多溝通,測試時多考慮相互間的影響等等,會上統一集中的幫助大家解決問題或提供解決問題的思路。我覺得每日會議可以讓大家更像一個團隊作戰,而不是單打獨鬥,各幹各的,最後亂成一團糟。

 

9. 注意風險控制,瞭解缺陷影響範圍

項目越往後,bug數量越收斂,而給我們最大的障礙可能就是我們不夠了解缺陷影響範圍,不懂得迴歸bug時還需要測試些什麼,這卻正是測試新人最大的挑戰。僅僅是測試bug裏說的這情況嗎?大多數時候肯定不夠,老生長談如何判斷功能間的依賴:

1. 有關輸入:這些功能會不會處理同樣的輸入?

2. 有關輸出:這些功能會不會在界面上顯示在同一個區域?會產生同一個輸出嗎?

3. 有關數據:是否會操作同樣的數據?是讀取還是修改?

如果上面三點中有一個答案是,那麼他們之間肯定就有依賴!

同樣,你也可以通過諮詢開發人員,這個bug改動會影響到哪些地方,對於熟悉公司業務及代碼的人來說,也可以通過diff兩個版本間代碼差異獲得答案。

 

10. 合版後明確迴歸範圍

這裏的迴歸跟上面的迴歸其實是有差異的,因爲上面的只針對bug而言,這裏的迴歸就涉及到該產品其他正在進行的項目內容。因爲公司進行多個項目多個分支並行開發,在進行該項目時,有別的項目已完成併發布上線,那麼該版本發佈前需要合併這些項目的代碼。有些情況下會出現未正常合併或合併過程中未正確處理好衝突,或在業務需求層面上就有相互影響的情況,這就需要有針對性的進行迴歸。

對於未合併的,讓對應項目參與者運行下冒煙的case就知曉結果了;對於有衝突的,讓合併代碼的開發人員告知衝突的代碼功能是什麼,在業務流程迴歸之外重點關注下對應的功能;對於業務層面,就需要對每個項目內容充分熟悉瞭解影響到的地方,明確需求具體內容,觸發條件,處理過程及結果,有側重點的進行驗證。



發佈了83 篇原創文章 · 獲贊 75 · 訪問量 85萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章