過時的傳統軟件開發方法并不能接管不斷升級的市場趨勢，并且這些方法缺乏解決方案，這些解決方案無法滿足引入“ 持續集成（CI）和持續交付（CD） ”的快速軟件發布的日益增長的需求。 除CI / CD之外，您還需要具有這種技術能力，開發人員可以適應縮短的交付周期和自動化流程。 要跟上測試領域變化的加速步伐，您還需要與其他QA專業人員加深，拓寬并建立牢固的網絡。 說起來容易做起來難，我知道！ 從質量保證經理的角度來看，我經常觀察到實施CI / CD管道發布周期，不正確的資源管理，不切實際的ETA以及任務管理中所涉及的猶豫所帶來的掙扎。 這就是為什么我打算談論CI / CD管道的興起，每個QA應該遵循的共同挑戰和可行的見解，以便使用CI / CD管道快速安全地瀏覽每個發行版。

為什么CI / CD管道成為大多數組織的明顯選擇？

到目前為止，測試人員遲早要轉向項目和組織中的持續交付。 團隊選擇了CI / CD管道來利用快速發布版本所帶來的好處，即只需按一下按鈕。 企業需要更快的反饋，因此大大縮短了上市時間。 這導致CI / CD管道在全球范圍內的采用率增加。 就個人經驗而言，CI / CD流程對我過去進行測試的方式產生了影響，因為它幫助我的團隊加快了上市進程。

我的開發人員朋友幾乎不需要測試方法，尤其是冗長的測試階段，從來沒有跟上交付速度。 當開發人員獲得有關其代碼的快速反饋時，連續交付將取決于開發人員的能力。 他們簽入的那一刻，如果他們錯誤地在包含不同測試層的構建管道中引入了某種問題，就會得到信號。 即使沒有測試自動化，您也傾向于了解實時用戶的反饋-來自客戶群的直接聯系。 開發人員永遠不會削弱快速反饋，從而提高生產效率。 構建管道減少了集成和發布測試所需的等待時間。 這意味著一切都一口氣發生：編寫代碼–在本地測試–審查–合并–集成–并交到測試人員手中。 關鍵部分之一是測試自動化，公司可以專注于軟件的持續集成和持續交付。 只需單擊一下即可將可執行文件放到本地，測試或生產環境中。 CI / CD流程中的最佳實踐可以提供高質量的產品。

隨著對敏捷，看板和其他最新SDLC方法的時間需求，CI / CD管道的重要性變得顯而易見。 但是，作為專業的質量檢查人員，我們應該如何在CI / CD管道中進行自我管理。 讓我們找出答案。

每個QA應該注意的合理步驟，以確保CI / CD管道成功

在CI / CD管道中，技術部分可能是測試人員的陷阱。 基本上，他們的職責不僅限于此：對需求，實踐，產品和過程的所有關注。 如果您要開始在持續交付環境中工作–考慮10倍！ 想一想：

• 團隊是否朝著正確的方向前進？
• 是否所有業務需求都已轉化為可執行規范？
• 作為質量檢查測試人員，您將以何種方式在方案，驗收標準和示例方面做出貢獻。
• 您認為已經浮動的流程有改進的空間嗎？ 您是否能夠檢測到廢物并最終將其清除？
• 您在非功能測試，性能，可訪問性和安全性方面的經驗。
• 跨瀏覽器測試，以確保您的更改對從不同瀏覽器，瀏覽器版本，設備和操作系統查看Web應用程序的受眾而言看起來不錯。
• 使用Selenium進行自動化的跨瀏覽器測試，計算出自動化測試的投資回報率 。
• 跨瀏覽器測試和響應測試之間的區別 。 兩種測試實踐經常被誤解為相同的。 但是，事實并非如此！
• 作為CI / CD管道的基礎，版本控制使開發人員可以在共享代碼庫上進行協作。 版本控制是CD的絕對必需和偉大的伴侶。 您在版本控制系統中具有撤消功能，這意味著回滾到以前的版本。 此外，可以在整個歷史記錄中跟蹤配置，數據庫，腳本，文檔。
• 跨所有暫存環境所需的數據和配置。 請記住， 登臺環境對于您的組織而言失敗的13個原因 。
• 使用測試框架和自動化工具在整個應用程序中創建自動化的穩定測試
• 深刻的見識：沒有代碼或功能未經測試，因此可能進一步降低速度； 有時會阻止您的團隊發布軟件。
• 保持回歸測試套件有效性的良好跟蹤機制可以清楚地概述流程，并確保僅將有用的測試添加到測試套件中，從而在控制回歸缺陷時對所有質量活動具有統一的視圖。
• 自動代碼提交，測試套件和測試環境會立即產生反饋，當您使用CI / CD管道時，它會自動解決諸如版本控制之類的問題，或者當編碼人員編寫單元測試時通常很難將其轉換為工作流程。 保持期望的水平是質量保證的關鍵。 質量保證意味著要包括不斷發展的想法和長期維護，以及可以浮出水面的三個重要方面：測試，交付和優化。
• 其他QA成員如何編寫測試包以在每次連續構建期間自動運行它們？ 將它們維護在CI系統中可以使測試套件更有條理，更易于訪問。
• 您需要一個Continuous Integration Server來監視主存儲庫，您將在其中運行自動測試新提交的提交。
• 負責盡可能頻繁地合并更改的開發人員的特定角色。
• 開發生命周期從清單或劇本開始，清單或劇本包括恰好是手動執行的任務。 稍后，這些任務可以使用腳本和工具轉移到自動化。 這樣，如果需要再次運行清單，您可以確保任務是可重復的，因為團隊成員可以運行腳本。 此外，您可以在環境之間一致地運行劇本腳本，從而提高了可靠性，就像用于在生產環境中部署代碼的腳本一樣。

質量檢查并不局限于為什么以及如何創建前端網站測試計劃的基本方面，實際上，它可以為組織增加價值。 只要您傾向于優化質量檢查，就可以更快地增加產品周期。 借助快速的反饋循環，您可以超越結果。

全面的測試對于軟件產品的成功起著至關重要的作用。 總是三思而后行，三次測試案例以實現自動化，并從中獲得最大收益，應盡早開始。 從第一天開始，逐步構建您的自動化套件，該套件可以以更便宜的價格檢測錯誤，而您可以在周期的后期階段發現相同的問題。 最后壓縮測試還有很多問題，因此請繼續弄清楚以下幾點：

• 您將多久重復一次該場景？
• 過程的長度。
• 征集所有針對多個構建執行的重復測試用例。
• 檢查涉及的人員和資源依賴關系以及可能由于這些原因造成的任何短缺或延遲。
• 如果要在任何地方跳過自動化，請確保它不會成為容易出錯的過程。

每條CI / CD管道面臨的最常見挑戰

• 開發人員將專用時間的20-40％用于調試。 這意味著，在調試軟件上花費更多的百分比而不是構建新功能會導致相反的結果，從而導致生產力下降，支出不受控制和員工流失。
• 即使是最全面的測試，分級和QA流程，也可能允許錯誤穿越裂縫，因此始終要準備面對意外或中斷，并經常破壞CI / CD管道中的代碼。
• 即使在部署代碼后，工程團隊也面臨挑戰，因為當您不為監視過程添加自動化功能時，周期將變得更加不受控制。 過時的生產監控實踐通常會使CI / CD流程停滯不前，并且應該制定明智的生產錯誤處理策略以減輕相關風險。
• 一次執行的容易出錯的任務可以阻止足夠的精力損失，例如痛苦的瑣事可能會耗費20分鐘以上的時間，而一周要乘以5次，則可能會增加100分鐘的痛苦時間。 因此，為了獲得健康的劑量，請解決瑣事并在初始階段進行優化，從而完全避免痛苦的時間。 在這方面，首先要做最困難的部分，這將進一步分析和確定組織過程中的弱點。 拖延的任務表明了需要改進的地方，因此團隊應該追求或保持他們的領先地位，以便盡早解決。
• 如果應用程序僅在開發人員的計算機上工作，則網站業務與之無關。 總體業務目標和同理心應該是每個團隊成員的主要職責。 CI / CD管道完全旨在將代碼更改發送到網站，以方便最終用戶。 因此，當您“完成”時，請確保整個團隊的責任和貢獻是完整的。

實施可靠的CI / CD管道的每個質量檢查的可行見解

除了理性的思考過程外，作為專業的質量檢查人員，您還應對生產環境中發生的每分鐘變化負責。 在任何發布周期中松懈都可能導致大量中斷。 這就是為什么必須對所有需要采取的可行見解進行檢查的清單，以確保CI / CD管道成功。

使用Selenium實現自動化跨瀏覽器測試的自動化測試

您的網站是您在互聯網上的業務的標識，如果您最近通過CI / CD管道更改了生產代碼后，它在某些瀏覽器和設備上看起來很奇怪，那將是非常糟糕的。 跨瀏覽器測試是一種衡量網站相對于不同瀏覽器和瀏覽器版本的不同渲染引擎的性能的過程。
使用Selenium進行測試自動化可以幫助您更快地加快產品開發速度，借助Selenium中的并行測試可以更快地將產品推向市場。

探索性和自動化測試

我們的普通讀者會知道我們的主要重點在于快速測試的能力。 保持質量和質量保證對每條CI / CD管道的價值，我將與您分享我們如何專注于測試計劃以適應CI和敏捷開發方法的經驗。 探索性測試對于成功的CI / CD管道至關重要，您可以將其與自動化相結合，從而在測試和業務方面取得增長。 從探索性測試中了解更多信息：一切都與發現有關！

當您開始在流程中整合質量檢查時，需要確定公司在質量檢查中的所有方面。 一旦知道了需要自動化的內容，就可以進行自動化。 功能測試不能放在自動化測試的地方，因為您不知道接下來可以編程什么。 在這種情況下，我們根據探索性錯誤將其與自動測試創建混合在一起。 現在，在功能性探索性測試之后對構建進行過濾，以自動測試剩余的錯誤。 您在功能性探索性測試中的認知能力使您在開始組裝所有功能以進行測試并將質量檢查轉變為發布的關守時達到了一個關鍵點。 開發人員開始將構建版本發布到質量保證部門的CI / CD服務器，由QA部門進行測試，然后再使用堅固的CI / CD管道進行發布。

功能和UI測試

功能和UI測試每天至少重復一次，對于中型應用程序，則需要2-3小時。 在使用Selenium進行測試自動化的情況下，無需頻繁更新自動化腳本，但是UI經常會被修改，因此需要頻繁更改腳本。 兩者都依賴于多個依賴關系，并且都容易出錯，并且當我們必須確定優先順序時，我想說的是在進行UI測試之前先進行功能測試，以充分利用資源。

自動化回歸測試

當開發人員更改功能或修復錯誤時，將使用回歸測試。 CI系統可作為針對長期產品的自動回歸測試套件的QA工具，非常適合敏捷開發，在敏捷開發中，團隊應至少每周部署一次產品，并具有較短的期限以適應手動回歸測試。 另一個優勢是您可以將基礎結構用于將來的產品，從而加速測試自動化。 當發現新的缺陷時，CI自動添加新的測試用例。 CI在自身的基礎上構建了針對新代碼自動運行的實質性回歸測試套件。

結合敏捷測試人員和開發人員

我認為，如果將質量描述為事后的做法，那將永遠是不幸的，這意味著您首先強調要求，然后進行設計，編碼，最后將齒輪轉向質量，然后說：“讓我們請一些測試人員來”。 當您必須在一周或一個月之內提早發貨時，測試或整體質量絕對是一個重要方面。 敏捷方法論將軟件開發分解為用戶故事（較小的任務）。 這樣可以加快反饋速度，并進入市場。 幫助您更快地開發更好的Web應用程序。 使用CI / CD管道，您可以更頻繁地驗證Web應用程序。 但是，自動化構建，集成，測試和部署軟件的各個方面可以降低風險。 而且，如果您在“ 敏捷與瀑布”方法學的背景下看到它，那么敏捷將通過支持預期需求經常變化和發展的過程而Swift落后于瀑布方法。 在開發經常進行大修的網站時，要與技術環境，客戶需求保持同步，并通過選擇有效的自動化流程來滿足開發人員的需求。 查閱我們的文章“ 從瀑布式測試到敏捷測試時我學到了什么？ ”

如果您無能為力，請不要使用Selenium啟動測試自動化！

當然， 使用Selenium進行自動化測試會有好處 。 但是，如果沒有策略，最終可能會使用復雜的代碼進行簡單的代碼測試。 重要的是分析如何自動化不同的零件。 實施自動化計劃不容忽視，但該戰略將幫助我們實現目標。 我總是建議隔離的單元測試，每種語言都支持。 快速運行的單元測試可提高置信度，并在短短幾秒鐘內確保代碼的正確性。 如果單元測試失敗，則無需進一步。 通過單元測試表明組件運行良好，應用程序正在根據客戶的期望進行構建。 是的，BDD是編寫更好的自動化測試的最佳實踐。 這里有8條可行的見解，旨在編寫更好的自動化代碼 。

根據您的項目需求選擇正確的自動化測試工具

您可以看到自動化測試工具的廣泛市場，重要的是選擇適合您總體需求的正確測試工具：它應該支持C＃，Java或.Net應用程序等平臺和技術，并使用哪種操作系統？ 此外，根據是否需要測試Web應用程序或移動應用程序（Android或iOS還是這兩種操作系統）來做出決定。 例如，如果您希望執行自動化的跨瀏覽器測試，那么將Selenium作為可靠的開源軟件作為首選。 但是，如果您選擇使用Selenium進行內部測試自動化，它仍然有一些限制。 限于使用Selenium Grid可以在其上并行測試的瀏覽器的數量。 另外，要運行4到8個并行測試會話的Selenium Grid，將需要非常堅實的硬件要求。 對此的最佳解決方案將被視為基于云的跨瀏覽器兼容性測試工具，例如LambdaTest。

LambdaTest提供了一個Selenium Grid，它與支持Selenium的每種框架和語言都兼容。 您可以使用Selenium on cloud進行大規模的測試自動化。 您還可以集成到許多第三方項目管理工具CI CD工具，以及它們的Chrome擴展程序和WordPress插件 。

LambdaTest還提供了Open Selenium API ，可幫助您提取測試詳細信息，將測試自動化Selenium腳本執行從LambdaTest平臺執行到您的首選系統的測試報告，而無需登錄LambdaTest。

在CI / CD管道中納入連續測試

連續測試是使用廣泛的自動化測試套件來評估Web應用的E2E評估的過程。 它可以確保快速傳播反饋和即將到來的沖刺。

CI系統不限于代碼級單元測試，甚至可以立即在相互依賴的平臺上執行集成測試。 不要使用集成測試來測試業務邏輯，這就是單元測試的目的。 CI系統運行單元測試對于每個構建都非常快。 集成測試的運行時間要長得多，而單元測試則針對代碼的基本正確性。 單元測試應清除所有業務邏輯錯誤。

將連續測試納入您的CI / CD管道中，并通過測試自動化和反饋功能使您的質量保證團隊能夠更快地進行評估。 查看我們的讀者以了解更多有關像Pro一樣在DevOps中實施連續測試的信息 。

引入故障注入測試以更好地覆蓋CI / CD管道

顧名思義，“故障注入測試”是您有意將故障放入代碼中的地方，以增強Web應用程序的堅固性以及測試范圍。 將故障注入測試作為檢查的標準部分進行介紹，并且當您的流程和實踐變得成熟時，它將確保Web應用程序的彈性。 確實，當您能夠在錯誤或錯誤出現在生產環境中之前分析它們的結果時，這是一個好習慣。 盡管您可以手動執行故障注入測試，但是也可以使用一些工具。

不要讓無人參與的測試失敗

團隊必須有一定的紀律性，以便團隊停止跳過任何失敗的測試，并且當您暫時暫不進行測試時（即拋出SkipException）或使用工具將其靜音，暫時放置適當的注釋并確保不保留它配置中的無人值守或忽略時間更長。 單個構建不包含很多更改，因此可以不時查看構建以找到測試。 實際上，審閱帶有某些更改的內部版本可幫助您確定任何損壞的測試。 而且CI / CD管道必須穩定，并帶有中繼線，該中繼線可以通過電子郵件或IM通知您構建是否失敗。 TeamCity提供了許多功能，其中一個功能可以讓您知道—誰負責測試失敗。

注意負載沖突

CI / CD流水線包含測試以確保交付的構建穩定且無錯誤。 在遵循CI / CD流程的同時，報告問題是關鍵因素。 完整的報告提供了有關如何運行測試以及如果任何人失敗的原因的詳細信息。 您是否曾經測試過Web服務器的性能？ 您使用了哪個工具？ 我認為有60％的機會是JMeter。 該工具模擬真實用戶的行為并提供復雜的報告。

最好的事情是，Jmeter與Selenium Grid一起檢查在多個用戶并發用戶流量下的軟件性能。 Maven，Jenkins和Selenium可以一起使用，以創建良好的端到端報告，創建APPDEX（應用程序性能指數）以及通過同時點擊瀏覽器來記錄應用程序的行為。 我將性能測試包括在討論中，以便您從開始就可以對其進行標記，以避免意外的負載沖突。

有意義的儀表板

確實，如果沒有自動化，則更早，更快速地進行測試會很麻煩。 任何CI / CD管道的主要挑戰之一是各個團隊或部門（例如DevOps，QA，安全團隊等）之間的協作，他們正在努力將通用的Web應用程序推向市場。 您需要一個對所有人透明的地方，或者一個儀表板，并傳達有意義的和有條理的信息。 諸如Jenkins，Git和Jira之類的CI / CD工具使團隊能夠無縫地進行協作，并通過評估每個人想要的對您的DevOps項目最重要的數據來定制有意義的儀表板。 我建議添加從DevOps工具的不同數據源配置的功能部件，以幫助管理CI / CD管道。 “功能”小工具可分解故事，并讓您知道哪些故事已完成或正在進行中。 一種更深入地挖掘以發展DevOps文化的方法。 不同的成員具有不同的優先級，因此在計劃設計儀表板時需要執行漸進評估。 為CI / CD管道創建有用的儀表板，以及每個人的同意都很重要時，是有點棘手的。 但是，這也至關重要！

例如，如果您要使用LambdaTest和跨瀏覽器測試云使用Selenium進行測試自動化，則會獲得一個直觀的儀表板，該儀表板顯示有關測試用例執行時間戳，元數據，逐個命令的屏幕截圖，Selenium日志，網絡日志，命令日志，視頻日志，它們代表測試執行的記錄等。

尋求獨特的命名約定以確保UI抵抗CI / CD管道

自動化工具是基于屬性的測試工具，可幫助查找和標識對象。 根據位置坐標，如果發現控件標題或位置發生變化，則該工具可能會失敗。 任何Web應用程序的UI都是一個不斷變化的部分。 隨著時間的推移，您將有不同的開發人員致力于不同的需求。 現在，您不希望這些開發人員在不遵循標準命名約定的情況下繼續前進。 由于命名重復，基于屬性的測試工具將無法精確定位對象。 稍后將變得很麻煩，因為您將不得不為整個Web應用程序重命名舊名稱。 因此，請為您的控件提供唯一的名稱，以確保自動測試本身不需要更改并且可以抵抗UI更改。

持續部署與持續交付，了解差異！

如果在代碼庫中進行了一些修改后立即部署了構建，則可能會使用戶感到煩惱。 持續交付的關鍵是保持代碼庫處于可部署狀態，不進行持續部署并不意味著您未在進行持續交付。 連續交付是一個很小的構建周期，并且周期中的短距離沖刺可以縮短檢測錯誤的周轉時間，從而快速修復這些錯誤。 總體而言，它為早期提供了穩定的代碼基礎。 這是一種首選方法，它允許團隊立即解決問題，而在您計劃發布代碼庫時不會解決。 它提供對產品推出，風險因素和功能的全面控制。

用戶體驗測試

在用戶體驗測試中，您從用戶那里收集定性和定量數據，并且在組裝完應用程序之后，測試目標就變成了用戶體驗，可以通過結合負載測試和跨瀏覽器兼容性或移動測試工具來實現。 端到端測試很重要，還需要避免不必要地延長端到端測試的時間。 如果這會影響生產率，那么如果您繼續執行更多測試，那么請繼續關注正確和重要的事情。

“如果您想要一個出色的網站，則必須進行測試。 在一個網站上工作了幾周后，您再也看不到它了。 你知道太多了 找出它是否真正可行的唯一方法是對其進行測試。” –史蒂夫·克魯格–不要讓我想

煙霧測試

冒煙測試將監視系統并驗證最重要的功能或核心功能是否正常運行。 冒煙測試實際上允許您對主要功能進行快速回歸測試，確定產品是否準備好進行測試以防止進一步浪費時間和資源。

自動化交付和部署

自動生成的可交付成果仍然可供更廣泛的受眾使用，而功勞歸功于自動化。 Alpha和Beta測試可以轉移到更多的開發階段。 CI / CD管道系統可通過系統測試部署腳本實現自動部署，有助于確保在移至其他環境時不會出現糾結。

文檔是堅固的CI / CD管道的基礎

在自動化的單元測試中，可以將代碼質量保護為文檔標準，從而幫助提高下一個解決方案的質量。 自動化的單元測試也可以用作自記錄代碼。 維護代碼在軟件開發中起著至關重要的作用。 應該解決文檔短缺或難以理解代碼的問題，因為程序員可能不愿意或不喜歡編寫文檔。 擁有一個包含所有信息的文件的文檔，代碼正在執行的操作應減輕不必要的軟件維護成本。

未處理的中斷一定會導致測試失敗

平臺安全性，在自動化測試過程中向框架中添加故障轉移邏輯，記錄任何類型的中斷，所有這些累積的努力可以在很大程度上減少或避免中斷，從而導致使用測試自動化進行全面驗證。 合法的錯誤或重試嘗試也可能無法處理中斷，因此在這種情況下，更安全的方法是“測試失敗”。

資源管理可以大大幫助您的航行

編寫自動腳本的工作應分配給具有自動測試工具提供的豐富腳本語言經驗的專家。 與此相反，如果不精通自動測試腳本的編寫，則可能是QA工程師更擅長編寫測試用例，并且在不需要深入了解腳本語言的情況下可以被聘用。 一旦設計了自動化腳本，您就可以向經驗不足的自動化測試人員提供知識轉移，并讓他們負責通過該腳本進行日常評估。 同時，您團隊中經驗豐富的質量檢查人員可以提出更多開箱即用的測試用例。

連續的提高

CI / CD管道不會在部署時結束。 反饋循環是CD的核心，它指示監視部署的附加階段。 該階段將再次使用自動化工具來確定部署對最終用戶的影響。 您需要密切關注諸如業務收入之類的明顯指標，以及諸如參與時間和用戶轉化率之類的更精細的指標，以觀察相關性。

所有團隊成員都在同一頁面上

即使他們不在您的CI服務器上，也應始終告知所有團隊成員。 自動化通知可以循環獲取無法訪問的質量檢查小組成員，從而有助于總體上保持較高的質量。 緊密的反饋循環可防止意外事件發生，并且每個人都可以通過Slack等通信應用程序在同一頁面上轉換情況，從而可以輕松集成更新，尤其是在您的團隊有大量日常用戶的情況下。

結論

在CI / CD方法論中，您將質量融入到CI / CD流程的每個步驟中。 特別是，持續交付的中央反饋回路是不斷進行重新檢查的地方，以確保將優質的產品交付給最終用戶。 自動化測試允許以無錯誤的代碼和預期的質量交付新功能。 新功能的項目計劃涉及到有關分析，自動化測試儀器任務和性能監視的考慮。

整個組織都扮演著重要的角色，應保持專注和激勵，以生產高質量的可交付成果。 當產品經理需要監督部署和質量保證時，他們便扮演了角色。 安全團隊應注意發布過程。 質量檢查團隊成員在測試開發和登臺環境時所承擔的主要責任。

質量保證小組的所有職能應與最終發布之前的生產一樣嚴格。 開發人員應專注于產品發布并進行詳細調查。 最后，在正確的自動化工具選擇上明智地選擇。 LambdaTest提供了2000多種真實的瀏覽器，以及與CI / CD工具（如Jenkins，Travis CI等）的集成，可幫助您將連續測試納入CI / CD管道中。 測試愉快！

翻譯自: https://www.javacodegeeks.com/2019/06/professional-qa-implementsrobust-pipeline.html

總結

以上是生活随笔為你收集整理的专业QA如何实施可靠的CI / CD管道？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。