ci/cd自動化測試
導讀：淺談 CI/CD 和軟件測試
知其然，知其所以然。相較於DevOps而言，CI/CD是一個相對具象的概念。在 IT 企業中，CI/CD的應用愈加廣泛，成為推動軟件研發活動的重要基礎設施服務，同時推動 DevOps 模式的實際落地。
什么是 CI/CD
在實踐 CI/CD 相關內容之前，我們有必要先認識下什么是 CI/CD。
一般傳統或者狹義、普遍的 CI/CD，是指持續集成（Continuous Integration，CI）和持續交付（Continuous Delivery，CD）。而更加廣義、全面的理解，是指持續集成（Continuous Integration，CI）、持續測試（Continuous Testing，CT）、持續交付（Continuous Delivery，CD）和持續部署（Continuous Deployment，CD）四個方面。通常，一個軟件開發的流水線如下圖所示。
- Design：這一階段完成軟件開發的需求分析和設計。
- Develop：這一階段完成軟件開發的功能代碼，一個最佳實踐是采用測試驅動開發（TDD）的方法，測試代碼和功能代碼的編寫同時進行。需要注意的是，在 Develop 階段也會運行單元測試和其他小型測試。
- Test：這一階段完成軟件的各項大型或專項測試，比如界面測試、API 測試、性能測試和系統測試等。
- Release：這一階段完成軟件產品的發布，並交付給用戶使用。
每日構建和每日測試
每日構建（Daily Build）在反應速度上沒有持續集成快，它更強調的是通過每天（通常是晚上）自動部署當天開發所累積的代碼，並結合每日測試（Daily Test）方法進行自動化測試，用於評估和衡量項目的進度。
持續集成特性決定了不可能在該階段加入大量的測試，而每日構建則一般是在夜里執行的，那么這時就可以做更多的事情，比如代碼質量檢查、單元測試、測試覆蓋率、集成測試等。每日構建會把當天所有的提交代碼都一起做集成，而不像持續集成那樣每提交一次代碼就做一次集成。持續集成屬於增量式構建，而每日構建則是一次完全構建。
每日構建是項目的心跳線。一般而言，通過每日構建我們可以看到項目的進度。比如今天有10個 Bug 的修復代碼都提交了，晚上進行自動部署並通過了自動化測試，第二天上班時通過查看郵件我們就可以發現每日構建成功了，那么項目就又往前邁了一大步，開發工作又有了具體的進展。
具體的，每日構建就是在每天晚上自動化部署一個 OpenStack 環境（可以是all-in-one，也可以是 multi-node），然后運行大型或專項測試，比如 API 性能測試、API 接口測試、功能測試、部署測試等。
現在做測試，經常聽到一個概念 持續集成 CI - Continuous Integration。
那什么是持續集成呢？相信大家看了不少文章之后依然是一臉懵逼。
這里呢，用我自己的理解談一下，不正確的地方還請指正。
要說持續集成，首先要明白什么是集成。很多測試同學說到集成，就想到集成測試。
這里的集成主要是指代碼的集成：
舉例來說，比如當前迭代，開發時間為兩周。項目開始后，開發人員會從代碼管理工具（SVN 或 GIT）的主干代碼上復制一份代碼到自己本地電腦。然后在自己的本地電腦上進行開發，假設這個項目有三個開發人員，分別是 jim（狗蛋）、lily（翠花）、tom（大錘）。
好，現在三個開發分別在自己電腦上開發。開發任務完成后，一次性提交自己本地代碼到代碼管理工具的主干代碼上。
這個過程就叫集成，也就是代碼集成，將自己本地的代碼集成到主干代碼。此時發生了所謂的集成地獄。三位開發有可能會改到同一個代碼文件、同一個方法，這樣就會出現代碼沖突。為了處理集成過程中的沖突，會花費非常多的時間、精力和成本，並且提高了發布風險。
為了降低這種風險和成本，於是持續集成就被提出了。強調的是不再一次性把代碼集成到主干，而是高頻率的持續集成。一天集成1次，甚至多次。同時在集成過程中，進行自動化測試，保證主干代碼一直可用。
為保證主干代碼可用，開發每次代碼集成后都需要進行 BVTBuild Verification Test測試，也就是類似冒煙測試的過程，比冒煙更簡單一些，主要保證系統可用。這種測試由於測試頻率高，因此對自動化測試的需求非常大。
那么現在主流的持續集成工具，比如 Jenkins 做些什么事情呢？
先來說一下沒有 Jenkins 的時候，我們怎么去更新測試環境的。
首先從 SVN 上獲取最新代碼；
在本地進行編譯
構建一個發布包，通過 FTP 上傳到測試環境服務器
將發布包中內容更新到相應的服務
重啟相關服務，以使更新生效
如果部署了負載均衡，則在其他服務器上重復 4， 5
每次構建和更新測試環境都是很繁瑣的任務，而且極易出現錯誤。那么 Jenkins 能干什么呢？
能讓這一系列事情全部自動化：
根據規則輪詢代碼管理工具，獲取最新代碼（也可以手動或設置其他規則）
基於不同的語言進行構建（需要自行配置）
通過 FTP 把構建后的內容自動上傳到對應的服務器
使用插件或者腳本，將發布包內容更新到各個環境
通過命令行調用自動化測試腳本，搭配代碼覆蓋率工具執行自動化測試
展示自動化測試報告，並郵件通知構建情況
也就是讓集成過程中繁瑣的事情都自動化了，那么進行持續集成也不會因為集成頻率過高帶來的環境部署和頻繁測試而導致開發效率降低。
每個軟件項目都涉及成功實施和部署項目的某種“過程”和“實踐”。 隨着項目規模和規模的增加，復雜程度也以指數方式增加。 領導團隊應盡一切努力來開發，測試和發布軟件，以便以遞增的方式進行發布，從而對客戶已經可用的軟件影響最小（或沒有影響）。
在本文中，我將介紹有關測試自動化的CI / CD最佳實踐，以幫助您加快上市進程。
在上一篇文章“ 什么是持續集成和持續交付？”中 ，我們已經介紹了CD / CD 。 我們在哪里討論了他們的目的？ CI / CD管道中涉及的貿易工具。 在測試/驗證階段發現的每個錯誤都經過嚴格的開發，集成，測試和關閉過程。 如果此活動是手動完成的，則可能會花費大量的工時和驗證工作，因此理想的是在CI / CD中具有“測試自動化”功能 。
CI / CD中的“部署管道”和測試自動化的作用
一個自動化的系統，稱為CI / CD中的Deployment Pipeline ，可以自動測試服務器上可用的增量版本。 由於整個過程是自動化的，因此與手動測試相比，總的周轉時間（TAT）將大大減少。
在大多數情況下，不可能完全自動化測試。 可能有一些需要手動干預的測試場景，或者需要手動觀察來確定測試是否通過的場景。 盡管自動化是CI / CD管道不可或缺的最佳實踐，但確定測試方案是否自動化將被認為是CI / CD至關重要的最佳實踐。
盡管使用自動化測試有許多好處，但在CI / CD管道中使用測試自動化的一些主要好處如下：
- 更快的錯誤關閉-問題檢測->問題修復->問題關閉。
- 有效利用現有的整體資源，例如測試人員，測試基礎結構等。
- 能夠並行執行測試。
- 測試計划和執行的一致性。
- 自動化測試用例執行所需的最低技術技能要求。
如何在CI / CD管道中實現最佳的測試自動化？
盡管CI / CD管道中測試自動化的范圍可能因一個項目而異，但CI / CD的某些最佳實踐可應用於任何項目，而不論其規模和規模。
增量變化與及時溝通
開發人員可以遵循大爆炸的方法來開發新功能或解決測試團隊報告的問題。 這意味着開發人員將使用該選項，一口氣將功能實現推入其中。 盡管完成了實現工作，但是這種方法還是存在一些問題。 主要缺點是很難隔離問題（如果實現存在問題
明智的方法是將功能分解為不同的子功能，並為每個功能使用唯一的功能標志 。 該技術不僅有助於隔離潛在的問題，而且在需要時可用於進行增量功能構建。 當將最終功能（由許多子功能組成的組合）推到主線/生產分支時，這也降低了出現集成問題的可能性。
在某些情況下，功能之間存在相互依賴關系，即功能“ A”依賴於功能“ B”，在這種情況下，任何開發人員都必須等待100％完成依賴項的功能。 通過正確使用存根和功能標志，兩個功能開發人員都可以避免死鎖情況，因為存根將用於計划中/正在進行的實現。 一旦所需的功能准備就緒，開發人員就必須擺脫基於存根/虛擬的實現，該實現只是一個已知接口的實現的占位符。
這項開發活動需要精心計划並在開發團隊之間進行及時互動，以充分利用CI / CD管道中的測試自動化。 遵循這種方法的任何紀律都會影響您的總體測試進度。
識別可以自動化的測試
如前所述，不太可能100％的測試可以自動化，因為至少在某些測試中，與自動化測試相比，手動測試會更有效。 由於測試自動化是CI / CD管道的核心，因此實現那些可以自動化的測試用例對於CI / CD是至關重要的最佳實踐。
可以自動化的兩大類測試：
頻繁執行的測試：如果測試人員“手動”執行此類測試，則可能會出錯，因為生產率可能會降低，因為測試人員一天必須多次執行相同的測試。 以必須要進行瀏覽器兼容性測試的Web產品為例。 某些測試案例可能涉及在不同瀏覽器/設備/操作系統組合上測試Web應用程序時捕獲其屏幕截圖。 為這些組合中的每一個拍攝屏幕截圖可能是一項繁瑣的任務。 因此，自動化的跨瀏覽器測試可以使測試人員騰出時間來編寫有效的測試用例 。
需要知識並依賴特定測試人員集合的測試：如果項目關鍵階段沒有可用資源，則僅具有測試執行所需領域知識的資源（開發人員/測試人員）的依賴可能會帶來風險。 因為只有該測試人員才知道測試的前提條件和程序，所以他的缺席會影響整個項目的可交付成果。 通過將測試自動化集成到CI / CD管道中可以避免這種情況，從而不會對項目截止日期造成不利影響
在許多其他情況下，可以使用自動化測試，其目的應該是利用工具和測試平台（可擴展）來幫助您實現這一大膽的目標。
一鍵遷移
如果具有一鍵式功能將代碼從一個應用程序環境遷移到另一個應用程序環境，則可以大大減少將代碼更改移至生產環境的工作。
架構良好的CI / CD管道應進行一鍵式遷移，因為它可以減少不同操作之間的摩擦（代碼遷移）。 選擇具有此功能的優良雲基礎架構以及高效，優雅地使用測試自動化可以優化開發和運營流程。 只需單擊一下即可推動您的開發，非常適合作為CI / CD的最佳實踐。
利用並行測試作為CI / CD管道的最佳實踐
CI / CD的另一個最佳實踐是並行測試執行。 一旦確定了需要自動化的測試，下一步應該是在測試方法中納入“並行執行”因素。 將測試自動化作為CI / CD管道的最佳實踐已經可以加速整個過程，但是如果將其與並行測試結合使用，結果會更好。 您可以同時執行多個自動化測試，這可以更快地產生結果。
如果在一台計算機上執行測試，則無法從並行測試中獲得最佳吞吐量。 這種情況會占用機器上的關鍵資源，例如CPU，GPU等，這可能會減慢機器上運行的其他測試的執行速度。 因此，執行測試的基礎結構非常重要。 對於測試Web應用程序/網站，擁有內部測試部署和執行基礎結構可能不是理想的解決方案（就成本和可伸縮性而言）。 這是LambdaTest的用處，可幫助您在包含2000多種瀏覽器和瀏覽器版本的雲上在線Selenium Grid上，使用TestNG，Pytest等測試自動化框架執行並行測試 。
從先前執行的項目中學到的東西
每個軟件項目都有不同的階段，即項目計划，需求收集，實施，測試，產品部署等。每個階段都涉及學習，這些學習可用於更好地計划和實施下一個項目。 即使項目的性質有所不同，您仍然可以利用過去項目中的一些最佳實踐，從而可以加快當前項目的每個階段。 另外，為避免重復其他項目中犯的錯誤。
您應該記下用於加速流程的測試自動化技術，這是CI / CD的最佳實踐。 您應該讓您的團隊成員（即開發人員，測試人員）參與進來，以探討可以重用測試自動化最佳實踐的可能性，這樣您和您的團隊就不必重新發明輪子了。 例如，他們可能使用了某些測試框架，這些框架幫助我在較短的時間內獲得了更好的測試結果。 記錄這些學習內容，因為這可能有助於制定合理的測試管理策略 。
為什么絕對需要文件？
在某些情況下，項目需求會隨着項目執行的過程而變化/發展。 同樣，測試自動化策略的設計方式應考慮到短期目標和長期目標的考慮。
盡管一段時間內可能會對測試計划或測試策略進行更改，但團隊至少應將某些流程標准化。 標准化可能意味着短名單中的特定測試框架，確定適合您預算和要求的雲基礎架構，組建一支能勝任測試腳本（使用Python / C＃/ Java /其他編程語言）的自動化團隊。 您還應該有一個備份計划（Plan-B），以防組織內的日程安排或整體業務發生任何變化。
記錄這些內容很重要，以便可以在任何時間點進行引用。 除了上面已經提到的指針外，文檔還應該包括一個部分，突出顯示與執行測試策略相關的“風險和假設”。 例如，將以4名自動化工程師作為資源計數來創建測試計划/測試策略。 但由於某些不可預見的情況，您可能需要縮減團隊規模。 因此，通過查看與項目關聯的所有不同參數來創建防呆測試策略。 強調測試策略的文檔應該是自由流通的文檔，即用重要的時間表和里程碑進行更新，並且應該進行版本控制，以便重新訪問該文檔以跟蹤進度。
用於代碼開發和維護的中央存儲庫
在任何項目中，團隊中都會有很多開發人員推送其代碼，這些代碼可能是功能實現或錯誤修復。 同樣，開發人員將執行拉取請求，以從服務器獲取最新的代碼更改。 在中央存儲庫中維護源代碼至關重要，並且被認為是CI / CD管道的最佳實踐之一。 這樣開發人員就可以使用生產服務器上可用的最新源代碼來使更改保持最新。
修訂/版本控制系統對於跟蹤更改，識別差異以及維護簡化任務以跟蹤應用程序構建的環境也很重要。
使用版本控制回滾
在某些情況下，測試團隊可能會遇到一些以前的軟件版本中未發現的問題； 可能的原因可能是受測試的發行軟件中推送的修復程序的副作用。 執行RCA（根本原因分析）有時可能會很耗時，並且您在生產環境中長期承受不起失去有價值的功能的負擔。
在這種情況下，推動該修復程序的開發人員應該能夠回滾其更改，以使發布不會停止，並且他還有更多的時間重新查看其實現。 沒有版本控制系統，這種無縫回滾是不可能的。 回滾並不僅限於源代碼； 它可以擴展到文檔，演示文稿，流程圖等。
臨時環境模仿生產環境
無論用於跟蹤代碼更改的版本控制工具如何，在所有開發環境中都經常使用開發和測試環境。 開發團隊可以為不同的客戶組使用不同的“開發分支”，但是代碼仍將被推送到生產服務器/登台服務器。 為了提高效率，過渡環境應該理想地反映生產環境。 我觀察到的一個常見錯誤與實時路況有關。 通常，登台環境會錯過生產環境用於處理負載的實時流量。 以下是登台環境使您的組織失敗的13個原因 。
這種方法使將工作代碼從登台服務器部署到生產服務器變得容易。 實際上，開發人員還應該具有靈活性，他們可以通過單擊按鈕來創建和設置新環境。 有一些工具，例如Jenkins，可以幫助實現相同目的。 使用開發團隊和DevOps團隊通用的工具對於簡化CI / CD流程的最佳實踐至關重要。
讓相關的利益相關者參與測試代碼的開發
讓正確的利益相關者參與測試自動化計划，開發和執行變得至關重要。 由於團隊中的開發人員可以為測試工程師實施的測試代碼增加更多的價值，因此最好讓他們參與測試用例的實現。 開發人員對軟件開發的體系結構，編碼技術和最佳實踐有更好的了解。 經驗豐富的QA工程師可能對測試基礎結構，測試框架等有很好的了解。因此，與QA工程師合作的開發人員可以減少測試用例開發中的工作量和時間，從而加快CI / CD管道的測試自動化。
在緊急情況下，開發團隊可以在不參與測試團隊的情況下處理自動化代碼，因此不會延遲實施自動化測試。 但是，建議讓相關的利益相關者，尤其是質量保證工程師和開發人員參與測試用例的實現。
結合反饋，以在CI / CD管道中提供可靠的測試自動化策略
測試策略文檔為如何計划和執行測試自動化以及其他與測試相關的活動制定了公平的計划。 除了更新測試策略（在需要時以及在需要時）之外，反饋循環還應用於及時更新CI / CD管道中測試自動化的代碼。
反饋可用於了解用戶的痛點並獲得有關自動化測試提供的基礎結構的總體用法的詳細信息。 例如，測試自動化工程師和DevOps團隊可能會在短暫的測試過程中對基礎架構有所了解。 這些觀察結果可能與用於捕獲日志/將Python和Selenium中實現的自動化測試代碼捕獲到用於測試/與測試執行相關的性能的雲基礎架構的方法有關。
所有這些反饋都應記錄在文檔中，並且相關的反饋應作為最佳實踐納入CI / CD自動化管道，以使測試代碼與當前要求保持同步。
CI / CD管道測試自動化中的頻繁代碼承諾具有微敏捷性
開發人員根據規范中提到的要求開始開發。 一旦實現完成，開發人員將對代碼執行單元測試，並修復在這一輪測試中遇到的問題。 由於測試是獨立測試，因此他應該能夠解決獨立於集成的問題。 本地測試完成后，開發人員會將代碼推送到代碼存儲庫。 在大多數開發環境中，通常將代碼推送到“開發部門”，一旦批准並測試了代碼，便可以將其推送到“生產部門”。
因此，應該鼓勵和激勵開發人員更加頻繁地推動代碼更改，以便輕松跟蹤更改。 團隊中的開發人員應認真遵循CI / CD的這一重要最佳實踐，以便您能夠在與CI / CD管道中的開發和測試自動化有關的活動中實現微敏捷性。
記住，它是CI + CD！
如果我們提到CI / CD流程的最佳實踐，則交流與協作是關鍵Struts，因為有多個團隊（產品規划，開發團隊，驗證團隊，DevOps團隊等）必須協同工作才能確保項目的成功。 因此，與這些領域中最優秀的領導者對CI / CD流程進行基准測試很重要。 並且被視為CI / CD管道的關鍵最佳實踐，可為優化提供敏銳的意見和建議。
CI和CD是兩個獨立的過程，但不能將它們稱為不可分割的過程。 執行CI流程的任何延遲或延遲都可能妨礙CD流程的輸出。 盡管可以使用自動化來提高CI / CD過程的效率，但是在很多方面自動化可能沒有效果。
另外，請記住，在任何項目中，都不會發生孤島活動，因為總會有人依賴於您的活動結果。 為此，項目利益相關者之間需要適當的溝通。 例如，您的質量檢查工程師可能正在研究某些測試用例，而這些測試用例並不能滿足所有要求。 如果執行了這樣的測試，您可能無法獲得良好的測試覆蓋率，因為在測試用例/測試套件實現中會漏掉重要的場景。
通過先執行較小的測試用例，使其保持簡單和井井有條！
我在許多項目中都見證過，當涉及到CI / CD管道的測試自動化時，我們常常會忘記以一種系統的方式優先考慮我們的測試用例。 這就是我的意思！ 作為CI / CD的最佳實踐，始終建議先執行較小和簡單的測試用例，然后再執行較長和復雜的用例。
這樣，您可以確定以獨立方式進行功能測試的各個測試用例的覆蓋范圍和性能。 設計測試用例以檢查多個模塊之間的交互的復雜測試用例可能會在以后出現！
團隊內部和團隊之間的透明度
許多項目都有位於不同地區的開發和質量檢查團隊。 除了需要確保每個團隊成員同步的高度協調之外，更好的透明度可以使事情變得更好。 在這里CI可以非常有效，因為它為團隊的主要利益相關者帶來了非常需要的透明度。
有了CI，團隊就可以更好地了解測試的總體狀態以及可以采取哪些措施來提高測試效率。 這就是如何促進集體智慧的使用，以改善團隊和項目。 必須讓每個人都在同一頁面上工作，尤其是在遠程工作時。 作為CI / CD流程的最佳實踐，項目管理工具可能非常有效。 使用項目管理工具，每個人都會改變其他團隊成員所進行的活動，還必須完成任務的截止日期。 以下是針對您的軟件測試團隊的19種最佳協作工具 。
為CI / CD處理選擇正確的工具
上述所有技巧和可行見解將幫助您使用針對CI / CD管道的最佳實踐來加快測試自動化的步伐。 盡管最終，起搏CI / CD管道在很大程度上取決於工具。 CI / CD有許多可用的工具，但是您應該根據預算，要求和經驗選擇合適的工具。 一些常用的CI / CD工具是Jenkins，Travis CI，Gitlab，TeamCity，Codeship，Circle CI等。
在對任何特定工具進行調零之前，我們強烈建議您先看一下該工具的優缺點，因為在開發過程中CI工具的任何更改都可能會影響您的交付成果和截止日期。