現代軟件工程 第十四章 【質量保障】 練習與討論

15.3.1 有些成功人士或公司認為不需要獨立的測試角色（Test），你怎么看？

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

人太牛： 不世出的天才，例如高德納寫書時發現排版軟件不好用，就自己寫了一個。也沒聽說他為這個軟件項目請了什么獨立測試人員。對了，他不讀Email，有秘書幫他處理這些事——這也是一種分工！

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

事太小：“我寫了個小類庫，全部自己測試”，這當然不錯。

但是如果由此論點出發，大力順水推舟，推廣到所有情況，從而得出“程序員就應該自己測試，專職測試不需要”這樣的結論，明顯不合適。

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

無知：      這就不好說什么了。

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

引起網上討論的兩篇文章在這里：

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

其中打分最高的回答來自前雇員（Evan Priestley），他總結了Facebook這個公司為什么貌似沒有全職測試人員：

a)         全公司人員經常使用自己的軟件產品！（如果你開發的軟件是航天飛行某控制模塊，你怎么能經常使用呢？）

b)         使用log來分析問題可能出在哪里。（我們的一些程序員寫程序都沒有log，那大家看什么呢？）

c)         利用用戶的反饋和實時狀態分析（比較過去一小時和上周同一時間的數據來判斷是否有bug。）

d)         應用開發商給Facebook報bug。（開發商其實比較不爽，但是FB有時就是無預警地修改API，你除了趕緊報bug，還能怎么著？）

e)         很多人自愿給Facebook報bug，這位貼主自稱每月給他的前雇主報13,000個問題。（沒錯，是每月一萬三千個！）

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

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

15.3.3 微軟是怎么做的呢？

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

• SDE：Software Design Engineer，簡稱dev。

• SDE/T：Software Design Engineer in Test，也寫代碼，但是重點在測試。

• STE：Software Test Engineer。

對于如何更有效地開發互聯網應用，微軟很多團隊都做過不少探索。微軟公司在創業之初也沒有多少專門的測試人員，在1984年的時候，開發：測試的比例是20:1.  后來隨著產品線的變化，有些項目的測試人員比例幾乎和開發人員一樣多。最近，一些團隊，是做互聯網業務相關的，嘗試把SDE和SDE/T合成一體。每個人都負責開發/測試/發布這一整套流程。這種做法，根據我的觀察，有好處，也有額外的成本。

15.3.4 團隊應該如何安排QA 和測試工作

測試、質量保障、軟件工程的質量，團隊和個人到底應該怎么辦呢？我認為，

• 在初始階段（新項目，團隊進入一個新領域，人員剛進入一個項目），每個團隊成員都要盡量打通各個環節，多負責，把所有事情都搞懂，培養通才。

• 當項目/產業發展到一定階段（進入陣地戰的時候），要大力提倡分工合作，培養專才。同時，要把好的工具和流程集成起來，從每日構建，到基本功能的自動化，都要盡快實現。

• 把自己項目的架構和流程做好，讓所有人都能比較容易地進行QA工作，這樣，團隊的“軟件工程質量”才會有提高。

• 培養“大家都要做QA，專人負責量化的Test，有條件多做測試自動化”的文化。

• 要明白自己項目的特點，避免照搬別人的做法。不要聽說某某偉大的項目的開發/測試比例是多少，因此就哭著喊著也要同樣的比例。

• 如果一個團隊是認真嚴肅地做軟件，那他們一定要考慮如何保證程序的質量/軟件工程的質量，以及達到這些質量，需要多少成本。

15.3.5  測試人員的職業發展

分工之后，每人負責一小塊東西，怎么才能體現出個人的獨特而巨大的價值呢？例如，你剛到一家出版社，領導讓你做“二審”這份工作，或者你剛到一個軟件公司，領導讓你做“測試”這份工作，你怎么才能展現出你獨特的價值呢？

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

15.4 如何衡量軟件工程的質量

在本書開頭我們講了如何證明自己做好了軟件工程：

• 研發出符合用戶需求的軟件

• 通過一定的軟件流程，在預計的時間內發布 “足夠好” 的軟件

• 并通過數據和其他方式展現所開發的軟件是可以維護和繼續發展的

我們能否量化上面提到的這些要點呢？ 小組的同學可以想出一些指標，也可以從文獻中查到學術界的論述，還可以通過實踐來總結。

下面是一些常用的量化指標,  軟件發布后發現的bug 的數量

1. 軟件 CC 后 DCR 的數量

2. 用戶的好評/差評 （例如AppStore 的5星級評價）

3. 在CC 后發現的bug 的數量

4. 文檔的完備性和準確性 （用百分率表示）

5. 修復 bug 所需的平均時間

6. 單位開發量（人*月）出現的重大 bug 的數量

7. 測試用例的覆蓋率

8. 模塊的復雜程度 （用工具檢測并有量化結果）

9. 代碼的行數

10. 文檔的數量和復雜程度

11. 有多少代碼被重用了

12. 平均每天構建失敗的次數

13. 軟件實現了多少功能點

14. 軟件能運行多久， 平均初次錯誤時間 （mean time to failure)  平均無故障時間 (mean time between failure)...

團隊可以選取 7 個指標 （包括自己想出的指標），然后在項目中計算這些指標并跟蹤。

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