按照產出的文檔，介紹項目開發過程中的工作步驟
1. 測試計劃：這個計劃，我個人覺得應該在詳細設計確定后，代碼開始編寫的時候進行制定，因為我是“提早開始測試工作”思路的忠實fans，雖然現在項目里都只有我一個人在這么早開始工作。。。-_-///
a) 測試計劃，主要是給后面的測試工作一些指南，不能寫成領導看的計劃，而是要寫成由做事的人看的計劃
b) 包含的內容可能有：
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) 總結報告的還有一個功能就是告訴項目組成員該系統已經按照測試計劃的要求進行了測試，并已經達到測試計劃中說明的“測試結束條件”，可以證明系統已經達到測試計劃所期望的質量
b) 這份測試總結需要記錄項目所有測試的結果情況，除了功能測試外，性能測試也會被包含在內。
文章來源于領測軟件測試網 http://www.k11sc111.com/
