測試自動(dòng)化的六大原則
?“測試”一詞最初是指“用于測定貴金屬的小容器”。這意味著測試是一種確定黃金或白銀質(zhì)量的方法。它也用于精煉有價(jià)值的合金，如錫。
后來，該術(shù)語在其他領(lǐng)域被采用，如今，在教育，醫(yī)學(xué)或軟件開發(fā)等環(huán)境中經(jīng)常會發(fā)現(xiàn)它。然而，它的本質(zhì)并沒有改變：測試被用來提煉最終價(jià)值。
我們在軟件開發(fā)中使用測試來確保代碼按預(yù)期工作。測試可以是手動(dòng)的，也可以是自動(dòng)的。手動(dòng)測試類似于汽車制造商撞車，以驗(yàn)證它們在道路上是否安全。它可以工作，但經(jīng)常這樣做太昂貴了，所以它通常在生產(chǎn)周期結(jié)束時(shí)完成。這種方法的問題在于，在此階段發(fā)現(xiàn)的問題可能會將產(chǎn)品的發(fā)布延遲數(shù)月。
自動(dòng)化軟件測試具有完全不同的成本結(jié)構(gòu)。有一個(gè)初始反轉(zhuǎn)和定期維護(hù)，但是一旦tes自動(dòng)化到位，我們就可以根據(jù)需要隨時(shí)運(yùn)行測試 - 只需幾分錢。
通過測試自動(dòng)化，開發(fā)人員可以獲得持續(xù)的反饋，使他們能夠在生產(chǎn)周期的早期發(fā)現(xiàn)問題。快速迭代可改進(jìn)設(shè)計(jì)、提高質(zhì)量和更安全的發(fā)布。
測試自動(dòng)化原理
整本書都是專門圍繞測試自動(dòng)化主題編寫的。這是每個(gè)開發(fā)人員在某些時(shí)候都需要掌握的技能，最好盡早完成。
以下是簡化學(xué)習(xí)曲線的六個(gè)原則：
- 測試應(yīng)能提高質(zhì)量。
- 測試應(yīng)降低引入故障的風(fēng)險(xiǎn)。
- 測試有助于理解代碼。
- 測試必須易于編寫。
- 測試套件必須易于運(yùn)行。
- 測試套件應(yīng)該需要最少的維護(hù)。
原則 1：測試自動(dòng)化提高質(zhì)量
質(zhì)量是一個(gè)難以捉摸的概念。盡我們所能，不可能用數(shù)字來定義它。然而，當(dāng)我們看到它時(shí)，我們就知道它。軟件行業(yè)提出了許多衡量質(zhì)量的指標(biāo)：缺陷數(shù)量、代碼覆蓋率、CI錯(cuò)誤率、測試失敗率等。每一個(gè)都抓住了質(zhì)量概念的某些方面。
自動(dòng)化測試通過持續(xù)運(yùn)行數(shù)百或數(shù)千個(gè)測試來改善質(zhì)量指標(biāo);在缺陷進(jìn)入生產(chǎn)環(huán)境之前發(fā)現(xiàn)缺陷，通知開發(fā)人員潛在的問題，并檢查系統(tǒng)是否偏離了用戶的期望。
撇開指標(biāo)不談，我們知道可靠的設(shè)計(jì)是質(zhì)量的先決條件。當(dāng)測試驅(qū)動(dòng)開發(fā)時(shí)，開發(fā)人員可以輕松嘗試不同的想法，并確定哪一個(gè)效果最好。測試驅(qū)動(dòng)開發(fā) （TDD） 和行為驅(qū)動(dòng)開發(fā) （BDD） 等實(shí)踐利用了這一特性，取得了巨大的成功。
原則2：測試自動(dòng)化降低風(fēng)險(xiǎn)
代碼審查和同行編程雖然必要且富有成效，但不能依靠它來查找錯(cuò)誤。經(jīng)驗(yàn)表明，更多的眼球并不能轉(zhuǎn)化為更少的錯(cuò)誤。
可靠地發(fā)現(xiàn)錯(cuò)誤的唯一方法是構(gòu)建一個(gè)全面的自動(dòng)化測試套件。測試可以從上到下檢查整個(gè)應(yīng)用程序。它們在造成任何傷害、發(fā)現(xiàn)回歸并在各種設(shè)備和環(huán)境上運(yùn)行應(yīng)用程序之前捕獲錯(cuò)誤，否則手動(dòng)嘗試的成本會非常高昂。
即使團(tuán)隊(duì)中的每個(gè)人都是一個(gè)非常聰明的開發(fā)人員，不知何故從未犯過錯(cuò)誤，第三方依賴項(xiàng)仍然會引入錯(cuò)誤并帶來風(fēng)險(xiǎn)。自動(dòng)測試可以掃描項(xiàng)目中的每一行代碼，以查找錯(cuò)誤和安全問題。
原則3：測試幫助您了解系統(tǒng)
很多時(shí)候，開發(fā)人員回到幾天前編寫的代碼，卻意識到他們已經(jīng)完全忘記了它是如何工作的。當(dāng)開發(fā)人員必須處理其他人編寫的代碼時(shí)，情況會更糟。
通常，閱讀測試是理解系統(tǒng)的最佳場所，因?yàn)樗鼈兺ㄟ^示例來展示事物的工作原理。因此，當(dāng)有疑問時(shí)，開發(fā)人員可以參考測試套件。
例如，測試可以向其他開發(fā)人員展示API應(yīng)該如何響應(yīng)，從而允許他們跳過查看文檔。
ctx := context.Background()result, _, err := env.Client.Server.Create(ctx, ServerCreateOpts { Name: "test", ServerType: &ServerType{ID: 1}, Image: &Image{ID: 2}, SSHKeys: []*SSHKey{ {ID: 1}, {ID: 2}, },})if err != nil { t.Fatalf("Server.Create failed: %s", err)}if result.Server == nil { t.Fatal("no server")}if result.Server.ID != 1 { t.Errorf("unexpected server ID: %v", result.Server.ID)}if result.RootPassword != "" { t.Errorf("expected no root password, got: %v", result.RootPassword)}if len(result.NextActions) != 1 || result.NextActions[0].ID != 2 { t.Errorf("unexpected next actions: %v", result.NextActions)}不確定是否需要一行代碼？注釋掉它以查看哪個(gè)測試失敗。有改進(jìn)功能的想法嗎？需要重構(gòu)一段代碼？嘗試一下并運(yùn)行自動(dòng)測試。你會驚訝于你能從系統(tǒng)的測試中學(xué)到多少東西。
原則4：自動(dòng)化測試應(yīng)該易于編寫
有些測試從手動(dòng)測試開始，然后自動(dòng)完成。但是，這通常會導(dǎo)致過于復(fù)雜，緩慢和尷尬的測試。當(dāng)測試和代碼具有一定的協(xié)同作用時(shí)，最好的結(jié)果就會出現(xiàn)。編寫測試的行為促使開發(fā)人員生成更多的模塊化代碼，這反過來又使測試更簡單，更精細(xì)。
測試的簡單性很重要，因?yàn)闉闇y試編寫測試是不切實(shí)際的。代碼也應(yīng)該易于讀取和寫入。否則，我們就有可能在測試本身中引入失敗，從而導(dǎo)致誤報(bào)和片狀。
許多測試框架使用域特定語言 （DSL） 以簡單的英語定義測試。也許最值得注意的例子是小黃瓜測試框架使用的語言Gherkin：
Feature: Is it Friday yet?Everybody wants to know when it's FridayScenario: Sunday isn't Friday Given today is Sunday When I ask whether it's Friday yet Then I should be told "Nope"
總而言之，在編寫測試時(shí)堅(jiān)持一些基礎(chǔ)知識是個(gè)好主意：
- 每個(gè)測試只寫一個(gè)斷言。
- 將代碼與測試分開，即生產(chǎn)代碼不應(yīng)包含測試。
- 保持測試彼此獨(dú)立，因?yàn)橐蕾囮P(guān)系很快就會滾雪球般地變成令人頭痛的混亂。
- 將測試重疊保持在最低限度，即不要測試相同的代碼兩次。
- 不要破壞測試代碼的封裝。不，僅測試外部接口。
原則5：測試應(yīng)易于運(yùn)行
如果開發(fā)人員需要打開清單才能開始測試運(yùn)行，則測試的運(yùn)行頻率不會達(dá)到應(yīng)有的水平。
理想情況下，每次代碼更改時(shí)都會運(yùn)行測試，而無需任何干預(yù)。我們在這里很幸運(yùn)，因?yàn)殚_發(fā)人員工具非常復(fù)雜。大多數(shù)現(xiàn)代IDE可以檢測文件中的更改并自動(dòng)啟動(dòng)測試套件，同樣可以通過nodemon，live reload，fswatch或testmon等命令行程序來實(shí)現(xiàn)。
說明：VS 代碼在后臺運(yùn)行測試
為了使測試易于運(yùn)行，必須滿足一些條件：
- 冪等性：測試不應(yīng)有副作用。副作用包括寫入文件、保存到數(shù)據(jù)庫或通常更改數(shù)據(jù)。開發(fā)人員應(yīng)該能夠安全地運(yùn)行任意次數(shù)的相同測試。
- 確定性：在給定相同輸入的情況下，測試應(yīng)始終給出相同的結(jié)果。當(dāng)測試需要開發(fā)人員無法控制的外部數(shù)據(jù)（例如日期/時(shí)間或來自 API 的響應(yīng)）時(shí)，應(yīng)使用模擬或存根偽造這些數(shù)據(jù)。
- 獨(dú)立：測試應(yīng)該彼此獨(dú)立，開發(fā)人員必須能夠以任何順序運(yùn)行它們。
- 輕量級：測試必須足夠輕量級，以便在合理的時(shí)間內(nèi)在開發(fā)人員的計(jì)算機(jī)上運(yùn)行。
- 粒度：開發(fā)人員必須能夠逐個(gè)運(yùn)行測試套件。
在開發(fā)人員的機(jī)器上運(yùn)行測試只是等式的一部分。測試還必須在持續(xù)集成管道中進(jìn)行。您的 CI/CD 管道充當(dāng)質(zhì)量門;它在每次提交時(shí)運(yùn)行測試套件，提供即時(shí)反饋，并允許開發(fā)人員檢測何時(shí)引入故障。
原則6：自動(dòng)化測試套件需要低維護(hù)
最后一個(gè)原則是前五個(gè)原則的必然結(jié)果。也就是說，如果你很好地滿足了其他人，你就可以免費(fèi)獲得它。盡管如此，這很重要，所以最好把它說出來。
開發(fā)人員希望做有創(chuàng)意和有益的工作。自動(dòng)化使機(jī)器能夠處理測試的苦差事。當(dāng)測試易于編寫且頻繁執(zhí)行時(shí)，將創(chuàng)建正反饋循環(huán)。開發(fā)人員傾向于欣賞自動(dòng)化如何使他們的生活更輕松，因此被激勵(lì)編寫和維護(hù)測試。
當(dāng)然，需要一些定期維護(hù)來保持測試的良好狀態(tài)。以下是編寫和維護(hù)測試套件的四條建議：
- 編寫足夠多的測試以使其有效（但不是更多）。如果錯(cuò)誤溜走，則需要更多的測試。相反，如果您發(fā)現(xiàn)測試因小更改而中斷，則需要?jiǎng)h除一些測試。
- 選擇適合該情況的最佳測試類型。單元測試快速且以激光為重點(diǎn)，而端到端測試涵蓋 UI，并且更繁重且更全面。遵循測試金字塔的測試套件具有健康的各種測試。
- 保持測試的可靠性。當(dāng)代碼正確時(shí)失敗的測試稱為誤報(bào)。有時(shí)無緣無故失敗的測試稱為片狀測試。兩者都會在測試套件中引起問題，因?yàn)樗鼈兪蔷薮蟮臅r(shí)間浪費(fèi)者和挫折感的來源。
- 保持測試速度快。一個(gè)緩慢的測試套件將阻礙開發(fā)。
結(jié)論
那些認(rèn)為測試成本高昂的人并不完全意識到質(zhì)量差的代價(jià)。單獨(dú)來看，錯(cuò)誤和缺陷對產(chǎn)品價(jià)值的影響可能難以衡量，但如果它們得不到解決，它們可能會迅速失控。幸運(yùn)的是，您可以通過構(gòu)建和完善自動(dòng)化測試套件來防止這種情況，從而為出色的開發(fā)人員體驗(yàn)和出色的高質(zhì)量軟件奠定基礎(chǔ)。?
