丨自動(dòng)化測試如何把bug殺死在搖籃里

當(dāng)我們確保每一個(gè)以前寫好的測試用例能正常通過后，就相當(dāng)于把Bug死在搖籃里，再所以今天我將帶你一起了解什么是自動(dòng)化測試，以及如何在項(xiàng)目中應(yīng)用自動(dòng)化測自動(dòng)化測試并不難理解，你可以想想人是怎么做測試的：首先根據(jù)需求寫成測試用例，設(shè)計(jì)好輸入值和期望的輸出，然后按照測試用例一個(gè)個(gè)操作，輸入一些內(nèi)容，做一些操作，觀察是不是和期望的結(jié)果一致，一致就通過，不一致就不通過。自動(dòng)化測試，就是把這些操作，用程序來完成的，本質(zhì)上還是要輸入和操作，要檢查輸出是不是和期望值一致。只要能按照測試用例操作和檢查，其實(shí)是人來做還是程序來做，結(jié)果都是一樣的。類、函數(shù)進(jìn)行直接測試，如果有一定量的自動(dòng)化測試代碼覆蓋，相對來說軟件質(zhì)量是更有保而且，一旦實(shí)現(xiàn)了自動(dòng)化，每測試一次的成本其實(shí)大幅降低了的，幾百個(gè)測試用例可能幾分鐘就跑完了。尤其是每次修改完代碼，合并到主干之前，把這幾百個(gè)測試用例跑一遍，可以有效地預(yù)防“修復(fù)一個(gè)Bug而產(chǎn)生新Bug”的情況發(fā)生。UI測試、端到端測試、契約測試、組件測試等。而很多時(shí)候同一個(gè)名字還有不同的解讀，在對自動(dòng)化測試類型的定義方面，的分類方法我覺得比較科學(xué)：根據(jù)數(shù)據(jù)做出決策，而不僅僅是依靠或無法衡量和評估的內(nèi)容。將自動(dòng)化測試分成了三大類：假設(shè)我們有一個(gè)，是基于三層架構(gòu)（如下圖所示），業(yè)務(wù)邏輯層的類叫類，數(shù)據(jù)層的類叫UserDA，以用戶的功能來說明幾種測試的區(qū)別比如說UserService這個(gè)類，有一個(gè)用戶的函數(shù)，現(xiàn)在要對它寫一個(gè)單元測試代碼，通過這樣的測試代碼，就可以清楚的知道UserService的create個(gè)函數(shù)是不是能正常小型測試的運(yùn)行，不需要依賴外部。如果有外部服務(wù)（比如文件操作、網(wǎng)絡(luò)服務(wù)、數(shù)據(jù)庫等），必須使用一個(gè)模擬的外部服務(wù)。比如上面例子中我們就使用了FaeUserDA這個(gè)模擬的數(shù)據(jù)庫類，實(shí)際上它不會真實(shí)的數(shù)據(jù)庫。這樣可以保證小型測試在很短時(shí)間內(nèi)就可以完成。（小型測試，來源：《軟件測試之道》中型測試是驗(yàn)證兩個(gè)或多個(gè)模塊應(yīng)用之間的交互，通常也叫集成測如果說要對用戶的功能寫集成測試，那么就會同時(shí)測試業(yè)務(wù)邏輯層的UserService類和數(shù)據(jù)層的UserDA類。如下所示：對于中型測試，可以使用外部服務(wù)（比如文件操作、網(wǎng)絡(luò)服務(wù)、數(shù)據(jù)庫等），可以模擬也可以使用真實(shí)的服務(wù)。比如上面這個(gè)例子，就是真實(shí)的數(shù)據(jù)庫類，但是用的內(nèi)存數(shù)據(jù)庫，至于中型測試要不要使用模擬的服務(wù)，有個(gè)簡單的標(biāo)準(zhǔn)，就是看能不能在單機(jī)情況下完成集（中型測試，來源：《軟件測試之道》系統(tǒng)，從前端一直到后端數(shù)據(jù)。大型測試也叫系統(tǒng)測試或者端對端測試。如果說要對用戶寫一個(gè)端對端測試的例子，那么看起來會像這樣對于大型測試，通常會直接使用外部服務(wù)（比如文件操作、網(wǎng)絡(luò)服務(wù)、數(shù)據(jù)庫等），而不會去模擬。比如上面這個(gè)例子，就是直接測試環(huán)境的地址，通過測試庫提供的API操作瀏覽器界面，輸入測試的用戶名，點(diǎn)擊按鈕，最后檢查輸出的結(jié)果是不是符合預(yù)期。（大型測試，來源：《軟件測試之道》區(qū)分測試類型的依據(jù)是什么以上就是主要的自動(dòng)測試類型了。捎帶著補(bǔ)充一個(gè)測試類型，那就是契約測試，這個(gè)測試最近出現(xiàn)的頻度比較高，主要是針對微服務(wù)的。其實(shí)就是讓微服務(wù)在測試時(shí)，不需要依賴于引用的外部的微服務(wù)，在本地就可以模擬運(yùn)行，同時(shí)又可以保證外部微服務(wù)的接口更新時(shí)，本地模擬的接口（契約）也能同步更新。對契約服務(wù)的說明可以參考這篇文章：《聊一聊契約測試》那么契約測試，屬于大型測試還是中型測針對這幾種測試類型列了一張表，根據(jù)數(shù)據(jù)給出了明確區(qū)分：（來源：TestingBlog）小型測試，沒有外部服務(wù)的依賴，都是要大型測試，幾乎不模擬，直接相關(guān)的外部服務(wù)上面的表中還反應(yīng)出一個(gè)事實(shí)：越是小型測試，執(zhí)行速度越快，越是大型測試，執(zhí)行速度越慢。通常一個(gè)項(xiàng)目的小型測試，不超過一分鐘就能全部跑完，一個(gè)中型測試，包括一些環(huán)境準(zhǔn)備的時(shí)間，可能要幾分鐘甚至更久，而大型測試就更久了。另外越是大型測試，寫起來的成本也相應(yīng)的會更高，所以一般項(xiàng)目中，小型測試最多，中型測試次之，大型測試最少。就像下面這張金字塔圖一樣。所以我們也常用測試金字塔來區(qū)分不同類型的測試粒度。（測試金字塔，來源：TestPyramid如果你對測試類型很感，可以參考《測試金字塔實(shí)戰(zhàn)》這篇文章作為補(bǔ)充怎么寫好自動(dòng)化測試代碼第一步就是準(zhǔn)備，例如創(chuàng)建實(shí)例，創(chuàng)建模擬對象；第二步就是執(zhí)行要測試的方法，傳入要測試的參數(shù)；第三步斷言就是檢查結(jié)果對不對，如果不對測試會失??；第四步還要對數(shù)據(jù)進(jìn)行清理，這樣不影響下一次測試。上面還有幾個(gè)測試代碼示例，都是這樣的四部分內(nèi)一個(gè)完整的自動(dòng)化測試要包括三個(gè)部分的驗(yàn)證功能是不是正確：例如說輸入正確的用戶名和，要能正常賬號覆蓋邊界條件：比如說如果用戶名或?yàn)榭?，?yīng)該不允許成功異常和錯(cuò)誤處理：比如說使用一個(gè)已經(jīng)用過的用戶名，應(yīng)該提示用戶名被使所以你看，寫一個(gè)測試代碼并沒有你想的那么復(fù)雜，那還有什么理由不去寫測試選擇好自動(dòng)化測試框架都不一樣。好在現(xiàn)在搜索引擎很方便，根據(jù)“你的語言+自動(dòng)測試框架”的關(guān)鍵字，就Web 的前端測試框架；Mocha：歷史悠久的一個(gè)JS測試框架；Nighwatch:一個(gè)API很簡單，但是功能很強(qiáng)大，可以直接操作瀏覽器的自動(dòng)測試框iOS可以參考這篇文章《iOS自動(dòng)化測試框架對比》。可以參考這篇文章《Android談?wù)勛詣?dòng)化測試》在持續(xù)集成環(huán)境上跑你的自動(dòng)化測讓自動(dòng)化測試在持續(xù)集成上運(yùn)行非常重要，才能最大化地發(fā)揮自動(dòng)化測試的作用因?yàn)槌掷m(xù)集成，會強(qiáng)制測試通過才能合并代碼，在合并代碼之前就能知道測試是不是都通過了，可以幫助程序員獲得最直觀的反饋，知道哪里可能存在問題，這樣才能真正做到防患于未然，把Bug殺死在搖籃里。下圖描述的就是自動(dòng)測試配合持續(xù)集成的一個(gè)標(biāo)準(zhǔn)流在提交代碼前，先本地跑一遍單元測試，這個(gè)過程很快的，失敗了需要繼續(xù)修單元測試成功后就可以提交到源代碼，提交后持續(xù)集成服務(wù)會自動(dòng)運(yùn)行完整的自（來源：MicroserviceTesting:UnitTests新項(xiàng)目和老項(xiàng)目的不同策如果是新項(xiàng)目，那么可以在一開始就保持一定的自動(dòng)化測試代碼的覆蓋率，你甚至還可以試試測試驅(qū)動(dòng)（TDD）的開發(fā)模式，也就是先寫測試代碼，再寫實(shí)現(xiàn)代碼，保證測試通過，最后對代碼進(jìn)行重構(gòu)。（來源：鄭曄《10x程序員工作法》專欄后面在的過程中修復(fù)Bug的時(shí)候，針對Bug補(bǔ)寫自動(dòng)化測試代碼。這樣一點(diǎn)一點(diǎn)，把自動(dòng)化測試代碼覆蓋率如果時(shí)間緊任務(wù)重，來不及寫自動(dòng)化測試怎么辦確實(shí)遇到時(shí)間緊的情況，我建議你要優(yōu)先保證中型測試代碼的覆蓋，因?yàn)檫@樣至少可以保證主要的用戶使用場景是正常的。然后把來不及完成的部分，創(chuàng)建一個(gè)Tiket，放到任務(wù)跟蹤系統(tǒng)里面，后面補(bǔ)上。今天我?guī)阋黄饘W(xué)習(xí)了關(guān)于自動(dòng)化測試有關(guān)的知識。自動(dòng)化測試，分為三小型測試，主要針對函數(shù)或者類進(jìn)行驗(yàn)證，不調(diào)用外部服務(wù)，執(zhí)行速度大型測試，對服務(wù)整體進(jìn)行驗(yàn)證，執(zhí)行速覆蓋邊界條件驗(yàn)證是否有異常和錯(cuò)誤的處自動(dòng)化測試，一定要配合好持續(xù)集成，才能最大化發(fā)揮其效對于自動(dòng)化測試的實(shí)施，開頭是最難的，因?yàn)樾枰〞r(shí)間選擇自動(dòng)化測試框架，需要針對自動(dòng)化測試框架搭建環(huán)境，甚至要去搭持續(xù)集成環(huán)境。但搭建持續(xù)集成和搭建自動(dòng)化測試環(huán)境，并且保證持續(xù)更新自動(dòng)測試代碼，這個(gè)技術(shù)投資，一定是你在項(xiàng)目中最有價(jià)值的投資之一。你所在項(xiàng)目中，自動(dòng)化測試代碼覆蓋如何？保持高覆蓋率的主要阻力或者是什么？打算感謝閱讀，如果你覺得這篇文章對你有一些啟發(fā)，也歡迎把它給你的朋友 不得售賣。頁面已增加防盜追蹤，將依 上一 28|軟件工程師的競爭力是什么？（下下一 30|用好源代碼管理工具，讓你的協(xié)作更高精選留言 2WebApplicationFactory 展小型測試：中型測試：大型測試比例大約為7:2:1 1展說試試Jenkins或者GitlabCI。 碼時(shí)候，到缺了要求補(bǔ)，還不就續(xù)教，來及寫的創(chuàng)建個(gè)Ic小 展作者回復(fù):推薦：《howwetestsoftwareat 探索無止 老師，我們現(xiàn)在使用的框架是.netcore,語言是C#，用其進(jìn)行后端開發(fā)。能否推薦一下好的自動(dòng)化測試框架。我根據(jù)您的檢索方法語言+自動(dòng)化測試框架找到的是RedwoodHQ，展作者回復(fù):如果是單元測試，.NetCore應(yīng)該自帶了，例如：《.NETC