你的項目統計這些資料嗎？(2)到底應該測試多少（1）——盡量的全面到底應該測試多少（2）——不要放過細節

前面我們曾經講過《你的項目統計這些資料嗎？》，這裡我們在補充一些內容。

1. bug原因分類

    bug產生的原因只有一種，那就是代碼編寫錯誤，沒有什麼設計錯誤還是需求錯誤之類的荒謬分析。如果牽強的分類會發生什麼情況，程式員為了減輕自己的責任，將問題盡量的歸結為：

     設計不充分 —— 設計人員的問題     需求不明確 —— 需求分析人員的問題
     測試案例不足 —— 管理員的問題——他沒給我足夠的時間用來測試。

然而這些統統都不是問題的真正原因，bug產生的原因就只有一種：代碼書寫錯誤。
     比如那個二分法尋找的著名bug：

     mid =  (left + right) / 2;會導致當left + right > Integer.Max的時候產生負數，從而引起數組越界。

     如果讓你來分類你會怎麼分？
         - 設計錯誤         - 基礎API不熟悉
         - 測試案例不充分
     是三個常見的分類方式。然而這麼分類的意義何在？
      設計錯誤，那以後就能夠規避設計上不出錯誤嗎？
      API不熟悉，那以後就能夠加深API的理解嗎？
      測試不充分，那以後就能夠做充分的測試嗎？

      答案都是否定的，因為
       引起設計錯誤的原因是時間不足，所以複查不充分。
       實際上作者可能知道>>>的用法，但是沒有考慮到這裡的越界情況，如果給他足夠多的時間（據說發現這個bug用了12年）
       測試不充分的原因仍然是時間不足。

      所以，代碼的Bug就是代碼的bug，不應該歸結為其他原因，這隻是編程人員減輕自己責任的一個借口而已。

2.bug產生階段分類

     做這個分析的目的是為了從上層來更早的提高品質。然而，只要把軟體工程分階段了，就違背了把品質更早的提高這個目標。這個將在《荒謬過程》一文中詳細闡述。

     所以與其做bug產生階段分類，不如想想如何才能夠去掉階段吧。

     更何況，每次項目統計出來的資料總是差不多，也就是分析了也沒有改進，那麼分析有什麼必要呢？

3.各階段工時分布

    和上述問題一樣，把軟體開發分階段就是違背了早期提高品質這個目標的。所以，也沒有必要統計各個階段的工時分布，況且，統計工時還需要耗費工時——這也是目標和行為背離的一個行為。

4.bug未發現的原因

   bug未發現的原因也只有1個，那就是測試不充分。   統計這個資料的原本目的是為了能夠通過bug未發現的原因進行分類分析，從而能夠提升品質，減少提交給客戶的bug數量。然而，這一統計本身並不能達到這個目的，反而只是浪費工時而已。
   請參照《到底應該測試多少（1）——盡量的全面》和《到底應該測試多少（2）——不要放過細節》這兩篇文章來看看測試中到底有多少遺漏。另外，迴歸測試的時候採用影響性分析——>有選擇的測試這種懶人思維也是導致測試不充分的原因。

   所以要想盡量減少遺漏給客戶的bug，那就從如下幾方面著手吧：

    A.增加測試案例種類
    B.改進測試手段 —— 引入自動化的測試，以降低迴歸測試成本
    C.改進測試流程 —— 不論何時提交，都要全面測試

   否則，做bug未發現原因分類這種分析也就是聊以慰藉而已。

5.Review的問題分類

    Review的時候問題可能分為：風格的問題、邏輯的問題、規範的問題、需求吻合度的問題等等若干種。但是做這種分類的意義只在於證明做了很多機器應該做的事情。

    關於這一點將在《走馬看花的代碼複查》中詳細闡述。

   Review的問題應該只有一種：耦合度偏高

   風格的問題、規範的問題屬於機器的工作，需求吻合度不應該在Review時才發現。而邏輯的問題通過Review發現的可能性很小。只有耦合度問題可以在Review中最容易發現，也應該在Review中發現。

6.文檔頁數

   文檔該不該寫都有一定的疑問，更何況去統計頁數。另外，頁數是一個很不靠譜的概念。字型的大小，間距的大小，換行的頻度都可能會影響文檔的頁數。更為重要的是，統計文檔的頁數對於軟體品質改進或者流程改善毫無協助。