最近，我們的產(chǎn)品上線了，上線之后，穩(wěn)定是最重要的，但是，出現(xiàn)了幾次bug，都是不應(yīng)該犯的錯(cuò)誤，所以，避免bug特別是重大bug出現(xiàn)，提高產(chǎn)品質(zhì)量，非常迫切。為此，我花了幾天時(shí)間，翻一些資料來(lái)系統(tǒng)地學(xué)習(xí)，此文是學(xué)習(xí)的總結(jié)。

產(chǎn)品開(kāi)發(fā)過(guò)程：需求分析、設(shè)計(jì)、編碼、單元測(cè)試、集成測(cè)試、功能測(cè)試、Beta測(cè)試和發(fā)布。在工程師開(kāi)發(fā)之前，策劃或產(chǎn)品提過(guò)來(lái)的需求、策劃的配置文件或者后期的測(cè)試，都可能影響產(chǎn)品質(zhì)量，但是，本文側(cè)重于從開(kāi)發(fā)者角度談提高產(chǎn)品質(zhì)量。先分享一張來(lái)自《Code Complete》的插圖。

可以看到，隨著項(xiàng)目規(guī)模變大，架構(gòu)、設(shè)計(jì)和集成測(cè)試、系統(tǒng)測(cè)試需要的時(shí)間會(huì)更多，而編碼和開(kāi)發(fā)者測(cè)試的時(shí)間更少。因此，提高效率最為明顯的方法是提高產(chǎn)品質(zhì)量， 減少測(cè)試、調(diào)試和修改所需時(shí)間。所以，設(shè)計(jì)、測(cè)試和編碼同樣重要，要分配更多時(shí)間，編碼完 != 工作完成。

測(cè)試的重要

在很多大一些的IT公司，比如微軟，開(kāi)發(fā)職位叫Software Development Engineer，SDE，軟件開(kāi)發(fā)工程師;測(cè)試職位叫Software Development Engineer in Test，SDET，軟件測(cè)試開(kāi)發(fā)工程師，可見(jiàn)測(cè)試人員本質(zhì)還是開(kāi)發(fā)工程師。這有別于我們?cè)诠纠锍３Ｒ?jiàn)到的QA，我是做游戲的，我見(jiàn)到的QA都是打開(kāi)游 戲，然后點(diǎn)點(diǎn)點(diǎn)，從表現(xiàn)上測(cè)試功能是否正常，這樣測(cè)試是無(wú)法全面測(cè)試的，這也難怪在很多公司里QA比開(kāi)發(fā)團(tuán)隊(duì)地位低。我覺(jué)得，對(duì)于測(cè)試這個(gè)職位，要做好， 是很難的。他要能讀懂策劃文檔和開(kāi)發(fā)文檔，從源頭上開(kāi)始著手。如果白盒測(cè)試，要能看懂別人寫(xiě)的代碼;如果黑盒測(cè)試，要和開(kāi)發(fā)人員多溝通，畫(huà)出來(lái)實(shí)現(xiàn)的流程 圖，并且分析網(wǎng)絡(luò)協(xié)議;然后，設(shè)計(jì)完備的測(cè)試用例。如果不根據(jù)需求、設(shè)計(jì)和實(shí)現(xiàn)，設(shè)計(jì)完備的測(cè)試流程，而只是操作一下試試功能是否正常，很多隱藏的bug 是測(cè)試不出來(lái)的。

在傳統(tǒng)軟件行業(yè)：軟件的質(zhì)量和穩(wěn)定最重要，代表企業(yè)：IBM、微軟、思科等。根據(jù)我查到的資料，開(kāi)發(fā)與測(cè)試人員比例，微軟1:1，思科1:1.5，普 遍在1:1 – 3:1。SDET從需求文檔、設(shè)計(jì)文檔開(kāi)始Review，SDE編碼，SDET寫(xiě)測(cè)試用例，跟極限編程的過(guò)程類(lèi)似。極限編程的基本過(guò)程：構(gòu)思 -> 編寫(xiě)測(cè)試代碼 -> 編寫(xiě)代碼 -> 測(cè)試，編寫(xiě)測(cè)試和編寫(xiě)代碼都是增量式的，寫(xiě)一點(diǎn)測(cè)一點(diǎn)，在編寫(xiě)以后的代碼中如果發(fā)現(xiàn)問(wèn)題可以較快的追蹤到問(wèn)題的原因，減小回歸錯(cuò)誤的糾錯(cuò)難度。

而互聯(lián)網(wǎng)行業(yè)：快很重要，有bug在線上也方便修改發(fā)布，更提倡full stack developer，代表企業(yè)：amazon、facebook、google等。開(kāi)發(fā)與測(cè)試人員比例，google 10:1， MySpace 5:1。阿里資深專(zhuān)家，amazon前高級(jí)經(jīng)理，陳皓認(rèn)為：并不是互聯(lián)網(wǎng)公司認(rèn)為測(cè)試不重要，而是他們認(rèn)為正因?yàn)闇y(cè)試很重要，所以才不應(yīng)該交給只做測(cè)試的 人，開(kāi)發(fā)人員要對(duì)自己開(kāi)發(fā)的產(chǎn)品質(zhì)量負(fù)責(zé)。對(duì)于一個(gè)公司，“產(chǎn)出性”的人應(yīng)該多于“支持性”的人。當(dāng)你的條件受限人手不夠的時(shí)候，你必然不能干所有的事， 但你要去做很多自動(dòng)化的事情，不管是自動(dòng)化部署還是自動(dòng)化運(yùn)維。然而當(dāng)你的人多的時(shí)候，你必然只會(huì)簡(jiǎn)單用人來(lái)解決問(wèn)題。勞動(dòng)密集型與知識(shí)密集型的公司差別 就在這里。

以微軟和google為代表的保證產(chǎn)品質(zhì)量的做法，都有道理，而且都是成功的。但是，我個(gè)人更傾向于full stack developer，第一，招很多SDET對(duì)大部分公司都不現(xiàn)實(shí)，合格的SDET薪資不會(huì)比SDE低;第二，我認(rèn)為開(kāi)發(fā)人員要對(duì)自己的開(kāi)發(fā)的內(nèi)容負(fù)責(zé)，主 動(dòng)的想辦法提高產(chǎn)品質(zhì)量，而不是被動(dòng)的等測(cè)試。

產(chǎn)品質(zhì)量目標(biāo)

評(píng)估產(chǎn)品質(zhì)量，常用的是千行代碼缺陷率，以下是查到的一些業(yè)界的千行代碼缺陷率數(shù)據(jù)。典型的統(tǒng)計(jì)表明，在開(kāi)發(fā)階段，平均50~60個(gè)，交付后 15~18個(gè);微軟內(nèi)部測(cè)試的產(chǎn)品10-20個(gè)，正式發(fā)布產(chǎn)品0.5個(gè);某外包公司，A級(jí)≤ 0.5個(gè)，B級(jí)≤1個(gè)，C級(jí)≤5個(gè);航天飛機(jī)的軟件，0個(gè)/50萬(wàn)行。缺陷率做到平均水平的1/10是很少見(jiàn)的，而如果10倍以上，產(chǎn)品可能永遠(yuǎn)也不會(huì)完 工。

跟性能瓶頸一樣，80%的錯(cuò)誤往往出現(xiàn)在20%的代碼中。大部分錯(cuò)誤都是低級(jí)錯(cuò)誤，比如，對(duì)需求或設(shè)計(jì)的誤解、書(shū)寫(xiě)錯(cuò)誤、賦值語(yǔ)句、邊界錯(cuò)誤或循環(huán)錯(cuò)誤。大多數(shù)錯(cuò)誤是容易改正的。另外，warning是很多錯(cuò)誤的根源，所以工程里要禁止warning。

發(fā)現(xiàn)錯(cuò)誤

主要通過(guò)檢查和測(cè)試。檢查包括：需求檢查、設(shè)計(jì)檢查、代碼詳查，測(cè)試包括：?jiǎn)卧獪y(cè)試、集成測(cè)試、系統(tǒng)測(cè)試等。

有統(tǒng)計(jì)數(shù)據(jù)表明：?jiǎn)卧獪y(cè)試的平均錯(cuò)誤檢出率是25%，集成測(cè)試35%，小規(guī)模Beta測(cè)試35%，系統(tǒng)測(cè)試45%。而對(duì)設(shè)計(jì)和代碼進(jìn)行詳查的錯(cuò)誤檢出率分別是55%和60%。

檢查

閱讀代碼要比測(cè)試平均每小時(shí)多發(fā)現(xiàn)80%多的錯(cuò)誤，代碼檢查和測(cè)試所獲得的收效之比為8:1。這是因?yàn)?，錯(cuò)誤越早發(fā)現(xiàn)，解決成本越低。

檢查方法：協(xié)同編程，詳查需求、設(shè)計(jì)、代碼。不僅僅是檢查，要提前思考怎么做?帶著思考檢查。

單元測(cè)試

1. 基于結(jié)構(gòu)的測(cè)試。測(cè)試用例要覆蓋每一條控制語(yǔ)句，if for while and or switch case等。

2. 數(shù)據(jù)流測(cè)試，避免重復(fù)初始化、重復(fù)銷(xiāo)毀、定義不使用、未初始化使用等情況，檢測(cè)數(shù)據(jù)流變化。

3. 錯(cuò)誤猜測(cè)：

1). 邊界分析，>=與>的區(qū)別，null、size是0的情況，比如測(cè)試小于MAX，三種邊界情況MAX，10000個(gè)好友/道具的時(shí)候會(huì)不會(huì)導(dǎo)致游戲卡死?

2). 復(fù)合邊界，int add(int a, int b)，a和b都小于2^31，但是，如果a和b都很大，它們的和會(huì)不會(huì)出界?

3). 壞數(shù)據(jù)，太小/大的數(shù)據(jù)，未初始化的數(shù)據(jù)，錯(cuò)誤類(lèi)型的數(shù)據(jù)，錯(cuò)誤長(zhǎng)度的數(shù)據(jù)等。

4). 向前兼容和向后兼容。比如，游戲最新版本是2.5，但是有的玩家一直不更新，還是1.0，要兼容這些玩家。

集成測(cè)試

在單元測(cè)試的基礎(chǔ)上，將所有模塊按照設(shè)計(jì)要求組裝成為子系統(tǒng)或系統(tǒng)，進(jìn)行集成測(cè)試。

執(zhí)行方案

綜合考慮我們團(tuán)隊(duì)的實(shí)際情況，最后我制定了“詳查+單元測(cè)試+集成測(cè)試+系統(tǒng)測(cè)試”的方案，來(lái)提高我們的產(chǎn)品質(zhì)量。有些方法，比如協(xié)同編程、凈室開(kāi)發(fā)，雖然很好，但是對(duì)于我們的團(tuán)隊(duì)來(lái)說(shuō)，執(zhí)行起來(lái)太難。ps：我對(duì)凈室開(kāi)發(fā)很感興趣，正在研究，研究透以后可能會(huì)試著采用。

詳查：先自己詳查，從需求開(kāi)始，然后是設(shè)計(jì)和編碼;然后，團(tuán)隊(duì)中的小伙伴互查。關(guān)于詳查，有兩點(diǎn)需要注意：1. 檢查前，要先制定代碼規(guī)范，讓開(kāi)發(fā)人員不把精力耗在代碼規(guī)范的爭(zhēng)執(zhí)上。2. 詳查結(jié)果不作為員工表現(xiàn)的考核標(biāo)準(zhǔn)，考核應(yīng)該基于最終的產(chǎn)品。

單元測(cè)試：重點(diǎn)是理清流程，針對(duì)每個(gè)流程都測(cè)試到。集成測(cè)試：把單元測(cè)試的功能組合起來(lái)測(cè)試，側(cè)重于模塊的整體性。系統(tǒng)測(cè)試：有點(diǎn)像QA的普遍工作，從功能上測(cè)試，各個(gè)需求點(diǎn)是否都正常。

執(zhí)行：我首先制定了代碼規(guī)范，并給大家講解，然后征求大家的意見(jiàn)統(tǒng)一。然后，寫(xiě)了一份本文章的內(nèi)部版本，并給大家詳細(xì)講解(為了讓小伙伴們更容易，內(nèi) 部版本細(xì)節(jié)比較豐富，舉了一些例子，寫(xiě)的比較啰嗦，稍微精簡(jiǎn)、加工之后，形成了這篇blog)。另外，需要注意，詳查結(jié)果不要作為員工表現(xiàn)的考核標(biāo)準(zhǔn)，考 核應(yīng)該基于最終的產(chǎn)品。

來(lái)源：PMTOO