質量管理體系之測試流程

引言

今天分享一下個人對於質量管理流程的看法，也是基於CMMI，看看這裡面有哪些東西可以為我們所用。

從員工（特別是從我們普通測試人員）角度來說，研究CMMI有哪些好處呢？

有「正規的」、「完善的」測試流程和質量管理流程可以借鑒。特別是對一些「項目管理水平低下且流程混亂」的企業工作的同學來說尤為重要。很多企業在面試時都會關注前一家單位的工作流程，研究CMMI能在面試時加分，應聘測試經理大都需要具備質量管理經驗。

有大量現成的項目資料可以借鑒。認證CMMI時，諮詢老師會提供一些其他單位的項目資料（特別是測試用例），這對於為文檔模板犯愁的同學、對疑惑用例該怎麼寫的同學幫助會比較大。

提升管理能力。管理的本質就是解決問題，研究CMMI後會發現自己解決問題時的思路更開闊，能有效的提升解決問題的能力。

提升職場軟實力。比如可以做出既美觀又實用的BUG統計報表。

既然有這麼多益處，為什麼又有那麼多人反感CMMI呢？覺得整天寫文檔，然後寫出來以後還沒什麼實際用處，吃力不討好。

齊白石有句話「學我者生，像我者死」。流程改造最重要的就是要符合公司的實情，如果因為CMMI裡面的流程「科學、規範」就貿然套用，那最後的結果必然不樂觀。其實CMMI本身也提倡要根據企業的實情來進行裁剪，換言之，我們要取其精華去其糟粕。

CMMI強調計劃、監控、標準、可度量。

計劃：「凡事預則立不預則廢」，這是普天皆知的道理。但現實是每個人做計劃的能力是不一樣的。如果想成為一個特別會做計劃的人，可以去研究CMMI。

監控：這主要是從管理角度來說的。我曾經有個下屬，彙報工作說三天完成了一個新需求的用例編寫，但我檢查後發現就增加了兩條用例。也曾有一個下屬，負責一個模塊4個月了，我卻發現還有大量的主流程相關的bug沒有發現。

標準：做事情標準很重要。舉個例子，什麼算是需求了解清楚了？安排一個下屬去參加需求評審，回來跟我說需求了解清楚了。然後我問了幾個問題卻都回答不上來。再比如說測試通過的標準是什麼？版本送測的標準是什麼？....這些都應該有一些約定。也可能有人說，自己公司編寫了很多標準文檔，但平時根本用不上，那些文檔有用嗎？我想說這根法律一個道理，我們大多數時候也用不到法律，標準的作用是在需要用的時候有據可查。一直用不上，說明你們做的還不錯啊（也可能是標準不合理）

度量：CMMI規定，要有專人（即QA，我們測試人員是QC）負責標準的檢查。這樣做有有個很明顯的好處：減少一些常規問題的扯皮和溝通成本。比如說很多人都經歷過需求和設計提供的不明確的問題，這個時候我們測試人員去說人家工作沒做好容易招人記恨，不說吧影響自己工作。這個時候QA就能很好的承擔起這個職責，督促產品和架構師提供更清晰準確的需求和設計。

總而言之，多吸取CMMI在計劃、監控、標準、可度量方面的思想，但不要盲目套用。

CMMI測試流程

下圖是CMMI中定義的測試流程：

01

—

測試計劃

CMMI中定義了《總體測試計劃》《單元測試計劃》《集成集成計劃》《系統測試計劃》《驗收測試計劃》。裡面的內容雖然不一樣，不過都是圍繞著5W1H的原則去說。有興趣的朋友可以看看對應的模塊。

02

—

編製測試需求

有的單位里接到需求後，就開始著手寫測試用例。當需求比較複雜時，這樣的做法容易帶來新問題，比如不利於評審（效果差）。

CMMI中強調的一個文檔是《需求跟蹤矩陣》（如下圖）：CMMI期望通過制定矩陣跟蹤表，達到需求的在詳設和編寫用例時被完全覆蓋。但生產過程中，需求很難在最初就完全明確下來，且會一直變化。

我們工作中常用的做法是用思維導圖把測試點整理出來。雖然雖然在這一環節上多花了時間，但總體時間成本是會下降。

03

—

編寫測試用例

CMMI中將用例分為功能測試用例、非功能測試用例（非功能測試用例包括性能測試用例、壓力測試用例、圖形界面測試用例、資料庫測試用例等）。

我們可以將非功能測試用例整理成為「公共測試用例庫」，以後再寫用例時，就不用花很多時間去編寫比如圖形界面相關的用例了。

04

—

單元測試

單元測試基本上都是開發人員的工作，他們會做一下主流程、格式化、數據驗證、異常提交等方面的測試。

很多測試同學聽過這句話「程序員應避免測試自己編寫的程序」。我發現有一些測試同學對這句話存在誤解，認為研發人員由於「定勢思維」會想當然的認為自己開發出來的是沒有問題的，發現不了問題。其實從我合作過的研發來看，大多數開發對於業務的正常場景、異常場景、需求改動後的影響範圍都是大概清楚的，也就是說可以滿足送測標準。 而且團隊中常常每個開發單獨負責一個模塊，這意味著他們對其他人的模塊去從邏輯上驗證是有困難的。

個人對這句話的理解是，互相檢查代碼，一方面是開發經驗豐富的程序員可以幫忙優化實現方法，一方面也是避免程序員忘記備註、或者命名方式方式不規範等問題。

05

—

集成測試

集成測試在大多數企業、測試團隊、項目中都會做。某些情況下，我們也會叫它「冒煙測試」。

經常有面試官會問集成測試做什麼工作，跟系統測試有什麼區別？這裡列一下集成測試的目的和工作內容：

集成測試目的是確保各單元模塊組合在一起後能夠滿足設計要求運行，並確保增量組裝的構件正確。它所測試的內容包括單元間的介面以及集成後的功能，對以前的集成進行回歸測試。

集成測試主要完成：

對模塊和子系統的連接進行測試，確保各程序模塊之間無錯誤連接

驗證整個軟體系統或子系統的輸入/輸出處理是否達到設計要求

驗證軟體系統或子系統（業務方面的）正常處理能力和異常處理能力

驗證是否達到產品需求，是否遵循系統設計

集成測試用例

在某些行業比如銀行，集成測試用例可能是由開發人員來編寫（也是他們執行）。他們會在完成集成測試之後送測，送測的文檔中包括《集成（聯調）測試用例》、《集成測試報告》《送測說明》。在《集成測試報告》中甚至會添加測試通過的截圖。 在送測說明中又會描述本次修改的內容、修改的原因、以及本次修改的影響範圍。

06

—

系統測試

跟集成測試的區別，就是還需要做兼容性測試、性能測試、安全測試、發布測試等等。

07

—

缺陷管理

缺陷管理的最終目標是最大限度地減少缺陷的出現率，從而提高軟體產品的質量。細分為：

從缺陷發生到結束的全生命周期進行跟蹤管理，儘可能發現所有的缺陷，確保每個被發現的缺陷都能夠被解決；

收集缺陷數據並根據缺陷趨勢圖識別測試過程的階段；缺陷趨勢圖是確定測試過程是否結束的重要依據；

在已收集到的缺陷數據的基礎上進行統計分析。總結缺陷出現的原因、類型和規律，採取相應措施避免該類型缺陷再次出現，並在開發過程的早期階段予以確定，起到缺陷預防的作用，並作為組織的過程財富。

缺陷分析

典型缺陷統計：通過缺陷的數據分析，總結缺陷出現的原因、類型和規律，採取相應措施避免該類型缺陷再次出現，提高產品質量。

線上bug統計：針對線上bug，分析bug原因，記錄修改過程，並從測試角度分析為什麼會漏測？以前怎麼測試的？以後怎麼改進測試的方式？

產品缺陷趨勢圖：統計項目組階段缺陷的趨勢圖，用於分析產品的質量。

問題關閉情況圖：

O/C圖：分析open和closed狀態的bug的趨勢

未完待續......

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！