優(yōu)化軟件質(zhì)量：?jiǎn)卧獪y(cè)試和自動(dòng)化

單元測(cè)試是防止錯(cuò)誤的第一道防線。這種級(jí)別的保護(hù)至關(guān)重要，因?yàn)樗鼮橐韵聹y(cè)試過(guò)程奠定了基礎(chǔ)：集成測(cè)試、驗(yàn)收測(cè)試以及最后的手動(dòng)測(cè)試，包括探索性測(cè)試。

在本文中，我將闡明單元測(cè)試與其他方法的區(qū)別，并舉例說(shuō)明何時(shí)可以或不可以沒(méi)有單元測(cè)試。我們還將討論自動(dòng)化測(cè)試，它在確保代碼可靠性和質(zhì)量方面發(fā)揮著重要作用。

單元測(cè)試

單元測(cè)試的想法是為每個(gè)重要的函數(shù)或方法編寫測(cè)試。這使得它能夠快速檢查最近的代碼更改是否導(dǎo)致了回歸，這意味著已經(jīng)測(cè)試過(guò)的程序部分中存在錯(cuò)誤，并且還可以更輕松地檢測(cè)和修復(fù)此類錯(cuò)誤。

當(dāng)單元測(cè)試過(guò)多時(shí)

任何沒(méi)有適當(dāng)測(cè)試覆蓋率的長(zhǎng)期項(xiàng)目注定遲早要從頭開(kāi)始重寫。單元測(cè)試是大多數(shù)項(xiàng)目的必備步驟，但在某些情況下可能會(huì)忽略此步驟。例如，您正在創(chuàng)建一個(gè)用于演示目的的項(xiàng)目。時(shí)間表非常艱難。您的系統(tǒng)是硬件和軟件的組合，在項(xiàng)目開(kāi)始時(shí)，并不完全清楚最終產(chǎn)品會(huì)是什么樣子。該軟件將在展覽或演示期間運(yùn)行1-2天。在這種情況下，就沒(méi)有必要進(jìn)行單元測(cè)試。

另一種情況是當(dāng)您在制作廣告網(wǎng)站，或者簡(jiǎn)單的Flash游戲，或者橫幅時(shí)，其中涉及復(fù)雜的布局、動(dòng)畫和大量的靜態(tài)內(nèi)容。以上都是為演示服務(wù)的。

如果您正在構(gòu)建一個(gè)包含一組靜態(tài) HTML 頁(yè)面和一個(gè)電子郵件提交表單的簡(jiǎn)單名片網(wǎng)站，則不需要進(jìn)行單元測(cè)試?？蛻艉芸赡軐?duì)此感到滿意，并且不再需要任何東西。手動(dòng)檢查和測(cè)試所有內(nèi)容很可能會(huì)更快。

單元測(cè)試實(shí)施

在規(guī)劃單元測(cè)試時(shí)，請(qǐng)記住您的目標(biāo)是確保單元測(cè)試代碼覆蓋率超過(guò) 80%。這意味著在運(yùn)行單元測(cè)試時(shí)至少執(zhí)行了 80% 的代碼庫(kù)。出于這些目的，我推薦使用JaCoCo for Java或 Istanbul for JavaScript 等工具。因此，要開(kāi)始將單元測(cè)試合并到您的開(kāi)發(fā)過(guò)程中，請(qǐng)嘗試執(zhí)行以下步驟。

1.選擇合適的測(cè)試框架

選擇一個(gè)適合您需求的框架，而不是重新發(fā)明輪子。例如，許多.NET開(kāi)發(fā)人員使用 MsTest，因?yàn)樗S Visual Studio 一起提供，但 NUnit 或 xUnit 可能會(huì)為您的項(xiàng)目提供更好的功能。

2. 決定測(cè)試什么

并非所有代碼都需要測(cè)試。簡(jiǎn)單、無(wú)依賴項(xiàng)的代碼可能不需要測(cè)試，而具有許多依賴項(xiàng)的復(fù)雜代碼可能會(huì)從測(cè)試前的重構(gòu)中受益。專注于測(cè)試復(fù)雜的算法代碼和相互依賴的組件，以確保清晰的交互和集成。

3. 保持一致的測(cè)試結(jié)構(gòu)

使用排列、執(zhí)行、斷言 (AAA) 模式以獲得清晰性和可維護(hù)性。

4. 一次測(cè)試一件事

每個(gè)測(cè)試應(yīng)該僅驗(yàn)證代碼的一個(gè)方面。對(duì)于復(fù)雜的流程，將其分解為較小的部分并單獨(dú)進(jìn)行測(cè)試。

5. 處理假貨的依賴關(guān)系

用假實(shí)現(xiàn)替換真正的依賴項(xiàng)，以避免測(cè)試不必要的組件。使用存根進(jìn)行預(yù)定義響應(yīng)，使用模擬來(lái)驗(yàn)證交互。

6.使用隔離框架

使用 Moq 或 Rhino Mocks 等現(xiàn)有框架來(lái)創(chuàng)建模擬和存根，而不是編寫自己的框架。這減少了錯(cuò)誤和維護(hù)開(kāi)銷。

7. 可測(cè)試性設(shè)計(jì)

最初編寫代碼時(shí)要考慮到可測(cè)試性。使用依賴注入，避免在方法內(nèi)直接實(shí)例化對(duì)象，并盡量減少使用帶有邏輯的靜態(tài)方法和構(gòu)造函數(shù)。

8. 重構(gòu)遺留代碼

如果處理無(wú)法測(cè)試的遺留代碼，請(qǐng)從重構(gòu)小的、可管理的部分開(kāi)始，并在編寫單元測(cè)試之前用集成和驗(yàn)收測(cè)試覆蓋它們。逐漸將此過(guò)程擴(kuò)展到代碼庫(kù)的更大部分。

自動(dòng)化測(cè)試

該方法的名稱是不言自明的：在自動(dòng)化測(cè)試中，測(cè)試用例是自動(dòng)執(zhí)行的。它比手動(dòng)測(cè)試發(fā)生得快得多，甚至可以在夜間進(jìn)行，因?yàn)檎麄€(gè)過(guò)程需要最少的人為干擾。當(dāng)您需要獲得快速反饋時(shí)，這種方法絕對(duì)會(huì)改變游戲規(guī)則。然而，與任何自動(dòng)化一樣，在初始設(shè)置階段可能需要大量時(shí)間和財(cái)務(wù)資源。即便如此，它還是完全值得使用的，因?yàn)樗鼤?huì)讓整個(gè)過(guò)程更加高效，代碼更加可靠。

自動(dòng)化測(cè)試實(shí)施

這里的第一步是了解項(xiàng)目是否包含測(cè)試自動(dòng)化。您需要確保項(xiàng)目擁有強(qiáng)大的測(cè)試自動(dòng)化框架。反過(guò)來(lái)，自動(dòng)化工程師應(yīng)該精通工具堆棧(例如，Selenium、Appium、Cypress)并遵循既定的自動(dòng)化指南。

1. 自動(dòng)化覆蓋率與手動(dòng)測(cè)試的比較

努力實(shí)現(xiàn)高比例的測(cè)試用例自動(dòng)化，最好超過(guò) 90%，以最大限度地提高效率并減少對(duì)手動(dòng)測(cè)試的依賴。

2. 項(xiàng)目概述及自動(dòng)化實(shí)施

自動(dòng)化測(cè)試始終是一個(gè)大型項(xiàng)目，涉及多個(gè)團(tuán)隊(duì)開(kāi)發(fā)共享產(chǎn)品，每個(gè)團(tuán)隊(duì)中都有手動(dòng) QA 測(cè)試人員。測(cè)試側(cè)重于前端和后端兩個(gè)方面。

3. 了解項(xiàng)目

首先，我們需要了解產(chǎn)品的用途及其用戶。這有助于優(yōu)先考慮自動(dòng)化工作。例如，如果產(chǎn)品為企業(yè)服務(wù)，則重點(diǎn)測(cè)試法律合規(guī)性和支付交易。對(duì)于面向消費(fèi)者的產(chǎn)品，優(yōu)先考慮卡間轉(zhuǎn)賬和服務(wù)支付等關(guān)鍵操作。自動(dòng)化應(yīng)該全面應(yīng)用于整個(gè)產(chǎn)品，而不僅僅是單個(gè)團(tuán)隊(duì)。

4. 識(shí)別關(guān)鍵利益相關(guān)者

熟悉所有利益相關(guān)者至關(guān)重要，因?yàn)榕c他們的互動(dòng)是必要的。關(guān)鍵人物包括：

· 產(chǎn)品所有者：他們是自動(dòng)化的客戶并定義其要求。

· QA 工程師：他們是自動(dòng)化工具的最終用戶，他們的滿意度是衡量成功的標(biāo)準(zhǔn)。

· 手動(dòng)測(cè)試主管：他們幫助組織流程并與手動(dòng)測(cè)試進(jìn)行協(xié)調(diào)。

· 前端開(kāi)發(fā)領(lǐng)導(dǎo)：他們影響自動(dòng)化測(cè)試的穩(wěn)定性和質(zhì)量。

· 采購(gòu)專家：他們負(fù)責(zé)硬件分配，主要是服務(wù)器設(shè)備。

5.了解團(tuán)隊(duì)

收集有關(guān)每個(gè)團(tuán)隊(duì)的項(xiàng)目范圍的信息，無(wú)論是涵蓋前端、后端還是兩者。了解 QA 團(tuán)隊(duì)如何測(cè)試他們的部分以及他們對(duì)自動(dòng)化的熟悉程度。確定測(cè)試挑戰(zhàn)并優(yōu)先考慮自動(dòng)化領(lǐng)域。

6. 制定自動(dòng)化要求

在大多數(shù)情況下，我們的目標(biāo)是采用經(jīng)典方法，而不采用創(chuàng)新解決方案：

· 編程語(yǔ)言：Java，方便招聘專員

· 前端測(cè)試：使用 Selenium。

· 后端測(cè)試：使用REST-assured進(jìn)行 REST 交互。

· 數(shù)據(jù)庫(kù)測(cè)試：選擇標(biāo)準(zhǔn) Java 庫(kù)

· 自動(dòng)化測(cè)試：選擇 Cucumber 既可以培訓(xùn)手動(dòng) QA 測(cè)試人員，又可以降低成本。

· 報(bào)告：最后但并非最不重要的一點(diǎn)是，使用 Allure 生成有吸引力且內(nèi)容豐富的報(bào)告。

7. 演示和入門

為所有利益相關(guān)者(包括產(chǎn)品負(fù)責(zé)人、QA 工程師、開(kāi)發(fā)人員和分析師)進(jìn)行演示，重點(diǎn)是清晰度。從前端團(tuán)隊(duì)開(kāi)始創(chuàng)建可見(jiàn)的結(jié)果。開(kāi)發(fā) 5-10 個(gè)自動(dòng)化測(cè)試，記錄它們，并使用 Allure 的圖形報(bào)告顯示結(jié)果。說(shuō)明自動(dòng)化基礎(chǔ)設(shè)施、主要目標(biāo)和效果，并比較手動(dòng)和自動(dòng)化測(cè)試。

8. 為自動(dòng)化準(zhǔn)備 UI

為了保證自動(dòng)化測(cè)試可靠穩(wěn)定，data-test-id在前端負(fù)責(zé)人和產(chǎn)品負(fù)責(zé)人的配合下，集中為UI元素添加“ ”屬性。這種做法通過(guò)將測(cè)試與 UI 元素位置或內(nèi)容的變化隔離開(kāi)來(lái)，極大地提高了測(cè)試的可靠性。

9. 開(kāi)發(fā)自動(dòng)化測(cè)試

在自動(dòng)化測(cè)試人員之間分配任務(wù)。使用模板創(chuàng)建自動(dòng)化項(xiàng)目框架。準(zhǔn)備用于前端測(cè)試的 Cucumber 步驟，使這些步驟可跨項(xiàng)目重復(fù)使用，并設(shè)置 Selenoid 和 Jenkins。通過(guò)設(shè)置存儲(chǔ)庫(kù)、創(chuàng)建 Jenkins 作業(yè)以及在 Cucumber、Git 和開(kāi)發(fā)環(huán)境中培訓(xùn) QA，將團(tuán)隊(duì)集成到自動(dòng)化中。

然后，QA 手動(dòng)測(cè)試人員將編寫自動(dòng)化測(cè)試，并由自動(dòng)化工程師進(jìn)行審查和集成。最終的 Cucumber 步驟開(kāi)發(fā)將在沖刺的空閑時(shí)間進(jìn)行。在每個(gè)沖刺結(jié)束時(shí)，在產(chǎn)品演示中展示結(jié)果并宣布新功能。

結(jié)論

正如您所看到的，單元測(cè)試和自動(dòng)化測(cè)試是互補(bǔ)的方法。通過(guò)每天使用它們來(lái)識(shí)別缺陷，您可以減少每個(gè)階段的回歸測(cè)試時(shí)間。此外，這將逐漸導(dǎo)致產(chǎn)品更快地投入生產(chǎn)，從而節(jié)省時(shí)間和資源。