如何評估軟件產品質量是每個產品測試經理以及每個測試人員都要面對的問題，但是這個問題又沒有一個標准的、統一的、可量化的方法。本文根據個人的測試經驗說說自己的看法，歡迎探討。
我主要碰到的幾個的問題
1、測試過程中，產品相關責任人詢問測試能否結束？版本質量如何？能否按計划發布？
2、測試結束，是否允許版本發布？
這里核心的問題軟件產品質量如何，我們是怎么評估我們的產品質量的。如果你有自己的評估方法和體系，我想就可以相對比較清晰的回答出產品的質量狀況。比如產品測試過程中用了哪些測試方法、發現了什么缺陷，可能存在的風險。如果還有時間，會再做哪些測試去保證測試質量。如果不允許發布，理由是什么。有一套自己的質量評估體系，就不會出現含糊其辭的對於質量的答復或者模棱兩可的就發布了版本。
當前現狀
1、版本測試結束，輸出測試報告，版本發布。當然，這個過程中會做一些客觀的度量數據分析。主要包括需求范圍是否100%交付、缺陷加權值是否正常、用例數是否正常等。也包括考慮對異常分布的缺陷值是否做進一步分析或者做了特殊說明、用例數太少是否做了特殊說明等。如果評估沒有什么問題，版本就審批通過發布了。這里會有幾個明顯的問題。我們來分析下：
（1）缺陷值在合理范圍內，版本質量就滿足發布要求了嗎？缺陷嚴重程度雖然有標准但是不同的測試人員執行起來結果還是會有偏差。
（2）用例數在合理范圍內，版本質量就滿足發布要求了嗎？用例是否有冗余，是否考慮產品特有的典型用例？不同的測試人員用例有效性會有很大的區別。
（3）如果這時評審發現產品某些特性需要補充測試，是否還有時間？已經到版本發布時間了。
2、測試過程中對於答復質量如何或者能不能結束、什么時候能夠結束。我比較常見的答復是還有多少用例沒有執行、大概需要多少天。也就是以手上的剩余工作去判斷測試結束時間。或者答復質量還行，這個版本測試用例是評審過的。
這2種情況是我經常見到的，版本計划安排的測試時間結束版本就發布，至於一些對測試報告中的質疑下面的人總是能找到一個合理的描述去解釋，自己有時候確實也沒精力去深入分析就把版本發布了。除了幾個重要的版本。很少能看到或者聽到一個人可以很清晰的去闡述產品的質量如何或者他自己手上的工作如何。
上述發生的問題也描述了，看着好像問題拋的也很合理，是不是就沒有辦法解決了，個人認為也不是。我理解主要是保證好測試前端工作和把控好測試過程。基於風險的測試策略，主動分析解決，版本發布或者不能發布就不會再最后時間才有定論。
如何評估軟件質量
如何評估軟件質量，確保軟件質量符合發布要求，我理解主要有如下幾個關鍵內容。
1、需求復雜度+代碼量
這里的需求復雜度主要是指需求實現的難易程度，需要綜合考慮開發對需求實現難易的程度、測試對需求可測試性評估程度、是否有成熟的方案、代碼是否復用等。通常來說需求實現越復雜，代碼量大的版本風險較高。
2、人力成熟度
人力成熟度，需要綜合考慮PM、開發、測試人力的成熟度。人力越成熟，開發、測試的風險就會降低。如果是新手開發的模塊，就需要特別重視了。當然，在開發、測試分工時，開發經理和測試經理通常是回根據需求復雜度和人力成熟度進行相應的分工。降低版本質量風險。
3、版本開發測試流程
版本開發測試流程，包括開發團隊和測試團隊工作的測試流程，從需求進入研發團隊到版本發布上線。包括各個階段的出、入口准則和工作內容、版本發布的准則等。這里重點描述幾個環節的出、入口條件和注意事項。
（1）需求准入和傳遞。需求已簽字和所有參與該版本的測試、開發及其他相關人員斗毆參與了需求傳遞。可以開展開發需求反串講和測試需求反串講活動保證開發、測試人員斗毆熟悉理解需求內容。
（2）代碼檢視。首先確保檢視人員，通常是項目組的核心骨干，熟悉業務特性和代碼框架。安排檢視活動時間，有些項目組會忽略這個活動。同時，輸出檢視結果，會起到一定的督促效果，也便於回顧。
（3）代碼工具掃描。確保項目組規定的代碼掃描工具完成，並提供掃描報告，要求掃描結果通過。可以減少代碼低級bug、降低圈復雜度，保證代碼質量。同時也可以降低后續測試人員用例設計代碼覆蓋的難度。
（4）測試分層出入口條件。嚴守各個環節的出入口條件。測試分層包括UT/IT/MST/BBIT/SDV/SIT/SVT等，通常不會分的這么細，根據自己項目情況進行變更。確保各個環節的工作內容、測試對象都已達到出口准則。分析各個環節的執行情況和交付件，調整下一環節的測試策略，確保已知風險盡早解決。
（5）測試用例評審。確保核心人員參與，特別是SE、開發Leader、測試Leader以及核心人員、版本維護人員等。評審形式采用盡量采用會議形式。對於電話會議或者郵件評審，醬油居多，不建議采用，其他特殊情況特殊考慮。評審閉環，確保意見全部修復。
（6）測試策略和測試計划評審。核心人員必須參與評審，包括pm、開發Leader、測試Leader及相關人員等。確保測試任務分工、測試時間合理。不出現明顯的時間壓縮，因為版本計划通常都是根據發布計划倒排的，所以測試Leader必須有主見，對於測試時間有風險必須及時提出。
（7）測試報告評審。測試報告評審通常都有規定的人員參與。希望到這一步驟時在任何人提出質疑時都可以准確答復質疑。對於版本的質量能有一個相對清晰的描述。雖然很多描述還是依靠主觀的。
4、需求變更
需求變更在軟件開發測試過程都是難以避免，在需求變更管控流程規范下積極面對。做好需求變更管理，分析引入變更對現有交付范圍、影響，刷新測試策略和計划。確保風險可控。不能盲目的、一味的接受，避免到最后風險不可控。
總結
軟件質量的評估我理解是重在過程。在版本開發測試流程指導下基於風險的測試策略層層遞進，降低或者消滅各個環節暴露的風險。確保版本發布上線質量。