軟體測試中功能測試的測試工作流程

　　1. 測試計劃：這個計劃，我個人覺得應該在詳細設計確定後，程式碼開始編寫的時候進行制定，因為我是“提早開始測試工作”思路的忠實fans，雖然現在專案裡都只有我一個人在這麼早開始工作......

　　測試計劃，主要是給後面的測試工作一些指南，不能寫成領導看的計劃，而是要寫成由做事的人看的計劃

　　包含的內容可能有：

　　i. 測試團隊人員及分工(要確定當測試時出現缺陷界定、測試環境準備等問題時能找到指定的人員)

　　ii. 測試開始結束時間(理想情況下，不要安排的太緊，趕工肯定會造成延期或測試不完整，可惜理想和現實的差距被規定為很大)

　　iii. 測試環境配置(什麼樣的硬體條件，是否網路、裝置等，系統在什麼地址訪問，訪問許可權、使用的測試資料等方面的預計和準備)

　　iv. 測試哪些東西要說清楚，這裡我建議把簡單的測試大綱納入測試計劃中，一方面領導可以看到你的計劃寫的多詳細，另一方面大綱可以很好的成為編寫用例的依據

　　v. 怎麼測試要說明白，如只做系統測試，那就要寫清楚不做整合測試，如果需要整合測試，就需要寫明白整合順序。另外如果需要進行效能、文件、等其他的測試也要在這個計劃中寫明，雖然一般這個計劃都是針對功能測試，但是如果有其他測試，也要寫出來並安排時間，相應測試的相關計劃等也需要指明

　　vi. 測試結束標誌(要說明測試達到什麼程度可以結束測試，不能等到把所有缺陷都找出來以後才結束，因為那將是一萬年)，允許缺陷存留在系統裡，我們只需要找到留多少這個度就夠了

　　2. 測試用例：這個文件，主要描述具體的測試步驟，但實際應用中，至少目前我的專案裡，由於時間的原因，很少有寫的，就算寫了的，也基本沒有用到測試裡，在這邊的很多專案大都是直接來測，全憑我個人的經驗來檢查(在此感謝領導們對於我二把刀技術的信任_@_)。但是我想說其實他很重要，也許你不需要寫的很詳細，但是絕對需要通過這樣的步驟來理順思路，這個文件的好壞和實用程度，直接可以決定你是否能“用最少的工作(量和時間)，儘早的發現儘可能多的缺陷”，寫這個文件需要用到一些測試方法理論，如等價類劃分、邊界值、這個表那個表。

　　3. 缺陷記錄：是功能測試過程中使用頻率最高的文件，用於在測試過程中記錄發現的缺陷，並由開發人員作為修改缺陷的依據，以及修改後測試人員進行回測的主要依據

　a) 該文當也有助於分析開發人員存在的“錯誤叢集”現象，總結易出錯的地方，對缺陷多的部分做更深入的測試，並提醒開發人員避免缺陷

　　b) 缺陷記錄填寫指南：

　　i. 缺陷級別(即嚴重程度)，一般由公司統一定義，為發現的缺陷進行分類，以便決定修改的緩急

　　ii. bug分類：區分發生的位置，是功能的，還是效能的，是有效性問題 還是其他問題等，與bug級別一起，用於決定bug的修改要求度|

　　iii. bug狀態：是標誌bug的當前情況，標識是否被處置(關閉狀態)，

　　iv. 上述這些指標一般由公司統一定義(一般標準都大同小異)，也會用於專案的度量

　　c) 缺陷記錄使用時的注意點：

　　i. 描述bug要有三要素：在哪裡，什麼情況(前提)下，發生了什麼樣的問題

　　ii. 可以藉助截圖、引用位置、模組等方式來描述bug，目的是讓開發人員能夠通過您的描述立刻馬上能夠重現bug，即使不能重現，也能讓開發人員瞭解到錯誤的所在

　　iii. 缺陷報告要由開發人員和測試人員共同完成，測試人員要督促開發人員填寫該表以便測試後續的回測工作

　　iv. 如果是在執行用例的同時填寫bug報告，用例的最後一列一般可以填寫用例的執行結果，如果用例發生了非期望的結果，那麼就要把問題記錄在缺陷記錄中，此時可以在缺陷記錄中引用該用例的編號

　　4. 測試總結報告：用於報告和總結專案測試工作的執行結果，列舉和統計相關測試資料，對比分析資料即工作中存在的問題為後續工作做出提示，並記錄遺留的問題等

　a) 總結報告的還有一個功能就是告訴專案組成員該系統已經按照測試計劃的要求進行了測試，並已經達到測試計劃中說明的“測試結束條件”，可以證明系統已經達到測試計劃所期望的質量

　　這份測試總結需要記錄專案所有測試的結果情況，除了功能測試外，效能測試也會被包含在內。