本文目錄結構

1      軟體專案測試過程

測試階段從橫向看有以下活動：

1.1   需求分析

測試從需求分析開始介入，測試人員參與需求的分析活動，確定測試的需求。需要了解測試需求及測試進度，即需要驗證什麼功能需求點，採用什麼測試策略，描述目前在進行哪一階段的測試（單元測試、整合測試、系統測試）以及每個階段內在進行的測試種類（功能測試、效能測試、壓力測試等）。詳細閱讀分析需求文件，進行邏輯梳理並勾勒出功能的大概流程圖；與產品經理等相關人員探討表述不清楚的地方，細化業務流程；考慮正常流程中的測試難點；考慮與其他功能的關聯；考慮非正常流程；考慮版本資料相容。

目標：

（1）      理解產品的設計意圖和設計思路。

（2）      功能確認，充分理解個功能的細節。

（3）      根據功能的大小、複雜預估測試需要的工具、環境、時間

1.2   專案整體計劃及評審

測試計劃在需求分析完成後，程式修改完畢前準備。測試計劃要描述測試活動的範圍、方法、資源和進度。

目標：

（1）          為測試各項活動制定一個現實可行的、綜合的計劃，包括每項測試活動的物件、範圍、方法、進度和預期結果。

（2）          為專案實施建立一個組織模型，並定義測試專案中每個角色的責任和工作內容。

（3）          開發有效的測試模型，能正確地驗證正在開發的軟體系統。

（4）          確定測試所需要的時間和資源，以保證其可獲得性、有效性。

（5）          確立每個測試階段測試完成以及測試成功的標準、要實現的目標。

（6）          識別出測試活動中各種風險，並消除可能存在的風險，降低由不可能消除的風險所帶來的損失。

輸入：

專案計劃和測試需求

輸出：

《專案測試計劃》

《專案測試計劃評審會議紀要》

1.3   測試用例設計及評審

內容：使用各種測試用例設計方法進行用例設計。測試用例的基本要素包括測試用例編號、測試標題、重要基本、測試輸入、操作步驟、預期結果等。

         測試用例文件是“活的”，測試用例在形成文件後也還需要不斷完善。主要來自三方面的緣故：第一、在測試過程中發現設計測試用例時考慮不周，需要完善；第二、在軟體交付使用後反饋的軟體缺陷，而缺陷又是因測試用例存在漏洞造成；第三、軟體自身的新增功能以及軟體版本的更新，測試用例也必須配套修改更新。

目標：

（1）      使測試用例反映不同的場景、條件或經由產品的事件流

（2）      測試用例必須要能完整覆蓋測試需求

輸入：

測試計劃

輸出：

《專案測試用例》

《專案測試用例評審會議紀要》

1.4   測試執行

當測試用例編寫完成通過評審後，並已提交的可測試的系統， 然後按照測試計劃和測試用例搭建測試環境，開始測試執行。對修改的bug進行迴歸測試。

測試的具體步驟：

（1）             建立測試系統，搭建測試環境

（2）             準備測試材料、測試工具

（3）             執行測試

（4）             驗證預期結果，測試不通過，反饋回給編碼人員修改。程式碼修改重新提交後，返回2繼續

（5）             記錄缺陷

（6）             評估測試需求的覆蓋率

（7）             分析缺陷

測試開始標準：

（1）          測試計劃評審通過；

（2）          測試用例已編寫完成，並已通過評審；

（3）          存在已提交的可測試的系統；

（4）          測試環境已搭建完畢。

測試退出標準：

（1）          測試用例全部通過；

（2）          存在的問題已得到合理的處理。

測試停止標準：

（1）          近半數以上測試用例無法執行；

（2）          測試環境與要求不符；

（3）          開發中需求頻繁變動。

目標：

（1）      所有的測試用例都被執行，並每條用例至少被執行一遍。

（2）      存在的問題已得到合理的處理。

輸入：

測試用例

測試環境

測試指令碼

輸出：

《測試執行記錄》

《系統bug清單》

1.5   測試評估

測試報告是對測試過程和測試結果進行分析和評估，確認測試計劃是否得到完整履行、測試覆蓋率是否達到預定要求並最終在報告中給出測試和產品質量的評估結論。

輸入：

《測試執行記錄》

《系統bug清單》

輸出：

《測試報告》

1.6   產品試用及客戶培訓

軟體部署後，給客戶提供產品試用，給客戶做相關培訓。

輸出：

《使用者手冊》

《客戶培訓PPT》

2      軟體測試階段

軟體V模型結構圖如：

2.1   單元測試

主要是測試程式程式碼，為的是確保各單元模組被正常編譯。有具體到模組的測試，也有具體到類、函式的測試等。——一般是由開發來完成

2.2  整合測試

單元測試後，將各單元組成完整的體系，測試軟體單位之間的介面是否正確，資料能否正常傳遞。——比如註冊和充值這兩個功能能否連通

2.3  系統測試

把軟體系統搭建起來，按照《軟體規格說明書》中的要求對各項功能進行測試，看是否符合需求、在系統執行是否存在漏洞等——根據測試用例，進行完整的系統測試

系統測試主要包括功能測試、介面測試、可靠性測試、易用性測試、效能測試。功能測試主要針對包括功能可用性、功能實現程度（功能流程&業務流程、資料處理&業務資料處理）方面測試。

2.4   驗收測試

按照專案任務書或合同、供需雙方約定的驗收依據文件進行的對整個系統的測試與評審，決定是否接收或拒收系統——使用者對軟體進行驗收

2.5   迴歸測試

迴歸測試是指重複以前的全部或部分的相同測試。新加入測試的模組，可能對其他模組產生副作用，故須進行某些程度的迴歸測試。

3      附錄

3.1  測試文件清單

3.2   缺陷管理流程

缺陷狀態一般分為：新建、開啟、已分配、已修復、關閉、重新開啟

中間會有：延期、重複、拒絕等狀態

缺陷管理流程：

3.3   缺陷等級劃分

A類--嚴重錯誤，包括以下各種錯誤：

　　1、由於程式所引起的宕機，非法退出

　　2、死迴圈

　　3、資料庫發生死鎖

　　4、因錯誤操作導致的程式中斷

　　5、功能錯誤

　　6、與資料庫連結錯誤

　　7、資料庫通訊錯誤

B類--較嚴重錯誤，包括以下錯誤：

　　1、程式錯誤

　　2、程式介面錯誤

　　3、資料庫的表、業務規則、預設值未加完整性等約束條件

C類--一般性錯誤，包括以下各種錯誤：

　　1、操作介面錯誤(包括資料視窗內列名定義、含義是否一致)

　　2、列印內容、格式錯誤

　　3、簡單的輸入顯示未放在前臺進行控制

　　4、刪除操作未給出提示

　　5、資料庫表中有過多的空欄位

D類--較小錯誤，包括以下各種錯誤：

　　1、介面不規範

　　2、輔助說明描述不清楚

　　3、輸入輸出不規範

　　4、長操作未給使用者提示

　　5、提示視窗文字未採用行業術語

　　6、可輸入區域和只讀區域沒有明顯的區分標誌

E類--測試建議

轉：https://wenku.baidu.com/view/53c209e2db38376baf1ffc4ffe4733687e21fc80.html