完整的需求文件包括以下內容：
需求分析注意事項：
分析需求的具體方法：
1）快速理解需求的捷徑：需求串講
主要解決的問題：需求理解不一致
方式：介紹需求背景、內容，進行答疑
2）驗證需求
需求文件也需要測試：正確性、必要性、完整性、一致性等。
3）從設計需求中提取測試需求
軟體需求是軟體測試需求的主要**，但不是全部**，軟體設計需求、軟體概要設計、詳細設計也都是測試需求的分析物件，是對測試需求的一種有力的補充。對於黑盒功能測試，幾乎98%的需求都是**於需求說明書，但有那麼一小部分需求來自設計需求或概要設計、詳細設計。也就那麼小部分需求，如果我們沒有意識到，就會給使用者帶來隱患。
在分析了需求之後，我們要確認測試業務涉及的測試類別，例如：
測試策略的具體實施：
1）需不需要白盒測試？
2）自動化測試採用哪種工具？針對介面測試還是ui測試？
3）效能測試採用哪種工具？jmeter還是loadrunner？
4）相容性測試如何做？手工測試還是使用平台測試？
在測試方案中，我們也需要確認測試過程如何管理，確認管理使用的工具和方法，比如：用例的管理方式、bug的管理方式和工具。在沒有固定測試團隊的企業，還需要考慮團隊的組建，比如測試的人數，高中低階的配比，入場出廠時間等等。確認測試資源，需要多少資源？資源是否到位？根據不同的開發模式，確認測試計畫，計畫主要包括：什麼人、什麼時間、做什麼事情。測試的目標要明確，同時要確認跟蹤機制。
每乙個公司對測試計畫和測試方案的定義都不一致，不是每乙個公司都有測試計畫和測試方案，有些只有測試計畫，有些只有測試方案，有些兩個都有。
測試方案主要包括以下內容：
測試範圍：由需求分析而來
測試策略：包括針對不同部分的測試方法、測試用例
測試控制：包括測試流程、測試執行、缺陷跟蹤
其他：環境、版本管理等。
測試風險
風險分析的目的是及時的調整測試內容和測試方案
軟體專案風險是指在軟體開發過程中遇到的預算和進度等方面的問題以及這些問題對軟體專案的影響，軟體專案的風險主要**於需求、技術、成本和進度
已經納入基線的需求再繼續變更
需求定義不準確，進一步的定義會擴充套件專案範疇
增加額外的需求
產品定義含混的部分比預期需要更多的時間
在做需求中客戶參與不夠
缺少有效的需求變化管理過程
計畫、資源和產品定義全憑客戶或上層領導口頭指令，並且不完全一致
計畫是優化，是「最佳狀態」，但計畫不現實，只能算是「期望狀態」
計畫基於使用特定的的小組成員，而那個特定發的小組成員其實指望不上
產品規模（**行數、功能點、與前一產品規模的百分比）比估計的要大
完成目標日期提前，但沒有相應地調整產品範圍或可用資源
涉足不熟悉的產品領域，花費在設計和實現上的時間比預期的要多
僅由管理層或市場人員進行技術決策，導致計畫進度緩慢，計畫時間延長
低效的專案組結構降低生產率
管理層審查決策的週期比預期的時間長
預算削減，打亂專案計畫
管理層作出了打擊專案組織積極性的決定
缺乏必要的規範，導至工作失誤與重複工作
非技術的第三方的工作(預算批准、裝置採購批准、法律方面的審查、安全保證等)時間比預期的延長
作為先決條件的任務(如培訓及其他專案)不能按時完成
開發人員和管理層之間關係不佳，導致決策緩慢,影響全域性
缺乏激勵措施，士氣低下，降低了生產能力
某些人員需要更多的時間適應還不熟悉的軟體工具和環境
專案後期加入新的開發人員，需進行培訓並逐漸與現有成員溝通，從而使現有成員的工作效率降低
由於專案組成員之間發生衝突，導致溝通不暢、設計欠佳、介面出現錯誤和額外的重複工作
不適應工作的成員沒有調離專案組,影響了專案組其他成員的積極性
沒有找到專案急需的具有特定技能的人
設施未及時到位
設施雖到位，但不配套，如沒有**、網線、辦公用品等
設施擁擠、雜亂或者破損
開發工具未及時到位
開發工具不如期望的那樣有效，開發人員需要時間建立工作環境或者切換新的工具
新的開發工具的學習期比預期的長,內容繁多
客戶對於最後交付的產品不滿意，要求重新設計和重做
客戶的意見未被採納，造成產品最終無法滿足使用者要求，因而必須重做
客戶對規劃、原型和規格的審核決策週期比預期的要長
客戶沒有或不能參與規劃、原型和規格階段的審核，導致需求不穩定和產品生產週期的變更
客戶答覆的時間(如回答或澄清與需求相關問題的時間)比預期長
客戶提供的元件質量欠佳，導致額外的測試、設計和整合工作，以及額外的客戶關係管理工作
矯正質量低下的不可接受的產品，需要比預期更多的測試、設計和實現工作
開發額外的不需要的功能(鍍金)，延長了計畫進度
嚴格要求與現有系統相容，需要進行比預期更多的測試、設計和實現工作
要求與其他系統或不受本專案組控制的系統相連，導致無法預料的設計、實現和測試工作
在不熟悉或未經檢驗的軟體和硬體環境中執行所產生的未預料到的問題
開發一種全新的模組將比預期花費更長的時間
依賴正在開發中的技術將延長計畫進度
設計質量低下，導致重複設計
一些必要的功能無法使用現有的**庫實現，開發人員必須使用新的庫或者自行開發新的功能
**庫質量低下，導致需要進行額外的測試，修正錯誤，或重新製作
過高估計了增強型工具對計畫進度的節省
分別開發的模組無法有效整合，需要重新設計或製作
大量的紙面工作導致程序比預期的慢
前期的質量保證行為不真實，導致後期的重複工作
太不正規(缺乏對軟體開發策略和標準的遵循)，導致溝通不足，質量欠佳，甚至需重新開發
過於正規(教條地堅持軟體開發策略和標準)，導致過多耗時於無用的工作
向管理層撰寫程序報告占用開發人員的時間比預期的多
風險管理粗心，導致未能發現重大的專案風險
基於需求的測試方法是最基本的測試方法，而需求的質量直接影響到後續的開發和測試工作
需求審核
需求測試
測試設計中進行需求測試
需求測試要素：正確性、必要性、完整性、一致性
需求測試應該盡早開始
冒煙測試
版本測試中資訊傳遞：修改內容，風險分析，配置管理
根據測試用例一條一條的執行
缺陷管理
確認回歸內容
確認回歸的方式：手工、自動化
用例的回歸
bug的回歸
回歸測試是自動化測試最好的用處
測試的枯燥性、重複性、引起的惰性
不同的思維模式
交叉測試多在測試的後期，功能基本穩定時執行
在專案測試完畢後，需要出具測試報告
回顧整個測試過程:
需求分析（需求串講、驗證、從設計需求中提取）---測試計畫（測試方案、測試策略）---測試用例編寫（需求測試）---測試執行（冒煙測試、系統測試、回歸測試、交叉測試、自由測試）---測試報告（缺陷分析、測試結論）
測試管理篇
需求分析注意事項 1.測試應盡早介入 介入越早發現問題越早解決問題成本越低 2.不斷變化的需求需要及時的收集和整理 3.沒有需求文件時，需要測試人員不斷的收集原始的客戶需求 4.要有質疑 堅持精神，當需求不明確時，我們可以將需求追溯到終端客戶。分析需求的具體方法 1.需求串講 主要解決問題 需求理解...
軟體測試 測試管理篇
本節內容 測試策略制定 需求，是軟體設計與測試的 需求除了終端使用者的功能需求外，還有設計性需求 可靠性需求 可測試性需求 效能需求 安全性需求等。需求也是要進行測試的。需求，設計，編碼，開發，測試一系列階段中，需求成本最低，測試成本最高。對於測試工作而言，所有的需求最後都需要轉換為測試需求。從測試...
測試管理（管事篇）
管理 管人 管事。說到管理，其實就是團隊，沒有團隊，就談不上管理。個人理解，對個人而言，更多應該是計畫，而非管理。做管理的時間並不長，或者說很短，可能很多地方理解的有問題。寫這篇文章也是為了能更多的與大家交流，也是記錄下在目前這個階段我的理解。本文均以在創業型公司工作為背景 全篇分為管事篇跟管人篇。...