如何進行DevOps平臺的測試管理設計

如何進行DevOps平臺的測試管理設計，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

前言：

IBM曾經指出，測試管理有助于DevOps通過利用數據促進持續集成和交付。本篇文章主要講述普元DevOps6.0是怎樣設計一個幫助用戶獲得他們優質產品的測試管理，普元DevOps6.0的測試管理如何做到幫助產品更快地交付。

目錄：

1.測試管理對于產品的幫助

2.什么是測試管理

3.測試管理的設計

1.測試管理對于產品的幫助

老話說的好，工欲善其事，必先利其器。對于開發團隊來說，有很多工作需要做好，測試管理不僅可以使產品實現這些效果，還可以使它們超越自我，達到最佳。IBM曾經指出，測試管理有助于產品通過利用數據促進交付。測試用例和測試數據可以輕松關聯，并分析各種結果。這些見解對于幫助開發團隊進步并不斷滿足用戶需求至關重要。

“功能測試可以證實應用程序的行為，測試數據管理能夠使研發機構去評估測試數據成功與否的變化”IBM說。通過對比前后期測試數據，無論測試是否通過，都將有助于分析測試數據結果。這種做法很好的處理了許多隱藏問題，從而能夠快速識別并解決產品的問題。

通常來說，測試已經到了軟件開發生命周期的最后階段，在保證一切工作正常的情況下留給企業做重大改變的空間非常有限。Datical指出，傳統的軟件開發手段通常會在開發周期后半程才發現缺陷，這通常迫使組織付出很大的代價來解決這些問題，并最終減緩整個開發進程。測試管理將成為產品質量的推動者，并確保產品符合利益相關者和用戶所設定的質量標準。

“QA實際上被認為是DevOps中非常關鍵的組件，甚至于DevOps強調質量保證是每個人的責任”，Datical說。但這并不意味著QA專業人員在DevOps環境中不再具有作用，而是意味著與組織中的其他所有人對質量和穩定性承擔更多的責任，QA可以并且應該扮演更具戰略意義的角色，并提供對質量保證功能的全面監督，以及建立更強大穩定的測試基礎設施。

正如意料之中的，測試管理使開發團隊和測試團隊能夠更好地協作以更快的交付和敏捷的支持，另一方面這些好處也從本質上導致了跨項目的質量的提高。

2.什么是測試管理

那是一個平平無奇的下午，我一如既往的搬運著代碼，老大突然過來和我說了有這么個需求，我當時是沒有相關概念的，老大看出我小小眼睛里的大大的疑惑，為了解決我的疑惑拉上了產品經理開了數次的討論會，給我說明了各種使用場景，我終于是了解了要做的是什么了，原來是測試管理。

那為什么DevOps要做測試管理呢？

獻上百度百科對于測試管理的介紹：就是把測試管理作為一個系統，對組成這個系統的各個過程加以識別和管理，以實現設定的系統目標。同時要使這些過程協同作用、互相促進，從而使它們的總體作用大于各過程作用之和。其主要目的是在設定的條件限制下，盡可能發現和排除產品缺陷。

美國質量保證研究所對軟件測試的研究結果表明:越早發現軟件中存在的問題，開發成本就越低;在編碼后修改軟件缺陷的成本是編碼前的10倍，在產品交付后修改軟件缺陷的成本是交付前的10倍;軟件質量越高，軟件發布后的維護成本越低。

看到這里就不應該問為什么做了，而是應該反問了，這么猴賽雷的能力為什么不做呢？

但是頭疼的事情來了，怎么設計才能達到效果？

3.測試管理的設計

我們可以將需求拆分成3個部分：測試用例、測試計劃、測試報告

1、測試用例

解析需求的過程和目的，明確要達到的效果，對操作過程和預期結果進行描述，這個過程將輸出為測試用例。那么怎么統一管理測試用例呢？DevOps的用例庫會對測試用例進行統一的管理。做到這里肯定還是不夠的，我們需要再對測試用例進行更詳細的分類，這里就使用了分組對相同類型或者是相同功能的測試用例進行分類，這里當然是不禁止套娃的，樹形分組可以把測試用例分類成你想要的那樣。

那么用例庫是不是就只能進行測試用例的操作或者管理呢？或者說僅僅增刪改查就能滿足用戶的需要了嗎？當然是不夠的，用戶可以在用例庫中對相關數據進行查看，測試用例將與不同測試計劃中的該條用例執行結果關聯，可對多次執行的結果進行分析和總結。為了追溯執行該條用例產生的缺陷，測試用例也與不同測試計劃中的該條用例產生的缺陷進行了關聯，可以隨時關注到所關聯的缺陷的狀態。

另外有一個使用場景需要考慮到，用戶如果要刪除掉某個已有執行結果的測試用例，那這個操作是不能影響引入該用例的已完成和歸檔的測試計劃，我們可以將該測試用例標記為已廢棄狀態。同樣的，引入該用例的未執行和已執行中的測試計劃中，該條用例也會被標記，可以讓測試人員根據具體需要決定是否要將此用例移除。

2、測試計劃

確定各測試階段的計劃和目標，明確要完成的測試活動，評估完成活動所需要的時間，進行活動安排和分配，這個過程將輸出為測試計劃。

什么叫各測試階段的計劃和目標？舉個栗子，比如驗證基本功能，目標就是確定產品基本功能可用。明確要完成的測試活動，接著上面拋來的栗子，要驗證基本功能所要執行的測試用例就是要完成的活動。評估時間的目的是對測試計劃執行的進度進行把控，可以幫助測試人員更好的利用和分配時間。活動安排和分配能對測試計劃的執行進行更細化的管理。如果是測試用例較多、時間比較緊張的計劃，不可能將一整個測試計劃的執行都讓一個測試伙伴去做，這時候就要根據測試伙伴們的時間分配任務了。

魯迅曾說，“沒有測試用例的測試計劃不是一個好的測試計劃”。

當創建測試計劃時，用戶選擇需要的測試用例導入，為了方便管理和查看，導入測試用例時也會帶入用例在用例庫的分組信息，要注意的是在計劃中修改用例的信息不應該對用例庫中的該測試用例產生影響。一個好的測試計劃不僅僅得有用例，用戶還會關心這些用例在用例庫里的比例，也就是用例庫覆蓋率。當然除了這個還必須要對測試計劃的執行過程進行關注，執行成功了多少，失敗了多少，還有多少關聯的任務還未解決，這都是用戶比較關注的問題，我們需要對這些數據進行統計。

測試計劃開始執行時，會進入測試執行頁，測試人員根據測試用例的步驟描述執行測試，測試結果與描述的預期結果進行比對，對比對的結果進行記錄，如果測試該功能產生了bug，直接在測試執行頁產生缺陷任務項，若存在相同的已存在的bug任務項，測試人員可更改相應的任務項的狀態。

這里也需要對測試的完成狀態進行把控，若計劃沒有執行完全，或者還有未執行的測試用例時，用戶要變更此計劃的狀態，要對用戶進行提醒，因為計劃的狀態“未執行->執行中->已完成->已歸檔”是不可逆的。測試執行時，項目管理員需要查看測試計劃的產生的缺陷的情況，那我們就需要提供查看此測試計劃關聯的缺陷項，測試人員可以對已解決的缺陷項關聯的測試用例進行驗證執行，可根據執行結果判斷缺陷是否已被解決，解決就關閉任務項，未解決就重新打開。

3、測試報告 

根據測試用例運行程序，將獲得的運行結果與預期結果進行比較和分析，記錄當前測試結果，記錄、跟蹤和管理產品缺陷，最終得到測試報告。

根據用戶關心的數據，測試報告的設計應該包含測試執行報告、測試結果報告、關聯缺陷報告。

測試執行報告應該從多個方面反映出測試計劃的執行過程，要反映計劃整體的進度，就需要從3個角度去看：從時間角度，計劃已執行的天數和評估的時間進行對比；從結果的角度，要看計劃中測試用例執行了多少，未通過的數量有多少；從關聯缺陷的角度，是否還有未解決的缺陷。

測試結果報告以計劃為單位展示測試用例執行結果數據，考慮到用戶會有查看匯總數據的需求，設計時應該提供匯總多個計劃中測試用例執行結果數據的。

測試小伙伴們比較關心的數據就是提交的缺陷改了沒，還有多少缺陷需要驗證的，缺陷報告會統計這些數據。測試小伙伴們在測試過程中提交關聯缺陷，缺陷報告會以直觀的柱狀圖展示自己提交的缺陷的狀態，幫助測試小伙伴們了解自己相關的工作量。

就寫到這里了，當然還有些不足的地方，比如說缺少了審批的環節、測試報告不夠全面、各模塊的關聯性是不是就足夠了？這些問題的解決會在之后的版本里推出，大家有什么想法可以在評論區討論哦！

最后的最后，辟謠！

“那句話我沒說過，是他瞎扯”  ————  魯迅

關于如何進行DevOps平臺的測試管理設計問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。