【轉載】關於軟件測試的幾點思考

      無心中在csdn博客上看到邱鵬寫的一篇博客，關於關於軟件測試的幾點反思 - 測試工做的三個階段，發現和本身的想法不謀而合，整個思考模式和方向和我在某公司實習的時候是同樣的，百度之，真的是該公司的高級測試人員。看來我有找到一位大神了。向大神學習，向大神看齊。關於測試的反思寫的不錯的，我想將齊摘錄下來，固然也能夠到原址去看。

測試的三個階段

第一個階段：發現和解決bug的階段
     這個階段的思路基本上儘量發現更多的bug，見一個滅一個，來兩個滅一雙。發現bug，解決後驗證bug，沒有任何根源性的推進，或者推進的效果很差。
     這個階段，測試工做主要集中在發現bug，要作好這個，須要多個方面的努力，好比下面這些：
- 更高效的發現bug，考驗測試設計的能力。
   這方面有很是多的方法和技巧，以及經驗，這裏不細說。
- 發現bug以後如何清晰的描述，定級，以及跟進和驗證。 
   這個看似簡單，可是你會發現不少測試工做作了幾年的人這樣的基本功仍是不夠紮實。也可能沒有受到過很好的訓練或者一直沒有人指導。
- 對業務和架構的理解能力。 
   沒有這方面的能力，很難發現一些深層次的bug。而這樣的能力對於快速學習和一些技術基礎也有不低的要求。
- 發現bug以後若是觸類旁通的儘早發現更多相似的bug。

     你們看到的不少經典的測試書籍講的基本都是這個階段作的事情，好比Software Testing，How We Test Software at Microsoft，以及探索性測試相關的書籍，都是專一在如何更高效的發現缺陷。

     上面這些東西都是一個業務測試人員的基本功。看似簡單，可是作好並非一件容易的事情。也許這些事情一點都不cool，不sexy，甚至去作職級評審的時候不佔優點，可是對於系統質量的提高，是切切實實帶來很大幫助的，其工做的價值應該獲得承認。可是若是一直停留在這個階段，就陷入到上面例子中說的掃馬路的階段，由於若是沒有其餘方面的改變，每次都有那麼多的bug。

不過不少時候，咱們的測試停留在這個階段也是由於現狀，考慮下這樣的狀況：
- 開發基本不自測，甚至沒有自測的環境，特別是涉及多個系統的對接。
- 提測後不少基本的功能都不能正常使用
- 項目管理比較混亂，可是最終的發佈日期又被老大們定死，因此測試時間經常被壓縮
並且，並且沒有對於開發人員的質量方面的考覈，那麼很長一段時間，咱們的測試將處於這個初級階段。
（這也是該公司目前的一個現狀啊）
我相信目前還有很多的團隊是處於這樣疲於應對的狀況下，不僅是小公司，可能一些大公司的部分項目也是如此。隨着整個研發體系的發展和深刻，咱們應該有更高的追求。

第二個階段：質量的管理
    在第一個階段中，可能有一些人會停下來想：咱們一直這樣下去也不是個辦法？有沒有更好的作法呢?

    最直接會想到的就是，怎麼讓別人少丟垃圾，讓自己的bug就更少一些。若是咱們作的工做只是發現bug解決bug，那麼就是一個消耗戰。不能造成一個良性的循環，就不能持續的優化，工做的長期累積價值就體現不出來。
這個階段核心的思路是對缺陷作分析和考覈，並作研發流程中主要問題的梳理和改善。

    經常作的事情能夠從下面幾個方面來看（這裏會是主管以上的人來負責）：
1. 作質量數據的統計和分析
    收集的數據不少，常見的有：
     - 外網的bug狀況，包括事故，及影響的程度
     - 測試階段的bug數量，分佈（按系統，團隊，開發我的），嚴重程度，bug的類別等維度
     - bug的橫向跨團隊和系統的對比，縱向的和歷史狀況對比
     - 版本發佈的狀況，代碼變動行數的狀況
   從這些數據的收集中就能發現不少問題，好比問題集中在哪裏，哪些模塊，哪些人，哪些類別等等，以及有沒有改善。

2. 問題的追溯和對於開發的考覈
     這個方面也許有一些爭議，可是我仍是以爲這個是一個很重要的方法。光靠觀念和自覺是不夠的，必須要有必定的反饋機制，就比如交規必定是配合着扣分和罰款等手段，不然記錄闖紅燈有什麼意義呢？並且現實的來講，這些方法起到約束的做用，也是一種心理暗示，要作本身作的東西負責，也便於養成好的習慣。
    一般的考覈指標涉及這些方面：
    - 編譯失敗次數的考覈
    - 外網事故和bug的數量
    - 測試階段的bug，特別是基礎功能bug和嚴重bug
  粗略的列了這麼多，其實能夠有不少，好比配置文件改錯的狀況，漏提測文件的次數等等。

對於bug方面其實也是同樣，若是開發在意（或者被迫在意）外網bug或者被測試發現的bug數量，他寫代碼的時候必定會更仔細，也會作些簡單的自測，讓提測的質量更高，提升了整個研發系統的效率，同時也是提高了質量，由於quality must be built in。

我我的的經驗，做爲測試人員幾乎同時面對過兩個開發團隊，一個有上述的考覈，一個沒有。表現出來的版本質量和對質量的關注徹底不同，並且前者也並無出現開發和測試的對立，以及測試不敢提bug等負面的狀況。

3. 對於測試的考覈
      除了對於開發的考覈，一樣也有對於測試的考覈，這樣也更加的公平。
測試的考覈一般考慮下面的指標：
     - 漏測：絕對數量或者漏測率
     - 版本的工做量和測試效率
     - 發佈延期的狀況
若是測試有這樣的壓力，也須要不斷努力去發現更多的bug。

      提及考覈，總有人以爲這不符合智力勞動的狀況，或者互聯網的做風，其實不太理解爲何會這麼以爲，放眼望去，有什麼工做不被考覈呢，sales要背quota，爲何軟件開發和測試不能對本身的工做的質量負責呢？固然，具體的指標如何去定才更合理那是另外一個要去考慮的。
      換個角度來看，適當的壓力（不該該致使焦慮和扭曲的作法），實際上是讓一我的表現最好的狀態。

4. 推進開發的自測
     這個問題一貫是個老大難問題。願意自測的開發團隊你不用太多的推進，不肯意作的推進也很難，或者你沒法判斷他有沒有作自測。並且這方面，一般取決於開發負責人的觀念和態度。
若是是介於之間的，咱們能夠作一些事情，好比：
    - 統計測試階段的bug中，屬於開發可自測發現的比例。經過這個能夠看有多少bug是不該該到測試階段的，以及橫行縱向的對比。固然這個標準要本身拿捏。
    - 給出一個自測的checklist。開發在提交前要完成這個list並正式的給出報告。這個方式咱們曾經在一個項目中用過，效果不錯，基本功能都經過這個保證了，前提是開發負責人承認。
    - 有一套自動化驗收的用例，能夠掛接到自動部署以後或者daily build。前提是咱們的自動化要足夠的問題，效果纔會好。

     這個階段除了業務測試的努力，也體現出了QA的價值。這裏的QA是指質量管理，有的地方叫SQA，專一在質量度量和研發流程的管理上。

      到這個階段，發現事情順了不少，質量也有更大程度的提高，並有改善的趨勢。

 

第三個階段：推進全面的質量提高
      到上面第二個階段，咱們發現質量有了必定的提高，可是仍是有很多的問題，並且有些問題須要咱們把思路和眼界拓寬來看。這裏討論的一些東西可能更適合互聯網的產品。
      這裏列一些咱們能夠去作的事情，受限於我的的經驗，可能還很片面。

1. 研發流程的梳理
其實在階段2的時候也可能有些團隊已經開始作這樣的事情，由於在分析質量和效率問題的時候，咱們發現不少問題不單純是代碼的問題，可能還涉及研發流程的不少方面，好比：
  - 需求不清楚
  - 跨團隊的配合問題 （這是一個老大難的問題）
  - 代碼版本管理
  - 技術方面的評審和你們的理解
因此整個研發流程的規範和梳理，以及配合對應的需求和版本管理的系統也是很是的必要，實際中發現效果也是比較的明顯。並且還有一點體會，在接手一個很混亂的情況時，這樣角度的數量和調整比技術方案的引入更重要和切中要點，能從40分到60分，技術是往80分走的過程效果更明顯。

2. 提交測試先後作的一些事情
  - 代碼的靜態掃描
     這個方法不少的團隊都在作，可是實際的效果彷佛差異不少，並且ROI也很難說，不過從方法自己來講仍是值得去作的，對測試人員也提出來更高的要求。
  - code review
     這個開發應該要作，特別是開發間的交叉review，很是的有幫助。不過這個也和自測同樣，取決於開發負責人的態度。另外，測試也應該去作，特別是對於diff 代碼的review，咱們檢查作了大概兩個月的時間，發現仍是很是的有收穫。發現了一些黑盒難以發現的問題，以及開發的代碼夾帶，而且對於這個版本影響範圍的評估也更準確。但問題是短時間會花費測試更多時間，以及須要測試人員有必定的技術能力。

3. 測試能力的提高
    測試階段有不少的事情能夠去作，以爲最主要的仍是兩個方面
     - 自動化。 愈來愈以爲這個是繞不開的話題，要想盡辦法去作，作得更高效更全面。前面有篇blog也提到了一些輕量級的作法，業務測試的團隊能夠參考 http://blog.csdn.net/superqa/article/details/20644285
     - 輔助手段，好比代碼覆蓋率，特別是差別的覆蓋率。這個你們都比較容易理解就不展開了。
     - 拓展測試的類型
     這個方面提及來有些泛，須要結合團隊和業務的狀況，好比安全測試，性能測試，兼容性測試等，去發現一些對於產品來講很重要的風險。
     這方面有兩個前提，一是咱們的基本功能質量到了一個階段，可讓你們騰出手去拓展測試的面，另外一方面咱們測試人員的能力要跟得上。

4. 發佈環節的質量把控
     這個方面和傳統的測試不太同樣，並且瞭解到不一樣的組織作法不一樣，執行發佈的人員可能不一樣，有開發，運維，專職的版本管理或者測試來作。
     在咱們的實踐中，發佈後來都逐步收到測試這邊，回頭來看以爲仍是有很多有幫助的地方。固然也不絕對的必須測試來作。
      - DO分離，避免了隨意的發佈，特別是在開發手上的時候。全部的bugfix都通過測試發佈，能夠更準確的度量質量（除非這個問題能夠不修復，不然確定要過發佈環節）
      - 知道最近發了什麼，可能的影響是什麼，須要線上關注什麼。
      - 灰度。 互聯網產品經常使用的一個控制風險和節奏的手段。
      - 擴容的快速自動化檢查，這方面也依賴於自動化的建設。
      - 發佈過程支持灰度的控制，備份和快速的回滾。對發佈系統有必定的要求，並且有可追溯性。

發佈處在整個研發流程很是關鍵的節點，在這個點能夠作不少的控制，也能發現不少的問題，對於測試團隊來講，從這裏能夠發現不少的問題，作不少的提高，對本身和相關的合做團隊。

5. 外網的監控
    發現發佈後的問題，持續運營過程當中的問題，推進優化。
    一般監控能夠分幾個層面，粗淺的能夠分紅幾類：
    - 運維層面的監控，好比機器，鏈路，資源使用，主要組件是否正常等。
    - 業務指標的監控，好比來自點擊率，BI系統等。
    - 集成在產品裏面的監控代碼，咱們稱之爲模塊調用監控。這個是全量的，有次數，成功率，響應時間等角度。  
    - 測試層面的自動化監控，關於在接口和功能層面。這個是採樣的，可是從用戶的角度來監控。
      以上這些監控都有對應的告警機制，能夠第一時間發現問題，避免形成更大的損失。爲了實現上面的監控須要作大量的工做，可是這些對於整個外網運營的質量很是的重要。

6. 外網事故和問題的收集，跟進和反向推進
     和前面的思路同樣，若是隻是發現問題解決問題仍是稍顯被動，那麼對於外網事故和問題的分析，仍是有不少推進性的幫助。

7. 用戶的問題反饋和滿意度
     進一步的質量不僅是系統自己的質量，而是從用戶角度看到的質量，有時候這個可能稍微超出一些系統層面的問題，可是由於最終的質量仍是用戶說了算，因此咱們應該擴展下思路。收集這樣的問題的渠道有不少
     - 外網問題反饋，好比來自客服系統的，用戶直接的反饋，如今不少app上都有反饋的功能。
     - 論壇信息的統計收集。我瞭解的另外一個測試團隊，他們還專門開發了一個自動收集外部反饋，以及過濾分析的系統來幫助他們及時的瞭解外包的問題反饋。

8. 運營層面的質量
  更進一步，關注運營方面的質量，跳出傳統意義的質量的範疇，關注咱們的業務指標，不僅是作一個高質量的產品，而是作一個業務上成功的產品。
   好比下面這樣的例子：
     - 商品詳情頁的圖片的質量
     - 活動頁面和詳情頁面價格不一致的狀況
     - 運營配置的錯誤致使的問題，哪些是能夠監控發現，哪些是能夠推進運營平臺的規則檢查?

      每次咱們的思路跳出一些框框，都會有不一樣的領域。有點點哲學上的意味，不少領域作到後面，其實會超出那個領域自己的範疇。就比如高性能的汽車，到後面就不得不研究空氣動力學這個本來是和航空有關的東西。可是，這是否超出了本意，若是去看待，又是另外一個問題。

       其實這樣的三個階段也是一個粗略的劃分，並不必定要逐步的來發展，其實都是一些具體的作法和實踐。以我目前經歷過的實踐只想到這樣的層次，應該還有更高級的階段。
       咱們越到後面咱們發現進一步的努力帶來的提高幅度其實不大。可是不少事情也是同樣，從85分到90分付出的努力可能比50到80分的努力還要大。另外一個更有趣的是汽車的極速和馬力的關係，家用車100馬力開到180km/h是能作到的，可是超過期速300，每提高一點須要增長的馬力要大得多，到400以上，車時速每再增長一千米，功率須要提高八馬力。這篇文章讀起來很是有意思，http://blog.sina.com.cn/s/blog_4d0109a301000ajz.html

       寫到這裏，咱們能夠跳到整個公司或者業務的層面，來思考一些對於測試更深層次的問題：測試團隊存在的價值和意義是什麼？
       只有對業務有明確的價值，業務測試，或者說整個測試團隊纔有存在的意義。只要業務OK，砍掉測試團隊也不是不可能。咱們必須時不時的跳出咱們本身的思惟的圈子，站在整個事業部老大的角度來思考下測試的價值和意義。
在下一篇關於測試組織方面咱們能夠再討論下這方面的內容。
  
      還有一個體會：測試的水平反應整個研發體系的能力和水平。
      若是咱們的測試還專一在第一階段，那說明整個研發還比較初級，開發和測試都是溫飽的階段。當咱們的測試人員再也不趴在地上盯着最基本的功能質量的時候，纔有可能擡起來看看更多有價值，有幫助和有長遠意義的工做，慢慢造成一個良性的循環。