先寫我的心得：

軟體開發過程中，程式碼是一直在變化的，所以它是一個時變系統(Time Variant)，所以無法找到一個簡易的線性方法來控制它的指標收斂。簡而言之，就是不同時期要用不同的方法。

開發初期or建立測項的初期：

基本功能測試(Functional Testing)

[Index1] 基本功能覆蓋率(總測試案例數/總基本功能數)：
對於QA這個角色的立場來說，我認為其最低要求應該是基本功能覆蓋率=100%，這代表著開發者努力設計的所有基本功能(可以用API來當數量)都至少被測試過一次。但實際上單一個測試案例常常會覆蓋到幾個功能，所以基本功能覆蓋率會低於100%。而且另外一個缺點是這裡只考慮單一功能，沒考慮到組合後的變化。
[Index2] 程式碼覆蓋率(測項跑過的程式碼行數/總程式碼行數)：
這時候可以參考程式碼覆蓋率，這個值愈高，代表程式碼的｢結構｣有愈多部分經過檢驗。但是這個方式並不能對程式碼的｢狀態｣檢驗過，畢竟在程式碼中的變數在不同的狀態所組合出來的變化是可能引入各式各樣的問題。

整合測試(Integration Testing)

為了考量不同的狀態所組合出來的變化，需要引入不同面向的思考，考慮各種不同使用情境來進行不同程度的整合測試，例如：

多組態測試(Configuration Testing)：不同chipset、不同記憶體高低配置、不同零件的組成

效能測試(Performance Testing)：除了一般的效能檢驗，其中還可以包括多使用者負載下的效能檢驗

壓力測試(Stress Testing)：非預期或高CPU Loading、注意記憶體洩漏、多Process下的情況

長時間測試(Long-Haul Testing)：與壓力測試不同，只是在長時間不關機下有無時間的因素會引入的問題，例如某些變數累積量超過預期、特定時間點才會引發的問題

基於真實使用者資訊所進行的測試(Scenario Testing/Validation Testing)

權限測試(Privilege Testing)：考慮各種安全性因素 g.邊界值測試(Boundary Test)

正向測試與反向測試

錯誤處理穩定性測試(Force Error Test)：使用故障注入(Fault injection) 的方式，故意去改變一些內部的數值，確認軟體是否能處理錯誤

舉例：若某軟體專案需設計 100 個軟體模組(或元件、class) ，那至少需要 101 個測試案例。其中 100 個是以 class 為單元的單元測試案例，以及 1 個整合後的軟體系統測試案例。但是這樣還是遠遠不足的(也許只達到所有可能性的30%而已)。
所以這個階段的指標應該是

[Index3-1] 總整合測試案例數
數目愈多愈好。

或是

[Index3-2] 整合測試佔比(總整合測試案例數/總測試案例數)
一個經驗參考數值是15%~20%，缺點是毫無理論基礎(呵呵…)。

程式碼穩定期、維護期：

[Index4] 測試案例執行率(測試案例總執行數/總測試案例數)：來代表測試檢驗工作有無做完整。
[Index5] 測試案例通過率(總通過測試案例數/總測試案例數?????)：假設上述面向都被好好考慮過了(測
試案例的完整度很高了)，並產出了某個數量的測試案例，那麼就愈來愈可以用來代表軟體品質。
[Index6] 近期程式碼動盪值(Code Turmoil)或程式碼翻動量(Code Churn)，即變動的程式碼行數(loc: lines of code)：引用文章用的風險指標之一
[Index7] 近期新發現的問題數：引用文章用的風險指標之一
[Index8] 仍未被解決的問題數：引用文章用的風險指標之一
註：

P0：致命的 (fatal bug)，出貨時一個也不能有
P1：嚴重的 (critical bug)
P2：一般的 (major/normal bug)
P3：次要的 (minor bug)

結論：

綜合以上，測試案例的完整度才是軟體品質管理的適當指標(愈完整則軟體品質愈易被管理，換句話說也就是品質愈沒問題)，但實在它是太難度量，所以只能依賴上述那些指標來綜合評估。
引用文章(在下方)用的風險指標算是另闢蹊徑，滿實際可行，且不用花太多心思去收集就可以得到的數據。

引用文章出自 http://www.qa-knowhow.com/?p=1658，圖表請到原站觀看

到底目前軟體品質的狀況如何? 軟體品質指標

這篇文章主要說明”軟體品質指標”的一些應用。
軟體開發的過程中，是不是有什麼軟體品質指標可以讓我們知道目前軟體品質的狀態? 甚至用來決定是不是可以到了出貨的品質。這也是 QA team 的挑戰。因為程式大部分都不是 QA 完成的，但是最終需要對於軟體品質狀態提供一些專業的分析。
定性 vs 定量
要建立軟體品質指標，又分為定性與定量。
定量的資料比較客觀例如：
Number of submitted defects
Number of rejected defects
Number of known issue
Number of P1/P2 cases
Line of Code changes
….
定性的資料可能有些主觀成分，例如：
Uncertain Technology
Cross team collaboration
Legacy code integration
Customer requirement changes
….
這些都會對於整體的軟體品質直接或是間接影響。
因此如果要訂定軟體品質指標，筆者建議，依據專案要達成目標的屬性，針對該目標延伸相關的指標。舉例來說，這次專案的主軸是 — 根據上一版客戶需求做修改。因此，這次品體品質指標可以專注在於滿足客戶需求的 cases 軟體品質並非追求零瑕疵，而是追求在當下相對穩定，符合客戶需求的品質。因此出貨時，我們主要需要掌握的是 “風險”。到底有哪些是已知的風險 (如雷達圖)或是未知的風險我們需要”共同”承擔。
品質是大家一起的責任而非品管部門
到底有沒有一個計分指標，可以客觀的說明整體專案的品質? 沒有 !
但是這邊筆者建議一種方式，可以建立起這樣品管指標的方法。
風險分析雷達圖
這邊筆者建議另外一種方式，為品管風險分析雷達圖。也就是說在特定的時間點時，目前軟體的品質風險為何?
可以將軟體品管的風險分為五大類 (讀者可自行調整，新增或是修改)
Code Turmoil : 程式碼修改的狀態。如果要快出貨但是還是有大量的程式碼修改，那麼品質風險就相對會提高。
Test complete Rate: 測試個案完成率。最後一個月快要出貨時，但是有大量的測試個案未完成，也表示品質有一些未知的風險。
Test Success Rate: 測試個案成功率。如果有大量的測試個案測試結果都是失敗，也表示品質風險提高。
Total Open Defect: 目前尚未解決的Defects。如果有很多都是 P1/P2 的 defects，也是一個客觀的品質風險。
Defect Found this Week: 這星期新發現的 defects。如果要出貨前夕，還是有大量新的問題被找到，那麼品質風險也相對較高。
這樣的圖如下所示。每一個類別越接近 6分，表示該項目品質風險越高。
例如這個圖表示，現階段有大量的程式碼異動，而且有許多新的問題在這個星期被找到。
Quality Risk Metrics
如果將這五大類別分數加總，就會得到一個整體的品質指標。品質風險最高為 6 x 6 = 36
隨著時間經過，就可以追蹤整體品質指標的狀況。例如這個例子，從一開始高風險 23 一直到最後風險降低為 6。要強調的是，我們不是為指標而工作。這只是方便整體團隊瞭解品質的狀態一個簡便的方式。最終軟體的品質還是以達到客戶與市場的目標為最終目標。而非一昧地追求這個數字。
Quality Risk Metrics over time
那麼要如何將這五大類產生出 0~6分的指標呢? 首先，要定義每一類別 1~5分的標準，舉例如下：讀者可以依據實際專案的狀況作調整。
RD 的工作: Code changes, Defect Found This week, Total Open defects如果這幾項很高，表示接下來的一個星期 RD 工作量會比較大。
QA 的工作: Test success rate , test complete rate，這兩項表示 QA 接下來的工作量。如果完成度很低、測試個案失敗很多，表示專案接下來會有比較多的QA工作要完成。
Quality Rating
小結
軟體品管有沒有一個指標可以代表品質? 沒有!
軟體品管主要在於掌握已知與未知的風險，最終出貨與否還是要客觀的評估市場與客戶對於產品品質的認知與接受度
如果真的要將品質指標量化，這篇文章建議一個雷達圖的方式，可以將軟體品質分為六大類，根據每一類定義 1~6的品質指標，最後加總。
最後，軟體品質是大家的責任，並非一個指標或是一個功能團隊所決定!