最近公司剛完成了一個比較大的項目-單品頁模塊化，即使用現在比較流行的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就知曉結果了；對於有衝突的，讓合併代碼的開發人員告知衝突的代碼功能是什麼，在業務流程迴歸之外重點關注下對應的功能；對於業務層面，就需要對每個項目內容充分熟悉瞭解影響到的地方，明確需求具體內容，觸發條件，處理過程及結果，有側重點的進行驗證。
