本節內容
測試策略制定
需求，是軟體設計與測試的**。需求除了終端使用者的功能需求外，還有設計性需求、可靠性需求、可測試性需求、效能需求、安全性需求等。需求也是要進行測試的。
需求，設計，編碼，開發，測試一系列階段中，需求成本最低，測試成本最高。
對於測試工作而言，所有的需求最後都需要轉換為測試需求。
從測試需求開始
50%以上的錯誤**於需求的錯誤。
測試需求的識別是後續的測試工作的基礎，也是起點。
測試需求主要**於業務需求。我們在拿到需求後，要能識別測試需求，接著是分析此測試需求，最後確定並提取出測試物件。
提取出了測試物件後，接下來需要確定對每一物件如何進行測試，拿出具體的方法及措施出來，這便是測試策略制定的問題。
完整的需求文件包括以下內容：
需求分析注意事項：
a是軟體測試部負責此日曆行程的測試工程師，在做日程提醒事件測試時，他發現如果手機電力不足（不足於開機），而這段時間正好有提醒事件發生，則在下次開機後不會再提醒，即發生在沒電池時段內的提醒事件會丟失。
而對於這種特殊情況，需求並未有明確定義（需求只定義了到達約定的時間便進行響鈴提醒，並彈出事件視窗）。於是a找到需求、開發討論關於這種特殊情況的處理。開發認為，電力不足的情況下，本來就不可能開機，提醒事件也就不可能彈出來，目前的處理是合理的。需求設計人員認為，如果在不能開機的情況下，提醒事件需在下次開機後進行積累提醒，如果使用者乙個月沒用此機，事務每天又多的話，再次開機後的訊息太多了，光關閉這些事件視窗都不是—件易事，使用者未必歡迎。最後這個問題就此擱淺（掛起）了。
無獨有偶，當該產品上線約一年後，從市場返回一張更改申請單，上面反映「客戶一天晚上，取出機子的電池在機外充電。後來由於忙於其他事情，3天後才再次開啟mp4來使用後發現，這3天內的提醒事件乙個都沒有，導致她把提前3天預訂飛機票的事給忘了，誤了她的一樁大事。後來打**到某公司當地辦事處進行投訴。
分析需求的具體方法
快速理解需求的捷徑：需求串講
主要解決問題：需求理解不一致
方式：介紹需求背景、內容、進行答疑
驗證需求
需求文件也要測試：正確性、必要性、完整性、一致性等。
從設計需求中提取測試需求
測試策略制定
在分析了需求之後，我們要確認測試業務涉及的測試類別：
測試策略的具體實施
測試策略需要確認測試使用的測試技術、測試過程的管理和控制、測試團隊的組建。
根據測試的需求，選擇測試技術；
在測試方案中，需要確認測試過程如何管理，確認管理使用的工具和方法。
測試過程的管理：即是測試流程，不同公司的流程是不一樣的。
在沒有固定測試團隊的企業，還需要考慮團隊的組建，比如測試的人數，高中低階的配比，入場出廠時間等等。
測試策略中包含測試計畫。
測試計畫的制定
根據不同的開發模式，確認測試計畫，計畫主要包括：：什麼人、什麼時間、做什麼事情。 測試的目標要明確，同時要確認跟蹤機制。
測試計畫評審通過後，測試組需嚴格按計畫中的時間完成各項任務。如果delay會直接影響績效工資，如果多次嚴重出現可能會失去這次工作機會，對後期找工作有負面影響。
測試方案設計
每乙個公司對測試計畫和測試方案的定義都不一樣。而且不是每乙個公司都有測試計畫和測試方案。
測試方案主要包括：
- 測試範圍：由需求分析而來
- 測試策略：包括針對不同部分的測試方法、測試用例
- 測試控制：包括測試流程，測試執行，缺陷跟蹤
- 其他：環境、版本管理（配置管理和變更管理）
- 測試風險：螺旋模型強調的是風險。
風險分析
分析風險的目的是及時的調整測試內容和測試方案
軟體專案風險是指在軟體開發過程中遇到的預算和進度等方面的問題以及這些問題對軟體專案的影響。
軟體專案的風險主要立案源於需求、技術、成本和進度。
需求風險
- 已經納入基線的需求在繼續變更
- 需求定義不準確，進一步的定義會擴充套件專案範圍
- 增加額外的需求
- 產品定義含混的部分比預期需要更多的時間
- 在做需求中客戶參與不夠
- 缺少有效的需求變化管理過程
計畫編制風險
- 計畫、資源和產品定義全憑客戶或上層領導口頭指令,並且不完全一致。
- 計畫是優化的,是」最佳狀態」,但計畫不現實,只能算是」期望狀態」
- 產品規模(**行數、功能點、與前一產品規模的百分比)比估計的要大
- 完成目標日期提前,但沒有相應地調整產品範圍或可用資源
- 涉足不熟悉的產品領域,花費在設計和實現上的時間比預期的要多
組織和管理風險（較深，了解就行）
- 僅由管理層或市場人員進行技術決策,導致計畫進度緩慢,計畫時間延長
- 低效的專案組結構降低生產率
- 預算削減,打亂專案計畫
- 缺乏必要的規範,導至工作失誤與重複工作
人員風險
- 作為先決條件的任務(如培訓及其他專案)不能按時完成
- 開發人員和管理層之間關係不佳,導致決策緩慢,影響全域性
- 缺乏激勵措施,士氣低下,降低了生產能力
- 某些人員需要更多的時間適應還不熟悉的軟體工具和環境
- 沒有找到專案急需的具有特定技能的人
開發環境風險
- 設施未及時到位
- 設施雖到位，但不配套
- 設施擁擠。雜亂或者破損
- 開發工具未及時到位
- 新的開發工具的學習期比預期的長,內容繁多
客戶風險
- 客戶對於最後交付的產品不滿意,要求重新設計和重做
- 客戶對規劃、原型和規格的審核決策週期比預期的要長
產品風險
- 嚴格要求與現有系統相容,需要進行比預期更多的測試、設計和實現工作
- 要求與其他系統或不受本專案組控制的系統相連,導致無法預料的設計、實現和測試工作
- 開發一種全新的模組將比預期花費更長的時間
- 依賴正在開發中的技術將延長計畫進度
設計和實現風險
- 設計質量低下，導致重複設計
- 一些必要的功能無法使用現有的**庫實現,開發人員必須使用新的庫或者自行開發新的功能
- **庫質量低下,導致需要進行額外的測試,修正錯誤,或重新製作
- 過高估計了增強型工具對計畫進度的節省
- 分別開發的模組無法有效整合,需要重新設計或製作
測試執行流程的設計
整個測試過程包括：
需求分析—測試計畫—測試方案—需求測試—測試用例編寫—測試執行（冒煙測試，系統測試，回歸測試，交叉測試）—測試報告
根據專案特性制定適合專案的測試執行流程。
測試方案與用例的設計，是屬於純測試技術上的設計，但對於整個專案的測試過程，光有技術還不夠，需要配合合適的測試流程。
好的策劃可以對專案的測試起到事半功倍的作用。
需求測試
基於需求的測試方法是最基本的測試方法。而需求的質量直接影響到後續的開發和測試工作。
- 需求審核
- 需求測試
- 測試設計中進行需求測試
- 需求測試的要素：正確性、必要性、完整性、一致性。
- 需求測試應該盡早開始。
內部發布版本測試
回歸測試
回歸測試是自動化測試最好的方式
交叉測試
交叉測試多在測試的後期，功能基本穩定時進行
自由測試（探索性測試）
來自於專案的需求，用錯誤推測法來測試。
測試報告的輸出
在專案測試完畢後，需要出具測試報告
測試報告的內容如下：
- 測試概括
- 測試過程分析
- 測試結論
- 缺陷清單
最重要的是：缺陷的分析（是功能還是設計或其他方面的缺陷）
軟體測試 管理篇
本節內容 測試策略制定 需求，是軟體設計與測試的 需求除了終端使用者的功能需求外，還有設計性需求 可靠性需求 可測試性需求 效能需求 安全性需求等。需求也是要進行測試的。需求，設計，編碼，開發，測試一系列階段中，需求成本最低，測試成本最高。對於測試工作而言，所有的需求最後都需要轉換為測試需求。從測試...
測試管理篇
需求分析注意事項 1.測試應盡早介入 介入越早發現問題越早解決問題成本越低 2.不斷變化的需求需要及時的收集和整理 3.沒有需求文件時，需要測試人員不斷的收集原始的客戶需求 4.要有質疑 堅持精神，當需求不明確時，我們可以將需求追溯到終端客戶。分析需求的具體方法 1.需求串講 主要解決問題 需求理解...
測試管理篇
完整的需求文件包括以下內容 需求分析注意事項 分析需求的具體方法 1 快速理解需求的捷徑 需求串講 主要解決的問題 需求理解不一致 方式 介紹需求背景 內容，進行答疑 2 驗證需求 需求文件也需要測試 正確性 必要性 完整性 一致性等。3 從設計需求中提取測試需求 軟體需求是軟體測試需求的主要 但不...