1 全過程的軟件測試圖解
傳統的軟件測試，開發人員完成任務以後，最後交付給測試人員，這種模式下，測試人員不能及早發現需求階段的缺陷，同時測試工做的開展也滯後了，產品質量得不到有效的過程控制和分析，整體進度可能會因爲返工問題形成拖延。html
什麼是全程軟件測試，也能夠說全面的軟件測試，以下圖所示：web
在整個SDLC中，三條角色主線和四個階段。編程
三條角色主線：開發、QA、測試，文中主要講解測試。運維
四個階段：需求、開發、發佈、平常運營。編程語言
簡單來講能夠概括爲下圖所示：ide
測試人員貫穿這四個階段，開展測試活動，試實踐活動簡單描述以下圖所示：工具
每一個階段也有開發人員對應的活動，以及QA人員對應的活動。post
對於產品而言，每次版本迭代，都會經歷：需求、開發、發佈，最後推向平常運營，發佈階段虛線指向的需求階段和平常運營階段，並非一個終止階段，而是不斷迭代的過程。單元測試
那測試人員是如何開展全程軟件測試活動的呢？測試
2 需求階段測試
在需求階段，開發人員、測試人員、QA人員主要作的事情，以下表所示：
| 階段 |
開發人員 |
測試人員 |
QA人員 |
| 需求階段 |
· 用戶故事分析 · 用戶故事估時 |
· 參與用戶故事分析、挖掘故事含混性 · 參考經驗庫質疑開發的時間估算 |
· 保證確認需求活動符合需求管理過程 · 管理用戶故事評審 · 管理需求變動 |
做爲測試人員的主要實踐以下：
參與用戶故事分析、挖掘故事含混性
在sprint會議上，對用戶故事進行分析，檢查功能性需求和非功能性需求是否描述清晰，其中能夠將非功能性需求做爲驗收要點，例如一個用戶故事：
「客戶但願提升響應時間」
測試人員應當協助開發人員消除故事的含混性：提升什麼的響應時間和響應時間爲多少？能夠建議修改成：
「客戶信息普通查詢返回結果的響應時間爲5s內」
說明在「客戶信息」模塊，進行「普通查詢」操做，返回結果的時間在5s內，這個陳述句已經清晰表達了，也達到了消除含混性的效果。一樣，測試人員能夠編寫提升查詢效率的用戶故事：
「客戶在信息查詢模塊，進行普通查詢，可以在5s內返回結果」
「備註：5s爲非功能性需求，也是驗收要點」
參考經驗庫質疑開發的時間估算
在sprint會議上，開發人員根據經驗出牌（團隊本身定義的規則，用撲克牌）估算時間，當給出最終結果的時候，測試人員應當對其進行質疑。測試人員借鑑歷史經驗庫：開發人員在某方面的技能如何、該模塊曾經產生過何種程度的缺陷、修復缺陷的消耗時間是多少等等，綜合考慮，提出疑問，讓開發估算最終的時間，儘量考慮這些因素。固然，測試人員可以質疑的其中一個前提是：測試人員具有相關開發經驗。
小結：在需求階段，測試人員要發揮做用，減小含混性需求引入到開發階段、同時協助開發作好時間估算。
3 開發階段測試
在開發階段，開發人員、測試人員、QA人員主要作的事情，以下表所示：
| 階段 |
開發人員 |
測試人員 |
QA人員 |
| 需求階段 |
· 用戶故事分析 · 用戶故事估時 |
· 參與用戶故事分析、挖掘故事含混性 · 參考經驗庫質疑開發的時間估算 |
· 保證確認需求活動符合需求管理過程 · 管理用戶故事評審 · 管理需求變動 |
做爲測試人員的主要實踐以下：
功能要點確認
Xmind是一個很是好用的腦圖工具，一般在開發人員進行編碼前，測試人員會針對需求處理的用戶故事，與開發人員進行確認，修正理解誤差，確保需求理解一致。
圖-5-腦圖用例模板
測試用例設計
測試人員主要設計測試故事點，使用DSL(Domain Specific language)，對測試用例進行描述，包括三個基本要素：
Feature、Scenario、Example，補充要素：xmind、Requirement。
Feature：把測試分類到某個模塊，並對這個特性自己的業務目的進行相關描述，帶進業 務目標，傳遞業務知識。
Scenario：標明這個Feature的測試場景，可使用文字描述步驟，或者使用xmind腦圖
描述，場景中的數據使用Examples中列出的。
Example：引出具體的數據表格把用到的數據都展現出來，避免相同步驟由於測試數據 的變化而重複若干遍形成冗餘。
Xmind：腦圖文件，展現測試故事點
Requirement：關聯需求管理系統的需求id。
隨着敏捷愈來愈廣爲人知，敏捷測試也更多受到了你們的關注。在這裏，我想談一下我在敏捷項目中遇到的一個自動化測試相關問題以及咱們如何藉助DSL領域專用語言來解決它。
對敏捷軟件開發方法有必定了解的人都知道，敏捷軟件開發過程是一個迭代式交付的過程。每一個迭代至關於比較小型的交付週期。那麼，爲了配合頻繁的軟件交付，敏捷測試相對於傳統測試必需要作相應的調整。這也致使了敏捷項目中的測試面臨幾個特有的挑戰：
- 頻繁的迴歸測試以確保每一個迭代的成果都是可交付的
- 讓整個開發團隊參與到測試活動中以縮短質量信息的反饋週期
- 讓客戶參與到測試活動中來幫助提升測試的有效性
自動化測試在應對頻繁的迴歸測試這個挑戰上起着很是關鍵的做用。自動化測試作很差，團隊最終會被每一個迭代都會增長的迴歸測試工做量壓垮。
我經歷過的一個團隊，在這個團隊中，你們很早就意識到了自動化測試的重要性，在自動化測試上的投入竭盡全力。咱們相信自動化功能測試增長到足夠多的時候，它就能指導手動迴歸測試，保證整個交付過程順利進行。
的確，自動化測試剛開始進行的時候，咱們收益頗多。每增長一個自動化測試，咱們就能減小一些手動測試。自動化測試讓咱們咱們有比較充裕的時間來手動測試那些尚未來得及自動化的、難以被自動化的功能點上，並且還能有時間和精力作探索性測試。這個結果讓團隊感到生活很美好，也讓咱們對自動化測試堅信不疑
然而好景不長，隨着自動化測試的不斷增長，咱們會面臨這樣一些問題：
- 自動化測試是圍繞着實現細節展開的。隨着數量的增多，業務的輪廓很容易迷失在細節中。
- 在功能級別喪失了對測試的追蹤。因爲測試人員沒法具體知曉那些測試案例被自動化測試覆蓋。每次迴歸的時候，團隊都須要迴歸整個測試組。
因而，咱們的手動測試愈來愈可貴到自動化測試的幫助。它開始成了項目的雞肋。測試代碼閱讀困難、維護困難以及測試結果的看起來也很費勁。這直接致使了咱們不只要投入至關的時間來增長自動化測試，也要投入很多時間來閱讀並利用測試結果。
因而咱們開始從新審視自動化測試的作法，繼續摸索更好的方式。
很快，咱們發現「可以跑起來」並非好的自動化測試僅需的特性。讓咱們經過一段測試代碼來看一下具體怎麼回事。
selenium.open(「/」) selenium.type(「id=username」, 「myname」) selenium.type(「id=password」, 「mypassword」) selenium.click(「id=btnLogin」) selenium.waitForPageToLoad(30000) assertTrue(selenium.isTextPresent(「Welcome to our website!」))
這個測試中，咱們首先打開了一個頁面，在頁面中尋找一個id爲username的輸入框，輸入「myname」，而後再尋找一個id爲password的輸入框，輸入「password」，而後點擊一個id爲btnLogin的按鈕，等待30秒之後，斷言頁面應該出現的文字。
咱們能夠看到，這個測試的實現很完整的描述了測試的操做過程，是一個面向步驟而不是目的的描述。固然，稍加分析，咱們也能夠看出來這個測試的目的是測用戶登陸成功系統。
可是，想象當咱們有不少這樣面向步驟來描述的測試時，要從中抽離出被無數細碎的操做步驟所淹沒的測試意圖，並把測試的結果利用起來，其實並無那麼直觀。並且，若是在測試中出現了錯誤，對於問題的具體功能點的定位也不是那麼容易。
與此同時，並非團隊中全部的成員都有能力閱讀和編寫這樣的測試。這無疑下降了團隊成員對於自動化測試的參與度。對於客戶，自動化測試更是一個黑盒子，作了什麼，沒作什麼，基本上搞不清，更談不上參與到自動化測試中，幫助提升測試的有效性。
種種情況，究其緣由就是測試可讀性太差，測試意圖不夠明顯。可運行而且容易讀的測試纔是好的自動化測試。這樣纔可以保證任什麼時候候，咱們不會喪失對於測試案例的跟蹤與管理。測試人員隨時均可以經過快速閱讀測試，瞭解那些功能已經被自動化測試覆蓋，有效規劃手工測試的工做量。
怎麼提升測試的可讀性呢？
咱們的解決辦法是DSL領域專用語言。
什麼是領域專用語言？在馬丁大叔的博客裏有比較詳細的描述。大體來講，領域專用語言就是針對某個領域的特定目的編程語言。不像Java、C#等通用語言，能夠解決任何領域的問題。領域專用語言經過本身獨特的語法結構來描述更接近於專業領域語言的業務。
讓測試的描述可以接近被測系統的領域語言、使測試意圖獲得清晰表達就是咱們想要獲得的效果。DSL正好可以幫咱們實現。
讓咱們再看看以前的那段代碼：
selenium.open(「/」) selenium.type(「id=username」, 「myname」) selenium.type(「id=password」, 「mypassword」) selenium.click(「id=btnLogin」) selenium.waitForPageToLoad(30000) assertTrue(selenium.isTextPresent(「Welcome to our website!」))
因爲使用的是通用語言，在咱們這個特定的使用場景中顯得過於細節化、過程化，不能清晰表達測試意圖。
換成DSL，咱們的測試就能夠直接用驗收標準的語言來描述以下：
Given I am on login page When I provide username and password Then I can enter the system
這樣測試的內容就直觀多了，還包含了一些業務信息，讓咱們知道這個是在測試一個登陸的場景，而不是任意的輸入信息，兼顧傳遞了業務知識的職責。至於這些DSL背後可以運行的代碼，也被隱藏起來。若是是不可以閱讀原來那樣的測試代碼的人（無論是需求分析人員仍是客戶甚至一些對自動化代碼關注比較少的測試人員）想要加入到自動化測試活動中進行反饋，就不會被DSL背後的代碼帶來的「噪音」所影響。
固然，在咱們的現實應用場景中，這個需求沒有那麼簡單，咱們的驗收標準還會考慮不一樣的數據好比輸入不一樣組合的用戶名密碼：
Given I am on login page When I provide ‘david’ and ‘davidpassword’ Then I can enter the system Given I am on login page When I provide ‘kate’ and ‘kate_p@ssword’ Then I can enter the system
以及更多的測試數據。
那麼這種狀況下，僅僅是比較通俗的語言仍是不夠的，畢竟測試數量在那擺着。若是測試數量不能減小，維護起來仍然很麻煩。打個比方，若是系統的實現變成了每次都要輸入用戶名、密碼和一個隨機驗證碼，咱們就須要在咱們的自動化測試中修改多處，比較繁瑣。所以，咱們須要在可讀性比較好的天然語言描述的測試上，把它的抽象層次再提升一點。
幸運的是，咱們當時選擇的DSL工具是cucumber，它除了提供了幾個測試的描述層次：Feature，Scenario，Steps，還提供了很是好的一種組織方式—數據表。
這樣，咱們的這個自動化測試就能夠把以前的那個登陸的功能根據特性、場景總結和具體的步驟分離開來，清晰的分層，同時利用數據表咱們的測試精簡成一系列被重複屢次但輸入數據有所變化的操做過程，以下：
Feature: authentication In order to have personalized information I want to access my account by providing authentication information So that the system can know who I am Scenario Outline: login successfully Given I am on login page When I provide ‘<username>’ and ‘<password>’ Then I can enter the system Examples: |username |password | |david |davidpass | |kate |kate_p@ssword|
測試這下看起來就更清爽了。首先，用Feature關鍵字，咱們把測試分類到login這個大特性下的，並對這個特性自己的業務目的進行相關描述，帶進業務目標，傳遞業務知識；而後用Scenario關鍵字來提升挈領的標明咱們這個測試場景中作的是測試登陸成功的狀況，而且把步驟都寫出來；最後，咱們用Examples關鍵字引出具體的數據表格把用到的數據都展現出來，避免咱們的相同步驟由於測試數據的變化而重複若干遍形成冗餘。萬一碰上了需求的變化，要求同時提供用戶名、密碼和驗證碼，那咱們的測試也只須要改動較少的地方就足夠了。
更棒的是，用了這種數據表的方式，整個團隊的協做效率提升了。對於寫代碼沒有那麼順暢的測試人員來講，增長自動化測試也就是增長更多測試數據，填充到數據表裏就能夠了。
就這樣，咱們用DSL實現了可執行的可讀性高的文檔。幫助了迴歸測試，下降了文檔維護難度，也促進團隊成員利用測試來傳遞知識的積極性，讓更多人可以參與到測試中。
用例評審
主要是堅持同行評審的原則，主要在測試組內進行，負責該任務的開發人員也會參與，簡單來講就是對測試用例進行查漏補缺的工做。
測試探索
進行了「功能要點確認」和「用例評審」後，爲了保證測試場景的覆蓋率，須要再進行測試探索。在開發人員完成雛形以後，使用探索式測試的策略，對功能基本流程進行有目的的快速走查，挖掘功能不肯定的地方和補充測試場景，避免不肯定的因素拖延到開發階段後期，形成返工。
其中：功能測試、Bug Tracking、迴歸測試、系統測試、驗收測試都是平常測試工做所需環節。
燃盡圖發佈
另外，測試人員還有一項重要工做，每日發佈燃盡圖，讓團隊瞭解當前進度狀況，總結問題
所在，尋求耗時超過預期時間任務的解決辦法。
圖-6-燃盡圖
圖形特色：
1）剩餘工時在計劃基準上方，表明進度有所延遲，應抓緊進度；
發現此類問題，須要分析總結，原則是保證交付時間，對相應任務進行調整，擁抱變化，發現任務粒度太大，該拆分的繼續拆分；對於重構須要慎重，不要過分深刻重構，給測試帶來額外工做量，影響整個進度，對於整個版本而言，只有開發、測試在承諾的時間內完成任務，纔是真正完成，僅僅開發完成交付算不上成功。
2）剩餘工時在計劃基準接近，表明進展良好，繼續保持；
此時也須要查看在這種進度下，優先級高的任務是否獲得時間保證，而不是由於處理完簡單任務才使得燃盡圖長的好看。每每有些開發人員，喜歡挑着任務來作，把簡單易作、優先級的任務先完成了，由於這些總在預期內可以完成，因此前期燃盡圖的趨勢看起來沒有問題。
缺陷經驗庫
每一個團隊都存在開發/測試新人和開發/測試老人，當測試人員與開發新人進行需求確認的時候，還須要進行缺陷經驗教訓的提醒，避免多走彎路。
提高開發自測質量
測試人員能夠提供相關checklist（你們能夠根據原做者提供的修改成符合團隊的）幫助開發人員在編碼過程當中關注開發自測的要點，從而提高質量。
圖-8-web軟件測試checklist
持續集成
利用持續集成（Jenkins）平臺，作到快速的構建開發代碼，自動的單元測試化，來提升開發代碼的效率和質量。
負責單元測試的開發人員，會收到失敗構建的郵件；
負責集成測試的開發人員，會收到失敗構建的郵件；
負責自動化測試（Selenium）的測試負責人員，會收到失敗構建的郵件；
這種方式，確保單元測試、集成測試、自動化測試，有相關人員關注和維護。
圖-9-持續集成
Sonar反饋
Sonar is an open platform to manage code quality. As such, it covers the 7 axes of code quality。
sonar分析結果
測試人員主要反饋問題以下：
Code coverage：團隊要求代碼覆蓋率在80%以上；
Test success：團隊要求測試成功率在100%；
Duplications：團隊要求代碼重複率在10%如下；
Violations：團隊要求Major類別的代碼規則缺陷在20如下；
開發團隊必須保證每一個環境的質量目標，纔可以保證整個的質量目標。
小結：
測試人員與開發人員永遠不是敵對關係，而是協助關係，確切來講是質量天枰的兩邊，任何一邊的工做沒有作好，都會失去平衡。
4 發佈階段測試
在發佈階段，開發人員、測試人員、QA人員主要作的事情，以下表所示：
| 階段 |
開發人員 |
測試人員 |
QA人員 |
| 發佈階段 |
· 上線申請 · 上線部署 · 服務監控 |
· 測試報告 · 線上功能檢查 |
· 管理評審活動 · 管理文檔產物 |
做爲測試人員的主要實踐以下：
測試報告
完成驗收測試，提供測試報告，給出測試數據度量，例如：
- 測試發現缺陷總數：測試過程當中產生的去除狀態爲「無效」、「不用改」的缺陷數目。
- 測試發現嚴重缺陷數：測試過程當中產生的並去除狀態爲「無效」、「不用改」的、且嚴重性爲「Major」和「Critical」的缺陷總數目。
- 測試發現缺陷修復數：測試過程當中產生的狀態爲「已關閉」的缺陷數量；
- 未解決缺陷數：去除狀態爲「無效」、「不用改」、「關閉」的缺陷總數。
- 缺陷修復率：（測試發現缺陷的修復數）÷（測試發現缺陷總數）×100％
- 嚴重缺陷率：（測試發現嚴重缺陷數）÷（測試發現缺陷總數）×100％
- 嚴重缺陷修復率：（已修復的嚴重缺陷數）÷（測試發現嚴重缺陷數）×100％
- 測試需求覆蓋率：已測試需求個數÷需求總數×100%
缺陷統計分析報告
另外，測試人員還有一項重要工做，對當前版本的缺陷進行統計分析：
按缺陷級別統計：
| Critical |
Major |
Medium |
Minor |
總計 |
|
| 首頁 |
0 |
0 |
1 |
0 |
1 |
| 模塊一 |
0 |
0 |
0 |
2 |
2 |
| 模塊二 |
0 |
1 |
2 |
10 |
13 |
| 模塊三 |
0 |
0 |
1 |
4 |
5 |
| 模塊四 |
0 |
0 |
1 |
2 |
3 |
| 模塊五 |
0 |
0 |
3 |
2 |
5 |
| 模塊六 |
0 |
1 |
0 |
1 |
2 |
| 模塊七 |
0 |
2 |
0 |
6 |
8 |
| sonar |
0 |
1 |
2 |
0 |
3 |
| 總計 |
0 |
5 |
10 |
27 |
圖-11-缺陷統計
按缺陷來源統計：
| 開發1 |
開發2 |
開發3 |
開發4 |
開發5 |
遺留 |
|
| Critical |
0 |
0 |
0 |
0 |
0 |
0 |
| Major |
1 |
2 |
0 |
0 |
0 |
2 |
| Medium |
1 |
7 |
0 |
1 |
0 |
1 |
| Minor |
1 |
7 |
4 |
6 |
3 |
6 |
| 總計 |
3 |
16 |
4 |
7 |
3 |
9 |
按缺陷狀態統計：
| 缺陷總數 |
已關閉缺陷數 |
遺留 |
缺陷修復率 |
嚴重缺陷數 |
嚴重缺陷率 |
已關閉嚴重缺陷數 |
嚴重缺陷修復率 |
| 42 |
40 |
2 |
95% |
5 |
12% |
5 |
100% |
測試進度和問題分析：
1. 從BUG的嚴重級別分佈來看，Major級別以上的BUG佔12%，佔的比重不高，說明大部分的主要功能已經實現了；
2. 其中在sonar定義級別的缺陷，主要集中在代碼規範和單元測試覆蓋率，說明代碼質量有待提升；
3. 版本測試的前期時間較充足，後期隨着開發提交完成的功能點增多，BUG數量增多，剩餘測試時間變得緊張；
4. 在版本測試期間，發現測試環境存在一次代碼被覆蓋、兩次因開發人員操做失誤影響測試執行的狀況；
小結：
測試人員應當持續反饋、改進、總結每一個版本發生的問題（無論是缺陷，仍是過程當中出現的），並對缺陷進行分析，總結出一些規律，幫助開發人員創建良好的習慣，改進代碼的質量。
5 平常運營階段測試
在平常運營階段，開發人員、測試人員、QA人員主要作的事情，以下表所示：
| 階段 |
開發人員 |
測試人員 |
QA人員 |
| 平常運營 |
生產故障登記 |
· 版本問題反饋和改進提議 · 生產故障分析 |
管理平常運營活動 |
平常運營階段，並非終止階段，即使需求、開發、發佈階段暫停活動，只要產品提供服務，平常運營都存在着。
做爲測試人員的主要實踐以下：
版本問題反饋和改進提議
對平常運營發生的問題，總結反饋，提出改進建議，而且跟蹤實施。
生產故障分析
協助開發排查生產故障，避免測試場景的遺漏。
6 人力資源
軟件測試並非保證產品質量的最後一道防線，測試人員也不是，測試人員的工做徹底能夠由更加資深的開發人員來完成，不過現實老是殘酷的，目前測試與開發的比例爲：1:3，在成熟的團隊是這樣子，另一些還在持續改進的團隊，因爲資源不足，可能去到1:7。開發人員在至關長的一段時間內不可能徹底替代測試人員，有個關鍵要素：思惟方式不一樣，有句古話來形容：江山易改本性難移。當開發人員的思惟方式改變的時候，那就成爲測試人員了，倒不如把測試人員獨立出來更好，而且培養給開發人員必定的測試素養，這個對保證產品質量都是有幫助的。
全程軟件測試實踐，強調的是貫穿每一個階段的測試活動，不管是開發、仍是測試，要理解雙方的活動價值，何時該作什麼事情，什麼事情該作到什麼程度纔算好，保證每一個環節的質量，纔可以保證產品的全程質量，另外產品質量不是測試出來的，而是構建過程當中沉澱下來的，開發人員的素養、測試人員的素養、以及團隊對開發測試過程的重視程度，決定了產品質量。產品質量就如同一塊蛋糕，應當切分爲小塊，落實到每一個人手裏，讓每一個人嚐到甜頭，擔當起來。
7 TQM(全面質量管理) in Software
這是一個延伸與關聯，過程以下:
TQM是以產品質量爲核心，創建起一套科學嚴密高效的質量體系，以提供知足用戶須要的產品的所有活動.
在軟件業，軟件質量得不到提升主要緣由在於質量觀念的缺少，而將全面質量管理的思想運用於軟件業，是提升軟件產品質量、獲取競爭優點的有效手段。CMM不但對於指導過程改進是一項很好的工具，並且把全面質量管理概念應用到軟件上，實現從需求管理到項目計劃、項目控制、軟件獲取、質量保證、配置管理的軟件過程全面質量管理。CMM的思想是一切從顧客需求出發，從全組織層面上實施過程質量管理，正符合了TQM的基本原則。所以，它的意義不只僅是對軟件開發的過程進程控制，最關鍵的它仍是一種高效的管理方法，有助於企業最大程度的下降成本，提升質量和用戶滿意度。
軟件質量管理體現TQM的運行機制 軟件質量管理是CMM四級中一個獨立的KPA，其目的是使項目的軟件質量管理活動是有計劃的、軟件產品的質量目標是量化的和受到管理的。它遵循了全面質量管理活動的科學程序—PDCA（Plan、Do、Check、Action），即四個階段:
（1） 計劃:即肯定質量目標以及實現這個目標須要採起的措施。制定質量計劃是整個質量管理活動的基礎。國家標準對質量下的定義爲: 質量是產品或服務知足明確或隱含須要能力的特徵和特性的總和。
對於軟件來講，軟件質量則體如今質量特性上，ISO/IEC9126中規定了6個質量特性，即功能性、可靠性、易用性、效率、可維護性和可一致性，每一個特性包含若干子特性。設定質量目標就是要找到用戶的質量需求與這些質量特性的相關性，並將其轉化爲開發過程當中可度量的技術指標或能力指標，做爲質量控制的依據。
上述的六大特性屬於軟件的外部屬性，與用戶滿意度直接相關，能夠根據組織的目標和項目的特色創建質量模型，並採用必定的方法，如QFD（Quality Function Deployment）、GQM（Goal Question Metrics）等肯定量化的質量目標，但這在實際工做中每每是至關複雜和難以得到的。所以，更經常使用的作法是以過程能力目標反映產品質量目標，一個典型的能力指標就是缺陷密度（即每單位規模工做產品中存在的缺陷數）和相應的階段缺陷排錯率，能夠根據歷史數據估計產品的規模和目標缺陷密度，從而對每一個階段發現的缺陷數量進行控制。
（2） 實施 ：即按預約計劃、目標措施及其分工實際執行。爲了在過程當中控制軟件的質量，需採起相應的手段在預約的階段點或里程碑上進行軟件工做產品質量的測量，經常使用的方法有 同行評審、原型評價、測試等。這些方法主要從兩方面對軟件的質量進行度量，一是內部屬性，即過程和活動自身能夠度量的屬性，例如工做產品的缺陷密度 ；二是外部屬性，即與用戶環境相關的屬性，這些屬性在過程當中每每難以度量，只有經過在項目的早期引入用戶測試來予以評價，而讓用戶參與開發過程，大大有利於產品質量的提升。
（3） 檢查 ：即把實施的結果和計劃的要求對比，檢查計劃的執行狀況和實施的效果，是否達到預期的目標，並找出緣由。在對質量度量的結果進行分析時，每每會用到一些統計工具和方法，如檢查表、直方圖、控制圖、Pareto圖、散佈圖、因果圖、運行圖等。這些工具能夠幫助肯定問題、評估現狀、發現緣由甚至造成下一步措施。
（4） 處理 ：即總結經驗教訓，將未解決的問題做爲下一階段制定計劃的依據。CMM要求對軟件質量測量的結果分析後，應「採起合適的與軟件質量計劃相一致的措施，以便使得產品的質量測量結果與軟件質量目標相符合」。
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
但願對您公司IT軟件研發與質量管理有幫助。 其它您可能感興趣的文章：
敏捷軟件質量保證的方法與實踐
構建高效的研發與自動化運維
IT運維監控解決方案介紹
IT持續集成之質量管理
人才公司環境與企業文化
企業績效管理系統之平衡記分卡
企業文化、團隊文化與知識共享
高效能的團隊建設
組織目標與我的目標
餐飲連鎖公司IT信息化解決方案一