本節內容
測試策略制定
需求，是軟體設計與測試的**。需求除了終端使用者的功能需求外，還有設計性需求、可靠性需求、可測試性需求、效能需求、安全性需求等。需求也是要進行測試的。
需求，設計，編碼，開發，測試一系列階段中，需求成本最低，測試成本最高。
對於測試工作而言，所有的需求最後都需要轉換為測試需求。
從測試需求開始
50%以上的錯誤**於需求的錯誤。
測試需求的識別是後續的測試工作的基礎，也是起點。
測試需求主要**於業務需求。我們在拿到需求後，要能識別測試需求，接著是分析此測試需求，最後確定並提取出測試物件。
提取出了測試物件後，接下來需要確定對每一物件如何進行測試，拿出具體的方法及措施出來，這便是測試策略制定的問題。
完整的需求文件包括以下內容：
需求分析注意事項：
a是軟體測試部負責此日曆行程的測試工程師，在做日程提醒事件測試時，他發現如果手機電力不足（不足於開機），而這段時間正好有提醒事件發生，則在下次開機後不會再提醒，即發生在沒電池時段內的提醒事件會丟失。
而對於這種特殊情況，需求並未有明確定義（需求只定義了到達約定的時間便進行響鈴提醒，並彈出事件視窗）。於是a找到需求、開發討論關於這種特殊情況的處理。開發認為，電力不足的情況下，本來就不可能開機，提醒事件也就不可能彈出來，目前的處理是合理的。需求設計人員認為，如果在不能開機的情況下，提醒事件需在下次開機後進行積累提醒，如果使用者乙個月沒用此機，事務每天又多的話，再次開機後的訊息太多了，光關閉這些事件視窗都不是—件易事，使用者未必歡迎。最後這個問題就此擱淺（掛起）了。
無獨有偶，當該產品上線約一年後，從市場返回一張更改申請單，上面反映「客戶一天晚上，取出機子的電池在機外充電。後來由於忙於其他事情，3天後才再次開啟mp4來使用後發現，這3天內的提醒事件乙個都沒有，導致她把提前3天預訂飛機票的事給忘了，誤了她的一樁大事。後來打**到某公司當地辦事處進行投訴。
注：分析需求的具體方法
快速理解需求的捷徑：需求串講
驗證需求
從設計需求中提取測試需求
測試策略制定
在分析了需求之後，我們要確認測試業務涉及的測試類別：
案例：
測試策略的具體實施
測試策略需要確認測試使用的測試技術、測試過程的管理和控制、測試團隊的組建。
測試策略中包含測試計畫。
測試計畫的制定
根據不同的開發模式，確認測試計畫，計畫主要包括：：什麼人、什麼時間、做什麼事情。 測試的目標要明確，同時要確認跟蹤機制。
測試方案設計
每乙個公司對測試計畫和測試方案的定義都不一樣。而且不是每乙個公司都有測試計畫和測試方案。
測試方案主要包括：
風險分析
分析風險的目的是及時的調整測試內容和測試方案
需求風險
計畫編制風險
組織和管理風險（較深，了解就行）
人員風險
開發環境風險
客戶風險
產品風險
設計和實現風險
測試執行流程的設計
整個測試過程包括： 需求分析—測試計畫—測試方案—需求測試—測試用例編寫—測試執行（冒煙測試，系統測試，回歸測試，交叉測試）—測試報告
根據專案特性制定適合專案的測試執行流程。
需求測試
基於需求的測試方法是最基本的測試方法。而需求的質量直接影響到後續的開發和測試工作。
內部發布版本測試
回歸測試
回歸測試是自動化測試最好的方式
交叉測試
交叉測試多在測試的後期，功能基本穩定時進行
自由測試（探索性測試）
來自於專案的需求，用錯誤推測法來測試。
測試報告的輸出
在專案測試完畢後，需要出具測試報告
測試報告的內容如下：
軟體測試 測試管理篇
本節內容 測試策略制定 需求，是軟體設計與測試的 需求除了終端使用者的功能需求外，還有設計性需求 可靠性需求 可測試性需求 效能需求 安全性需求等。需求也是要進行測試的。需求，設計，編碼，開發，測試一系列階段中，需求成本最低，測試成本最高。對於測試工作而言，所有的需求最後都需要轉換為測試需求。從測試...
測試管理篇
需求分析注意事項 1.測試應盡早介入 介入越早發現問題越早解決問題成本越低 2.不斷變化的需求需要及時的收集和整理 3.沒有需求文件時，需要測試人員不斷的收集原始的客戶需求 4.要有質疑 堅持精神，當需求不明確時，我們可以將需求追溯到終端客戶。分析需求的具體方法 1.需求串講 主要解決問題 需求理解...
測試管理篇
完整的需求文件包括以下內容 需求分析注意事項 分析需求的具體方法 1 快速理解需求的捷徑 需求串講 主要解決的問題 需求理解不一致 方式 介紹需求背景 內容，進行答疑 2 驗證需求 需求文件也需要測試 正確性 必要性 完整性 一致性等。3 從設計需求中提取測試需求 軟體需求是軟體測試需求的主要 但不...