Bug 數量與軟體品質控制

我日前看了「那些 Bug 是怎麼找來的？」這篇文章，裡面提到用 Bug 數量作為軟體品質的管理指標。管理學有云「可量化者方能管理」，可量化者就是指標項目，諸如一小時的產品生產數量、一天完成的工作項目等等。然而，錯定指標的例子也比比皆是。在軟體工程上，最經典的採用不適當管理指標的案例，就是用「程式行數」來管理工作進度了。就我所知，在理論或實務上，都不是用 Bug 數量作軟體品質管理的指標。此處所說的軟體品質管理，指的是開發過程中的品質管理，交貨時，理論上是無 Bug 的。既然選擇了不適當的指標項目，自然就產生「Bug 多，品質好；Bug 少，還是品質好！」這種無助於管理的結論。

測試案例 (test case) 才是軟體品質管理的適當指標項目，更嚴謹地說是測試案例的完整度。舉個簡單例子，如果某軟體專案需要設計 100 個 class ，那麼就至少需要 101 個測試案例。其中 100 個是以 class 為單元的單元測試案例，以及 1 個整合後的軟體系統測試案例。這樣還只能給 100 分中的 30 分而已。要達到 60 分的合格標準，還要有根據使用案例與活動關係圖設計的單元測試案例，而整個軟體系統也要有處於臨界值狀態的壓力測試案例。測試案例愈完整，則軟體品質愈容易被管理，亦即管理者可以從 xUnit 之類的測試工具的日報表中，看出昨天有哪些 bug 不在今天的報表中。完美情形下，會得到一個收斂的月報表，不會有 bug 忽隱忽現 (前天出現、昨天不見，今天又跑出來) 。

就我個人看法，測試案例的內容，應該由資深的系統分析師、或者是編寫軟體規格需求的人決定。例如當系統分析師決定專案中需要一個使用者輸入介面的視覺化控制項時，就等於決定了這裡需要一個測試案例，當然系統分析師應該要描述這個測試案例的內容。這個工作，要先於 coding ，不能等到開發小組實作時才決定。至於實作測試案例的人員，可以是開發小組本身，也可以是獨立的測試小組。在強調模型驅動開發架構 (MDA) 的 RUP 中，甚至可以在塑模作業時，就同時評估出應該要有多少測試案例。「從用例到測試用例的追蹤」是一篇非常好的文章，很漂亮地說明了如何從 Use Case 決定 Test Case ，從而實現一個有效的軟體品質管理目標。

樂多舊網址: http://blog.roodo.com/rocksaying/archives/2121217.html

樂多舊回應

jonachen@gmail.com(喲哪桑) (#comment-3125436)

Fri, 22 Sep 2006 12:00:21 +0800

Hi 石頭君,

大概是ithome的trackback不work吧！直到今日我才注意到您的看法。

我以為，Bug 數量作軟體品質管理，是很常見的，至於合不合理，是另一個問題。例如，我們設一個品質目標︰沒有發現新的Bug時，才能交貨，這也是用Bug數量來做管理的例子。此外，很多人用軟體出貨後所發現的Bug，做為品質的指標，這個指標當然有意義，但可能為時已晚。

Bug 數量有非常多應用。每週發現的新bug、有待處理的bug、已發現bug的總數，都有其不同的管理應用方式。如您所說的測試案例 (test case) ，我也會拿來配合每週發現的bug數來一齊比對。例如，每週發現的bug數愈來愈少，呈現一個收斂圖形時，我也會檢查，每週所規劃的test case數、每週所執行的test case數，是否也有穩定的成長。如果收斂的bug數是來自於測試不完整，那就有疑點了。

Just my 2 cents!

未留名 (#comment-3128886)

Sat, 23 Sep 2006 00:16:05 +0800

我雖然有做 trackback ，但 ithome 的 trackback 好像沒作用。

以我 MBA 的知識，加上個人的 programming 經驗，以 Bug 數量作為「軟體品質管理指標」的效果是很差的。一個 newbie programmer 可以在一天內搞出100個 bugs ，又在一天內全部被 senior programmer 修正。但有時一個 senior programmer 也會被一個 bug 困住好幾天。這樣能夠衡量什麼呢？也許更適合作為 programmer 的技術指標吧。

從 PM 的角度來看，以使用者和開發者都認可的 use case 為準，必須在此 use case 的範疇下無 bug 才能交貨。因此開發者關心的應該是開發過程中的 bug 。交貨後才發現的 bug ，確實「為時已晚」。

不過我觀察國內的 case 好像有個現象，使用者不參與 use case 內容的，彷彿使用者跟這軟體沒關係。依據開發者單方面規劃的 use case 來撰寫 test case ，通常驗收時都可以過關，等使用者實際上線後問題百出再來修正。這種現象好像很正常，但我個人總覺得哪裡不對。

未留名 (#comment-3153716)

Wed, 27 Sep 2006 18:32:46 +0800

Echo你一下: 的確, 在PSP(Personal Software Process)裡, 每個工程師的defect rate, 是工程師衡量自己的指標之一. 很多人立刻會跳腳, 怎麼可以這樣做? 這樣還有誰敢寫code? 不過, bug本就是人寫出來的, 再厲害的投手也不可能永遠不失分, 但還是要衡量自己, 才知自己好不好, 以求技藝的進步.

至於你最後的疑惑, 其實, use case 本就是user's case, 沒有 user, 真的很怪, 卻是事實. 曾聽某位PMP界的大老說, 在台灣, 甲方的問題, 比乙方大的多, 但是大家都在改進乙方, 甲方沒在改進. 你覺得呢?

未留名 (#comment-3156101)

Thu, 28 Sep 2006 01:46:20 +0800

完全同意。這讓我想起來獨孤木在 Taiwan.CNet 上發表的一篇專案管理文章。當初看到這篇文章時，差點笑翻。這種典型的上班族笑話，沒有親身經歷過的人看不出笑點在哪。

甲方 (使用者) 在看到乙方 (軟體開發廠商) 的雛形之後，往往就會產生先入為主的印象。雛形不好看，甲方就認為這乙方能力不行；雛形太好看，甲方就會對結果產生不切實際的期待。動輒得疚，兩面不是人。

我原本以為塑模工具的使用，可以減少這個問題，甚至可以讓使用者自己塑模。但我的想法在實際進入軟體產業後，被批評「太前衛」，實際上連乙方自己都不用塑模工具，又如何能指望甲方會用？這又牽扯到國內資訊教育的問題了，甲方接口單位通常是甲方的 MIS ，通常跟乙方一樣是資訊科班出身，但依我側面了解 (我不是資訊科班出身的) ，國內資訊教育對「資訊軟體的生產過程」這方面的知識可說是付之闕如，也難怪甲方無法參與開發流程，甚至參與後反而成為專案的阻力。