?左移測試教程：最佳實踐綜合指南
譯文譯者 | 李睿
審校 | 重樓
“本指南探討了左移測試方法，以及如何使用這種方法提高軟件產品的質量。”
左移測試方法包括將測試活動“左移”或在開發周期中相對早期地移動。因此，測試人員在軟件開發生命周期中參與得越早，使他們能夠在更早的階段識別缺陷和瓶頸。除了提高代碼質量和減少完成周期所需的時間之外，它還有助于確保在生產中引入更少的缺陷。
很多企業不斷面臨著在敏捷環境中更快行動的挑戰。通常情況下，這需要縮短交付時間，同時以更低的成本提高每個后續版本的質量。
敏捷開發計劃優先考慮更短的sprints，并計劃盡可能快地將客戶反饋合并到功能中。然而，這樣的進步如果遇到了嚴重的質量問題，將讓客戶感到不滿。在此之后，測試和質量出現了漂移，“快速移動和突破”不再可持續，測試成為了一個重要的絆腳石。
在傳統模式中，測試人員通常在開發之后開始測試。為此，出現了一種被稱為左移測試的質量保證技術，它具有諸如節省成本和提前檢測缺陷等優點。
一、左移測試的由來
左移方法促使人們重新思考如何處理軟件質量改進。早些時候，在瀑布方法中，開發人員和質量保證專家在具有不同角色和職責的團隊中工作。即使在敏捷方法中，測試也通常排在最后。
左移測試的思想旨在將測試階段引入軟件開發生命周期(SDLC)的早期階段。因此，團隊可以更有效地協同工作，并定期相互溝通。因此，左移是早期將測試和開發結合在一起的常見術語。
可以考慮一個一切都是由開發人員完成的這樣一個場景。他們將工作移交給測試團隊，從系統測試開始，然后開發團隊開始開發新的項目。在質量保證（QA）測試期間，測試中出現的錯誤必須在發布到生產環境之前加以修復。在這種情況下，開發人員繼續完成當前的任務，并集中精力修復上一個項目中的缺陷和錯誤，以緩解最后交付期限，否則部署將不得不等到新的發布周期。而這是額外的時間投資!
左移方法旨在通過在生命周期的早期將任務移到左邊來提高質量。它在軟件開發生命周期的早期通過重復測試和檢測問題以及早期最小化風險來整合測試。因此，與在開發結束時開始測試的典型測試方法相比，測試可能是一種更現實的檢測產品缺陷的方法。
二、SDLC后期測試的影響
在生命周期后期發現的缺陷更為復雜且修復成本更高。這就是在瀑布式方法結束時將測試視為一個順序階段被認為是軟件測試的一個主要陷阱的原因。
以下是開發周期進行后期測試的影響：
?測試人員可能較少參與初始計劃，導致分配的測試資源不足。
?許多需求、架構和設計缺陷直到在實施上花費了大量精力才被發現和糾正。
?隨著越來越多的軟件被創建和集成，調試變得越來越困難。
?測試自動化的時間更短，這最終會導致缺陷回歸。
?封裝使得白盒測試和在測試期間實現高水平的代碼覆蓋率變得更加困難。
?修復在測試中發現的缺陷的時間更少，增加了在以后的系統升級中被推遲的可能性。
?延遲測試影響開發和維護成本，導致錯過最后期限和項目延遲，并由于殘留缺陷而降低質量。
?由于軟件存在缺陷，客戶最終用戶體驗不佳。
三、為什么進行左移測試
在傳統的瀑布模型中，在開發周期結束時進行測試，一些嚴重的缺陷經常被忽略。在開發流程結束時修復這些關鍵的缺陷是困難和昂貴的。隨著漏洞的發現，修復它們的成本呈指數級增長。
然而，通過讓測試人員更早地參與到開發周期中進行左測試有助于減少與發現和修復缺陷相關的成本。因此，對項目的可交付成果沒有延遲或影響，并且提高了客戶滿意度。
以下是導致左移快速發展的一些因素：
?通過將編碼和測試結合起來，左移方法減少了代碼的不安全性。同時也提高了工程師的工作效率。
?左移方法使工程師能夠通過持續集成(CI)和測試自動化來快速測試代碼。這允許團隊朝著持續測試和CI/CD管道開發他們的軟件開發生命周期(SDLC)。
?在產品開發生命周期中幾乎立即發現缺陷。
?通過幾乎立即識別缺陷來減少處理缺陷的成本。
?在產品開發生命周期中幾乎立即發現缺陷。
?DevOps中的左移測試帶來了一個更重要的項目。這就建立了消費者的忠誠度并提高了業務成果。
?由于代碼包含較少的缺陷修復和代碼修復，因此可以獲得更重要的項目。
?減少項目超出事件評估過程的可能性。
?由于代碼穩定并在財務計劃中傳達，因此提高了消費者忠誠度。
?保持更大的代碼庫。
?通過在開發周期之前的測試，團隊可以更快地發現代價昂貴的問題。這樣可以節省時間和成本。
?左移方法允許團隊更有可能為他們的企業設計整個測試擴展。
四、在測試中左移的好處
左移不僅能更早地找到缺陷，它還可以幫助團隊更好地與所有利益相關者合作，提高集體能力，并制作更現實的測試用例，以確保無缺陷的交付。左移測試帶來了一些企業文化上的好處，因為它強調了敏捷宣言中眾所周知的原則：
?根據計劃應對變化。
?客戶協作優先于合同談判。
?工作軟件勝過全面的文檔。
?流程和測試工具之上的交互和個體。
以下是左移測試的幾個顯著優點：
?改進了客戶和用戶體驗：左移促進高質量的代碼和按時交付，減少修復缺陷，創建一個更集中的以客戶需求為中心的環境，從而帶來更好的產品設計和用戶體驗。
?早期缺陷檢測：早期的、漸進的、持續的測試可以在缺陷導致生產問題之前減少它們的數量。
?增強覆蓋范圍：左移測試的額外優勢是增加了測試覆蓋范圍。如果有更多的人更頻繁地創建測試并更早地開始，那么測試將對軟件進行更大比例的評估。
?顯著的成本節約：早期檢測顯著地提高了效率，減少了技術債務，降低了修復缺陷所需的工作量、時間和成本。
?改進了軟件團隊文化、能力、士氣和員工忠誠度：讓交付團隊中的每個人都參與測試活動需要左移。企業團隊不再在發布前的最后一刻匆忙討論和執行測試。
?幫助重塑產品開發：測試中的左移并不意味著沒有在生產中進行測試，也不意味著測試完全轉移到軟件開發生命周期的設計階段。左移將測試注入到每個sprint中。一些測試仍然應該在最后進行，但應該是剩余的一些。
五、當左移時會發生什么?
在左移方法中，測試人員直接了解測試版本的最終標準。例如，測試人員可能會意識到，當他們了解產品規格說明時，與組件和系統開發人員密切合作會更有效。他們可以提出探索性的問題，與API開發人員溝通，并為新服務創建測試存根。當測試人員積極參與這些早期階段時，他們最終會“向左移動”。
以下看看當在測試中采用左移方法時會發生什么。
1.設計階段
傳統上，產品設計團隊會等到他們有了大量的新功能，然后開始漫長的設計過程。在此之前，測試人員可能對新功能正在進行開發的事實并不關心。在現代軟件開發中，可以通過引入以下問題來測試新的功能想法。
?該功能的用途是什么？它為客戶解決了哪些問題？
?如何知道這個功能成功地滿足了客戶的需求?
?可以構建并用作“學習版本”以確保其交付價值的功能的最小部分是什么?
?當人們使用這個功能時，最糟糕和最好的事情是什么？
2.持續使用測試來指導開發
這是一個典型的“左移”場景：一家企業的團隊決定構建一個功能，并且正在與交付團隊在計劃會議中進行規范討論。只是問“我們將如何測試這個?”這樣的問題就會引發富有成效的討論，因為它可以幫助人們理解這一功能，并可能導致在單元、集成、系統級別/API、用戶界面（UI）或其他適用級別為這些故事進行測試。
3.設計測試計劃
與正式的測試計劃不同，團隊可以在創建每個故事時捕獲一些期望的和不希望的行為實例。然后，把它們變成測試。團隊可以運行它并幫助開發。
這些測試將成為詳細的文檔，說明該功能在生產環境中是如何工作的，自動化的回歸測試可以確保未來的更改不會破壞它。增加團隊準確交付客戶所需的機會的一種方法是，在構建每個功能時，考慮更多的測試用例來自動化或人工探索。
盡早且經常進行測試，盡早且經常自動執行
敏捷開發的好處是可以隨時實現自動化。可以為一個功能編寫最基本的測試，即使還沒有完全開發它。也可以為該功能向產品和測試代碼中添加增量測試。可能需要更多的返工，更多的關于如何編寫可維護的測試的知識，當測試人員、開發人員和其他團隊成員協作在編碼過程中自動化測試時，需要等待更多的問題得到回答，而這與瀑布過程的交接有很大的偏差。
4.不僅僅是與測試人員有關
左移方法是軟件團隊都參與其中的一種技術。以下是每個角色需要做出的一些調整：
?測試人員：積極參與設計階段。要構建測試，不應該等待代碼。嘗試將這些代榪分成幾個可測試的小塊，以保證測試的成功。
?開發人員：參與關于測試策略和計劃的討論。企業投入可能有助于減輕測試團隊的負擔，并降低技術債務。將企業的自動化測試套件作為代碼庫的重要組成部分進行維護。
?產品經理：確保企業的團隊能夠獲得合適的資源來進行合作并獲得反饋。設定與左移策略相一致的目標和期望。這可能需要為整個團隊設定質量目標，并減少每個sprint的功能工作。
基礎設施和部署團隊：企業的部署管道需要盡早可用，并且具有高容量，以便測試套件能夠快速運行，因為測試需要頻繁和早期地發生。
六、左移測試的類型
有四種不同類型的左移方法，每種方法提供不同的價值。
1.傳統的方法
要理解傳統的左移方法，首先理解軟件開發生命周期中的傳統V模型是很重要的。SDLC V-Model是基于每個開發階段的測試階段的瀑布模型的擴展。它也被稱為驗證和確認模型。下圖顯示了一個典型的V型模型。
傳統的左移方法減少了測試次數，從而將其移到V型模型右側的左側。單元測試和集成測試是傳統左移方法的主要關注點。這種測試是使用API測試和Selenium完成的。然而，驗收測試和系統測試并沒有得到高度重視。
2.增量方法
這種左移策略最適合開發復雜和大型軟件系統的項目。同時管理所有任務和可交付成果有時變得很困難，因此它們被分成更小的塊。這些組件構建在彼此之上，并且軟件隨每個增量一起交付給客戶。在每次交付之后，開發和測試都被移到左邊。這有利于測試團隊測試每個組件。
因此，它通過增量開發周期來進行增量測試。下圖顯示了該過程的一個示例。
3.敏捷/DevOps方法
這種左移測試方法通常在幾個sprint中執行。它側重于通過由各種較小的sprint組成的進化生命周期進行持續測試。它主要用于開發測試，而不是在系統操作化之后進行的操作測試。
4.基于模型的方法
左移方法的主要目標是盡早發現缺陷。然而，在上面討論的三個模型中，測試將在開發周期的早期開始。因此，在需求收集期間遺漏了一些關鍵問題，這些問題在開發周期完成后才會被發現。
七、左移的關鍵策略
以下是一些可以實現的關鍵策略，以將軟件測試向左轉移。
?計劃：這是左移戰略的一個重要方面，因為它是測試生命周期任務的跳板。測試人員可以通過與管理層和運營利益相關者合作，更好地理解未來的需求。有了這種洞察力，就可以計劃并確認預算、資源分配和測試策略。
?靜態測試：它在項目的早期階段完成，包括需求和設計驗證。使用靜態測試，可以在項目生命周期的早期發現問題，以免它們變得過于昂貴而無法修復。
?統一的測試策略：使用統一的測試策略，企業可以評估自動化、存根、環境和測試數據上的限制，保證各自的團隊能夠滿足需求。一般來說，這是端到端測試的高級方法，從單元測試到用戶驗收測試(UAT)，再到操作準備測試(ORT)和部署后測試(PDT)。這一策略將涵蓋所有質量保證（QA）職責和步驟。
?基于風險的分析：軟件風險分析決定了每個測試用例的結果和失敗的概率。功能測試、非功能測試和回歸測試都可以使用這種方法進行。
八、如何實施左移戰略?
左移不僅僅是幫助測試團隊盡早發現缺陷，現在了解他們需要做些什么來開始左移測試：
1.確定并計劃測試生命周期
計劃是左移方法不可或缺的一部分。當測試分析人員在實際開發過程開始之前確定并計劃整個測試生命周期時，它的效果最好。這為測試生命周期中的所有活動提供了一個強有力的起點，并將幫助所有業務和運營利益相關者、開發人員和測試人員理解項目的任務、目標和預期結果。
這樣做的一種方法是從項目計劃和需求規范階段確定測試需求。測試計劃包括預算、資源、測試策略和其他項目需求。這有助于團隊從項目的第一天開始就關注質量，而不是等到軟件開發生命周期的后期才發現缺陷。
2.引入基于開發人員的測試方法
開發人員的主要角色是根據需求編寫新功能或增強功能。然而，測試不再是由測試人員完成的任務。
由于開發人員最熟悉他們的代碼，他們可以嚴格測試自己編寫的代碼以排除任何缺陷，并檢查應用程序的功能。確保新代碼在與應用程序的現有功能集成時不會產生任何缺陷也是至關重要的。
因此，一旦開發出代碼進行測試，可以確保更快地識別缺陷。它加快了暴露和修復編碼錯誤的速度。它有助于減少單元中的不確定性。開發測試的目的是在代碼傳遞給質量保證（QA）團隊之前消除編碼錯誤。基于開發人員的測試和基于質量保證（QA）的測試的完美結合將確保輕松識別缺陷和發布高質量的功能。
3.代碼評審質量檢查
合作是成功的關鍵。為了確保更高的代碼質量，所有開發人員必須同意遵守相同的編碼標準。
隨著開發人員為測試工作做出貢獻，測試人員可以專注于為開發人員的腳本定義質量檢查，并專注于探索性、安全性和性能測試。
4.使用相同的工具
測試團隊面臨的一個重要問題是無法使用開發人員使用的相同工具創建自動化測試。這成為測試人員創建自動化框架的障礙。最佳實踐是使用開發人員使用的相同技術堆棧。
5.功能測試
它是對軟件進行更改以添加新功能或修改現有功能的過程。測試這些功能是非常重要的，并且逐步交付軟件需要開發和質量保證（QA）團隊協同工作來交付構建。
在每次簽入之后，就可以知道系統在缺陷方面的實際狀態。通過嚴格的代碼質量檢查，可以在早期階段檢測到缺陷，因此更容易修復，從而提高每個功能的質量。
6.采用測試自動化技術
在這種DevOps驅動的環境中，強烈建議采用測試自動化技術，以最大限度地提高左移測試的可用性。通過測試自動化，開發人員和測試人員可以在軟件開發的所有階段自動化整個從構建到測試的過程。
為了降低測試成本，需要始終使用基于云的測試平臺，以便企業的質量保證（QA）團隊可以訪問不同的瀏覽器、設備和平臺。
九、左移測試的挑戰
正如人們所看到的，左移策略帶來了許多好處。然而，每件事都有它的挑戰。這是左移測試的一個限制。
1.文化認可
清單上的第一個是認可。左移測試需要企業文化的重大轉變。習慣于傳統工作流程的開發人員和測試人員可能會發現左移是一個偏差。它可能會打亂工作、工具和所需技能的流程。如何克服? 內化左移測試的重要性是很重要的。此外，倡導優先事項的學習會議有助于確保順利過渡到新方法。
2.精力浪費
只有一些內容可以盡早測試。如果仍然需要打下基礎，左移測試可能需要投入大量的精力和時間。在開發圖形用戶界面（GUI）之前編寫測試的情況下，圖形用戶界面（GUI）功能很有可能在完全開發時需要更多的增強，因此大部分精力都被浪費了。
如何克服？如果需要在早期測試特定的測試，則必須更早完成開發。例如，如果API測試對企業的項目至關重要，并且正試圖進行左移測試，那么需要盡早開發API。
3.測試范圍
測試范圍都涵蓋了嗎？需要多少自動化?準備好全套服務了嗎?回答這些問題的答案可能會讓人頭疼。
定義智能測試策略是自動化測試成功的關鍵。以下是可以幫助確定是否應該自動化測試用例的因素列表。
?自動化的復雜性
?平均腳本創建時間
?期望的回歸速度
?發布的頻率
?構建的穩定性
?測試用例的變更/增加率
十、左移測試的最佳實踐
本節將討論在實現左移方法時應該遵循的一些最佳實踐：
提供持續的反饋
持續的反饋可以快速地修正誤差和間隙。此外，它可以更好地了解每個參與者，并改進未來的項目。
為了實現有效的持續反饋循環，應該：
?為會議設定目標。
?詳細記錄反饋。
?確保有效的溝通渠道。
1.早期測試
早期的測試不應該意味著測試不會發生在軟件開發生命周期(SDLC)的后期階段。早期測試本質上允許通過早期缺陷檢測來降低風險。這并不意味著缺陷不能在后期出現。因此，質量保證（QA）專家和項目經理應該準備好并利用持續測試。
質量保證（QA）專家應該列出代碼預期的價值、執行和操作成就的程度，以便運行測試的開發人員了解應該搜索哪些缺陷。
2.自動化測試
每次更新、發布、定制和集成都會對系統的整體質量造成新的威脅。另外，人工測試不能滿足更快、更高質量的軟件開發的需求。 一個可行的方法是使用測試自動化，這為測試人員節省了大量的時間。
3.靜態代碼分析
靜態代碼分析是在不執行代碼的情況下分析代碼。它檢查了基本的代碼結構，并保證代碼與各種規范和規則保持一致。在這一分析中，將根據指導方針和標準檢查代碼。靜態代碼分析的另一個好處是可以實現自動化。但是應該在軟件開發生命周期(SDLC)的早期做這樣的分析。
十一、結論
在持續開發周期的所有階段都參與測試可能會讓人望而生畏。盡管如此，來自測試社區的許多成功案例表明，無論成為什么角色，這都是可能的。
一些專家表示，向開發人員展示如何進行測試的最佳方式是成為一名具有測試經驗的開發人員。也有人說在項目的每個階段都要“停下來思考和測試/審查”。如果有一些編碼經驗或對學習感興趣，那么將其測試專業知識與實際開發工作相結合是一個很好的選擇。
無可爭辯的是，測試人員都將負責創建高質量的交付。如果企業的項目或團隊正試圖左移，那么這一指南可能是一個很好的手冊，可以幫助他們以更快的速度交付優秀的產品。
原文標題：
Shift Left Testing Tutorial: Comprehensive Guide With Best Practices，作者：Rhea Dube
原文鏈接：
https://dzone.com/articles/shift-left-testing-tutorial-comprehensive-guide-wi
