談如何提高產(chǎn)品質(zhì)量
最近,我們的產(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è)诠纠锍3R?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ò)程類似。極限編程的基本過(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。阿里資深專家,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ù)銷毀、定義不使用、未初始化使用等情況,檢測(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ò)誤類型的數(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
- 目前還沒(méi)評(píng)論,等你發(fā)揮!