測試流程依次如下：

1.需求：閱讀需求，理解需求，與客戶、開發、架構多方交流，深入瞭解需求。

2.測試計劃: 根據需求估算測試所需資源（人力、裝置等）、所需時間、功能點劃分、如何合理分配安排資源等。

3.用例設計：根據測試計劃、任務分配、功能點劃分，設計合理的測試用例。

4.執行測試：根據測試用例的詳細步驟，執行測試用例。--every tester(主要是初級測試人員)

5.執行結果記錄和bug記錄：對每個case記錄測試的結果，有bug的在測試管理工具中編寫bug記錄。

6.defect tracking：追蹤leader分配給你追蹤的bug.直到 bug fixed

7.測試報告：透過不斷測試、追蹤，直到被測軟體達到測試需求要求，並沒有重大bug.

8.使用者體驗、軟體釋出等

測試流程依次如下：

1、需求：閱讀需求，理解需求，與客戶、開發、架構多方交流，深入瞭解需求。--testing team

2、測試計劃: 根據需求估算測試所需資源（人力、裝置等）、所需時間、功能點劃分、如何合理分配安排資源等。---testing leader or testing manager

3、用例設計：根據測試計劃、任務分配、功能點劃分，設計合理的測試用例。---testing leader, senior tester

4、執行測試：根據測試用例的詳細步驟，執行測試用例。--every tester(主要是初級測試人員)

5、執行結果記錄和bug記錄：對每個case記錄測試的結果，有bug的在測試管理工具中編寫bug記錄。--every tester(主要是初級測試人員)

6、defect tracking：追蹤leader分配給你追蹤的bug.直到 bug fixed。--every tester

7、測試報告：透過不斷測試、追蹤，直到被測軟體達到測試需求要求，並沒有重大bug.

8、使用者體驗、軟體釋出等。

簡言之，整個軟體測試的流程如下：

接收客戶/產品的原始需求-確認需求-分析需求-風險預測-確認可測性（接收測試）-工作(測試)計劃-測試設計（用例）評審-執行測試-提交缺陷報告-迴歸測試-提交測試報告-工作總結-持續整合

軟體測試的流程其實在學習理論知識或是一些介紹專項測試的書籍上都是相對標準的測試流程。但在實際工作中多數公司不會按照標準的流程來，一是專案性質決定，二是公司內部規範，專案性質的話分為外包或自研，但總的來說，這些都是截止日期的，所以當資源與時間衝突時，沒有足夠的時間進行多數的流程規範。比如各種評審會議（需求評審 ，程式碼評審，用例評審，上線前產品評審等等）都會省略掉，甚至是編寫測試用例的節點，會以測試點代替，尤其對於頻繁迭代的網際網路公司。但作為測試人員， 因為我們最終要對整個產品的質量負責 ，所以在實際工作過程中，一定要在隨機應變，隨時調整測試策略，以應對各種未知的問題。

1、測試需求分析階段：閱讀需求，理解需求，主要就是對業務的學習，分析需求點，參與需求評審會議。

2、測試計劃階段：主要任務就是編寫測試計劃，參考軟體需求規格說明書，專案總體計劃，內容包括測試範圍（來自需求文件），進度安排，人力物力的分配，整體測試策略的制定。風險評估與規避措施有一個制定。

3、測試設計階段：主要是編寫測試用例，會參考需求文件（原型圖），概要設計，詳細設計等文件，用例編寫完成之後會進行評審。

4、測試執行階段：搭建環境，執行冒煙測試（預測試）-然後進入正式測試，bug管理直到測試結束。

5、測試評估階段：出測試報告，確認是否可以上線。

擴充套件資料：

件測試是伴隨著軟體的產生而產生的。早期的軟體開發過程中軟體規模都很小、複雜程度低，軟體開發的過程混亂無序、相當隨意，測試的含義比較狹窄，開發人員將測試等同於“除錯”，目的是糾正軟體中已經知道的故障，常常由開發人員自己完成這部分的工作。

對測試的投入極少，測試介入也晚，常常是等到形成程式碼，產品已經基本完成時才進行測試。到了上世紀8年代初期，軟體和IT行業進入了大發展，軟體趨向大型化、高複雜度，軟體的質量越來越重要。

軟體測試按照研發階段一般分為5個部分：單元測試、整合測試、確認測試、系統測試、驗收測試。

單元測試

又稱為模組測試，是針對軟體設計的最小單位程式模組進行正確性檢查的測試工作，單元測試需要從程式內部結構出發設計測試用例，多個模組可以平行地獨立進行單元測試。

一、單元測試的內容：

1、模組介面測試

2、區域性資料結構測試

3、 路徑測試

4、錯誤處理測試

5、邊界測試

二、單元測試步驟：

利用設計文件設計測試用例；建立被測模組的樁模組或驅動模組；利用被測試模組、驅動模組和樁模組來建立測試環境，進行測試。

驅動模組：相當於所測模組的主程式，它接收測試資料，把這些資料傳送給所測模組，最後再輸出實際結果

樁模組：用以代替所測模組呼叫的子模組。

整合測試

又稱為組裝測試或聯合測試，在單元測試的基礎上，需要將所有模組按照概要設計說明書和詳細設計說明書的要求進行組裝。

模組組裝成系統的方式：一次性組裝方式和增殖式組裝方式

一、一次性組裝方式

先對模組分別進行測試，再把所有模組組裝進行測試

二、增值式組裝測試

先對一個個模組進行模組測試，然後將這些模組逐步組裝成系統，分為兩種方式：自頂向下的增殖方式和自底向上的增殖方式

1、自頂向下的增殖方式（不需要驅動模組）

將模組銨系統程式結構，嚴控制層次自頂向下進行組裝。

首先以主模組作為被測模組兼驅動模組，所有直屬主模組的下屬模組全部用樁模組代替，對主模組進行測試。再採用深度優先或廣度優先的策略，用實際模組代替樁模組，再用樁模組代替它們的直接下屬模組，與已經測試的模組構成新的子系統。然後進行迴歸測試。

2、自底向上的增殖方式（不需要驅動模組）

由驅動模組控制最底層模組的並行測試。

3、混合增殖式

自頂向下增殖方式：

優點：能夠較早的發現主要控制方面的問題

缺點：需要建立樁模組，增加了一些附加的測試，涉及演算法和輸入輸出的模組一般在底層，這些底層模組要到組裝和測試的後期才能發現。一旦發現問題就會出現過多的迴歸測試。

自底向上增殖方式：

優點：不需要建立樁模組，建立驅動模組要比建立樁模組要簡單得多，同時涉及到演算法已近輸入輸出的模組要先測試，把最容易出現問題的部分在早期解決。

缺點：程式一直未能作為一個實體存在，直到最後一個模組加上才能形成一個實體,控制方面最後才能接觸。

三、整合測試完成的標誌：

1、成功執行了測試計劃中規定的所有整合測試

2、修改了所發現的錯誤

3、測試結果透過專門小組的評審

4、整合測試需要提交的測試報告：

5、整合測試計劃、整合測試規格說明書以及整合測試分析報告

確認測試

確認測試的目標是驗證軟體的功能和效能以及其他特性是否與使用者的要求一致。確認測試一般包括有效性測試和軟體配置複查。一般有第三方測試機構進行。

一、進行有效性測試

現軟體確認要透過一系列黑盒測試。確認測試同樣需要制訂測試計劃和過程，測試計劃應規定測試的種類和測試進度，測試過程則定義一些特殊的測試用例，旨在說明軟體與需求是否一致。

無是計劃還是過程，都應該著重考慮軟體是否滿足合同規定的所有功能和效能，文件資料是否完整、準確人機介面和其他方面（例如，可移植性、相容性、錯誤恢復能力和可維護性等）是否令使用者滿意。

確認測試的結果有兩種可能，一種是功能和效能指標滿足軟體需求說明的要求，使用者可以接受；另一種是軟體不滿足軟體需求說明的要求，使用者無法接受。專案進行到這個階段才發現嚴重錯誤和偏差一般很難在預定的工期內改正，因此必須與使用者協商，尋求一個妥善解決問題的方法

二、軟體配置複查

保證軟體配置的所有成分齊全，質量都符合要求。應該遵守使用者手冊和操作手冊中的規定步驟。

系統測試

軟體作為計算機系統的一部分，與硬體、網路、外設、支撐軟體、資料以及人員結合在一起，在實際或模擬環境下，對計算機系統進行測試，目的在於與系統需求比較，發現問題。

驗收測試

以使用者為主的測試，軟體開發人員和質量保證人員參加，由使用者設計測試用例。

不是對系統進行全覆蓋測試，而是對核心業務流程進行測試。

軟體測試流程：

在測試前拿到產品需求文件，進行需求分析及需求評審前先對需求文件進行詳細的閱讀，對有疑問的地方進行標註。具體可從以下進行：a.分析產品功能點b.產品核心競爭力c.Kano模型、馬斯洛需求分析、多問幾個為什麼、上下文分析法

工欲善其事，必先利其器；對測試而言，測試用例就是器，做好了才能把好關a.使用思維導圖列舉測試大綱，儘量發散，想到什麼就寫什麼，；先放後收，對知識點進行總結和歸納，標記重點測試模組，刪除冗餘及重複測試點。b.可使用邊界值法、等價類劃分法、錯誤推測法、因果圖法等設計案例c.根據測試大綱制定測試用例，需包含模組名、測試優先順序、操作步驟、期望結果、測試結果、備註

a.測試作為主導，聯合開發、專案經理、PM進行測試用例評審b.可先講解測試大綱，讓開發、專案經理、PM心中對測試用例有個大概；後再進行詳細測試用例講解

a.根據測試用例執行測試b.發現問題保留現場，記錄測試方法，通知開發解決問題c.覆蓋測試用例之外若有時間可進行探索性測試

a.在Bug管理工具上提交Bug，詳細記錄測試步驟b.根據Bug嚴重程度劃分Bug等級:致命、嚴重、一般、提示c.推動開發解決問題，記錄問題進展，一般聊天溝通，若問題嚴重則需透過郵件推動解決

a.對已修復的Bug進行驗證b.對Bug所在模組進行基本功能測試；整體進行冒煙測試，確保不會因為修改Bug而引起其他功能出現問題

可使用金字塔原理設計測試報告，先總後分，上級統領下級，下級推匯出上級，環環相扣a.對Bug進行彙總，篩選出各個等級的Bug存活情況b.制訂Bug發現及解決曲線圖，一般版本正常應是前期多，後期收斂，存活的是級別較低的Bugc.總結歸納版本情況，評估釋出與否

一、制定測試計劃

l 開啟測試專案

l 根據使用者需求報告中關於功能要求和效能指標的規格說明書，定義相應的測試需求報告，即制訂黑盒測試的最高標準，以後所有的測試工作都將圍繞著測試需求來進行，符合測試需求的應用程式即是合格的，反之即是不合格的；同時，還要適當選擇測試內容，合理安排測試人員、測試時間及測試資源等。

輸入：需求文件、需求跟蹤表、開發計劃

輸出：測試計劃

二、測試準備

l 在計劃制定好之後，在執行之前，必須將測試所需的人力資源，硬體資源，軟體資源，文件資源，測試資料以及環境和人文資源準備充分

l 將測試計劃階段制訂的測試需求分解、細化為若干個可執行的測試過程，併為每個測試過程選擇適當的測試用例（測試用例選擇的好壞將直接影響到測試結果的有效性）

輸入：測試計劃

輸出：測試方案、測試用例、缺陷定義、測試策略

三、測試執行

l 測試組根據測試計劃和測試日程安排進行測試，並輸出測試結果

l 執行測試開發階段建立的測試過程，並對所發現的缺陷進行跟蹤管理。測試執行一般由單元測試、組合測試、整合測試、系統測試及迴歸測試等步驟組成，測試人員應本著科學負責的態度，一步一個腳印地進行測試。

輸入：測試用例、測試規範

輸出：測試報告、測試進度表

四、測試評估

l 有測試結果評估小組或評估人員對測試結果進行評測，分析，並輸出分析結果

結合量化的測試覆蓋域及缺陷跟蹤報告，對於應用軟體的質量和開發團隊的工作進度及工作效率進行綜合評價。

l 顯然，黑盒測試只有嚴格按照步驟進行，才可能對應用程式的質量進行把關。

五、文件收集

l 將從測試計劃開始到評估結束的所有文件進行整理收集。

l 對整個測試過程進行總結，並對測試結果進行總結

l 量產測試報告

六、測試總結報告

l 提交測試結果

l 歸還所借相關資源

l 文件入庫

l 關閉測試專案

七、檔案配置管理

測試計劃

首先，根據使用者需求報告中關於功能要求和效能指標的規格說明書，定義相應的測試需求報告，即制訂黑盒測試的最高標準，以後所有的測試工作都將圍繞著測試需求來進行，符合測試需求的應用程式即是合格的，反之即是不合格的；同時，還要適當選擇測試內容，合理安排測試人員、測試時間及測試資源等。

測試設計

將測試計劃階段制訂的測試需求分解、細化為若干個可執行的測試過程，併為每個測試過程選擇適當的測試用例（測試用例選擇的好壞將直接影響到測試結果的有效性）。

測試開發

建立可重複使用的自動測試過程。

測試執行

執行測試開發階段建立的自動測試過程，並對所發現的缺陷進行跟蹤管理。測試執行一般由單元測試、組合測試、整合測試、系統聯調及迴歸測試等步驟組成，測試人員應本著科學負責的態度，一步一個腳印地進行測試。

測試評估

結合量化的測試覆蓋域及缺陷跟蹤報告，對於應用軟體的質量和開發團隊的工作進度及工作效率進行綜合評價

測試流程依次如下：

1.需求：閱讀需求，理解需求，與客戶、開發、架構多方交流，深入瞭解需求。--testing team

2.測試計劃: 根據需求估算測試所需資源（人力、裝置等）、所需時間、功能點劃分、如何合理分配安排資源等。---testing leader or testing manager

3.用例設計：根據測試計劃、任務分配、功能點劃分，設計合理的測試用例。---testing leader, senior tester

4.執行測試：根據測試用例的詳細步驟，執行測試用例。--every tester(主要是初級測試人員)

5.執行結果記錄和bug記錄：對每個case記錄測試的結果，有bug的在測試管理工具中編寫bug記錄。--every tester(主要是初級測試人員)

6.defect tracking：追蹤leader分配給你追蹤的bug.直到 bug fixed。--every tester

7.測試報告：透過不斷測試、追蹤，直到被測軟體達到測試需求要求，並沒有重大bug.

8.使用者體驗、軟體釋出等……