軟件測(cè)試是什么，同學(xué)們有沒有詳細(xì)思考過這個(gè)問題呢？今天，在這里成都樂搏軟件測(cè)試培訓(xùn)學(xué)校的測(cè)試?yán)蠋焷斫o同學(xué)講講關(guān)于軟件測(cè)試的幾點(diǎn)反思，有興趣的同學(xué)快來看看吧！希望能夠?qū)δ阌兴鶐椭?br />   首先我想先從一個(gè)例子開始，一個(gè)現(xiàn)實(shí)生活中的例子。
  對(duì)于一個(gè)城市，假設(shè)我們的工作目標(biāo)是提升環(huán)境的質(zhì)量，減少垃圾。那么我們可以做什么？
  首先，我們可以請(qǐng)很多環(huán)衛(wèi)工人，出去打掃各個(gè)街道，這個(gè)馬上就有了效果，環(huán)境變得更干凈了。但是還不夠好的地方是明天還是有很多東西需要打掃，治標(biāo)不治本，只要一停下來立馬回到之前的狀況。
  接下來，我們往前面想一想，為什么有那么多垃圾呢？其中一個(gè)方面是很多人亂扔垃圾。所以更進(jìn)步一點(diǎn)的方案是，對(duì)于亂扔垃圾的人有些約束或者懲罰，比如抓到了曝光或者罰錢，這樣扔垃圾的人會(huì)變少。
  再然后，我們發(fā)現(xiàn)即使做到了上面，還是有不少垃圾，而且上面強(qiáng)制的方案也帶來不少的反感。我們需要更深層次的思考，為什么會(huì)有那么多垃圾？是因?yàn)槔疤?？設(shè)計(jì)得不合理？如果是這樣，就需要從其他公共設(shè)施方面做一些改進(jìn)了。
  對(duì)于我們的測(cè)試工作，也是有類似的思路，只不過細(xì)節(jié)上要考慮更多。
  個(gè)階段：發(fā)現(xiàn)和解決bug的階段
  這個(gè)階段的思路基本上盡可能發(fā)現(xiàn)更多的bug，見一個(gè)滅一個(gè)，來兩個(gè)滅一雙。
  發(fā)現(xiàn)bug，解決后驗(yàn)證bug，沒有任何根源性的推動(dòng)，或者推動(dòng)的效果不好。
  這個(gè)階段，測(cè)試工作主要集中在發(fā)現(xiàn)bug，要做好這個(gè)，需要多個(gè)方面的努力，比如下面這些：
  -更高效的發(fā)現(xiàn)bug，考驗(yàn)測(cè)試設(shè)計(jì)的能力。
  這方面有非常多的方法和技巧，以及經(jīng)驗(yàn)，這里不細(xì)說。
  -發(fā)現(xiàn)bug之后如何清晰的描述，定級(jí)，以及跟進(jìn)和驗(yàn)證。
  這個(gè)看似簡單，但是你會(huì)發(fā)現(xiàn)很多測(cè)試工作做了幾年的人這樣的基本功還是不夠扎實(shí)。也可能沒有受到過很好的訓(xùn)練或者一直沒有人指導(dǎo)。
  -對(duì)業(yè)務(wù)和架構(gòu)的理解能力。
  沒有這方面的能力，很難發(fā)現(xiàn)一些深層次的bug。而這樣的能力對(duì)于快速學(xué)習(xí)和一些技術(shù)基礎(chǔ)也有不低的要求。
  -發(fā)現(xiàn)bug之后如果舉一反三的盡早發(fā)現(xiàn)更多類似的bug。
  大家看到的很多經(jīng)典的測(cè)試書籍講的基本都是這個(gè)階段做的事情，比如Software Testing，How We Test Software at Microsoft，以及探索性測(cè)試相關(guān)的書籍，都是專注在如何更高效的發(fā)現(xiàn)缺陷。
  上面這些東西都是一個(gè)業(yè)務(wù)測(cè)試人員的基本功?？此坪唵?，但是做好并不是一件容易的事情。也許這些事情一點(diǎn)都不cool，不sexy，甚至去做職級(jí)評(píng)審的時(shí)候不占優(yōu)勢(shì)，但是對(duì)于系統(tǒng)質(zhì)量的提升，是切切實(shí)實(shí)帶來很大幫助的，其工作的價(jià)值應(yīng)該得到認(rèn)可。但是如果一直停留在這個(gè)階段，就陷入到上面例子中說的掃馬路的階段，因?yàn)槿绻麤]有其他方面的改變，每次都有那么多的bug。
  不過很多時(shí)候，我們的測(cè)試停留在這個(gè)階段也是因?yàn)楝F(xiàn)狀，考慮下這樣的情況：
  -開發(fā)基本不自測(cè)，甚至沒有自測(cè)的環(huán)境，特別是涉及多個(gè)系統(tǒng)的對(duì)接。
  -提測(cè)后很多基本的功能都不能正常使用
  -項(xiàng)目管理比較混亂，但是最終的發(fā)布日期又被老大們定死，所以測(cè)試時(shí)間常常被壓縮
  而且，而且沒有對(duì)于開發(fā)人員的質(zhì)量方面的考核，那么很長一段時(shí)間，我們的測(cè)試將處于這個(gè)初級(jí)階段。
  我相信目前還有不少的團(tuán)隊(duì)是處于這樣疲于應(yīng)對(duì)的情況下，不只是小企業(yè)，可能一些大企業(yè)的部分項(xiàng)目也是如此。隨著整個(gè)研發(fā)體系的發(fā)展和深入，我們應(yīng)該有更高的追求。
  第二個(gè)階段：質(zhì)量的管理
  在個(gè)階段中，可能有一些人會(huì)停下來想：我們一直這樣下去也不是個(gè)辦法？有沒有更好的做法呢?
  最直接會(huì)想到的就是，怎么讓別人少丟垃圾，讓本身的bug就更少一些。如果我們做的工作只是發(fā)現(xiàn)bug解決bug，那么就是一個(gè)消耗戰(zhàn)。不能形成一個(gè)良性的循環(huán)，就不能持續(xù)的優(yōu)化，工作的長期累積價(jià)值就體現(xiàn)不出來。
  這個(gè)階段核心的思路是對(duì)缺陷做分析和考核，并做研發(fā)流程中主要問題的梳理和改善。
  常常做的事情可以從下面幾個(gè)方面來看：
  1.做質(zhì)量數(shù)據(jù)的統(tǒng)計(jì)和分析
  收集的數(shù)據(jù)很多，常見的有：
  -外網(wǎng)的bug情況，包括事故，及影響的程度
  -測(cè)試階段的bug數(shù)量，分布（按系統(tǒng)，團(tuán)隊(duì)，開發(fā)個(gè)人），嚴(yán)重程度，bug的類別等維度
  -bug的橫向跨團(tuán)隊(duì)和系統(tǒng)的對(duì)比，縱向的和歷史情況對(duì)比
  -版本發(fā)布的情況，代碼變更行數(shù)的情況
  從這些數(shù)據(jù)的收集中就能發(fā)現(xiàn)很多問題，比如問題集中在哪里，哪些模塊，哪些人，哪些類別等等，以及有沒有改善。
  2.問題的追溯和對(duì)于開發(fā)的考核
  這個(gè)方面也許有一些爭議，但是我還是覺得這個(gè)是一個(gè)很重要的方法。光靠觀念和自覺是不夠的，必需要有一定的反饋機(jī)制，就好比交規(guī)一定是配合著扣分和罰款等手段，否則記錄闖紅燈有什么意義呢？而且現(xiàn)實(shí)的來說，這些方法起到約束的作用，也是一種心理暗示，要做自己做的東西負(fù)責(zé)，也便于養(yǎng)成好的習(xí)慣。
  通常的考核指標(biāo)涉及這些方面：
  -編譯失敗次數(shù)的考核
  -外網(wǎng)事故和bug的數(shù)量
  -測(cè)試階段的bug，特別是基礎(chǔ)功能bug和嚴(yán)重bug
  粗略的列了這么多，其實(shí)可以有很多，比如配置文件改錯(cuò)的情況，漏提測(cè)文件的次數(shù)等等。
  這里也許有很多的討論，但是讓我們看看一個(gè)實(shí)際的例子。下圖是某個(gè)系統(tǒng)的編譯失敗的情況，在11月份的時(shí)候提出要統(tǒng)計(jì)并公開（并無懲罰條款）編譯失敗的情況，包含到開發(fā)的團(tuán)隊(duì)和個(gè)人等明顯，12月份開始出現(xiàn)了明顯的下降并穩(wěn)定了。這個(gè)圖隱藏了一些細(xì)節(jié)，如果剔除其他因素只看開發(fā)代碼原因的編譯失敗則更明顯，特別是后面有懲罰機(jī)制之后，進(jìn)一步下降。
  編譯失敗大幅的下降一方面是節(jié)省了大家的時(shí)間，另一方面其實(shí)也是提高了版本質(zhì)量，想想如果有很多的編譯失敗，而且是到提交測(cè)試的階段，這樣的代碼質(zhì)量能好嗎？是可能做過自測(cè)嗎?有了這樣的機(jī)制，至少會(huì)更仔細(xì)一些。
  對(duì)于bug方面其實(shí)也是一樣，如果開發(fā)在乎（或者被迫在乎）外網(wǎng)bug或者被測(cè)試發(fā)現(xiàn)的bug數(shù)量，他寫代碼的時(shí)候一定會(huì)更仔細(xì)，也會(huì)做些簡單的自測(cè)，讓提測(cè)的質(zhì)量更高，提高了整個(gè)研發(fā)系統(tǒng)的效率，同時(shí)也是提升了質(zhì)量，因?yàn)閝uality must be built in。
  我個(gè)人的經(jīng)驗(yàn)，作為測(cè)試人員幾乎同時(shí)面對(duì)過兩個(gè)開發(fā)團(tuán)隊(duì)，一個(gè)有上述的考核，一個(gè)沒有。表現(xiàn)出來的版本質(zhì)量和對(duì)質(zhì)量的關(guān)注完全不一樣，而且前者也并沒有出現(xiàn)開發(fā)和測(cè)試的對(duì)立，以及測(cè)試不敢提bug等負(fù)面的情況。
  3.對(duì)于測(cè)試的考核
  除了對(duì)于開發(fā)的考核，同樣也有對(duì)于測(cè)試的考核，這樣也更加的公平。
  測(cè)試的考核通常考慮下面的指標(biāo)：
  -漏測(cè)：絕對(duì)數(shù)量或者漏測(cè)率
  -版本的工作量和測(cè)試效率
  -發(fā)布延期的情況
  如果測(cè)試有這樣的壓力，也需要不斷努力去發(fā)現(xiàn)更多的bug。
  說起考核，總有人覺得這不符合智力勞動(dòng)的情況，或者互聯(lián)網(wǎng)的作風(fēng)，其實(shí)不太理解為什么會(huì)這么覺得，放眼望去，有什么工作不被考核呢，sales要背quota，為什么軟件開發(fā)和測(cè)試不能對(duì)自己的工作的質(zhì)量負(fù)責(zé)呢？當(dāng)然，具體的指標(biāo)如何去定才更合理那是另一個(gè)要去考慮的。
  換個(gè)角度來看，適當(dāng)?shù)膲毫Γú粦?yīng)該導(dǎo)致焦慮和扭曲的做法），其實(shí)是讓一個(gè)人表現(xiàn)的狀態(tài)。
  4.推動(dòng)開發(fā)的自測(cè)
  這個(gè)問題一向是個(gè)老大難問題。愿意自測(cè)的開發(fā)團(tuán)隊(duì)你不用太多的推動(dòng)，不愿意做的推動(dòng)也很難，或者你無法判斷他有沒有做自測(cè)。而且這方面，通常取決于開發(fā)負(fù)責(zé)人的觀念和態(tài)度。
  如果是介于之間的，我們可以做一些事情，比如：
  -統(tǒng)計(jì)測(cè)試階段的bug中，屬于開發(fā)可自測(cè)發(fā)現(xiàn)的比例。通過這個(gè)可以看有多少bug是不應(yīng)該到測(cè)試階段的，以及橫行縱向的對(duì)比。當(dāng)然這個(gè)標(biāo)準(zhǔn)要自己拿捏。
  -給出一個(gè)自測(cè)的checklist。開發(fā)在提交前要完成這個(gè)list并正式的給出報(bào)告。這個(gè)方式我們?cè)?jīng)在一個(gè)項(xiàng)目中用過，效果不錯(cuò)，基本功能都通過這個(gè)了，前提是開發(fā)負(fù)責(zé)人認(rèn)可。
  -有一套自動(dòng)化驗(yàn)收的用例，可以掛接到自動(dòng)部署之后或者daily build。前提是我們的自動(dòng)化要足夠的問題，效果才會(huì)好。
  這個(gè)階段除了業(yè)務(wù)測(cè)試的努力，也體現(xiàn)出了QA的價(jià)值。這里的QA是指質(zhì)量管理，有的地方叫SQA，專注在質(zhì)量度量和研發(fā)流程的管理上。
  到這個(gè)階段，發(fā)現(xiàn)事情順了很多，質(zhì)量也有更大程度的提升，并有改善額趨勢(shì)。
  第三個(gè)階段：推動(dòng)全面的質(zhì)量提升
  到上面第二個(gè)階段，我們發(fā)現(xiàn)質(zhì)量有了一定的提升，但是還是有不少的問題，而且有些問題需要我們把思路和眼界拓寬來看。這里討論的一些東西可能更適合互聯(lián)網(wǎng)的產(chǎn)品。
  這里列一些我們可以去做的事情，受限于個(gè)人的經(jīng)驗(yàn)，可能還很片面。
  1.研發(fā)流程的梳理
  其實(shí)在階段2的時(shí)候也可能有些團(tuán)隊(duì)已經(jīng)開始做這樣的事情，因?yàn)樵诜治鲑|(zhì)量和效率問題的時(shí)候，我們發(fā)現(xiàn)很多問題不單純是代碼的問題，可能還涉及研發(fā)流程的很多方面，比如：
  -需求不清楚
  -跨團(tuán)隊(duì)的配合問題
  -代碼版本管理
  -技術(shù)方面的評(píng)審和大家的理解
  所以整個(gè)研發(fā)流程的規(guī)范和梳理，以及配合對(duì)應(yīng)的需求和版本管理的系統(tǒng)也是非常的必要，實(shí)際中發(fā)現(xiàn)效果也是比較的明顯。而且還有一點(diǎn)體會(huì)，在接手一個(gè)很混亂的狀況時(shí)，這樣角度的數(shù)量和調(diào)整比技術(shù)方案的引入更重要和切中要點(diǎn)，能從40分到60分，技術(shù)是往80分走的過程效果更明顯。
  2.提交測(cè)試前后做的一些事情
  -代碼的靜態(tài)掃描
  這個(gè)方法很多的團(tuán)隊(duì)都在做，但是實(shí)際的效果似乎差別很多，而且ROI也很難說，不過從方法本身來說還是值得去做的，對(duì)測(cè)試人員也提出來更高的要求。
  -code review
  這個(gè)開發(fā)應(yīng)該要做，特別是開發(fā)間的交叉review，非常的有幫助。不過這個(gè)也和自測(cè)一樣，取決于開發(fā)負(fù)責(zé)人的態(tài)度。另外，測(cè)試也應(yīng)該去做，特別是對(duì)于diff代碼的review，我們檢查做了大概兩個(gè)月的時(shí)間，發(fā)現(xiàn)還是非常的有收獲。發(fā)現(xiàn)了一些黑盒難以發(fā)現(xiàn)的問題，以及開發(fā)的代碼夾帶，并且對(duì)于這個(gè)版本影響范圍的評(píng)估也更準(zhǔn)確。但問題是短期會(huì)花費(fèi)測(cè)試更多時(shí)間，以及需要測(cè)試人員有一定的技術(shù)能力。
  3.測(cè)試能力的提升
  測(cè)試階段有很多的事情可以去做，覺得最主要的還是兩個(gè)方面
  -自動(dòng)化。越來越覺得這個(gè)是繞不開的話題，要想盡辦法去做，做得更高效更全面。前面有篇blog也提到了一些輕量級(jí)的做法。
  -輔助手段，比如代碼覆蓋率，特別是差異的覆蓋率。這個(gè)大家都比較容易理解就不展開了。
  -拓展測(cè)試的類型
  這個(gè)方面說起來有些泛，需要結(jié)合團(tuán)隊(duì)和業(yè)務(wù)的情況，比如安全測(cè)試，性能測(cè)試，兼容性測(cè)試等，去發(fā)現(xiàn)一些對(duì)于產(chǎn)品來說很重要的風(fēng)險(xiǎn)。
  這方面有兩個(gè)前提，一是我們的基本功能質(zhì)量到了一個(gè)階段，可以讓大家騰出手去拓展測(cè)試的面，另一方面我們測(cè)試人員的能力要跟得上。
  4.發(fā)布環(huán)節(jié)的質(zhì)量把控
  這個(gè)方面和傳統(tǒng)的測(cè)試不太一樣，而且了解到不同的組織做法不同，執(zhí)行發(fā)布的人員可能不同，有開發(fā)，運(yùn)維，專職的版本管理或者測(cè)試來做。
  在我們的實(shí)踐中，發(fā)布后來都逐步收到測(cè)試這邊，回頭來看覺得還是有不少有幫助的地方。當(dāng)然也不絕對(duì)的必須測(cè)試來做。
  -DO分離，避免了隨意的發(fā)布，特別是在開發(fā)手上的時(shí)候。所有的bugfix都經(jīng)過測(cè)試發(fā)布，可以更準(zhǔn)確的度量質(zhì)量（除非這個(gè)問題可以不修復(fù)，否則肯定要過發(fā)布環(huán)節(jié)）
  -知道最近發(fā)了什么，可能的影響是什么，需要線上關(guān)注什么。
  -灰度?；ヂ?lián)網(wǎng)產(chǎn)品常用的一個(gè)控制風(fēng)險(xiǎn)和節(jié)奏的手段。
  -擴(kuò)容的快速自動(dòng)化檢查，這方面也依賴于自動(dòng)化的建設(shè)。
  -發(fā)布過程支持灰度的控制，備份和快速的回滾。對(duì)發(fā)布系統(tǒng)有一定的要求，而且有可追溯性。
  發(fā)布處在整個(gè)研發(fā)流程非常關(guān)鍵的節(jié)點(diǎn)，在這個(gè)點(diǎn)可以做很多的控制，也能發(fā)現(xiàn)很多的問題，對(duì)于測(cè)試團(tuán)隊(duì)來說，從這里可以發(fā)現(xiàn)很多的問題，做很多的提升，對(duì)自己和相關(guān)的合作團(tuán)隊(duì)。
  5.外網(wǎng)的監(jiān)控
  發(fā)現(xiàn)發(fā)布后的問題，持續(xù)運(yùn)營過程中的問題，推動(dòng)優(yōu)化。
  通常監(jiān)控可以分幾個(gè)層面，粗淺的可以分成幾類：
  -運(yùn)維層面的監(jiān)控，比如機(jī)器，鏈路，資源使用，主要組件是否正常等。
  -業(yè)務(wù)指標(biāo)的監(jiān)控，比如來自點(diǎn)擊率，BI系統(tǒng)等。
  -集成在產(chǎn)品里面的監(jiān)控代碼，我們稱之為模塊調(diào)用監(jiān)控。這個(gè)是全量的，有次數(shù)，成功率，響應(yīng)時(shí)間等角度。
  -測(cè)試層面的自動(dòng)化監(jiān)控，關(guān)于在接口和功能層面。這個(gè)是采樣的，但是從用戶的角度來監(jiān)控。
  以上這些監(jiān)控都有對(duì)應(yīng)的告警機(jī)制，可以時(shí)間發(fā)現(xiàn)問題，避免造成更大的損失。為了實(shí)現(xiàn)上面的監(jiān)控需要做大量的工作，但是這些對(duì)于整個(gè)外網(wǎng)運(yùn)營的質(zhì)量非常的重要。
  6.外網(wǎng)事故和問題的收集，跟進(jìn)和反向推動(dòng)
  和前面的思路一樣，如果只是發(fā)現(xiàn)問題解決問題還是稍顯被動(dòng)，那么對(duì)于外網(wǎng)事故和問題的分析，還是有很多推動(dòng)性的幫助。
  7.用戶的問題反饋和滿意度
  進(jìn)一步的質(zhì)量不只是系統(tǒng)本身的質(zhì)量，而是從用戶角度看到的質(zhì)量，有時(shí)候這個(gè)可能稍微超出一些系統(tǒng)層面的問題，但是因?yàn)樽罱K的質(zhì)量還是用戶說了算，所以我們應(yīng)該擴(kuò)展下思路。收集這樣的問題的渠道有很多
  -外網(wǎng)問題反饋，比如來自客服系統(tǒng)的，用戶直接的反饋，現(xiàn)在很多app上都有反饋的功能。
  -論壇信息的統(tǒng)計(jì)收集。我了解的另一個(gè)測(cè)試團(tuán)隊(duì)，他們還專門開發(fā)了一個(gè)自動(dòng)收集外部反饋，以及過濾分析的系統(tǒng)來幫助他們及時(shí)的了解外包的問題反饋。
  8.運(yùn)營層面的質(zhì)量
  更進(jìn)一步，關(guān)注運(yùn)營方面的質(zhì)量，跳出傳統(tǒng)意義的質(zhì)量的范疇，關(guān)注我們的業(yè)務(wù)指標(biāo)，不只是做一個(gè)高質(zhì)量的產(chǎn)品，而是做一個(gè)業(yè)務(wù)上成功的產(chǎn)品。
  比如下面這樣的例子：
  -商品詳情頁的圖片的質(zhì)量
  -活動(dòng)頁面和詳情頁面價(jià)格不一致的情況
  -運(yùn)營配置的錯(cuò)誤導(dǎo)致的問題，哪些是可以監(jiān)控發(fā)現(xiàn)，哪些是可以推動(dòng)運(yùn)營平臺(tái)的規(guī)則檢查?
  每次我們的思路跳出一些框框，都會(huì)有不同的領(lǐng)域。有點(diǎn)點(diǎn)哲學(xué)上的意味，很多領(lǐng)域做到后面，其實(shí)會(huì)超出那個(gè)領(lǐng)域本身的范疇。就好比高性能的汽車，到后面就不得不研究空氣動(dòng)力學(xué)這個(gè)原本是和航空有關(guān)的東西。但是，這是否超出了本意，如果去看待，又是另一個(gè)問題。