測試覆蓋率是一項幫助我們在恰當(dāng)優(yōu)先級下使用稀少測試時間的一項策略。當(dāng)最后東西被測試完，我們有多少自動化覆蓋，用戶使用這特性多經(jīng)常，并且對應(yīng)用程序來說這特性有多關(guān)鍵這些都是要考慮的因素。這兒有一些在你轉(zhuǎn)向持續(xù)交付時保持高質(zhì)量的主意。

在過去糟糕的日子里，我們有一個測試持續(xù)數(shù)周或者數(shù)月的測試階段。我們開始只是測試和尋找問題，但是最后，我們不得不開始有一個足夠固定的考慮發(fā)布的版本。

測試者們云集在候選中，并且我們從沒有足夠的時間去在軟件上跑遍我們的想法。即使我們做了，為了確保所有的特性我們想要測試一個使用的平衡——或者用戶用例的核心，或者組件，或者需求——為了這個版本而被測試覆蓋到。

覆蓋率的想法誕生了。

20年后，我共事過的團(tuán)隊很多不再有“測試階段”。如果他們有，它是半天或者一天，可能最多一個星期。一些大的企業(yè)從多個團(tuán)隊強(qiáng)調(diào)了測試集成控件的本質(zhì)，但是他們趨向把這個堪稱是一個傳統(tǒng)活動，而不是一個結(jié)束狀態(tài)。

測試也比之前慣有的復(fù)雜得多。我們有單元測試覆蓋，集成測試覆蓋，自動化測試覆蓋，并且，是的，真實人為探索和調(diào)研覆蓋。

在那優(yōu)先的是我們有一個三維：時間。很多我工作過的軟件機(jī)構(gòu)至少有一個日常版本，不是一個持續(xù)版本。為發(fā)版測試一周候選人幾乎不工作，因為人們忙于提交修復(fù)，經(jīng)常在主要分支上——版本候選人被推自的相同地方。持續(xù)部署上演，合適的我們正在測試的開發(fā)服務(wù)器在實時變化。

使用產(chǎn)品的持續(xù)交付，每一個修復(fù)單獨滾給產(chǎn)品——沒有“等待和測試每一個東西”時間。

改變“部署”意味的什么

當(dāng)窗口程序到來，他們實際上習(xí)慣運送，在箱子里或者在一張碟上。我們能收集當(dāng)前所有文件的版本并把它們作為一束部署。網(wǎng)站改變了所有：突然，我們只推送一個簡單網(wǎng)頁，以及可能一些圖片，一次給產(chǎn)品。假如網(wǎng)頁被孤立并且唯一的風(fēng)險是它會出錯，我們不需要重啟整個應(yīng)用。

一些最有名的早期持續(xù)交付的用例確實只能單獨推送靜態(tài)PHP文件或者在小群里。只要代碼不改變一個代碼庫或者數(shù)據(jù)庫，程序員會更早地回滾一個錯誤，突然不再需要一個長期，涉及回歸測試流程了。

微服務(wù)提供給我們一個類似的利益。只要服務(wù)被關(guān)聯(lián)并且我們知道主應(yīng)用程序在哪里呼叫服務(wù)，然后我們能階段測試服務(wù)，那兒它與用戶接口交互，并且滾動出來——沒有一個整個應(yīng)用程序的大型整頓。

轉(zhuǎn)變到持續(xù)交付

我共事過的許多團(tuán)隊正在嘗試移向微服務(wù)，但是事情并沒有那么簡單。他們沒有在恰當(dāng)位置的技術(shù)去做推送——按鈕，被關(guān)聯(lián)到部署。假如他們做了，然后他們當(dāng)然不會輕易回滾。

回滾經(jīng)常由做人為改變和向前部署組成。它要求相當(dāng)?shù)慕Y(jié)構(gòu)去關(guān)聯(lián)一個變化和前滾而不滾出其他提交晚的。我工作過的一個公司有過這種問題，并且測試者只評論所有的來自最后推進(jìn)的變化。

不要那樣做。

同時，覆蓋率的想法丟了。我們假裝我們生活在這個完美的獨立服務(wù)的世界，但是失敗的需求依然很高。對一個特性或者組件的修復(fù)很容易暴露另一些特性。直到這些“波紋變化”被淘汰，持續(xù)交付將只意味著快速滾出一束被破壞的代碼。

底部一行：團(tuán)隊需要一個當(dāng)他們轉(zhuǎn)向持續(xù)交付時如何測試的游戲計劃。

追蹤風(fēng)險和特性

今天我說看到的是團(tuán)隊有所有自動測試主意的列表并且在部署前恰當(dāng)?shù)貓?zhí)行它們——所有的Selenium測試，所有單元測試，等等。

那帶來的問題是所有的主意對自動化來說太多了而沒法做，就像切換命令，打印，瀏覽器改變大小——那些被忽略了。可能他們?yōu)槊恳粋€故事測試一次，然后忘記。并且，當(dāng)然，它成為被遺忘的東西以至于結(jié)束咬我們。

在團(tuán)隊的最后燒毀流程，你可以使用一個基于產(chǎn)品特性的低技術(shù)的測試板，指派每一個特性一個分?jǐn)?shù)從1到5（或者哭臉到笑臉）關(guān)于他們?nèi)绾魏芎玫販y試。對下一個發(fā)布，當(dāng)決定誰去指派，看一看之前的發(fā)布并且覆蓋這版被觸及的東西，對產(chǎn)品關(guān)鍵的，或者只是沒有很好覆蓋的。

你也能在固定筆記上寫出緊急風(fēng)險并把它們放到墻上，按優(yōu)先級排序。任何人能添加他們想要的任一東西到墻上，最嚴(yán)重的問題排在底部。每一天，團(tuán)隊每個成員從墻上推掉這些風(fēng)險中至少一個，測試它，并且把筆記移向其他地方并約定日期。最后你加上那些卡片回到將要被測的棧頂端。這個策略甚至能為持續(xù)交付工作——只一直推卡片。你可能甚至在產(chǎn)品里開始測試！

關(guān)注優(yōu)先級

覆蓋率是一個幫助我們花稀有的測試時間在恰當(dāng)優(yōu)先級的策略。當(dāng)最后東西被測了，我們有多少自動化覆蓋率，客戶多頻繁使用這個特性，并且這個特性對應(yīng)用程序多關(guān)鍵是所有要考慮的因素。

取代提供給你們一些偽科學(xué)規(guī)則推出如何好地測試每個地方，我嘗試提供一對主意去尋找可視化的方法并且以創(chuàng)造出共用的理解方式去抓住問題。

一些團(tuán)隊會忽略覆蓋率的經(jīng)典問題并且能獨立部署小的組件。對其他每個人：我們最好去工作。

轉(zhuǎn)載于:https://www.cnblogs.com/fengye151/p/11519214.html

總結(jié)

以上是生活随笔為你收集整理的在持续交付阶段中的测试覆盖率（译）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。