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

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

測試自動化入門

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

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

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

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

我的建議通常是退后一步，弄清楚您需要驗證的內容以及如何進行驗證。有一種非常酷的方法叫MSCW。

Mark Lambert：MSCW方法是什么？

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

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

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

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

當我編寫測試策略時，我會花一些時間來制定我的測試計劃。我真正關心的應用程序領域是什么？哪些領域將易于實現自動化？我通常從那開始。

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

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

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

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

API測試

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

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

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

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

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

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

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

在我們錄制的網絡研討會中，Max Saperstone提供了更多信息，內容涉及如何更有效地交付具有行為驅動開發（BDD）的高質量軟件。查看更多視頻。