題記：上週，產品終於Release了，前後歷時近兩年時間，期間經歷了一次需求變動，四次Interation。產品是新版本開發，需要同時在四個平臺(window,Linux,Aix,zLinux)開發，每次迭代實現一個feature。在敏捷盛行的今天，這樣的開發週期是很多公司所無法接受的，但作為一個伺服器端產品，對軟體質量的要求比較高(作為一名資歷尚淺的QA，暫淺不評述這種有點類似“螺旋模型”的開發模式的優劣），只想談談在每次迭代測試間，我們還有哪些地方可以做得更好！

     背景：前一版留有測試用例1600+，其中P1的大概200個左右，P2有600多，剩下主要是P3以及少部分P4。在上一版，在沒有automation的來做Regression test的情況下，跑完一輪full cycle，即1600+的測試用例， 差不多需要4名QA，10 working day，也就是每人每天完成40左右的測試用例。

     1. 自動化測試

其實之前的版本留有一套自動化測試，但沒有任何文件、不穩定、難以維護，所以在做新版產品開發時就決定要投入精力重新開發出一套自動化測試來。作為一個生命週期很長的產品(>5年)，有著一套健壯、穩定的自動化測試來做迴歸測試，以確保程式碼改動，或新增功能不會影響以前能夠正常工作的功能，這是十分又必須要的。需要明確的是：不要期望自動化測試能夠幫助你發現新的bug。

      其次，在寫自動化指令碼之前需要明確哪些測試用例有自動化的價值，並不是之前

      從技術上講，自動化框架編碼，寫自動化指令碼並不是十分困難，那難在什麼地方呢？我覺得難點在於：自動化測試用例能真實全面反映使用者場景。同樣的關鍵字，同樣的用例，但不同的人寫出來的自動化指令碼可能是不同的，不同在於對用例的理解，在於經驗。

      整個自動化測試完成後的Pass Rate。 如果自動化指令碼誤報率很高的話，就會讓人對自動化測試的可靠性大加懷疑了。為了保證準確性，會在一些keyword中，或則自動化指令碼中新增一些容錯延時機制。自動化測試完成的時間是可接受的。如果自動化測試跑完需要兩三天時間，這就有點無法接受了。要在保證

      自動化的開發也分成了兩個Interation,第一個階段完成了自動化框架、大部分的keyword和基本的smoke測試用例的自動化，第二個階段，補充一些keyword,完成regression測試用例。最後，新Feature的自動化。到目前為止，產品的自動化覆蓋率差不多40%左右，但覆蓋了產品核心功能。

 這套自動化測試發現了哪些問題呢？這個問題肯定經常被問到，稍微歸納下：

       程式碼改動導致以前正常工作的功能Fail。舉例，之前可以正常處理uuencode編碼的郵件(注: UUEncode格式本來就比較難處理)，因為一次程式碼改動fail。

       驗證HotFix/Patch。一次幫sustain team驗證Patch, 打完patch後，沒跑幾個cases ,系統就掛了。

       記憶體洩露。發現過一次記憶體洩露，當跑完十幾個特定用例後，記憶體居然被吃光了後Crash。結果發現在跑這十幾個cases時，需要reload配置，但每次reload都沒釋放之前資源。

       多執行緒競爭資源。這次automation 過程中的crash很難重現，最後是RD分析dump檔案後找到Root Cause的。

自動化開發過程中的一些經驗教訓：

•       sync-up meeting(也叫stand up meeting)。每天花上十分鐘，sync下進度，討論下在編碼、寫自動化用例過程中遇到的問題，這在自動化開發初始階段還是很有必要的。
•       確保每天完成的自動化指令碼都能100%通過，然後把這些沒問題的自動化指令碼和之前的指令碼串起來跑，確保沒問題。
•       實現好的自動化指令碼需要互動檢查，看步驟，看檢查點是否完備。
•       自動化框架原始碼、實現的關鍵字、自動化指令碼、配置檔案、生成的Data 都必須加入到版本控制系統中去，如SVN，Git都可以。確保程式碼，指令碼沒問題後，及時Check in。
•       每天自動化測試的結果整理統計後，發給team裡面的人。
•       對於那些Fail的測試用例，需要有人去follow up。
•       當發現測試用例的fail是由程式碼改動引起的，確認不是bug後，需要及時調整自動化程式碼，自動化測試用例。記得Check in 你的變動。
•       自動化環境的部署文件，自動化框架和關鍵字實現文件。前人栽樹，後人乘涼的道理，方便他人接手。

現有的自動化測試有哪些不足呢：

•  自動化環境的部署略顯複雜。讓一個新人跟著文件部署好一套自動化環境，至少需要半天時間，要掌握基本的troubleshoting技巧，寫自動化指令碼，差不多需要一週時間。
• 自動化關鍵字的實現稍顯複雜。部分原因是Domino這樣的環境決定的。
• 部分自動化測試用例執行時間偏長。
• 自動化測試是個持續投入的過程，一套穩健的自動化測試能提高你對產品質量的信心。

2. 迭代測試

      基於這樣的開發模型，每一輪迭代，和測試相關的活動有這些：寫SRS(也可以RD寫)，SRS的review， 根據SRS完成Test Design，建立測試用例，測試用例review，一輪新功能的測試，每天自動化迴歸測試，發現問題，驗證問題，又一輪新功能測試，最後一輪full cycle測試，實現新功能的自動化，效能測試等。

      四輪迭代下來，新增測試用例700左右，提的tracker有360多個。因為早期自動化測試的投入，大大減輕了後期手動迴歸測試的工作量。可以想象下，四個平臺，每個平臺又要支援多個作業系統版本，這樣的測試工作量！

在每次迭代過程中，就測試而言，有哪些地方可以做的更好呢？

      首先，每輪迭代後，是不是可以做下測試用例的Refine，即新建立測試用例的優化，可能建立用例的時候時間比較倉促，對產品的理解不透徹，或其他什麼原因，在執行的過程，或多或少都會發現測試用例的不合理，有些測試點缺少測試用例，也就是當初的測試用例沒有覆蓋，有哪些地方需要優化的呢？

· 測試用例的執行步驟(Step)， 預期結果(Expected Result)。 可能是需求的變化，或則建立用例時理解的錯誤，按照步驟得不到預期結果，這時候就需要調整執行步驟，或則預期結果。

· 測試用例的優先順序(Priority)。隨著測試的進行，對產品的理解也更加透徹，這時候對測試用例的優先順序可能和當初寫測試用例的時候有些變化。

· 補充測試用例。回過頭來看那些已經發現的bug，你會發現很大一部分不是通過當初設計的測試用例發現的。這時候需要及時補充測試用例。

      其次，每一輪迭代測試後，好好分析研究那些已經提交的Tracker， 整理統計這些bug，會學到很多。

· 在測試的過程中關注Bug曲線、分佈。那個著名的測試理論“Defect Clustering”告訴我們bug總是喜歡扎堆出現，通過Bug曲線，你會知道那個模組這段時間需要重點測。下面這兩幅並不是Bug曲線圖，而是我統計的導致產品Crash的Bug的分佈，能告訴我哪些模組的程式碼質量如何。

· 關注Bug的Root Cause。我覺得一個好的QA不僅發現Bug， 而且應該有意識的嘗試提出Bug預防策略。通過把Bug分類，把Root Cause類似的bug放一起，你會發現很多Bug是可以避免的。比如，之前SEG在處理一個使用者提交的bug時，發現這是由於用錯了資料型別。而在這一版中，也發現了三四個由於用錯資料型別導致crash的例子。如果能整理出來，給RD，讓他們有這個意識，這樣的Bug可以避免。下面這個圖統計的是導致crash的Root Cause有哪些。

· 那些每個Iteration都會出現的Bug。四次迭代，期間都經歷的UI的變動，每次新增一個新的Feature，都會在log資料庫，Notification，隔離資料庫中新增相關的UI介面。你會發現每次那些細微的地方，如log資料庫中的delete records, log records, notification中新加的功能的條目， 還有那個Copy按鈕，RD在第一次迭代的時候，不會注意到這些地方的UI也需要改動，在第三次迭代的時候RD可能換了一個人，這時候他也不會關注到這些地方，這種類似的問題，每次迭代都提，是不是可以在RD在做這一塊的時候，就給予些提醒呢？

· 通過Bug反思測試用例設計。當發現一個Bug並不是通過已有的測試用例發現的(這種情況很常見)，特別是新功能，這時候我們可以回憶下當時設計測試用例的時候，是怎麼想的，當時採用了什麼方法，有沒有更好的測試用例設計技術。上一篇文章講的就是這個問題。

· 通過分析Bug獲得測試經驗。最近在看<探索式測試>這本書，書中講到一些測試方法。比如取消測試法，看看那些提交的tracker, 在安裝那一塊，我們發現有好幾個bug，都是關於“back”按鈕不起作用的。再如，強迫症測試法，我們發現的一個類似的就是，把我們的一個程序reload十次，就crash了，另一個連續敲15次同樣的命令，也crash了。我想說的是這些測試方法，測試經驗的總結，而這些測試經驗的獲取應該是通過與Bug的一次次親密接觸獲取的。

轉載來自：http://www.cnblogs.com/matt123/archive/2012/11/05/2755900.html