從上表可以看到，編碼過(guò)程的缺陷大部分依賴(lài)系統測試發(fā)現。單元測試和集成測試活動(dòng)開(kāi)展不夠深入。我們可以進(jìn)一步分析這些統測試出來(lái)的測試缺陷，是不是可以被更前端的評審/測試/設計討論活動(dòng)所替代。詳細見(jiàn)“四、利用泄漏的下游缺陷回溯過(guò)程有效性”
另外，我們看到，需求階段引入的缺陷絕大部分是在設計階段發(fā)現的。這可能是我們大部分項目的一個(gè)現實(shí)，需求不穩定、需求不明確，很多東西需要在設計過(guò)程中才能明確下來(lái)。也許從這個(gè)分析結果中給我們一個(gè)啟示，我們在設計評審時(shí)候，也需要重新審視我們的需求規格說(shuō)明書(shū)，必要時(shí)候利用需求追蹤矩陣這樣的規矩方法來(lái)輔助我們發(fā)現上游需求的缺陷。把這樣的機制固化起來(lái)，作為我們標準研發(fā)過(guò)程的一個(gè)要素或者過(guò)程指導書(shū)。
當然，實(shí)際規劃“缺陷引入-發(fā)現矩陣”時(shí)，可以依據自己的管理要求，對缺陷的發(fā)現活動(dòng)和引入階段進(jìn)行細分或初分，并且在Bug系統中提交時(shí)，需要準確的填寫(xiě)這些屬性字段。
- 利用缺陷的分布進(jìn)行分析
- 可以選某個(gè)階段的測試缺陷進(jìn)行分析，按照這些缺陷對應的產(chǎn)品組成部分來(lái)匯總這些數據。利用這樣的分布，可以找出我們產(chǎn)品/項目的高危模塊來(lái)。這些模塊導致了我們產(chǎn)品的主要缺陷。主要用到的分析手段是數據透視表和柏拉圖。讓我們看看下面的例子：
這是一個(gè)簡(jiǎn)單的OA系統，它只有5個(gè)子系統。我們把這些子系統各有多少缺陷列出來(lái)，找到了改善質(zhì)量的關(guān)鍵模塊是后臺交易模塊。
延伸閱讀
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/