讀書筆記 -《代碼大全》第20章軟件質量概述

這一章主要給我們講了什么是軟件質量,它有哪些特性,如何保障軟件質量,也就是有哪些活動、技術可以保障軟件質量,以及何時采用什么樣的方法、技術來保障軟件質量,我們怎樣組合這些技術才能達到最大效能等問題。

整章的描述都圍繞著這樣的問題,甚至整本代碼大全其實都是在尋求這些問題的解答。但本書闡述的大多是從過往經驗中抽象出來的問題,比較理想化。書中并沒有講到如何把學到的知識應用于實際情況中。而實際情況無疑是復雜的,因人而異的,甚至是難以協調的,那么除了要把這章知識學透,還應該更多思考我們在日常事務中如何很好地運用這些知識,以創(chuàng)造出它應有的價值。


軟件質量的特性

軟件質量,顧名思義,指整個軟件系統(tǒng)的質量。面對日益復雜的軟件系統(tǒng),我們描述它的質量已經不能用簡單的幾句話下定義了,應該要從不同方面來衡量、定位,那么這不同方面或說指標都有哪些呢?
本章從外在和內在兩個層級來描述軟件質量特性,而它們內部又分為很多種具體的特性,從不同的角度闡明了軟件質量的方方面面,也讓我們可以從不同角度去觀察并且從不同角度設立不同的質量目標。

  • 外在特性(用戶關心的)
  • 正確性
  • 可用性
  • 效率
  • 可靠性
  • 完整性
  • 適應性
  • 精確性
  • 健壯性
  • 內在特性(程序員應該關心的)
  • 可維護性
  • 靈活性
  • 可移植性
  • 可重用性
  • 可讀性
  • 可測試性
  • 可理解性

后續(xù)的質量保障工作其實就是圍繞這些質量目標來進行的。所以在執(zhí)行質量保障工作之前,首先是目標先行,有了目標,做事才能有的放矢,效率才高。
但是因為這些質量特性之間有相生也有相克的,再加上現實情況的復雜,而且投入的資源和成本的有限。那么我們不可能完成所有這些質量目標的。所以回到了一個權衡的過程,而往往最難的一步就是根據實際情況做出權衡。


改善軟件質量的技術

找出了質量目標,接下來就是訂立質量保障計劃。
實施質量保障計劃需要引入一些有效的質量保障活動(技術)。這些技術都有哪些呢?

  • 設立明確質量目標
  • 明確定義質量保障工作(讓員工知道質量應當放在第一位)
  • 測試策略
  • 軟件工程指南(問題定義、需求分析、架構設計、構建以及系統(tǒng)測試)??
  • 非正式技術復查(code review,互相走讀,結對審查)
  • 正式技術復查(會議評審代碼?或專門的工具過代碼?)
  • 外部審查
  • 開發(fā)過程
  • 對變更進行控制的過程
  • 結果的量化(參見《Principles of software Engineering》有關度量質量特性的詳細內容)
  • 制作原型
  • 等等

不同質量保障技術的相對效能

根據過去的統(tǒng)計,不同質量保障技術,效能是不一樣的。下面我們從以下幾個方面來衡量它們的“效能”:

  • 缺陷檢測率
  • 找出缺陷的成本
  • 修正缺陷的成本

缺陷檢測率的對比:(一張圖足以說明問題)

各軟件檢錯措施缺陷檢測率.png

所以單獨使用一種技術,最好的檢出率也才65%,達不到很好保障軟件質量。所以需要綜合運用各種技術,向更高的缺陷檢測率發(fā)起沖擊。
書中介紹了極限編程的平均缺陷排除率為90%,最好的情況可達到97%,是一個值得推薦的開發(fā)方法,它運用了如下這些保障技術組合:
極限編程缺陷檢測率.png

很多人將這一效率歸功于極限編程實踐中的協作,即結對編程。

找出缺陷的成本
查找缺陷的成本受到諸多因素影響,舉幾個例子:

  • 特定的檢測技術所能找到的缺陷總量
  • 缺陷被發(fā)現時所處的開發(fā)階段
  • 經濟因素之外的其他因素

大部分研究(具體指哪里的研究?是否真的靠譜?這是值得考究的問題)都發(fā)現,檢查比測試的成本更小。閱讀代碼每小時能夠檢測出的缺陷要比測試高出80%左右(Basili and Selby 1987)(1987年的數據是否還適用于現在?)。后來,IBM的一項研究(樣本量多大?具體什么樣的研究?使用了什么方法做研究?)又發(fā)現,檢查(手工閱讀代碼?)發(fā)現一個錯誤只需要3.5個工作時,而測試則需要花費15~25個工作時(Kaplan 1995)。

修正缺陷的成本
一個缺陷存在的時間越長,消除它的代價就越高昂。因此能夠盡早發(fā)現錯誤的檢測方法可以降低修正缺陷的成本。
這里又要拿檢查和測試做對比了,首先如代碼檢查,一舉可以確定問題的現象和原因;而測試,則只能發(fā)現問題表象,而要找到并從根本上修正缺陷還需要額外的工作。

微軟應用部門發(fā)現:代碼復查(review)投資回報率達到1.38,而測試只有0.17。

推薦的聯合技術:

  • 對所有的需求、架構以及系統(tǒng)關鍵部分的設計進行正式檢查
  • 建?;蛘邉?chuàng)建原型
  • 代碼閱讀或者檢查
  • 執(zhí)行測試

什么時候進行質量保證工作

盡早捕捉錯誤才能有效地節(jié)省成本。

  • 需求中一個缺陷會孕育出設計上的一個或多個缺陷,而這些設計錯誤優(yōu)惠繁殖出更多的代碼缺陷。
  • 需求中一個錯誤會導致多余的架構設計或錯誤的架構決策。多余的架構設計又導致多余的代碼、測試用例和文檔。
  • 一個需求上的錯誤可能產生最終不得不被拋棄的架構、代碼以及測試用例。

在早期就開始強調質量保證工作,貫徹整個項目,在開工時添加到項目計劃中,并應該作為項目的結束點,當整個工作結束的時候檢驗產品的質量。


軟件質量的普遍原理

軟件質量的普遍原理就是改善質量以降低開發(fā)成本。

提高生產效率和改善質量的最佳途徑是減少花在這種代碼返工上的時間,無論返工的代碼是由需求、設計改變還是調試引起的。
前期充足準備,只要避免引入錯誤,就可以減少調試時間,從而提高生產力。因此,效果最明顯的縮短開發(fā)周期的辦法就是改善產品的質量,由此減少花費在調試和軟件返工上面的時間總量。
而且,NASA軟件工程實驗室在分析400人年工作量的50個開發(fā)項目的300萬行代碼后發(fā)現,更多的質量保證工作能降低錯誤率,但不會增加開發(fā)總成本(Card 1987)。

質量保證計劃核對表.png

更多資源(書籍)

  • Ginac, Frank P. 《Customer Oriented Software Quality Assurance》(《面向用戶的軟件質量保證》) 。這是一本言簡意賅的書,其中描述了質量特性、規(guī)律、質量保證計劃、測試在質量保證中的角色以及著名的質量改善計劃。
  • Lewis, Wiilliam E.《Software Testing and Continuous Quality Improvement》(《軟件測試和連續(xù)質量改進》)。這本書廣泛討論了質量生命周期,包括有關測試技術的深入討論,它還提供了大量的表格和核對表。
最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
【社區(qū)內容提示】社區(qū)部分內容疑似由AI輔助生成,瀏覽時請結合常識與多方信息審慎甄別。
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發(fā)布,文章內容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務。

相關閱讀更多精彩內容

友情鏈接更多精彩內容