持續交付會如何影響測試
如果要做持續交付,那我們必須關注我們寫的程式碼的質量。不是所有團隊都配備專門的測試人員,但如果有測試人員的話,他們會和開發人員緊密合作,編寫在單元測試中無法覆蓋的少數測試的自動化程式碼,並幫助開發人員搭建單元測試。
\\Industrial Logic Canada公司的執行長Jeff Morgan在2018年eXperience Agile大會上介紹了持續交付會如何影響測試人員的工作。InfoQ會以問答、總結和文章的形式報導eXperience Agile大會。
\\Morgan說,持續交付的優勢在於可以迅速在生產環境下進行實驗。它可以幫助我們儘快測試使用者對產品的想法,並收集資料結果。
\\我們大多數的應用程式都會進行單元測試。Morgan表示他們沒有人工測試,一切測試都是自動化進行的。並不存在強化階段,我們必須從一開始就保證產品的質量。
\\Morgan建議如果你需要專門的測試知識,那讓測試方面的專家和團隊一起工作,不要讓專家悶頭寫測試。是整個團隊需要測試,不僅僅是這個專家需要測試。
\\Morgan說,由於測試人員越來越技術化,開發人員也越來越注重測試的重要性,隨著時間的推移,開發人員也會承擔測試的工作,測試人員也會做一些開發的工作。
\\InfoQ採訪了Morgan,諮詢了他持續交付會如何影響測試工作。
\\InfoQ:當組織採用持續交付的方法時,軟體搭建和交付的方式會有什麼重大改變?
\\\\\Jeff Morgan:最主要的變化是我們不會再用傳統的軟體開發方式了,構建完軟體之後就直接進入測試階段。選擇進行持續交付,一旦程式碼進行了原始碼管理並遍歷了部署管道,程式碼就部署到了生產環境下。
\\這個重大的變更也表明,測試需要在開發的同時進行。實際上,我們通常不會把開發和測試認為是兩個分開的工作。相反,測試是整個開發流程的一部分。這個變更還表明,我們會更多地依賴自動化:自動化測試、自動化部署和環境自動化。
\
InfoQ:持續交付會如何影響我們對於質量的看法?
\\\\\Morgan:通常,我們會在軟體開發週期的最後,在釋出前才驗證並完善軟體的質量。這通常被稱為強化階段。但是我們如果採用持續交付,就沒有必要設立專門的強化階段,因為只要檢查了程式碼就會立刻進入生產環境。 相反,在我們寫程式碼的時候,我們要全程關注軟體的質量。對於我工作的團隊來說,這代表著我們寫程式碼的方式發生了徹底的改變。我們會採用結對程式設計、測試驅動開發、減少分支、以及功能開關等實踐。開發人員會更加註意測試和質量問題。如果團隊中有開發人員,他們會主要關注少量端到端的自動化,並和開發人員結對進行探索性測試。與傳統的僅由測試人員來測試不同,團隊中的“每個人”都會進行非功能性需求的測試。很優秀的團隊中,開發人員和測試人員之間並沒有很多區別。
\\我們也會使用大家所說的DevOps來幫助我們完善系統。通過搭建管道,用不同的方法執行我們所有的測試來降低風險,並通過測試來消除安全性、能力以及合規性的問題。通過容器和基礎設施來避免環境方面的風險。通過對於小的變更的釋出控制來避免對於使用者和產品產生的風險。
\
InfoQ:這會如何影響測試人員的工作?
\\\\\\\Morgan:首先我要指出在現代社會,不是所有團隊都會配備專門的測試人員的。如果有測試人員的話,他們不會手動執行測試指令碼。相反,他們要編寫少量單元測試無法覆蓋的自動化程式碼,幫助開發人員從金字塔最上面轉移到最底端的單元測試。他們和開發人員合作非常緊密,並幫助搭建管道。他們會在整個開發過程中和開發人員結對,來進行探索性測試。一旦發現了缺陷,他們會和開發人員結對,立刻修復並部署修訂後的版本。所有的工作都是和開發人員合作完成的。
\
InfoQ:如果沒有“測試階段”的時間的話,開發人員應該做什麼?
\\\\\Morgan:根據我的經驗,和傳統的“敏捷”相比,持續交付中會進行更多的測試。同時,在開發週期的不同時間都會進行測試,而不僅僅在最後才進行測試。我們非常依賴於自動化(主要是單元測試)和管道,來保證系統的質量。
\\開發人員應該和開發人員緊密合作,保證軟體的質量,保證缺陷幾乎不會發生。開發人員通常要關注金字塔最上面的“使用者測試”。他們還可以和開發人員結對,幫助他們獲得並提升自己的測試能力。測試人員還需要幫助定義構建管道。
\\有時候會需要專門的測試專家,比如安全或負載/效能測試專家。這種情況下,他們需要和團隊討論、建立並維護測試指令碼在管道階段的運作。
\\在很多方面,管道是最接近“測試階段”的存在。每次檢入程式碼時,我們在這裡執行所有測試,並最終將我們的程式碼部署到生產環境。儘管所有的管道都是不同的,但我發現各個團隊之間總有些核心的通用模式。這裡舉例說明了團隊可能會有的管道階段:
\\搭建並執行單元測試
\\執行動態程式碼分析,如果質量沒有達到的話就會失敗
\\在功能開關開啟的時候進行部署,只執行關注於未釋出功能的測試。任何不在控制之內的後端系統都應該模擬。
\\在功能開關關閉的時候進行部署,執行其他的測試,實現迴歸。這個測試要很快執行,因此它們可以並行運作。同時,任何控制之外的後端系統都應該模擬。
\\在功能開關關閉的時候進行部署,在不同的瀏覽器和裝置上進行小部分測試。後端需要模擬。
\\在功能開關關閉的情況下部署,執行一小部分測試,不需要模擬。這能保證完整整合工作的正常運作。
\\執行靜態和動態安全測試。
\\執行負載和效能測試。
\\執行合規性測試,解決任何生產前的合規性工作。
\\部署到生產環境。
\\如果任何階段失敗了,管道都需要停止。
\
InfoQ:你對於想要採用持續交付的組織有什麼建議?
\\\\\Morgan:有很多公司跟我說正在接受持續交付。當我問他們為什麼的時候,他們大多數會聊到更快的交付或是質量提升。雖然這都是很好的目標,但我認為持續交付有更重要的優勢。在我認為,採用持續交付的最重要原因是改變我們計劃和交付產品的方式。持續交付可以幫助我們拋棄辛苦的、推測性的長期產品路線圖,而改為採用“精益創新”方式來進行產品設計。它可以幫助我們根據真實使用者的體驗來修改程式碼,以交付完善的產品。這是我認為使用持續交付的關注點。
\\對於正在使用持續交付的公司,他們需要了解DevOps並不是解決所有問題的方法。它當然是個重要的組成部分,但必須要和高質量的開發相結合。實際上,我建議首先提高質量,這需要一些時間。一旦實現之後,你可以考慮新增持續整合,這樣開發人員可以儘快在搭建過程中獲得反饋。隨著時間的推移,你可以把它擴充套件為成熟的部署管道。
\\一旦你的組織中有了質量保證的文化之後,你就可以為每天交付多次新增DevOps自動化了。
\
相關文章
- 持續整合、持續交付與持續部署
- 持續整合、持續部署、持續交付、持續釋出
- 你真的懂持續整合、持續交付、持續部署嗎?!
- 太多指令碼將會毀掉持續交付指令碼
- 聊聊持續測試
- 為什麼單元測試不是持續交付的唯一答案
- 淺談持續整合(CI)、持續交付(CD)、持續部署(CD)
- 對持續整合、 持續交付、持續部署和持續釋出的介紹
- 3分鐘瞭解清楚持續整合、持續交付、持續部署
- 持續整合持續部署持續交付_持續整合與持續部署之間的真正區別
- 聊聊持續測試與安全
- 持續測試效能的方法
- 如何將 InfoSec、Compliance 整合到持續交付流水線中
- SAP開源的持續整合-持續交付的解決方案
- 影響測試進度因素
- [譯] 構建、測試、分發!運用 Fastlane 與 Jenkins,完整的 iOS 持續交付指南ASTJenkinsiOS
- 聊聊持續測試的進階
- Linux 核心的持續整合測試Linux
- .netcore持續整合測試篇之測試方法改造NetCore
- 思考如何將自動化測試加入持續整合中
- 移動影響報告:可持續發展目標(SDG)
- 聊聊持續交付與軟體架構架構
- 雲原生下的DevOps與持續交付dev
- ResumeGo:LinkedIn如何影響求職者的面試機會Go求職面試
- 使用 Xcode Server 持續整合 & 打包測試XCodeServer
- 持續整合、持續交付和持續部署有什麼區別?0基礎學習linux技能Linux
- 持續交付探索與實踐(一):交付流水線的設計
- .net持續整合測試篇之Nunit引數化測試
- 可持續旅遊會如何發展?
- 快速指南:在DevOps中實現持續交付dev
- eBay透過事件溯源實現持續交付事件
- GitOps | 一種雲原生的持續交付模型Git模型
- 持續交付中的分支管理與版本控制
- 安卓 ROM 持續交付及小米雲測平臺實踐 - 劉斌安卓
- 雲效DevOps實踐-8分鐘如何快速實現持續交付dev
- 如何解決Finder持續無響應的問題
- 介面效能測試 —— Jmeter併發與持續性壓測JMeter
- 喬樑專訪——讓持續交付變為可能