原始問答
Q：最近我們組想自己審視一下軟件質(zhì)量，但是缺少相關(guān)的經(jīng)驗(yàn)知識(shí)（組內(nèi)沒有qa)。 想向你了解一下，現(xiàn)在常用的軟件質(zhì)量評(píng)估方法? 你有關(guān)于軟件質(zhì)量相關(guān)的文章推薦嗎？ 或者有哪些書籍推薦?
A：軟件質(zhì)量評(píng)估，我暫時(shí)還一時(shí)想不起來。對(duì)于軟件質(zhì)量（測(cè)試）相關(guān)的書籍我這有基本，具體的可以參考我之前參加的播客：https://music.163.com/#/program?id=903513756 和 http://codetimecn.com/episodes/test，里面有書籍的介紹。
單純的評(píng)估這塊，我之前做過一個(gè)軟件測(cè)試成熟度模型，可以用于評(píng)估團(tuán)隊(duì)的測(cè)試能力。
Q： 其實(shí)我有一個(gè)問題，軟件質(zhì)量該如何體現(xiàn)。感覺測(cè)試何軟件質(zhì)量有區(qū)別，但是我說不出來。特別是現(xiàn)在客戶非常依賴手動(dòng)測(cè)試，有專門的測(cè)試部門
A： 首先，質(zhì)量是個(gè)很大的概念，本質(zhì)是一種主觀感受。我們通常所指的狹義質(zhì)量為可靠性，軟件的可靠性可以通過線上bug數(shù)來衡量（或者數(shù)量的變化趨勢(shì)）。 更加準(zhǔn)確的計(jì)算為線上bug數(shù)/開發(fā)中的bug數(shù)。
這個(gè)指標(biāo)是量化可靠性的其中一種理論，由于業(yè)界本身對(duì)于軟件質(zhì)量的度量還沒有統(tǒng)一的結(jié)論，我們可以采用這個(gè)值作為相對(duì)值進(jìn)行對(duì)比。例如當(dāng)比率很大時(shí)，可靠性質(zhì)量很不好。
還有一個(gè)評(píng)估方法是工業(yè)界的的質(zhì)量體系。也就是說，你的開發(fā)流程需要符合一定的標(biāo)準(zhǔn)，我就認(rèn)為你的質(zhì)量是有保證的。但是這個(gè)方式比較復(fù)雜而且不好量化
線上bug數(shù)屬于簡(jiǎn)單粗暴型，用比例會(huì)準(zhǔn)確一下是因?yàn)楫a(chǎn)品的規(guī)模不同，線上bug數(shù)是不同的。
修正與總結(jié)：
在回答了上述問題后，我對(duì)自己的答安并不十分自信，因?yàn)槲业挠^點(diǎn)是來源于自己的經(jīng)驗(yàn)加上一些碎片話的知識(shí)。
更加準(zhǔn)確的定義
為了更加準(zhǔn)確的找尋關(guān)于“軟件質(zhì)量” 的概念，我再次查閱了維基百科：https://en.wikipedia.org/wiki/Software_quality。
如上所示軟件質(zhì)量的定義與軟件測(cè)試一樣，并沒有統(tǒng)一的定義。大的有三個(gè)維度的定義：
- 滿足需求
- 客戶價(jià)值
- 缺陷級(jí)別
這段話的最后部分也指出了最早的質(zhì)量定義是主觀的感受。后面還提到了用戶滿意度。
總之，準(zhǔn)確的定義軟件質(zhì)量依然是困難的，不過，我們還是有一些可以依據(jù)的定義，他們采用的是質(zhì)量模型：
如 ISO/IEC 9126的定義的： https://en.wikipedia.org/wiki/ISO/IEC_9126
以及 CISQ's quality model
更加準(zhǔn)確的評(píng)估方法
由于軟件質(zhì)量定義暫時(shí)難已統(tǒng)一，并且是主觀的感受。那么評(píng)估它也就顯得比較主觀了。
當(dāng)然，最簡(jiǎn)單的非軟件測(cè)試莫屬，那么Bug數(shù)毫無疑問的成為了一種可行的評(píng)估方式，因?yàn)檐浖y(cè)試最早的定義即是，“為了發(fā)現(xiàn)錯(cuò)誤而執(zhí)行程序的過程”，其中的錯(cuò)誤，我們就可以狹義的理解為Bug。那這里又會(huì)存在一個(gè)問題，什么bug才有測(cè)量意義呢？
根據(jù)上述軟件質(zhì)量的定義，“用戶”，“客戶”，這些真正使用軟件的人的感受才是最能反應(yīng)質(zhì)量的，所以說，“用戶”， “客戶”遇到的bug 才是更加符合質(zhì)量的定義的可用于反應(yīng)軟件質(zhì)量的Bug類型。（也就是我們所說的線上Bug）
另外，我們可以參考IT界的一些常用的定義來評(píng)估質(zhì)量，例如：
ISO 9126-3
所提到的質(zhì)量模型，我們可以通過檢查軟件開發(fā)過程中，以及軟件自身是否具備某些特質(zhì)，以及對(duì)應(yīng)于該特質(zhì)相關(guān)的用于評(píng)估的屬性來評(píng)估軟件的質(zhì)量是好是壞。例如：
我們通過右側(cè)的屬性來評(píng)估左側(cè)的質(zhì)量特性：
從而得到一個(gè)綜合的質(zhì)量評(píng)估結(jié)果。
盡管上面給出了很多屬性，但是相信大家讀完了，依然疑惑，即便是有了這些屬性，每個(gè)屬性本身也并非都是標(biāo)準(zhǔn)化，且容易度量的，如coding practices即是典型的例子，里面提到了compliance with OO，可是這一點(diǎn)卻是評(píng)估的人不同，顯然量化的結(jié)果是不同，假如OO compliance的滿分是10分，對(duì)于某OO設(shè)計(jì)，打6，還是7分，還是8，就仁者見仁，智者見智了。
假如我們狹義的理解質(zhì)量為質(zhì)量模型中的可靠性，需要check的點(diǎn)：
盡管已經(jīng)有了這么多點(diǎn)，上面最后一句依然表明了可靠性的衡量需要考慮被評(píng)估軟件本身的架構(gòu)以及使用的第三方庫(kù)，然后通過自定義的check點(diǎn)來做。也就是說，這個(gè)需要可靠性的評(píng)估標(biāo)準(zhǔn)，需要因地制宜，看情況而定。顯然這種措辭依然表達(dá)出了主觀標(biāo)準(zhǔn)的意思。
也正是如此，我們身邊的日常用品的質(zhì)量往往會(huì)打著IOS9001/IOS9002質(zhì)量體系認(rèn)證，來表明其質(zhì)量是保證的，也就是說，我的產(chǎn)品是在質(zhì)量保證的流程體系下生產(chǎn)出來的。這樣以來，貌似這種評(píng)估定義，跟上述定義大體類似，實(shí)際上都是難以準(zhǔn)確度量的，更大的意義也許是跟沒有質(zhì)量保證的產(chǎn)品去分開吧。
總之，度量軟件質(zhì)量是如此的復(fù)雜，且不一定真的能夠準(zhǔn)確量化質(zhì)量。那倒不如就在開發(fā)過程中時(shí)刻按照這些check list約束開發(fā)過程，讓開發(fā)過程是在有保證的情況下交付軟件。讓真正的質(zhì)量交給時(shí)間，交給我們的線上去體現(xiàn)吧。這也想汽車界的著名質(zhì)量雜志的JD Power的做法，用線上故障數(shù)來評(píng)估質(zhì)量吧（對(duì)于汽車，準(zhǔn)確的是每百輛故障數(shù)）。
