在這三篇博客文章中，我們深入了解了如何構(gòu)建有效的測試策略以及如何將測試自動化用作該策略的一部分。我采訪了Coveros測試自動化總監(jiān)Max Saperstone。Max是一位經(jīng)驗豐富的測試工程師，專注于CI/CD流程中的測試自動化。他向各種客戶伸出援手，以幫助他們開展測試和自動化工作。Max還是一位經(jīng)驗豐富且經(jīng)過認證的敏捷開發(fā)人員，在測試和敏捷開發(fā)人員會議上的演講活動受到追捧。我們很幸運能在此關(guān)頭擁有Max的經(jīng)驗，在Parasoft討論我們心中最接近的話題。

這是一個由三部分組成的系列文章的一部分，該系列文章討論了Max關(guān)于測試自動化入門的想法。一件事很明顯，Max希望幫助客戶退后一步，在進入測試自動化之前考慮一下全局。幫助他的客戶回答重要問題，例如“我為什么要自動化測試？”這樣他們可以為自己的工作設(shè)定明確的目標。我們還簡短地討論了API測試，Max似乎和我們在同一頁面上——API測試至關(guān)重要。讓我們看看Max怎么說：

測試自動化入門

Mark Lambert：嗨，Max，很高興再次與您在一起。我知道您在Coveros的職責(zé)是幫助和協(xié)助客戶制定有效的測試自動化策略。您能告訴我們您認為什么是有效的測試自動化策略嗎？團隊應(yīng)該從哪里開始？

Max Saperstone：嗨，Mark，這是一個很好的問題！有趣的是，正如您所知道的，我的專長是自動化，盡管如此，當(dāng)團隊開始時，我的建議通常是：“不要僅僅涉足自動化。”

真正最好的起點是從整體上看質(zhì)量檢查。因此，首先要了解的是“整體質(zhì)量”對您的項目意味著什么，以及如何進行驗證。只有知道了這些問題的答案后，您才可以真正地決定要自動化什么，以及不想自動化什么。

對我而言，這始終是最大的挑戰(zhàn)之一。我看到很多團隊開始涉足開始編寫Selenium腳本或QTP腳本，并且他們有一堆“東西”。但最終，這些東西是如何使用的？您如何處理測試結(jié)果？您如何決定何時發(fā)貨？

我的建議通常是退后一步，弄清楚您需要驗證的內(nèi)容以及如何進行驗證。有一種非?？岬姆椒ń?/span>MSCW。

Mark Lambert：MSCW方法是什么？

Max Saperstone：MSCW方法實際上只是一個縮寫。這是您必須自動化的東西，您應(yīng)該自動化的東西，您可以自動化的東西，以及不能自動化的東西。這個想法實際上是在您的自動化策略中花一些時間和思想，以找出最大的收益所在。

對我而言，這總是可以追溯到ROI。持續(xù)運行的測試有哪些？您的應(yīng)用程序真正有價值的地方是什么，您不能在其中犯任何錯誤？對用戶的影響最大的是什么？您從永遠屬于“野性”的東西開始，并且始終屬于“應(yīng)有的”東西。

然后，您進入了“可能”和“想要”的其他區(qū)域。例如，測試可用性，要實現(xiàn)自動化確實是一件非常困難且困難的事情：如何告訴機器感覺正確與不感覺正確？

另一個難以自動化的領(lǐng)域是第三方集成。例如，假設(shè)您具有FitBit集成，則最終可以使它自動化。但這將需要數(shù)周或數(shù)月的時間。真正值得花這么長時間來使之自動化嗎？

當(dāng)我編寫測試策略時，我會花一些時間來制定我的測試計劃。我真正關(guān)心的應(yīng)用程序領(lǐng)域是什么？哪些領(lǐng)域?qū)⒁子趯崿F(xiàn)自動化？我通常從那開始。

Mark Lambert：那么您如何組織這個呢？

Max Saperstone：當(dāng)然，這實際上仍是從功能層面上講。只要退后一步，就考慮一下測試金字塔和質(zhì)量所涉及的不同角色來考慮您的策略，因為它不僅僅是測試人員。開發(fā)人員應(yīng)該在測試金字塔的下部編寫單元測試和集成測試。在某個時刻，測試人員像冰山一角一樣接管了工作。在表面之下，您要確保所有代碼都已通過單元測試進行了測試-確保代碼執(zhí)行開發(fā)人員認為代碼應(yīng)執(zhí)行的操作。下一步是集成測試，它可以確保應(yīng)用程序的不同部分以其他部分認為的實際方式工作。最后，您擁有測試人員，他們坐在冰山的頂端，他們真的想確保整個應(yīng)用程序都能完成最終客戶的實際需求。

如果您沒有正確地完成這兩個基礎(chǔ)部分-自動化會獲得回報，并且在這些低層級上又快速又容易-頂層的錯誤將很難調(diào)試和修復(fù)。你不知道。 “這是功能問題嗎？是組件問題？還是代碼問題？”但是，如果您知道所有其他所有功能均正常運行，則可以很輕松地解決這些問題。

但是，如果您知道所有單元測試和集成測試均已通過，那么將故障診斷為可能的功能問題會更快。相反的情況是，自動化策略較差，要找出根本原因，需要大量調(diào)試，而好的自動化策略問題則要簡單得多。

API測試

Mark Lambert：在Parasoft，我們已經(jīng)討論API測試已有近二十年了，但是，對于許多人來說，采用API測試仍然是新鮮事物。這可能是由于API的隱藏特性所致，它位于UI和代碼之間的層中，許多人看不到它。您認為前進的方向是什么？組織如何真正以最有效的方式利用API測試？

Max Saperstone：這是一個很好的問題。我喜歡API測試，因為來自測試人員（不一定訪問所有代碼），這是從黑匣子角度進行大量測試的好方法。僅僅因為我不知道代碼是做什么的，并不意味著我對API沒有很好的了解。

希望我能看到一個API期望輸入什么以及它正在生成的輸出，無論是否有WSDL或相關(guān)的草率文檔。API測試使我能夠以非常快速的方式進行測試，因為那時它是數(shù)據(jù)驅(qū)動的。我有一個端點，我拋出了許多我認為有效的不同輸入組合，并檢查了所有不同的輸出。我不一定真的需要了解很多關(guān)于代碼的知識，并且有很多非常好的框架可以為我處理這些事情。

因此，從測試人員的角度來看，這絕對是我喜歡API測試的原因。另外，它們速度快，通常不易碎。如果您有一個組織來設(shè)置合同并具有定義明確的端點（并且不會經(jīng)常更改），那么對API測試的維護就很少，它們可以為您提供有關(guān)系統(tǒng)的大量信息。

Mark Lambert：我認為您剛才談到的關(guān)于API測試快速且穩(wěn)定的原因，確實是它們變得非常有價值的原因。而且，它們是組織內(nèi)測試人員和開發(fā)人員之間的一種很好的溝通機制。

Max Saperstone：絕對。通常，當(dāng)我談到組織的集成測試時，API測試是其中的很大一部分。它們速度很快，為您提供了許多真正有價值的信息，并且比UI測試更加穩(wěn)定。

在下一篇文章中，我們與Max討論建立測試策略以及他對測試金字塔的看法。

在我們錄制的網(wǎng)絡(luò)研討會中，Max Saperstone提供了更多信息，內(nèi)容涉及如何更有效地交付具有行為驅(qū)動開發(fā)（BDD）的高質(zhì)量軟件。查看更多視頻。