導讀
先從引發的5個問題講起，再簡單回顧一下devops 簡介和興起背景 ,再從itest 測試管理團隊的視角提出應對辦法
DevOps後，測試面臨的挑戰
敏捷開發必然是迭代開發管理模式，以實現持續整合和持續交付，而不是瀑布模式下階段性介入。
問題1：持續整合首先引入的問題是整合環境的管理的問題，大公司有專門的運部門還相對好一些，小公司環境會直接摔給測試人員自己整，測試人員如果環境一直依賴開發人員，那測試人員在公司的地位當然也可想而知了。
問題2： 持續交付下，不可能做到每個迭代手動迴歸的所有case
問題3：每個迭代側重點不一樣，測試策略必然不一樣
問題4：上級管理者，需要快速知道整體測試進展，以便更好的進行風險把控
問題5：敏捷測試中，在每日站立會中，要拿測試資料說話，咋便利收集測試資料，簡單扔兩個統計圖是遠遠不夠的，需要體現出進度和工作量的資料，以及相關過程監控趨勢分析資料，資料從哪來呢?
在探討應對之道前，先簡單回顧一下 devOps
DevOps 簡介：
DevOps 是一個完整的面向IT運維的工作流，以 IT 自動化以及持續整合（CI）、持續部署（CD）為基礎，來優化程式開發、測試、系統運維等所有環節，DevOps的引入能對產品交付、測試、功能開發和維護起到意義深遠的影響。
DevOps 興起的必然趨勢：
配套技術錄下已發展成熟：微服務架構理念、容器技術使得DevOps的實施變得更加容易，計算能力提升和雲環境的發展使得快速開發的產品可以立刻獲得更廣泛的使用。
來自市場的外部需求：這世界變化太快，產品需要快速適應這些變化，並需要快速把產品互動到用用手中，團隊可以更快地得到使用者的反饋，從而進行更快地響應。而且，DevOps小步快跑的形式帶來的變化是比較小的，出現問題的偏差每次都不會太大，修復起來也會相對容易一些。
實現DevOps
硬性要求:相關支撐工具，如cd/ci 工具，自動化運維工具等
軟性需求：團隊文化 ，即敏捷開發文化；團隊技術水平
如何實現devops 不是本文要闡述的問題。
既然devOps 是必然趨勢，那開篇的問題也應意味著遲早要碰到，下面我們來看看應對之道：
問題1，測試環境管理應對之道：
採用虛擬化技術，主要是容器技術，第一可實現快速部署，第二在有限硬體資源下，可合理調配資源降底環境成本，當然大廠有大廠的玩法，小廠有小三的玩法，但都可以用，只是大廠在使用上需結合業務系統自身的特點做一定的整合或改造，比如微服務的路由，微服務閘道器，業務元件多，可能還需要用類似Kubernetes相關技術以及Namespace實現隔離;小廠是單體應用，或是數量不多的少量微服務，或是微應用，用原生的docker 就可以解決，測試人員編寫docker file 也不是難事。
Itest(流程驅動開源測試管理軟體新秀官網) 即將釋出的3.1.2 版本中，將實現環境管理功能，簡單來說，就是可以管理測試環境的docker 映象，或docker file 檔案，實現一鍵部署測試環境，當然我們這是小廠的玩法 ,大廠這裡略過，估計會有一套相關環境管理的支援系統做輔助。
環境功能已開發完成，未測試，業餘時間做，等不忙了進行測試，即將釋出的3.1.2 版本會含此功能
預發環境可理解為UAT 環境，就是線下和生產環境的軟體環境一模一樣的環境，當然硬體配置上會有差別
問題2，每個迭代不可能手動執行所有case ，應對之道：
自動化測試，首先自動化迴歸測試所有case 對應的介面，然後手動重點測試當前迭代完成的功能，再根據具體研發實現的改動，圈定一些測試包，手動執行測試包內的有例，說到這裡，肯定有同學會反問，這要做風險很大，確實是有風險，這要求開發團隊在實現時，要麼元件化，要麼微服務化，這樣新的迭代對原有功能實現的影響最小，話有說回來，既然要玩devOps ，必須這麼搞測試呀，如兩週一個迭代，每個迭代手動跑完所有CASE是不實現的，就算有這風險， 也能倒逼研發在設計時多考慮元件化，微服務化，降低偶和（中型及大廠都有這自己的企業中臺實現這些比較容易），才能快速迭代，快速響應變化，否則這是假敏捷，只是把瀑布模型拆分為幾個提交可測試特件的里程碑（雖然這也是一小點進步）。當然上述這是其中兩種主要方法，現實中還需要根據實際情況作出相應調整。
Itest(流程驅動開源測試管理軟體新秀官網) 測試包管理功能如下圖所示，3.2.1 版中獎現介面測試功能，在EXCEL中一行測試一個介面，設定上接品URL，引數，請求方式， 預期返回資料 ，如需要，還有用於認證的toekn 引數，然匯入到itest 中，itest 來執行這些介面測試，並把測試結果管理起來，也可在ITEST中設定每個介面執行測試的次數，以及執行的時間，或是按預定的時間，itest 定時去執行這個介面測試。
每個一測試包，代表了某個測試策略的一組測試用例，且可檢視執行結果
另外測試小組能力水平也不一樣，且具體到某個迭代開發團隊，測試團隊，可能都有差別，比如團隊是分散式的 可參見本一另一個貼子 分散式團隊中溝通引發的問題, itest 解決之道
不同的團隊規模，不同的迭代內容，不同的測試策略，測試流程也可能不一樣，在itest 中 流程推動缺陷流轉，不同的流程對應不同的狀態演化，反應不同管控目的，並可實時調整
問題3， 每個迭代側重點不一樣，測試策略必然不一樣，應對之道：
itest (流程驅動開源測試管理軟體新秀官網) 根據當前或即將進行的迭代的產品或是專案目標，定測試任務，以便進行整體上的把控，然後挑選出當前迭代要解決的BUG和需求（itest 後期會增加需求管理功能），以及要執行的測試用例包，組成一個完整的測試迭代；然後測試和開發人員，直接在這個迭代下處理 BUG，執行用例，填寫測試進度任務進度，填寫需求實現狀態（進度）。且可以便捷的檢視特定測試迭代的報告；對於單一某個測試包也可檢視其測試結果。
測試迭代報告
問題4：上級管理者，需要快速知道整體測試進展，以便更好的進行風險把控
上級管理者， 首要關注的是整體的測試進度，在itest 中，在一個測試迭代內可建多個測試任務，每個任務針對特定測試目的，然後以敏捷管理的看板形式展現出來，一目瞭然，沒有再實現甘特圖，我們認為，電子看板就足夠了，當進度和上級管理者預期有出入時，他可提交干預，加入更多資源，或是其他風險規避措施。測試執行中，具體的 BUG資料，用例執行資料不是不重要,他是更“微觀”資料，在管理上首先需要巨集觀方面管理資料，把測試工作納入到任務管理中，就是為了巨集觀管理目的，巨集觀和“微觀”本質上就是先整體後具體。
問題5：敏捷測試中，在每日站立會中，要拿測試資料說話，咋便利收集測試資料，簡單扔兩個統計圖是遠遠不夠的，需要體現出進度和工作量的資料，以及相關過程監控趨勢分析資料，資料從哪來呢?
itest (流程驅動開源測試管理軟體新秀官網) 的應對之道：站立會，每個人說話的時間不長，就更要求有整理好的資料說話，體現測試的專業性，在ITEST中，提供兩個資料渠道，第一通過總覽，幫助會前，作每日工作覆盤；第二通過測試度量，以27個主題，從多維度(時間、人員、工作量、團隊、缺陷和用例)、多指標過程監控，和結果彙總兩方面來量化測試工作，然後再對這些量化資料進行歸納和總結。下面僅用幾個圖例來示例，後續會有相關解讀itest 測試度量的貼子發出。比如BUG 齡期，itest 中有絕對齡期和相對齡期，一個指從BUG被發現，到被closed的 齡期,相對齡期指BUG停留在某個狀態下的齡期,測試用例的執行，不僅看用例數，更看執行成本 ，從提交|開啟|待處理|關閉|處理bug次數 趨勢中分析，整個研發團隊(含測試)工作瓶頸點在哪等等。
