devops 下測試組織管理面臨的挑戰及應對 分佈式團隊中溝通引起的問題, itest 解決之道

    導讀

    先從引起的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次數 趨勢中分析，整個研發團隊(含測試)工做瓶頸點在哪等等。

    itest ,一款匯聚10年經驗，流程驅動測試的開源的測試管理軟件，是咱們測試人本身開發測試管理軟件，體現咱們對測試的情懷，是最懂測試人的開源測試管理軟件新秀  ；Itest 開源團隊成員由來自對軟件測試有情懷，熱衷於開源，又熱心傳播分享咱們測試理念的一羣人組成。也可在線體驗，也有一鍵安裝包， https://itest.work/rsf/site/itest/product/index.html 

 

本文借鑑了下面PPT的管理理念，itest 是PPT中闡述內容加devops 思想的落地實現產品

項目管理在測試管理中的應用 

 

 附itest  v3.1.1 上敏捷測試功能模型，後續隨着新版本發佈，會加入新特性，如接口，環境，需求，