?“測試”一詞最初是指“用于測定貴金屬的小容器”。這意味著測試是一種確定黃金或白銀質(zhì)量的方法。它也用于精煉有價值的合金，如錫。

網(wǎng)站建設(shè)哪家好，找創(chuàng)新互聯(lián)！專注于網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、微信小程序定制開發(fā)、集團企業(yè)網(wǎng)站建設(shè)等服務(wù)項目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了鹽津免費建站歡迎大家使用！

后來，該術(shù)語在其他領(lǐng)域被采用，如今，在教育，醫(yī)學(xué)或軟件開發(fā)等環(huán)境中經(jīng)常會發(fā)現(xiàn)它。然而，它的本質(zhì)并沒有改變：測試被用來提煉最終價值。

我們在軟件開發(fā)中使用測試來確保代碼按預(yù)期工作。測試可以是手動的，也可以是自動的。手動測試類似于汽車制造商撞車，以驗證它們在道路上是否安全。它可以工作，但經(jīng)常這樣做太昂貴了，所以它通常在生產(chǎn)周期結(jié)束時完成。這種方法的問題在于，在此階段發(fā)現(xiàn)的問題可能會將產(chǎn)品的發(fā)布延遲數(shù)月。

自動化軟件測試具有完全不同的成本結(jié)構(gòu)。有一個初始反轉(zhuǎn)和定期維護(hù)，但是一旦tes自動化到位，我們就可以根據(jù)需要隨時運行測試 - 只需幾分錢。

通過測試自動化，開發(fā)人員可以獲得持續(xù)的反饋，使他們能夠在生產(chǎn)周期的早期發(fā)現(xiàn)問題?？焖俚筛倪M(jìn)設(shè)計、提高質(zhì)量和更安全的發(fā)布。

測試自動化原理

整本書都是專門圍繞測試自動化主題編寫的。這是每個開發(fā)人員在某些時候都需要掌握的技能，最好盡早完成。

以下是簡化學(xué)習(xí)曲線的六個原則：

1. 測試應(yīng)能提高質(zhì)量。
2. 測試應(yīng)降低引入故障的風(fēng)險。
3. 測試有助于理解代碼。
4. 測試必須易于編寫。
5. 測試套件必須易于運行。
6. 測試套件應(yīng)該需要最少的維護(hù)。

原則 1：測試自動化提高質(zhì)量

質(zhì)量是一個難以捉摸的概念。盡我們所能，不可能用數(shù)字來定義它。然而，當(dāng)我們看到它時，我們就知道它。軟件行業(yè)提出了許多衡量質(zhì)量的指標(biāo)：缺陷數(shù)量、代碼覆蓋率、CI錯誤率、測試失敗率等。每一個都抓住了質(zhì)量概念的某些方面。

自動化測試通過持續(xù)運行數(shù)百或數(shù)千個測試來改善質(zhì)量指標(biāo);在缺陷進(jìn)入生產(chǎn)環(huán)境之前發(fā)現(xiàn)缺陷，通知開發(fā)人員潛在的問題，并檢查系統(tǒng)是否偏離了用戶的期望。

撇開指標(biāo)不談，我們知道可靠的設(shè)計是質(zhì)量的先決條件。當(dāng)測試驅(qū)動開發(fā)時，開發(fā)人員可以輕松嘗試不同的想法，并確定哪一個效果最好。測試驅(qū)動開發(fā) （TDD） 和行為驅(qū)動開發(fā) （BDD） 等實踐利用了這一特性，取得了巨大的成功。

原則2：測試自動化降低風(fēng)險

代碼審查和同行編程雖然必要且富有成效，但不能依靠它來查找錯誤。經(jīng)驗表明，更多的眼球并不能轉(zhuǎn)化為更少的錯誤。

可靠地發(fā)現(xiàn)錯誤的唯一方法是構(gòu)建一個全面的自動化測試套件。測試可以從上到下檢查整個應(yīng)用程序。它們在造成任何傷害、發(fā)現(xiàn)回歸并在各種設(shè)備和環(huán)境上運行應(yīng)用程序之前捕獲錯誤，否則手動嘗試的成本會非常高昂。

即使團隊中的每個人都是一個非常聰明的開發(fā)人員，不知何故從未犯過錯誤，第三方依賴項仍然會引入錯誤并帶來風(fēng)險。自動測試可以掃描項目中的每一行代碼，以查找錯誤和安全問題。

原則3：測試幫助您了解系統(tǒng)

很多時候，開發(fā)人員回到幾天前編寫的代碼，卻意識到他們已經(jīng)完全忘記了它是如何工作的。當(dāng)開發(fā)人員必須處理其他人編寫的代碼時，情況會更糟。

通常，閱讀測試是理解系統(tǒng)的最佳場所，因為它們通過示例來展示事物的工作原理。因此，當(dāng)有疑問時，開發(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)}

不確定是否需要一行代碼？注釋掉它以查看哪個測試失敗。有改進(jìn)功能的想法嗎？需要重構(gòu)一段代碼？嘗試一下并運行自動測試。你會驚訝于你能從系統(tǒng)的測試中學(xué)到多少東西。

原則4：自動化測試應(yīng)該易于編寫

有些測試從手動測試開始，然后自動完成。但是，這通常會導(dǎo)致過于復(fù)雜，緩慢和尷尬的測試。當(dāng)測試和代碼具有一定的協(xié)同作用時，最好的結(jié)果就會出現(xiàn)。編寫測試的行為促使開發(fā)人員生成更多的模塊化代碼，這反過來又使測試更簡單，更精細(xì)。

測試的簡單性很重要，因為為測試編寫測試是不切實際的。代碼也應(yīng)該易于讀取和寫入。否則，我們就有可能在測試本身中引入失敗，從而導(dǎ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"

總而言之，在編寫測試時堅持一些基礎(chǔ)知識是個好主意：

• 每個測試只寫一個斷言。
• 將代碼與測試分開，即生產(chǎn)代碼不應(yīng)包含測試。
• 保持測試彼此獨立，因為依賴關(guān)系很快就會滾雪球般地變成令人頭痛的混亂。
• 將測試重疊保持在最低限度，即不要測試相同的代碼兩次。
• 不要破壞測試代碼的封裝。不，僅測試外部接口。

原則5：測試應(yīng)易于運行

如果開發(fā)人員需要打開清單才能開始測試運行，則測試的運行頻率不會達(dá)到應(yīng)有的水平。

理想情況下，每次代碼更改時都會運行測試，而無需任何干預(yù)。我們在這里很幸運，因為開發(fā)人員工具非常復(fù)雜。大多數(shù)現(xiàn)代IDE可以檢測文件中的更改并自動啟動測試套件，同樣可以通過nodemon，live reload，fswatch或testmon等命令行程序來實現(xiàn)。

說明：VS 代碼在后臺運行測試

為了使測試易于運行，必須滿足一些條件：

• 冪等性：測試不應(yīng)有副作用。副作用包括寫入文件、保存到數(shù)據(jù)庫或通常更改數(shù)據(jù)。開發(fā)人員應(yīng)該能夠安全地運行任意次數(shù)的相同測試。
• 確定性：在給定相同輸入的情況下，測試應(yīng)始終給出相同的結(jié)果。當(dāng)測試需要開發(fā)人員無法控制的外部數(shù)據(jù)（例如日期/時間或來自 API 的響應(yīng)）時，應(yīng)使用模擬或存根偽造這些數(shù)據(jù)。
• 獨立：測試應(yīng)該彼此獨立，開發(fā)人員必須能夠以任何順序運行它們。
• 輕量級：測試必須足夠輕量級，以便在合理的時間內(nèi)在開發(fā)人員的計算機上運行。
• 粒度：開發(fā)人員必須能夠逐個運行測試套件。

在開發(fā)人員的機器上運行測試只是等式的一部分。測試還必須在持續(xù)集成管道中進(jìn)行。您的 CI/CD 管道充當(dāng)質(zhì)量門;它在每次提交時運行測試套件，提供即時反饋，并允許開發(fā)人員檢測何時引入故障。

原則6：自動化測試套件需要低維護(hù)

最后一個原則是前五個原則的必然結(jié)果。也就是說，如果你很好地滿足了其他人，你就可以免費獲得它。盡管如此，這很重要，所以最好把它說出來。

開發(fā)人員希望做有創(chuàng)意和有益的工作。自動化使機器能夠處理測試的苦差事。當(dāng)測試易于編寫且頻繁執(zhí)行時，將創(chuàng)建正反饋循環(huán)。開發(fā)人員傾向于欣賞自動化如何使他們的生活更輕松，因此被激勵編寫和維護(hù)測試。

當(dāng)然，需要一些定期維護(hù)來保持測試的良好狀態(tài)。以下是編寫和維護(hù)測試套件的四條建議：

• 編寫足夠多的測試以使其有效（但不是更多）。如果錯誤溜走，則需要更多的測試。相反，如果您發(fā)現(xiàn)測試因小更改而中斷，則需要刪除一些測試。
• 選擇適合該情況的最佳測試類型。單元測試快速且以激光為重點，而端到端測試涵蓋 UI，并且更繁重且更全面。遵循測試金字塔的測試套件具有健康的各種測試。

• 保持測試的可靠性。當(dāng)代碼正確時失敗的測試稱為誤報。有時無緣無故失敗的測試稱為片狀測試。兩者都會在測試套件中引起問題，因為它們是巨大的時間浪費者和挫折感的來源。
• 保持測試速度快。一個緩慢的測試套件將阻礙開發(fā)。

結(jié)論

那些認(rèn)為測試成本高昂的人并不完全意識到質(zhì)量差的代價。單獨來看，錯誤和缺陷對產(chǎn)品價值的影響可能難以衡量，但如果它們得不到解決，它們可能會迅速失控。幸運的是，您可以通過構(gòu)建和完善自動化測試套件來防止這種情況，從而為出色的開發(fā)人員體驗和出色的高質(zhì)量軟件奠定基礎(chǔ)。?

網(wǎng)站名稱：測試自動化的六大原則
文章地址：http://uogjgqi.cn/article/cdheiio.html