如何找到自動和手動測試合適的平衡點

很容易陷入陷阱，認(rèn)為只要你設(shè)置一次自動化測試，然后讓它自己運行。然而，事實是自動化測試并不是和我們想的那樣“只要設(shè)置了就不用再管它”。

實際上，我們需要定期維護(hù)所有自動化測試腳本的源代碼，包括更新代碼和應(yīng)用程序更新。沒有維護(hù)源代碼可能導(dǎo)致錯誤的測試結(jié)果。

關(guān)于自動化測試的另一個常見誤解是它完全基于工具。雖然該工具很重要，但自動化仍然與人有關(guān)。這是因為測試自動化工具不會為我們完成所有工作，我們?nèi)匀恍枰邆渥詣踊R的測試人員來操作該工具，開發(fā)腳本并維護(hù)源代碼。使用非技術(shù)資源只是“錄制和回放”的這種方法永遠(yuǎn)無法維護(hù)。

除了這些誤解之外，其實你擁有自動化測試的能力在軟件測試領(lǐng)域是非常有價值的，這個是毋庸置疑的。那么我們有多少測試可以用到自動化呢？全部？

事實是，我們根本無法自動化一切。假設(shè)我們可以自動化所有內(nèi)容，假設(shè)我們可以測試每個代碼塊，每個細(xì)節(jié)，其實這是我們無法做到的。從測試覆蓋的角度來看，100%覆蓋率是一個夢想。這是不可能的。

即使你可以自動化所有內(nèi)容，這也不是最好的方法。也不會將所有的測試都進(jìn)行自動化。這有兩個原因：

你自動化的測試越多，你需要維護(hù)的源代碼就越多，這就像是老鼠窩一樣。反過來，如果你沒有或忘記維護(hù)，可能會導(dǎo)致錯誤報告等問題，而你并不知道這些問題。相比之下，手動測試人員就能夠識別測試和用戶體驗差異的問題，可以糾正可能導(dǎo)致錯誤報告的不匹配設(shè)置。

一般來說，自動化從測試中沒有了非常重要的人為因素。除了上面提到的問題之外，手動測試還可以比自動化測試更準(zhǔn)確地測試真實場景，比如應(yīng)用程序新引入的功能可能以不可預(yù)見的方式與現(xiàn)有功能進(jìn)行交互。測試自動化不夠先進(jìn)，無法捕捉所有這些無法預(yù)料的情況。所以人的視角我們是不能丟棄的。

如果我們不能將所有內(nèi)容都進(jìn)行自動化，那么我們應(yīng)該將哪些內(nèi)容進(jìn)行自動化測試呢？

通常情況下，你會希望將應(yīng)用程序中更復(fù)雜的部分留給手動測試人員，因為這部分可能出bug的地方更多。例如，如果你嘗試在多個應(yīng)用程序和不同技術(shù)堆棧之間實現(xiàn)整個端到端流程的自動化，則腳本更有可能中斷。這就好比有一個人握著方向盤可以更容易識別出那些錯誤的轉(zhuǎn)彎。

除此之外，這里有三種方法來決定是否可以自動化：

識別應(yīng)用程序的高風(fēng)險區(qū)域并自動進(jìn)行冒煙測試，這是一項具有高影響力的簡單測試。例如，如果90%的用戶擁有相同類型的用戶配置文件，你可能希望自動執(zhí)行使用該類型配置文件登錄的測試，因為任何問題都會影響90%的用戶。其余10%的登錄失敗風(fēng)險不足以保證自動化測試。

大多數(shù)上下文驅(qū)動的手動測試人員都是主題（模塊）專家，他們對自己的領(lǐng)域非常熟悉，他們了解內(nèi)部和外部測試的系統(tǒng)。讓這些測試人員咨詢自動化工程師以確定自動化測試的區(qū)域，例如冒煙測試或針對其他應(yīng)用程序的測試，對于了解自動化可以在哪些方面增加價值（或在哪些方面沒有價值）大有幫助。

探索性測試通常可以提供有關(guān)自動化的對話。那是因為在探索性測試期間，你會收集并記錄信息和問題。然后，你可以使用這些信息來決定自動化測試在哪里有意義。

最后但同樣重要的是，當(dāng)我們自動化測試時，我們需要衡量該自動化的價值，以確保它提供我們想要的結(jié)果，并返回一個比手動測試所提供的更大的價值。

例如，如果你運行一個自動化測試100次，并且每次都通過測試，那么該測試是否確實提供了任何價值？如果結(jié)果確實準(zhǔn)確，那么測試可能不是一個有價值的階段，除非它是一個高風(fēng)險的場景。但是，如果手動測試發(fā)現(xiàn)更多bug，我們必須詢問什么更有價值：自動化測試所節(jié)省的時間，還是通過運行手動測試發(fā)現(xiàn)實際bug所節(jié)省時間？

這并不是說自動化測試沒有價值，因為它肯定是有價值的；但這不是一個通用的解決方案。相反，這是一種我們需要從策略上采取并定期回顧的方法。