按照產出的文檔，介紹項目開發過程中的工作步驟
1. 測試計劃：這個計劃，我個人覺得應該在詳細設計確定后，代碼開始編寫的時候進行制定，因為我是“提早開始測試工作”思路的忠實fans，雖然現在項目里都只有我一個人在這么早開始工作。。。-_-///
a) 測試計劃，主要是給后面的測試工作一些指南，不能寫成領導看的計劃，而是要寫成由做事的人看的計劃
b) 包含的內容可能有：
i. 測試團隊人員及分工(要確定當測試時出現缺陷界定、測試環境準備等問題時能找到指定的人員)
ii. 測試開始結束時間(理想情況下，不要安排的太緊，趕工肯定會造成延期或測試不完整，可惜理想和現實的差距被規定為很大)
iii. 測試環境配置(什么樣的硬件條件，是否網絡、設備等，系統在什么地址訪問，訪問權限、使用的測試數據等方面的預計和準備)
iv. 測試哪些東西要說清楚，這里我建議把簡單的測試大綱納入測試計劃中，一方面領導可以看到你的計劃寫的多詳細，另一方面大綱可以很好的成為編寫用例的依據
v. 怎么測試要說明白，如只做系統測試，那就要寫清楚不做集成測試，如果需要集成測試，就需要寫明白集成順序。另外如果需要進行性能、文檔、等其他的測試也要在這個計劃中寫明，雖然一般這個計劃都是針對功能測試，但是如果有其他測試，也要寫出來并安排時間，相應測試的相關計劃等也需要指明
vi. 測試結束標志(要說明測試達到什么程度可以結束測試，不能等到把所有缺陷都找出來以后才結束，因為那將是一萬年)，允許缺陷存留在系統里，我們只需要找到留多少這個度就夠了
2. 測試用例：這個文檔，主要描述具體的測試步驟，但實際應用中，至少目前我的項目里，由于時間的原因，很少有寫的，就算寫了的，也基本沒有用到測試里，在這邊的很多項目大都是直接來測，全憑我個人的經驗來檢查(在此感謝領導們對于我二把刀技術的信任_@_)。但是我想說其實他很重要，也許你不需要寫的很詳細，但是絕對需要通過這樣的步驟來理順思路，這個文檔的好壞和實用程度，直接可以決定你是否能“用最少的工作(量和時間)，盡早的發現盡可能多的缺陷”，寫這個文檔需要用到一些測試方法理論，如等價類劃分、邊界值、這個表那個表(汗。。。忘記了)
3. 缺陷記錄：是功能測試過程中使用頻率最高的文檔，用于在測試過程中記錄發現的缺陷，并由開發人員作為修改缺陷的依據，以及修改后測試人員進行回測的主要依據
a) 該文當也有助于分析開發人員存在的“錯誤集群”現象，總結易出錯的地方，對缺陷多的部分做更深入的測試，并提醒開發人員避免缺陷
b) 缺陷記錄填寫指南：
i. 缺陷級別(即嚴重程度)，一般由公司統一定義，為發現的缺陷進行分類，以便決定修改的緩急
ii. bug分類：區分發生的位置，是功能的，還是性能的，是有效性問題 還是其他問題等，與bug級別一起，用于決定bug的修改要求度
文章來源于領測軟件測試網 http://www.kjueaiud.com/
