現(xiàn)代軟件工程 第十四章 【質(zhì)量保障】 練習(xí)與討論

15.3.1 有些成功人士或公司認(rèn)為不需要獨(dú)立的測(cè)試角色（Test），你怎么看？

我猜想和踢足球類似，還是那幾個(gè)原因：

人太牛： 不世出的天才，例如高德納寫(xiě)書(shū)時(shí)發(fā)現(xiàn)排版軟件不好用，就自己寫(xiě)了一個(gè)。也沒(méi)聽(tīng)說(shuō)他為這個(gè)軟件項(xiàng)目請(qǐng)了什么獨(dú)立測(cè)試人員。對(duì)了，他不讀Email，有秘書(shū)幫他處理這些事——這也是一種分工！

有些軟件工程師是在后臺(tái)鉆研和開(kāi)發(fā)高難度的算法，或者做某種后臺(tái)的處理工作，這個(gè)工作本身的難度較高，測(cè)試主要是自己通過(guò)工具完成。如果一定要找一個(gè)測(cè)試人員，這個(gè)測(cè)試人員的水平要相當(dāng)高才行，如果水平那么高，那就不如也一起參與開(kāi)發(fā)就好了。

事太?。骸拔覍?xiě)了個(gè)小類庫(kù)，全部自己測(cè)試”，這當(dāng)然不錯(cuò)。

但是如果由此論點(diǎn)出發(fā)，大力順?biāo)浦郏茝V到所有情況，從而得出“程序員就應(yīng)該自己測(cè)試，專職測(cè)試不需要”這樣的結(jié)論，明顯不合適。

人不夠： 那就自己動(dòng)手多做一些事情，也挺好。就像前面提到的，一個(gè)人可以扮演多個(gè)角色。

無(wú)知：      這就不好說(shuō)什么了。

15.3.2 為什么一些成功的公司不用測(cè)試人員

引起網(wǎng)上討論的兩篇文章在這里：

http://sriramk.com/blog/2012/01/testing.html中文翻譯在：http://www.aqee.net/on-testers-and-testing/。

http://www.quora.com/Is-it-true-that-Facebook-has-no-testers

其中打分最高的回答來(lái)自前雇員（Evan Priestley），他總結(jié)了Facebook這個(gè)公司為什么貌似沒(méi)有全職測(cè)試人員：

a)         全公司人員經(jīng)常使用自己的軟件產(chǎn)品?。ㄈ绻汩_(kāi)發(fā)的軟件是航天飛行某控制模塊，你怎么能經(jīng)常使用呢？）

b)         使用log來(lái)分析問(wèn)題可能出在哪里。（我們的一些程序員寫(xiě)程序都沒(méi)有l(wèi)og，那大家看什么呢？）

c)         利用用戶的反饋和實(shí)時(shí)狀態(tài)分析（比較過(guò)去一小時(shí)和上周同一時(shí)間的數(shù)據(jù)來(lái)判斷是否有bug。）

d)         應(yīng)用開(kāi)發(fā)商給Facebook報(bào)bug。（開(kāi)發(fā)商其實(shí)比較不爽，但是FB有時(shí)就是無(wú)預(yù)警地修改API，你除了趕緊報(bào)bug，還能怎么著？）

e)         很多人自愿給Facebook報(bào)bug，這位貼主自稱每月給他的前雇主報(bào)13,000個(gè)問(wèn)題。（沒(méi)錯(cuò)，是每月一萬(wàn)三千個(gè)?。?/p>

f)          最后這位前雇員還加了一句：還有一個(gè)原因是，F(xiàn)acebook大體上也不需要搞出太高水平的軟件。

當(dāng)你的公司也能有a）到e）這樣的文化、流程、開(kāi)發(fā)商和給力的前員工，而且你的軟件“大體上也不要太高質(zhì)量”，你的確不需要什么全職測(cè)試人員！

15.3.3 微軟是怎么做的呢？

就像MSF原則講的那樣，有分工，有合作。微軟開(kāi)發(fā)測(cè)試主要有三種角色[i]：

• SDE：Software Design Engineer，簡(jiǎn)稱dev。

• SDE/T：Software Design Engineer in Test，也寫(xiě)代碼，但是重點(diǎn)在測(cè)試。

• STE：Software Test Engineer。

對(duì)于如何更有效地開(kāi)發(fā)互聯(lián)網(wǎng)應(yīng)用，微軟很多團(tuán)隊(duì)都做過(guò)不少探索。微軟公司在創(chuàng)業(yè)之初也沒(méi)有多少專門的測(cè)試人員，在1984年的時(shí)候，開(kāi)發(fā)：測(cè)試的比例是20:1.  后來(lái)隨著產(chǎn)品線的變化，有些項(xiàng)目的測(cè)試人員比例幾乎和開(kāi)發(fā)人員一樣多。最近，一些團(tuán)隊(duì)，是做互聯(lián)網(wǎng)業(yè)務(wù)相關(guān)的，嘗試把SDE和SDE/T合成一體。每個(gè)人都負(fù)責(zé)開(kāi)發(fā)/測(cè)試/發(fā)布這一整套流程。這種做法，根據(jù)我的觀察，有好處，也有額外的成本。

15.3.4 團(tuán)隊(duì)?wèi)?yīng)該如何安排QA 和測(cè)試工作

測(cè)試、質(zhì)量保障、軟件工程的質(zhì)量，團(tuán)隊(duì)和個(gè)人到底應(yīng)該怎么辦呢？我認(rèn)為，

• 在初始階段（新項(xiàng)目，團(tuán)隊(duì)進(jìn)入一個(gè)新領(lǐng)域，人員剛進(jìn)入一個(gè)項(xiàng)目），每個(gè)團(tuán)隊(duì)成員都要盡量打通各個(gè)環(huán)節(jié)，多負(fù)責(zé)，把所有事情都搞懂，培養(yǎng)通才。

• 當(dāng)項(xiàng)目/產(chǎn)業(yè)發(fā)展到一定階段（進(jìn)入陣地戰(zhàn)的時(shí)候），要大力提倡分工合作，培養(yǎng)專才。同時(shí)，要把好的工具和流程集成起來(lái)，從每日構(gòu)建，到基本功能的自動(dòng)化，都要盡快實(shí)現(xiàn)。

• 把自己項(xiàng)目的架構(gòu)和流程做好，讓所有人都能比較容易地進(jìn)行QA工作，這樣，團(tuán)隊(duì)的“軟件工程質(zhì)量”才會(huì)有提高。

• 培養(yǎng)“大家都要做QA，專人負(fù)責(zé)量化的Test，有條件多做測(cè)試自動(dòng)化”的文化。

• 要明白自己項(xiàng)目的特點(diǎn)，避免照搬別人的做法。不要聽(tīng)說(shuō)某某偉大的項(xiàng)目的開(kāi)發(fā)/測(cè)試比例是多少，因此就哭著喊著也要同樣的比例。

• 如果一個(gè)團(tuán)隊(duì)是認(rèn)真嚴(yán)肅地做軟件，那他們一定要考慮如何保證程序的質(zhì)量/軟件工程的質(zhì)量，以及達(dá)到這些質(zhì)量，需要多少成本。

15.3.5  測(cè)試人員的職業(yè)發(fā)展

分工之后，每人負(fù)責(zé)一小塊東西，怎么才能體現(xiàn)出個(gè)人的獨(dú)特而巨大的價(jià)值呢？例如，你剛到一家出版社，領(lǐng)導(dǎo)讓你做“二審”這份工作，或者你剛到一個(gè)軟件公司，領(lǐng)導(dǎo)讓你做“測(cè)試”這份工作，你怎么才能展現(xiàn)出你獨(dú)特的價(jià)值呢？

請(qǐng)找到幾個(gè)軟件測(cè)試工程師（例如，軟件學(xué)院的測(cè)試專業(yè)早幾年畢業(yè)的師兄師姐，測(cè)試論壇上活躍的用戶，軟件公司的測(cè)試人員），和他們了解并探討測(cè)試這門專業(yè)。

15.4 如何衡量軟件工程的質(zhì)量

在本書(shū)開(kāi)頭我們講了如何證明自己做好了軟件工程：

• 研發(fā)出符合用戶需求的軟件

• 通過(guò)一定的軟件流程，在預(yù)計(jì)的時(shí)間內(nèi)發(fā)布 “足夠好” 的軟件

• 并通過(guò)數(shù)據(jù)和其他方式展現(xiàn)所開(kāi)發(fā)的軟件是可以維護(hù)和繼續(xù)發(fā)展的

我們能否量化上面提到的這些要點(diǎn)呢？ 小組的同學(xué)可以想出一些指標(biāo)，也可以從文獻(xiàn)中查到學(xué)術(shù)界的論述，還可以通過(guò)實(shí)踐來(lái)總結(jié)。

下面是一些常用的量化指標(biāo),  軟件發(fā)布后發(fā)現(xiàn)的bug 的數(shù)量

1. 軟件 CC 后 DCR 的數(shù)量

2. 用戶的好評(píng)/差評(píng) （例如AppStore 的5星級(jí)評(píng)價(jià)）

3. 在CC 后發(fā)現(xiàn)的bug 的數(shù)量

4. 文檔的完備性和準(zhǔn)確性 （用百分率表示）

5. 修復(fù) bug 所需的平均時(shí)間

6. 單位開(kāi)發(fā)量（人*月）出現(xiàn)的重大 bug 的數(shù)量

7. 測(cè)試用例的覆蓋率

8. 模塊的復(fù)雜程度 （用工具檢測(cè)并有量化結(jié)果）

9. 代碼的行數(shù)

10. 文檔的數(shù)量和復(fù)雜程度

11. 有多少代碼被重用了

12. 平均每天構(gòu)建失敗的次數(shù)

13. 軟件實(shí)現(xiàn)了多少功能點(diǎn)

14. 軟件能運(yùn)行多久， 平均初次錯(cuò)誤時(shí)間 （mean time to failure)  平均無(wú)故障時(shí)間 (mean time between failure)...

團(tuán)隊(duì)可以選取 7 個(gè)指標(biāo) （包括自己想出的指標(biāo)），然后在項(xiàng)目中計(jì)算這些指標(biāo)并跟蹤。

[i] 這本書(shū)講了不少微軟公司各種角色的故事： How To Move Mount Fuji, 作者: William Poundstone, ISBN 0316778494