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

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

創(chuàng)新互聯(lián)公司專注于忻府網(wǎng)站建設服務及定制，我們擁有豐富的企業(yè)做網(wǎng)站經驗。 熱誠為您提供忻府營銷型網(wǎng)站建設，忻府網(wǎng)站制作、忻府網(wǎng)頁設計、忻府網(wǎng)站官網(wǎng)定制、微信平臺小程序開發(fā)服務，打造忻府網(wǎng)絡公司原創(chuàng)品牌,更為您提供忻府網(wǎng)站排名全網(wǎng)營銷落地服務。

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

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

事太?。骸拔覍懥藗€小類庫，全部自己測試”，這當然不錯。

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

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

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

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

引起網(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

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

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

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

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

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

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

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

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

15.3.3 微軟是怎么做的呢？

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

• SDE：Software Design Engineer，簡稱dev。

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

• STE：Software Test Engineer。

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

7. 測試用例的覆蓋率

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

9. 代碼的行數(shù)

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

11. 有多少代碼被重用了

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

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

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

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

 

---

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

當前題目：現(xiàn)代軟件工程第十四章【質量保障】練習與討論
分享網(wǎng)址：http://www.rwnh.cn/article10/jsccdo.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供企業(yè)建站、標簽優(yōu)化、搜索引擎優(yōu)化、服務器托管、網(wǎng)頁設計公司、App設計

廣告

聲明：本網(wǎng)站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)