在與Coveros測試自動化總監Max Saperstone的第二部分對話中（第一部分在這里），我們深入了解了如何建立有效的測試策略以及他對商業測試自動化工具的想法。

Max在他的客戶中發現的情況與Parasoft在我們這里遇到的情況相同。許多組織在測試以及如何在每個測試階段分配資源方面都面臨挑戰。Max隨后討論了他對商用工具的看法，并圍繞無代碼測試進行了更多討論。

測試策略和測試金字塔

Mark Lambert：制定API測試策略意味著您可以在流程中盡早發現問題，并且盡早隔離問題顯然是業界所追求的。但是，當我與人們交談時，他們將測試策略描述為更像蛋卷冰淇淋或倒金字塔。那也是你看到的嗎？如果是這樣，那么您看到軟件團隊面對這種冰激凌類型的情況有哪些挑戰？

Max Saperstone：我在倒金字塔上看到了各種各樣的變化。有些差不多是一個沙漏，底部有很多活動，頂部有很多活動，而中間卻很少。

確實，問題歸結為成本和速度，老實說，速度也流入成本。單元測試很便宜，應該在幾秒鐘內即可完成。這些單元測試確實應該構成金字塔的底部。它們創建起來應該相對便宜，維護起來也相對便宜。如果它們不是快速，可維護的東西，那么它們要么不是真正的單元測試，要么就是您做的不好。

我要做的很多事情都是與開發人員，測試人員和需求分析人員一起工作。我需要了解在不同區域進行真正測試的必要條件，并且每個人都在同一頁面上。例如，當您測試數據庫時，它不再是單元測試，而是真正的組件測試。我看到團隊中有很多單元測試，但也有很多集成測試。隔離差和復雜的單元測試會減慢單元測試過程。

您希望單元測試更快的原因是即使在代碼編譯之前也要迅速獲得反饋。您要確保代碼至少能達到開發人員想要的功能。因為如果它沒有按照開發人員的意愿進行操作，則沒有任何理由進一步發展。

通常以UI測試的形式進行的功能測試本質上是脆弱的，它們更難以維護。那么，為什么一個團隊想要更多呢？我進入不同的組織，他們說：“嗯，自動化對我們沒有用。”我說：“好吧，讓我們看看您的測試。”我發現這是三件事的結合：它們有太多的UI測試，它們太難以維護，并且編寫得不好。我告訴他們他們可以減少UI測試的數量，因為所有其他這些測試層（單元和組件）都可以支持它們，并且當他們改進它們時，我可以幫助他們編寫比目前更好的功能測試。

Mark Lambert：您提到了我想回到的話題，因為自15年前加入Parasoft以來，我就一直看到這個問題。當有人說“是的，我正在進行單元測試”，但是當您進入那里時，他們實際上并未在進行單元測試，實際上他們在金字塔上更高。如您所說，僅使用單元測試框架并不一定意味著他們正在進行單元測試。你為什么這么認為呢？有人要創建正確的或真實的單元測試有什么挑戰？

Max Saperstone：這絕對不是我在一兩個地方見過的孤立事件。坦白地說，與集成或系統測試相比，編寫好的單元測試很困難。如果要進行良好的單元測試，則必須模擬單元依賴的所有內容。

編寫模擬并不容易。這需要更多的工作；它需要更多的庫。開發人員實際上為此苦苦掙扎。他們可能不知道該怎么做，或者可能沒有時間去做。由于這些原因，他們可能決定采取捷徑來快速連接數據庫，例如，這是短期解決方案。一周后，其他所有人都在使用相同的代碼，現在更改它已為時已晚。當我指出這些問題時，對此的回答是“嗯，我們正在編寫測試。總比沒有好。”確實如此，但是這些團隊很快就進入了他們的測試效果不佳的地方。

我實際上并不認為這大部分都是無知。我真的認為在大多數情況下，這是一個時間緊縮。當涉及到這一點時，我在每個組織中都看到了這一點，與最初做正確的事情相比，管理層更關心的是發布產品。因此，這些團隊積累了技術債務，并且在短期內沒有問題。但是，真正的問題在于，當他們不找回并減少債務時，當他們重構代碼或進行某些更改時，這些復雜的，非隔離的“單元測試”變得越來越脆弱，并且事情越來越多，開始崩潰。盡管起初他們有良好的意愿，但不良測試和技術債務的累積卻造成了我所看到的問題。

測試自動化工具

Mark Lambert：在幫助客戶部署其測試策略并確定要在何處應用自動化時，他們必須做出一些技術決策。例如，他們需要決定是否要使用開源或商業解決方案？還是只是建立自己的框架？您建議他們從哪里開始決策過程？

Max Saperstone：這是一個很好的問題，Mark。這實際上是我最常被問到的問題之一：我應該使用哪種工具？我應該使用什么框架？客戶通常將開始進行自動化或進入API測試。不幸的是，我總是給出的答案是“哦，我不知道”，因為我不喜歡工具優先方法。

我非常希望客戶退后一步，考慮他們的要求是什么。他們從測試結果分析和可追溯性角度看什么？他們想要完成什么？他們希望工具支持什么級別的測試金字塔？只是在UI，API和單元測試上進行測試？總體測試策略是什么？

一旦我回答了所有這些問題。然后我將研究市場上存在的一些框架和工具，并根據研究客戶的需求做出決策。我總是建議先使用開源工具。我非常樂于嘗試做盡可能敏捷的事情，其中很大一部分是實驗。眾所周知，有時候失敗是實驗的一部分。您可能會找到正確的工具，并且一開始可能工作正常，也可能無法正常工作。如果您必須為這些工具付費，那么實驗會變得很昂貴，而且您可能無法獲得所需的東西。

在嘗試了開放源代碼工具之后，我建議我的客戶看一下具有免費試用期的商業工具來嘗試檢查。在這一點上，我建議他們開始對商業解決方案進行更多分析。

在考慮開放源代碼工具時，要考慮的一大問題是支持。那里有不同的開源框架和工具，僅僅因為它們是免費的，并不意味著它們是垃圾，但這也不意味著它們也很不錯。例如，Selenium周圍存在一種污名，人們質疑免費工具是否有好處。現在有一個龐大的社區對此做出了貢獻，盡管您可以繼續免費下載它，但它是用于UI測試的第一大自動化工具。

知道那里提供了哪些支持對于開源工具很重要。這也是區分優秀開源項目的關鍵因素之一；社區的支持。您提出問題，人們會相對迅速地得到答案。Selenium有很多人專門在那里回答問題。這樣的社區支持，無論是付費工具還是免費工具，都非常重要。

開源工具的危險在于可能會陷入錯誤或使用問題，并且項目會被放棄，盡管這在商業工具中也可能發生。但是，如果我沒有將測試便攜式化，那就是我創建的問題。

當您查看所有這些不同的工具和方法時，都需要權衡取舍。對我而言，有了適當水平的支持和支持，這總是會使開源社區更有價值。

商業工具

Mark Lambert：如果擔心供應商鎖定，您是否正在尋找可以輕松在不同框架之間移植測試的技術？換句話說，評估商業解決方案的一個關鍵方面是能否在工具之間切換并確保您不被其平臺鎖定？

Max Saperstone：是的，這確實。對于許多供應商而言，互換性支持是一件好事，而對于某些工具，它確實運作良好。但是，當您最初進行首次實驗時，您不一定要從商業工具開始。如果我不得不重寫六個不同的測試套件以僅嘗試六個不同的軟件，那將是一件痛苦的事情。

Mark Lambert：因此，首先開放源代碼，直到遇到障礙，然后尋找可以幫助您超越障礙的東西？

Max Saperstone：可能吧。有很多不同的解決方案，它們有免費版本或“免費增值”模型，您可以在上面付費購買其他功能。除此之外，還有付費版本。我非常喜歡這些工具，因為一旦研究它們，我就意識到我可以做所有這些很棒的事情。對我來說，很多時候值得這樣做，因為如果該工具具有所有正確的功能，并且我可以事先進行很多開發，則在構建期間只需要一兩個許可證即可運行該工具。還算不錯

同樣，這也取決于團隊的技術水平。付費產品的好處是，它們通常會為您準備好支持。如果該小組在技術上不熟練使用測試工具，并且他們需要更多支持，則可以使用該工具。對于Parasoft的產品，支持是客戶要付費的事情之一，這在戰略上很有意義。

無代碼測試

Mark Lambert：針對您對非技術用戶的評論，例如，對Selenium編碼不滿意的人，無編碼測試工具是否可以解決？無代碼測試對您意味著什么？你怎么看？

Max Saperstone：大約五年來，我已經看到無代碼測試自動化工具。我回想起我最初意識到它們的時候，它們真的很光滑。我喜歡它們可以使很多事情變得相對簡單，并且其中一些超越了無代碼方面。例如，有些工具使您可以在需要時開始學習并開始用Java或Python編寫東西。當您的技術團隊較少時，具備無代碼測試能力和必要時添加代碼的能力就很重要。

在我看來，每種單一類型的工具都有其成本。您必須為具有編碼背景的人員支付更多的費用，而為技術測試人員較少的人員支付更少的費用。但是，這可能會被技術抵消并向供應商支持付出更多。因此，我認為無代碼測試確實為此提供了一個很好的解決方案。

我看到的最大挑戰是在這個領域中存在許多不同的參與者。我還沒有真正看到一個供應商領先于其他供應商。供應商似乎仍然站不住腳。盡管這肯定意味著測試自動化工具的市場正在增長，但是這些工具可能無法解決我們在測試自動化領域中存在的主要問題。

前面我提到過，我通常認為有兩件事是問題：團隊花太多時間來維護他們的測試，因為它們很脆弱并且很容易損壞。另一個是人們正在編寫糟糕的測試。通常，這些就是我認為測試自動化的主要痛點。我認為無代碼自動化實際上不能解決這些問題。它們確實使編寫測試變得容易得多，但是我認為這不是最常見的問題。這些工具可能會更容易編寫相同的不良測試。

 這些問題很多，自動化缺乏成功，這可以歸結為缺乏測試策略。我認為工具和自動化還沒有真正爆發，它們確實在解決問題，但是并沒有解決該領域最大的問題。

在下一篇文章中，我們與Max談談他在測試和測試自動化方面的失敗和成功經驗。