軟體測試工作基本流程

       最近在為面試新工作做準備，是以想想整理一下軟體測試的基本工作流程，大緻梳理一遍，這樣也便于自己在面試過程中可以沉着的面對面試官的測試工作如何進行的問題。

首先，作為測試人員需要學習并了解業務，分析需求點

      為什麼測試人員要參加需求分析？也就是進行測試需求分析的目的是什麼？

第一、把使用者需求轉化為功能需求：1）對測試範圍進度量    2）對處理分支進行度量   3）對需求業務的場景進行度量   4）明确其功能對應的輸入、處理和輸出   5）把隐式需求轉變為明确。

第二、明确測試活動的五個要素：測試需求是什麼、決定怎麼測試、明确測試時間、确定測試人員、确定測試環境：測試中需要的技能，工具以及相應的背景知識，測試過程中可能遇到的風險等等。測試需求需要做到盡可能的詳細明确，以避免測試遺漏和誤解。

怎麼進行測試需求分析？

第一、确認功能（業務功能、輔助功能、資料限制、易用性需求、編輯限制、參數需求、權限需求、性能限制）：

1、業務功能：與使用者實際業務直接相關的功能或者細節

2、輔助功能：輔助完成業務功能的一些功能或者細節，例如：設定過濾條件

3、資料限制：功能的細節，主要是用于控制在執行功能時，資料的顯示範圍，資料之間的關系等

4、易用性需求：功能的細節，産品中必須提供，便于功能操作使用的一些細節，例如：快捷鍵等

5、編輯限制：功能的細節，在功能執行時，對輸入資料項目的一些限制條件，例如：隻能輸入數字等

6、參數需求：功能的細節，在功能執行時，需要根據參數設定不同，進行不同處理的細節

7、權限需求：功能的細節，在功能執行的過程，根據不同的權限進行不同的處理，不包括直接限制某個功能的權限

8、性能限制：功能的細節，執行功能時，必須滿足的性能需求

第二、場景分析

1、考慮場景的調用者：考慮每一個場景提供的服務是供哪些外部子產品或者系統調用的，找出所有調用者。調用前提，限制都要考慮。每一個調用都可以考慮成一個大的業務流程（一般和外部有互動的業務出錯率比較大，需要重點關注）

2考慮系統内部各個場景之間的：形成内部業務流程，需要分析每個場景之間的限制關系，執行條件，組織出各種業務流程圖

第三、挖掘隐性需求

這需要測試工程師的經驗積累：1）常用的或者規定的業務流程   2）各個業務流程分支的周遊   3）明确規定不可使用的業務流程   4）沒有明确規定但是應該不可使用的業務流程   5）其他異常或者不符合規定的操作

       以上是粗略的講解了如何進行測試需求分析，詳細的測試需求方法可以參考《軟體測試需求分析方法》這篇部落格。在需求分析過程中編寫整個測試計劃，在這個過程中需要參考需求規格說明書，這個階段一般情況下是測試主管編寫的。包括測試人員，測試時間，測試工具，以及測試方法等。這是在測試需求分析中的産物《測試計劃》，如何編寫測試計劃，請參考以下文章《如何編寫一個好的測試計劃》。

接下來就是測試用例設計

       測試用例是測試工作的最核心的子產品，在執行任何測試之前，首先必須完成測試用例的編寫。測試用例是指導你執行測試，幫助證明軟體功能或發現軟體缺陷的一種說明。用例設計好後進行稽核。這個地方該講的東西就多了，如何設計測試用例，設計測試用的方法，怎麼進行測試用例的稽核等等。

第一、如何進行測試用例的設計

       編寫測試用例之前我們需要對項目的需求有清晰的了解，對要測試什麼，按照什麼順序測試，覆寫哪些需求做到心中有數，作為測試用例的編寫者不僅了解要有常見的測試用例編寫方法，同時需要了解被測軟體的設計、功能規格說明、使用者試用場景以及程式/子產品的結構。

步驟：

1、測試需求分析：從項目部拿到軟體的需求規格說明書後，開始對項目的需求進行分析，通過自己的分析、了解，整理成為測試需求， 清楚分析出被測試對象具有哪些功能。 明确測試用例中的測試集用例與需求的關系，即一個或多個測試用例集對應一個測試需求。

2、業務流程分析：分析完需求後，明确每一個功能的業務處理流程，不同的功能點作業務的組合，以及項目的隐式需求。如遇複雜的測試用例設計前，先畫出軟體的業務流程。從業務流程上，應得到以下資訊：

A、 主流程是什麼?

B、 條件備選流程是什麼?

C、 資料流向是什麼?

D、 關鍵的判斷條件是什麼?

3、測試用例設計

       完成以上兩步則可進行測試用例設計，功能測試用例，應盡量考慮邊界、異常、性能的情況，以便發現更多的隐藏問題。設計測試用例的常見方法：1）等價類    2）邊界值    3）因果圖    4) 判定表    5)資料遷移    6) 正交實驗    7) 場景法    8) 錯誤推斷（注意：編寫測試用例時，我們盡可能取的不應該是有效等價類而應該是無效等價類）

4.編寫完成後自我檢查以及部門内部評審：

1）測試用例本身的描述是否清晰，語言準确；是否存在二義性；

2）測試用例内容是否完整，是否清晰的包含輸入和預期輸出的結果；測試步驟是否清晰；

3）測試用例中使用的測試資料是否恰當，準确；

4）測試用例是否具有指導性，是否能靈活的指導軟體測試工程師通過測試用例發現更多的缺陷，而不是限制他們的思維；

5）是否考慮到測試用例執行的效率。對于不斷重複執行的步驟，是否保證了驗證點相同；或者測試用例的設計是否存在備援性等。這些都可能導緻測試用例執行效率低下；

6）畫出軟體需求跟蹤矩陣，驗證測試用例是否完全覆寫了需求，驗證測試用例的覆寫性；

7）測試用例是否完全遵守了軟體需求的規定。這一點其實有一些難做到。考慮到時間/成本的關系，應該視具體情況而定。

具體詳細内容可參考《如何有效的進行測試用例評審》

5.測試用例更新完善

       測試用例編寫完成之後需要不斷完善，如遇需求更改或功能新增時，測試用例必須配套修改更新，同時在測試過程中發現設計測試用例時考慮不周，需要對測試用例進行修改完善;在軟體傳遞使用後客戶回報的軟體缺陷，而缺陷又是因測試用例存在漏洞造成，也需要對測試用例進行完善。

緊接着就是在測試過程中占很大一部分比重得測試用例執行過程

       首先搭建測試環境，準備好測試資料，進行預測，預測通過之後，按照測試用例進入正式測試，有效的測試執行可以将測試用例發揮最大的價值。是以，測試用例規範執行有助于更好的發現代碼中存在的缺陷。根據個人測試工作經驗，好的測試執行應該包含如下内容：

1、測試執行中評估測試執行時間不足，需及時上報風險。滿足品質優先，進度其次原則。

2、測試用例按優先級順序執行，通常是基本、詳細和異常順序執行。

3、未執行用例、标志為删除或者無效的用例，需注明原因。

4、執行過程中有疑問的測試用例（場景、操作步驟、檢查點等）需找測試設計人員澄清。

5、測試執行需對用例描述的檢查點逐一檢查，避免遺漏。

6、重視不易重制的缺陷場景，可能是一個bug。

7、執行過程中發現有前期設計遺漏用例需補充到用例文檔并執行驗證。

8、建議測試人員交叉執行重複測試用例，用例執行對相同測試人員有免疫性。避免可能的缺陷一直遺漏到現網。

9、如有需要，建議保留測試結果，結果可視。也便于不同版本間的測試結果對比。

10、已确認問題需及時按照問題單提單要求（規範和缺陷定級）提單。

11、跟蹤問題單修複情況并回歸驗證問題單。

12、每輪次測試結束，find一下是否有core檔案産生。

13、測試結束，将最終測試用例文檔上傳到歸檔目錄，實作用例重用。

       以上是針對一般的軟體測試流程，如果是自動化測試的話，應該還有根據測試用例進行腳本編寫，運作腳本等。此處可能寫的不詳細，希望大家可以再下方評論讓我完善。

       在測試用例執行過程中，包含了：功能測試階段、缺陷跟蹤階段（bug tracking）、回歸測試階段、系統測試階段、驗收測試階段等（系統已滿足測試條件（開發完成），按照已經評審過的測試用例依次執行，執行過程中及時記錄問題，将問題及時送出到QC上，要跟蹤缺陷。等開發修複後進行回歸測試，确認修複後關閉缺陷，如果說該問題要更新而生産上未進行驗證，就把缺陷狀态改為生産未驗證。對有異議的缺陷經甲方、開發和測試三方進行溝通讨論，由甲方最終确定處理方式。在測試過程中也會碰到對需求有異議，會回報給經理，由經理與甲方溝通來對該需求提出一些可行性建議，最終還是由甲方來确定具體根據各個公司的業務流程而不一樣）。

最後已達到準出要求的根據測試情況寫測試報告，對整個測試過程和版本的品質做一個評估

       測試報告是指把測試的過程和結果寫成文檔，對發現的問題和缺陷進行分析，為糾正軟體的存在的品質問題提供依據，同時為軟體驗收和傳遞打下基礎。測試報告是測試階段最後的文檔産出物。優秀的測試經理或測試人員應該具備良好的文檔編寫能力，一份詳細的測試報告包含足夠的資訊，包括産品品質和測試過程的評價，測試報告基于測試中的資料采集以及對最終的測試結果分析。

測試報告的内容可以總結為以下目錄：

 首頁

 引言（目的、背景、縮略語、參考文獻）

 測試概要(測試方法、範圍、測試環境、工具)

 測試結果與缺陷分析（功能、性能）

 測試結論與建議（項目概況、測試時間 測試情況、結論性能彙總）

 附錄（缺陷統計）

       至此并不算最後的完結工作，軟體測試還包含了線上功能檢查、目前版本問題回報以及改進建議 等。這樣才算是軟體測試最終結束，軟體測試是貫穿于整個軟體生命周期的。

       小生不才還望大家多多包涵，此文章是用來幫助自己應付面試用的，大家多多提意見，完善該文章。

       最後祝大家和自己，能夠有所收獲，面試順利（Interview success）。

本文轉自：https://blog.csdn.net/sinat_41392571/article/details/81514521