軟體測試流程及規範（參考大華為的規範）

參考某大佬（窩真不知道是哪位大佬）總結的測試流程並結合在華為做測試學到的規範，整理的我們公司的測試流程，分享是一種美德，so開始你的閱讀吧~

軟體測試流程及規範

一、目標

制定完整且具體的測試路線和流程，為快速、高效和高質量的軟體測試提供基礎流程框架。最終目標是實現軟體測試規範化、標準化。

二、測試流程說明

三、需求分析

需求分析由SA制定，要求細化每一個功能的細節，每一個按鈕的位置以及邊界範圍，對於稍大或稍複雜需求要求建模。

（1）測試需求是制訂測試計劃的基本依據，只有確定了的測試需求才能夠為測試計劃提供客觀依據;

（2）測試需求是設計測試用例的指導，只有確定了要測什麼、需要測哪些方面，才能有針對性的設計測試用例;

（3）測試需求是計算測試覆蓋的分母，沒有測試需求就無法有效地進行測試覆蓋.

四、需求評審（需求澄清）

參與人員，包括：SE、OM、PC、AD、TE以及QA。

SE提出需求。

開發人員（OM、PC、AD）考慮功能實現的方案與可行性。

TE主要是對需求的理解提出疑問，以便才能根據需求寫用例。

QA人員是最終對軟體質量進行驗證的人，所以也需要了解需求

五、開發人員編寫排期

開發人員需要根據需求功能點進行排期，然後將開發計劃傳送給參與專案的所有人員

六、測試計劃排期

測試人員根據開發計劃，安排測試的具體測試時間（包括SIT轉測），然後將測試計劃傳送給參與專案的所有人員。

七、編寫測試用例

     根據詳細的需求文檔，開始進行用例的編寫。

八、用例評審

用例評審前，先將用例傳送給相關人員，以便他們事先了解用例將對哪些功能進行驗證以及驗證的細節。

     在用例評審中，參與人員需要對用例中與實際功能不符合的用例或者格式不規範規用例提出修改建議。

九、提交基線

  開發人員完成所有功能後，會對自己的功能進行一個自測。自測完成後提交測試進行基線。

十、Showcase

開發人員自測完成後將實現的功能演示給測試人員。

測試人員可以提出疑問由開發人員解答或者後續提單解決。

十一、轉測

轉測試是開發把所有需求都開發完成，並所有需求都showcase完畢。

（即：開發轉版本給測試組前進行的系統測試，目的是來評斷這個版本功能是否可測。如果預測試不通過，打回，開發組返工，如果通過，測試組開始第一輪系統測試。）

迭代出口（轉測之前是迭代出口，迭代出口前是迭代期）完成了，需要自己到測試環境進行驗證。

轉測時間根據版本制定。版本轉測試以後，需要對本版本進行總結，版本製作人需要對合入版本期間的異常進行總結，對合入的事件做好記錄，對版本延遲的原因要給出負責主題。

(1)第一輪系統轉測試，測試組會執行所有測試用例，發現缺陷提交問題單，並每日彙報測試進展。第一輪測試結束後，測試組將所有的問題單跟蹤提交給開發人員，由他們進行修改。然後對基線後的第二輪進行測試，第二輪會對第一輪中發現的問題進行重點回歸。

(2)在他們修復bug期間，測試組會對第一輪系統測試做一個測試評估，出一個測試報告。 還要根據實際情況，對測試組寫的測試用例進行修改和增加，開發修改bug結束，提交一個新的版本給測試組。

首先是迴歸缺陷，然後會在用例中挑選一些優先級別比較高的用例來進行測試，發現問題繼續提交缺陷問題單，直到缺陷率低於使用者要求，測試組將進行最後一輪的大版本測試，結束系統測試。具體測試輪次根據版本質量和專案複雜度而決定。

十二、測試通過

經過兩到三輪或四輪的測試後，直到沒發現新的問題。或暫時無法解決，或不緊急的問題，通過上級確認，可以通過。

編寫測試報告與驗收方案（驗收方案是交由QA進行驗證的，測試人員重點關注的是功能是否可以正常執行，QA關注的是整個流程的質量以及終端使用者的質量）。

十三、測試評估

執行階段結束了進入測試評估階段，測試組會出一個總的測試報告對測試組測試的這個過程和版本的質量做一個詳細的評估 ：

1) 需求需要評審那些？

2) 用例需要評審那些？

3) 計劃應該評審那些？

4) 缺陷評審那些？

5) bug評估？

十四、測試總結文件報告輸出

可以讓具體的任務負責人對該本次測試中個人負責的模快進行評價，提出相關建議，給出總體的評估。 

bug按照不同等級統計出來，用例數量、用例執行數量。

對專案中測試人力資源的統計。（單位：人/天）

專案中軟硬體資源統計。

提出軟體總體的評價。

十五、測試報告

測試報告包括對軟體功能的結論，說明為滿足此項功能而設計的軟體能力以及經過一項或多項測試已證實的能力。

說明該專案軟體的開發是否達到預定目標，是否可以交付使用。總結測試工作的資源消耗資料：如工作人員的水平級別數量、機時消耗等。

記錄測試結果與發現及本專案測試工作所得到的各項輸出的承載體，根據輸入與計劃、要求的對比來總結此次專案所獲得的經驗。

十六、備註

附加：敏捷測試流程

來源：http://www.testclass.net/software_test/

敏捷測試的一個核心是迭代，在每個時間點上，所有專案人員都是有事可做的。

• 下面是我理解中的敏捷測試流程圖：

第一階段：

通過上面的流程圖，對於一個月的需求分析，在敏捷中，可能三五天就確定下來。這個需求定得會很模糊，但整體框架確定。產品對其中某一模組功能確認，開發人員開始對確認的功能編碼，開發人員編碼的過程中，測試進行功能分解，因為根據模糊的需求很難寫出具體的用例，所以，只能儘量對功能進行分析得細些，標註需要驗證的內容。

第二階段：

開發完成後交給測試人員進行測試，開發人員繼續開發新的功能。那麼測試人員發現的問題怎麼辦呢？會從開發團隊中抽出一個人員來用於解決測試發現的問題。但開發進度並沒有因為測試而停止。

流程分析：

在這個流程中弱化了文件，強調了各個人員的溝通，通過這種迭代的方式，三個月的專案，可以能兩個月和兩個半月就會完成。

但這種流程並非完美，假如一個功能在需求分析階段就是錯誤的，因為它是一個迭代漸進的過程。也只能一路錯下去。

• 對測試問題的處理

上面的圖更能清晰看出對問題的處理過程。

第一塊麵板中是開發人員未實現的功能，第二塊面板中是開發完成功能，測試人員對其進行測試，發現不通過的就放回未開發的面板中，測試通過的將放到第三塊面板中。