本文解釋了一個(gè)完整的自動(dòng)化測試策略，如果它是可行的，并且自動(dòng)化 QA 保證質(zhì)量。 事實(shí)上，軟件測試非常耗費(fèi)時(shí)間和資源?？梢詮牟煌慕嵌扔^察軟件的測試。它可以根據(jù)我們正在測試的內(nèi)容進(jìn)行劃分。例如...

本文解釋了一個(gè)完整的自動(dòng)化測試策略，如果它是可行的，并且自動(dòng)化 QA 保證質(zhì)量。

事實(shí)上，軟件測試非常耗費(fèi)時(shí)間和資源?？梢詮牟煌慕嵌扔^察軟件的測試。它可以根據(jù)我們正在測試的內(nèi)容進(jìn)行劃分。例如，項(xiàng)目中的每個(gè)可交付成果，如需求、設(shè)計(jì)、代碼、文檔、用戶界面等，都應(yīng)該進(jìn)行測試。此外，我們可以根據(jù)用戶和功能需求或規(guī)范對代碼進(jìn)行測試，即黑盒測試。在這個(gè)級別，我們將代碼作為黑盒進(jìn)行測試，以確保程序預(yù)期的所有服務(wù)都存在，按預(yù)期工作并且沒有問題。我們可能還需要測試代碼的結(jié)構(gòu)，即白盒測試。測試也可以根據(jù)測試中的子階段或活動(dòng)進(jìn)行劃分，例如，測試用例的生成和設(shè)計(jì)，測試用例執(zhí)行和測試數(shù)據(jù)庫的驗(yàn)證構(gòu)建等。測試確保開發(fā)的軟件最終無錯(cuò)誤。但是，沒有任何流程可以保證所開發(fā)的軟件是 100% 無錯(cuò)誤的。

盡管手動(dòng)測試通常會(huì)導(dǎo)致遺漏的錯(cuò)誤、次優(yōu)的測試覆蓋率和人為錯(cuò)誤，但即使在大型項(xiàng)目中，也無法用自動(dòng)化測試完全取代它。UX、可用性、探索性等測試需要人為因素，因?yàn)樽詣?dòng)工具無法模仿用戶行為。自動(dòng)化測試也不適用于安全測試。自動(dòng)漏洞掃描需要隨后的手動(dòng)檢查，因?yàn)樗鼤?huì)提供許多誤報(bào)。

在當(dāng)今的現(xiàn)實(shí)場景中，應(yīng)用程序會(huì)根據(jù)用戶反饋、Web 流量（性能/負(fù)載）、競爭、合規(guī)法律等頻繁變化。因此，要保持競爭優(yōu)勢，就需要?jiǎng)?chuàng)新、升級和增強(qiáng)您的產(chǎn)品，使一切自動(dòng)化變得具有挑戰(zhàn)性。那么實(shí)施完整的自動(dòng)化測試策略意味著什么呢？它甚至可行嗎？全自動(dòng) QA 能保證質(zhì)量嗎？

觀看此網(wǎng)絡(luò)研討會(huì)，了解企業(yè)范圍內(nèi)的可操作策略、自動(dòng)化測試的注意事項(xiàng)以及有助于提高發(fā)布和測試速度的 DevOps 工具。

我們需要完整的自動(dòng)化測試嗎？

自動(dòng)化測試不是精確測試；它正在檢查事實(shí)。檢查是機(jī)器可決定的；測試需要感知。測試是一項(xiàng)調(diào)查活動(dòng)，我們旨在通過探索獲得有關(guān)被測系統(tǒng)的新信息。測試（手動(dòng)）需要人類對可用性做出合理的判斷。結(jié)果，我們可以注意到我們沒有預(yù)料到的違規(guī)行為。此外，在實(shí)施測試自動(dòng)化解決方案時(shí)，除了編寫測試用例腳本之外，還有其他相關(guān)的開發(fā)活動(dòng)。

通常，企業(yè)開發(fā)一個(gè)框架來演示測試用例選擇、報(bào)告等操作?？蚣艿拈_發(fā)是一項(xiàng)艱巨的任務(wù)，需要熟練的開發(fā)人員，并且需要時(shí)間來構(gòu)建。此外，即使有一個(gè)功能齊全的框架，編寫腳本自動(dòng)檢查所花費(fèi)的時(shí)間也比手動(dòng)執(zhí)行相同的測試要長。

但是，企業(yè)不應(yīng)該對其中一種寬容，因?yàn)檫@兩種方法都需要深入了解應(yīng)用程序的質(zhì)量。企業(yè)花費(fèi)大量時(shí)間使用最佳工具和實(shí)踐來開發(fā)完美的測試自動(dòng)化解決方案，但如果自動(dòng)化檢查對團(tuán)隊(duì)沒有幫助，那就無益了。我們不應(yīng)該以取代人工 QA 為目標(biāo)，而應(yīng)該接受他們對團(tuán)隊(duì)的優(yōu)勢。例如，自動(dòng)化測試有助于騰出 QA 的時(shí)間進(jìn)行更多探索性測試，并會(huì)發(fā)現(xiàn)錯(cuò)誤。

哪些測試應(yīng)該自動(dòng)化？

團(tuán)隊(duì)通常希望盡可能地自動(dòng)化一切。但是當(dāng)他們遇到各種問題時(shí)，這又會(huì)困擾他們。企業(yè)應(yīng)該分析他們希望自動(dòng)化的測試用例的類型以及不能自動(dòng)化或不應(yīng)該自動(dòng)化的用例。團(tuán)隊(duì)不應(yīng)該僅僅為了測試而自動(dòng)化測試。例如，如果您將需要大量維護(hù)的一整套測試自動(dòng)化，那么您正在投入額外的時(shí)間和金錢，而這些時(shí)間和金錢您可能沒有。相反，如果您專注于采用基于風(fēng)險(xiǎn)的方法，這將有所幫助，這樣您就可以只自動(dòng)化最有價(jià)值的測試。

讓我們看一下最可行的自動(dòng)化測試場景：

回歸測試：回歸測試需要多次測試相同的變量，以確保新功能不會(huì)與舊功能混淆?；貧w測試非常適合自動(dòng)化。復(fù)雜的功能：企業(yè)可以自動(dòng)化所有需要復(fù)雜計(jì)算的測試。冒煙測試：可以通過運(yùn)行自動(dòng)化測試為企業(yè)驗(yàn)證重要功能的質(zhì)量，這將快速分析功能是否需要更多測試。數(shù)據(jù)驅(qū)動(dòng)測試：使用大量數(shù)據(jù)集重復(fù)測試功能也是考慮自動(dòng)化測試的好方案。性能測試：在不同情況下監(jiān)控軟件性能的測試非常適合自動(dòng)化測試。為手動(dòng)測試團(tuán)隊(duì)進(jìn)行性能測試將非常詳細(xì)且耗時(shí)。功能測試：每當(dāng)開發(fā)人員需要執(zhí)行快速執(zhí)行以獲得即時(shí)反饋的功能測試時(shí)，這是另一個(gè)有意義的自動(dòng)化測試示例。如果沒有自動(dòng)化，就不可能實(shí)現(xiàn)這一目標(biāo)，尤其是在快速發(fā)展的組織中。

自動(dòng)化測試的問題

問題的癥結(jié)在于敏捷團(tuán)隊(duì)不再進(jìn)行測試。由于 DevOps 等開發(fā)實(shí)踐和文化，手動(dòng)測試已經(jīng)失去了優(yōu)勢。QA 領(lǐng)域存在分歧——會(huì)編碼的和不會(huì)編碼的。大多數(shù)測試人員現(xiàn)在都在努力跟上自動(dòng)化需求。在每個(gè) sprint 中都存在自動(dòng)化測試的壓力，并且沒有足夠的時(shí)間進(jìn)行徹底的探索性測試。

敏捷開發(fā)中的問題是測試人員采用用戶流程并自動(dòng)化其驗(yàn)收標(biāo)準(zhǔn)。但是，在這樣做的同時(shí)，他們主要也是唯一的重點(diǎn)是與他們有限的編碼技能作斗爭以通過測試。因此，當(dāng)您只對自動(dòng)化測試感興趣并看到它在構(gòu)建管道中通過時(shí)，這自然會(huì)產(chǎn)生狹窄的焦點(diǎn)。高期望大多數(shù)商業(yè)人士相信新的技術(shù)解決方案將化險(xiǎn)為夷。測試工具也不例外！我們不能否認(rèn)，如今的工具幾乎可以解決我們目前在測試自動(dòng)化中面臨的所有問題。然而，這種不切實(shí)際的樂觀也導(dǎo)致了不切實(shí)際的期望。無論工具多么稱職，如果管理層的期望不切實(shí)際，它就不會(huì)滿足期望。自動(dòng)化不必要

的測試 不要僅僅為了測試而自動(dòng)化測試。取而代之的是，在這個(gè)過程中投入一些想法。研究產(chǎn)品的高層和低層架構(gòu)。問會(huì)出什么問題。分析集成點(diǎn)并尋找潛在的突破點(diǎn)。

在您的整體測試方法中采用基于風(fēng)險(xiǎn)的自動(dòng)化方法。例如，某物發(fā)生故障的可能性有多大，故障的影響是什么？如果答案很高，那么這些場景應(yīng)該在每次構(gòu)建時(shí)自動(dòng)化并執(zhí)行。有缺陷的安全性 僅僅因?yàn)闇y試工具沒有發(fā)現(xiàn)任何缺陷并不意味著軟件中沒有缺陷。至關(guān)重要的是要了解，如果測試包含缺陷，它們將帶來不正確的結(jié)果。自動(dòng)化測試將無限期地保留那些不滿意的結(jié)果。忽略重要場景一個(gè)嚴(yán)重的問題經(jīng)常會(huì)泄漏到生產(chǎn)環(huán)境中，因?yàn)闆]有人考慮過特定的場景。執(zhí)行多少自動(dòng)化測試并不重要。如果忽略了一個(gè)場景，那么根據(jù) Sod 定律就會(huì)出現(xiàn)錯(cuò)誤，即，如果某些事情可能會(huì)出錯(cuò)，它就會(huì)出錯(cuò)。

結(jié)論

大多數(shù)測試自動(dòng)化工程師花時(shí)間與自動(dòng)化代碼作斗爭，并使測試在現(xiàn)代軟件開發(fā)中發(fā)揮作用。他們幾乎不專注于適當(dāng)?shù)臏y試和探索系統(tǒng)。

沒有足夠的時(shí)間編寫自動(dòng)化代碼和執(zhí)行探索性測試。團(tuán)隊(duì)在沖刺后自動(dòng)化沖刺，忘記大局。

通常企業(yè)最終會(huì)執(zhí)行大量自動(dòng)化測試，但探索性測試會(huì)發(fā)現(xiàn)大多數(shù)錯(cuò)誤。相反，企業(yè)應(yīng)該根據(jù)風(fēng)險(xiǎn)評估選擇要自動(dòng)化的內(nèi)容。什么可能出問題，如果確實(shí)出問題會(huì)對業(yè)務(wù)產(chǎn)生什么影響？