?

摘要：

談到什么是組成一次自動化測試的“恰當(dāng)實施”經(jīng)常會關(guān)注你需要用的工具，但是那僅僅是等式的一部分。巴斯 迪杰斯特拉詳細說明了你需要考慮的其他四件事，他們?nèi)绾沃铝τ谀愕淖詣踊瘻y試的成功，以及關(guān)聯(lián)到不能適當(dāng)關(guān)注它們中任一件的風(fēng)險。

為了團隊指望快速傳送質(zhì)量，執(zhí)行自動化測試是軟件開發(fā)周期中一個重要組成部分。測試自動化，無論如何，當(dāng)恰當(dāng)實施時只能成功。論及什么組成測試自動化的“恰當(dāng)實施”經(jīng)常關(guān)注于任務(wù)必須使用的什么工具，或者最好（假如甚至有這樣一個事物）或者最高效的為給予的任務(wù)使用特定工具的方法。

依我看來，雖然，使用的工具只是整體自動化測試方程式的一個部分。任何成功的自動化測試的實施是有五個獨特的部分組成的。

在這篇文章，我們看一看這些部分的每一個，他們?nèi)绾沃铝τ谀愕臏y試自動化實施的成功，以及關(guān)聯(lián)到不能適當(dāng)關(guān)注它們中任一件的風(fēng)險。

1.測試自動化工具

雖然不是在成功的測試自動化實施中充當(dāng)角色的唯一因素，工具顯然在你的自動化努力整體結(jié)果中起了影響。在測試下選擇一款工具不夠與你的應(yīng)用相配，或者一個你的自動化團隊不適合的技能組合，將導(dǎo)致少于最優(yōu)的結(jié)果。

甚至比選擇工具更重要的是，無論如何，問你自己到底什么是正確的在你想要覆蓋你的自動化測試里，并且再決定更高效的獲取那個結(jié)果的方法。一個需要被問到的問題的極限例子是在什么級別上一個特定的功能模塊或者業(yè)務(wù)邏輯需要被確認。

你想要確認你的用戶能打開你的網(wǎng)店，搜索一個特定的產(chǎn)品，并且接著放置并注意排序嗎？你可能將想要使用端到端的用戶接口驅(qū)動測試去檢查這個。假如你正要確認一塊邏輯的正確性以決定是否一個用戶被允許去購買一個特定的物品（比如，由于在國家或者鄉(xiāng)村的標(biāo)準(zhǔn)），然后你可能將能在低水平測試下寫掛鉤于你的應(yīng)用程序的測試，比如一個應(yīng)用程序接口或者甚至簡單的代碼分類。這組成了一個不同的為測試的范圍和方法并且，結(jié)果，需要一個不同的工具。

簡而言之，為了確定你能第一時間花時間在如何達到要求結(jié)果之前知道你的自動化測試需要驗證什么。記住在使你的工具做它并不被設(shè)計的事情里有一個重大風(fēng)險。

2.測試數(shù)據(jù)

任何嚴肅的測試自動化解決方案的另一個重要的因素是管理測試數(shù)據(jù)的方法。測試范圍越廣，越重要，但是也是越要求的，測試數(shù)據(jù)管理來了。

當(dāng)在單元測試里你能遠離模擬所有你的測試依賴的數(shù)據(jù)，當(dāng)你開始在集成上工作時或者端到端測試，你將需要在測試下呈現(xiàn)你應(yīng)用程序里特定的數(shù)據(jù)。并且，為了使事情更加復(fù)雜，你將經(jīng)常在處于試驗階段同時在某一個特定的國家里要其他系統(tǒng)里的數(shù)據(jù)以與你的連通的應(yīng)用程序交互。

有一些在這些測試類型中處理測試數(shù)據(jù)的方法：

• 在測試開始階段創(chuàng)造要求的測試數(shù)據(jù)
• 在開始測試前為了存在的測試數(shù)據(jù)去查詢系統(tǒng)
• 開始測試執(zhí)行前在測試階段初始化你的應(yīng)用程序數(shù)據(jù)庫

這些方法每一個有它的潛在危險：

• 在測試的開始階段創(chuàng)建測試數(shù)據(jù)增加測試執(zhí)行時間，在測試本身甚至開始啟動前增加失敗的風(fēng)險，并且導(dǎo)致很多無用的測試數(shù)據(jù)假如沒有合適的數(shù)據(jù)清理程序。
• 當(dāng)你在開始測試前為存在的測試數(shù)據(jù)去查詢系統(tǒng)時，你啟動了偶然使用非法測試數(shù)據(jù)的風(fēng)險，或者沒有有著合適的優(yōu)先級出現(xiàn)在系統(tǒng)里的測試數(shù)據(jù)。
• 在測試執(zhí)行前初始化數(shù)據(jù)庫讓你以數(shù)據(jù)庫快照去管理并保持更細——那便是，假如你甚至首先被允許執(zhí)行一個數(shù)據(jù)庫恢復(fù)程序。
• 注意沒有合適的為集成和端到端測試的測試數(shù)據(jù)處理方法。無論如何，選擇錯誤的程序，或者根本未能定位測試數(shù)據(jù)問題，將可能導(dǎo)致自動化測試解決方案變得不可重復(fù)利用，不可維護，或者不可測量。
• 整塊材料正快速地重蹈恐龍的覆轍。現(xiàn)代信息技術(shù)系統(tǒng)由許多相互連通的組件，服務(wù)，和為傳遞業(yè)務(wù)價值而工作一起的應(yīng)用程序組成。對測試目的，無論如何，這通常不是好消息：不得不管理和依賴于可用性的獨立性，尤其是那些在你的控制循環(huán)外的那些，為了你的集成和端到端測試能引起很多間接費用，挫折，和測試時間的延遲。依然，當(dāng)你想要創(chuàng)造和使用自動測試作為你的測試方法的一部分時可靠性和易管理的測試環(huán)境是關(guān)鍵。
• 一個減輕失敗或者不存在的測試環(huán)境的風(fēng)險的辦法是使用仿真技術(shù)比如樁，模擬，和服務(wù)虛擬化以復(fù)制在你的測試環(huán)境下關(guān)鍵性的而難獲取的獨立性的行為。做模擬真實的獨立性行為的仿真足夠完成你想要執(zhí)行的測試用例能大大提升你的自動化測試速度——并且，因此，你的開發(fā)效果。
• 此外，當(dāng)虛擬環(huán)境被恰當(dāng)?shù)貏?chuàng)建（比如，通過杠桿作用集裝箱化）時，重建一個相同測試環(huán)境的新實例，有著相同的測試數(shù)據(jù)和其他特性完成，使它可能從一個自動化移向確實的持續(xù)性測試，假如你正要適應(yīng)持續(xù)性的傳遞時這作為一個越靈活的方法且更好地對市場需求增長的反應(yīng)繼而成為先決條件。
• 自動化測試執(zhí)行作為結(jié)果生成的報告應(yīng)該成為任何可靠的測試自動化方法的重要的一部分。創(chuàng)造好的測試結(jié)果報告經(jīng)常被忽略，雖然它是潛在的時代——（和生命——）在任意測試自動化項目里節(jié)省了任務(wù)。好的報告遠超乎展示測試運行的數(shù)量，通過的，和失敗的，雖然只有它也比什么都沒有好。
• 為了使一份測試執(zhí)行報告變得確實有價值，需要被執(zhí)行的測試（注意為了任何好的報告清晰的命名你的測試并且不含糊的格式是基礎(chǔ)的）是什么可視化并且不僅是結(jié)果是什么（通過或失敗），而且萬一測試失敗一些導(dǎo)致錯誤的東西在哪里，盡可能精確地詳細說明。
• 這不同于由僅僅復(fù)制任何和每一個進你的測試報告帶來的提供信息過載——那不必要地延遲到引起測試失敗的根源。一份好的報告展示了錯誤的一些東西，在測試錯誤發(fā)生處（在什么步驟上），錯誤信息是什么（依賴于你的匯報觀眾，這就像堆棧跟蹤一樣簡單，但是其他案例里你可能需要提供也可被非技術(shù)人員讀的錯誤的信息），以及在測試下應(yīng)用程序的狀態(tài)是在失敗的時候（比如說，為用戶接口驅(qū)動測試使用一個截圖）。
• 注意一份好的報告策略可能包含創(chuàng)建每一次執(zhí)行超過一份報告。假如你的測試是一個可持續(xù)集成構(gòu)建管道的一部分，你可能想要創(chuàng)建能被你的構(gòu)建引擎解釋的低水平報告去決定是否繼續(xù)這個構(gòu)建。但是你也可能想要以HTML格式創(chuàng)建一個可讀性的報告，按測試目的的原文描述完成，萬一失敗測試同時以人類-可讀信息和截圖。它都取決于觀眾。

3.測試環(huán)境

• 整塊材料正快速地重蹈恐龍的覆轍。現(xiàn)代信息技術(shù)系統(tǒng)由許多相互連通的組件，服務(wù)，和為傳遞業(yè)務(wù)價值而工作一起的應(yīng)用程序組成。對測試目的，無論如何，這通常不是好消息：不得不管理和依賴于可用性的獨立性，尤其是那些在你的控制循環(huán)外的那些，為了你的集成和端到端測試能引起很多間接費用，挫折，和測試時間的延遲。依然，當(dāng)你想要創(chuàng)造和使用自動測試作為你的測試方法的一部分時可靠性和易管理的測試環(huán)境是關(guān)鍵。
• 一個減輕失敗或者不存在的測試環(huán)境的風(fēng)險的辦法是使用仿真技術(shù)比如樁，模擬，和服務(wù)虛擬化以復(fù)制在你的測試環(huán)境下關(guān)鍵性的而難獲取的獨立性的行為。做模擬真實的獨立性行為的仿真足夠完成你想要執(zhí)行的測試用例能大大提升你的自動化測試速度——并且，因此，你的開發(fā)效果。
• 此外，當(dāng)虛擬環(huán)境被恰當(dāng)?shù)貏?chuàng)建（比如，通過杠桿作用集裝箱化）時，重建一個相同測試環(huán)境的新實例，有著相同的測試數(shù)據(jù)和其他特性完成，使它可能從一個自動化移向確實的持續(xù)性測試，假如你正要適應(yīng)持續(xù)性的傳遞時這作為一個越靈活的方法且更好地對市場需求增長的反應(yīng)繼而成為先決條件。

4.報告

• 自動化測試執(zhí)行作為結(jié)果生成的報告應(yīng)該成為任何可靠的測試自動化方法的重要的一部分。創(chuàng)造好的測試結(jié)果報告經(jīng)常被忽略，雖然它是潛在的時代——（和生命——）在任意測試自動化項目里節(jié)省了任務(wù)。好的報告遠超乎展示測試運行的數(shù)量，通過的，和失敗的，雖然只有它也比什么都沒有好。
• 為了使一份測試執(zhí)行報告變得確實有價值，需要被執(zhí)行的測試（注意為了任何好的報告清晰的命名你的測試并且不含糊的格式是基礎(chǔ)的）是什么可視化并且不僅是結(jié)果是什么（通過或失敗），而且萬一測試失敗一些導(dǎo)致錯誤的東西在哪里，盡可能精確地詳細說明。
• 這不同于由僅僅復(fù)制任何和每一個進你的測試報告帶來的提供信息過載——那不必要地延遲到引起測試失敗的根源。一份好的報告展示了錯誤的一些東西，在測試錯誤發(fā)生處（在什么步驟上），錯誤信息是什么（依賴于你的匯報觀眾，這就像堆棧跟蹤一樣簡單，但是其他案例里你可能需要提供也可被非技術(shù)人員讀的錯誤的信息），以及在測試下應(yīng)用程序的狀態(tài)是在失敗的時候（比如說，為用戶接口驅(qū)動測試使用一個截圖）。
• 注意一份好的報告策略可能包含創(chuàng)建每一次執(zhí)行超過一份報告。假如你的測試是一個可持續(xù)集成構(gòu)建管道的一部分，你可能想要創(chuàng)建能被你的構(gòu)建引擎解釋的低水平報告去決定是否繼續(xù)這個構(gòu)建。但是你也可能想要以HTML格式創(chuàng)建一個可讀性的報告，按測試目的的原文描述完成，萬一失敗測試同時以人類-可讀信息和截圖。它都取決于觀眾。

5.技能

最后，不可議論地最重要的，為創(chuàng)建一個強有力且有效的測試自動化解決方案的迷是負責(zé)實施它的人。沒有富有技能的自動化顧問，架構(gòu)師，工程師，和開發(fā)關(guān)注所有其他在這篇文章里提及的測試自動化的方面，你將可能立即在任何地方結(jié)束。

你的測試自動化團隊理想地必須都是在測試領(lǐng)域有技能的，因此他們能回答為什么測試自動化將首先是一個合適的解決方案，同時什么測試要被自動化；并且有技能于軟件開發(fā)，意味著他們知道如何去創(chuàng)建一次測試自動化強有力且可維護的實施。這不意味著你的測試自動化每一個成員需要在每個領(lǐng)域都有技能，但是作為一個整體，你的團隊為了交付需要有一個這兩方面的健康平衡。

把它所有的放在一起

一個好的測試自動化解決方案需要關(guān)注更多不僅僅是驅(qū)動測試的工具。為了真正成功的自動化，你需要想辦法在你的測試數(shù)據(jù)策略上，在你如何管理你的測試環(huán)境上，并且在你通知你的觀眾關(guān)于你自動化的測試執(zhí)行結(jié)果的方式上。最重要的是，無論如何，它是關(guān)于創(chuàng)建一個知道如何做所有以上的人的團隊。

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

《新程序員》：云原生和全面數(shù)字化實踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結(jié)

以上是生活随笔為你收集整理的成功的自动化测试实施的5大支柱（译）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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