在需求收集/分析階段，需求人員會對用戶的需求進行詳細的分析，形成產品說明書/需求說明文檔，做得更好的可以細化到用例圖，活動圖等UML圖。舉一個例子，下面就是一個游戲人物信息系統的用例圖。
從圖中可以了解這個系統的基本功能，以及各個功能之間的組成。然后可以在測試計劃書中結合產品說明書對此系統功能塊的測試目標進行詳細的描述，從而保證系統重要功能塊的覆蓋面，后面有經驗的案例設計人員會通過測試計劃書設計出合理的案例對功能進行測試。這時我們測試人員還可以起到另一個作用，對需求進行評審，比如丟棄物品功能，大家有不同的見解，這時可以讓需求人員進一步確認用戶是否需要對丟棄物品功能的需求進行修改。不同系統的產品說明書與用例圖總是不同的，不過在測試人員的眼中，它可是用來確定產品是否可以滿足用戶需求的主要標準，我們可以將它提取出來，寫成測試規程，測試規程可以對應一個或多個測試用例。這里主要描述產品需要達到的功能，性能要求，穩定性要求。基本要求就是讓測試在早期的需求分析階段就介入項目，對需求有一個整體的把握，有助于確定后期測試的目標。當然，更高要求是對需求進行評審/測試，論證需求是否可以滿足用戶的要求，從而降低需求帶來的風險。
● 同類需求的一致規范性。在同一個項目中，一些細節需要開發人員統一處理，比如：退出正在編輯的界面，是否彈出提示框；標點符號是用中文半角還是全角；錯誤提示是彈出窗口還是顯示在原界面；錯誤提示語與圖標風格是否統一等等。測試人員（或需求人員）最好能整理出一個列表，通過評審與開發人員達成一致，這樣在后期測試時會避免很多不必要的麻煩，也為產品風格的統一性鋪好了路基。
2.2測試策略/方案/計劃
測試策略
測試策略要解決的問題是根據測試需求、資源配備及工程環境，因地制宜剪裁測試工作，形成測試工作的測試流程。對于一個小項目做大測試是得不償失的，同樣，對一個大項目做小測試也是不負責任的。通常，對于工作量小于5個人月的普通商用軟件，重點應該抓系統測試（包括功能測試、性能測試及GUI測試等）及驗收測試，而不宜鋪排開來，面面俱到。而對于一個工作量接近30個人月的中型商用軟件而言，一般應該認真完成需求驗證、設計驗證、單元測試、集成測試、系統測試及驗收測試，而不宜只關注系統測試。但這并不絕對，針對產品的測試流程設計還需要從用戶的實際需求出發，比如，用戶希望軟件有好的人機交互界面，這時，就應該考慮采用快速原型生成工具來進行用戶界面設計的測試； 又如用戶希望軟件有較好的健壯性，這時，就應該考慮進行相應的負載測試/可恢復性測試等性能測試內容。
一個好的測試策略設計應能清楚地回答下列問題：是否在測試成本與測試預期效果之間達到了最佳平衡？是否在測試需求與測試活動安排之間達到了最佳平衡？策略設計形成的技術路線是否在工程實際與企業質量承諾之間達到了最佳平衡？策略設計形成的技術路線是否具有可行性？有無設計依據？
測試方案
測試方案是對測試策略設計形成的技術路線的進一步細化。如某一技術路線規定了某小型軟件項目測試工作要重點圍繞“功能測試與驗收測試”展開。那么測試方案設計階段就必須具體定義哪些功能需要被測試到，以及如何去測試，哪些部分需要做驗收，以及采用什么形式做。
測試方案的設計除了要明確定義各個測試活動的對象、執行人員、測試進度、放行標準等一系列屬性外，還要充分考慮到成本與技術可行性。一個好的測試方案總是遵循以下設計原則：測試成本與測試工作產生的效益處于最佳比值； 各具體測試活動描述清晰，目標明確，內容完備； 測試手段是可行的； 測試產生的結果是可以用于指導產品質量改進的。
測試計劃
測試計劃是將測試方案具體安排到項目的各個周期中，確定在項目各個周期中具體實施的測試工作。
所以，最終的測試計劃可能包括以下40點：
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 |
標題 | 軟件標識 | 目錄 | 文檔的目的和閱讀人群 | 測試對象描述 | 軟件產品概述 | 相關文檔列表 | 有關的標準/法規 | 可追溯的需求 | 有關的命名約定和標識約定 |
項目相關部門和成員/聯系信息/職責 | 測試項目組和人員/聯系信息/職責 | 假設和依賴 | 項目風險分析 | 測試優先級和重點 | 范圍和測試限制 | 測試過程描述 | 采用的測試方法描述 | 測試環境描述 | 測試環境有效性分析 |
測試環境建立/配置 | 軟件移植性 | 軟件配置管理過程 | 測試數據建立需求 | 系統和錯誤日志描述 /工具 | 缺陷管理/輔助工具 | 自動化測試描述 | 測試工具描述 | 測試腳本/測試代碼維護過程和版本控制 | 跟蹤/解決的工具和流程 |
項目測試度量標準 | 報告需求/測試交付產品 | 軟件入口/出口標準 | 測試周期/標準 | 測試暫停/重啟標準 | 人員分配 | 人員培訓 | 測試地點/場所 | 測試項目組之外可用的資源 | 與所有權相關的級別/分類/安全/許可 |
此階段的難點和重點：
● 測試周期時間點的確定：
△ 實際測試總比你預想的要花更多的時間，遇到更多的麻煩，所以要盡量爭取足夠的測試時間。還要盡可能考慮到測試過程中的風險，比如測試環境的問題、部署失敗的問題、開發延期的問題、人員變動的問題等等。盡量避免不加思索的說這個東西我一星期肯定可以測完。
△ 多參考軟件開發管理類文檔，在測試的時間進度安排上與開發保持同步，如果是整機測試，還需要考慮硬件開發團隊的進度計劃。
● 測試資源的配置：
△ 最常見的就是角色安排多，測試人員少。解決這一問題的根本途徑是招募測試人才，建設高效測試團隊。然而，遠水解不了近渴。那么，就需要考慮一下變通之策：外包和外協都是不錯的處理辦法。
△ 不同部門之間配置專門的接口人負責項目信息的快速有效傳遞，減少人多口雜或信息不流通引起的項目風險。
△ 建議適當考慮自動測試工具，某些工具的確能減少工作壓力。
△ 了解測試團隊各成員的專業技能與興趣也是很重要的，避免無人擔當相應角色。
● 測試標準的設定：
△ 測試標準以用戶需求和功能技術規范文檔為基礎，根據項目不同的實際情況設定不同的標準，切不可一成不變。
△ 盡量提高測試困難部分的標準：如自動化測試工具開發/環境搭建的標準，集成測試的執行規范，性能測試的執行手冊等等。高要求才能出好產品，往往最困難的部分，就是項目成敗的關鍵。同時，也是整個測試團隊需要提升和學習的重點技術。
2.3 測試環境搭建
測試環境（test environment）是指測試運行其上的軟件和硬件環境的描述，以及任何其它與被測軟件交互的軟件，包括驅動和樁。測試環境是指為了完成軟件測試工作所必需的計算機硬件、軟件、網絡設備、歷史數據的總稱。毫無疑問，穩定和可控的測試環境，可以使測試人員花費較少的時間就完成測試用例的執行，也無需為測試用例、測試過程的維護花費額外的時間，并且可以保證每一個被提交的缺陷都可以在任何時候被準確的重現。
簡單的說，經過良好規劃和管理的測試環境，可以盡可能的減少環境的變動對測試工作的不利影響，并可以對測試工作的效率和質量的提高產生積極的作用。
一般來說，按照測試計劃的要求按部就班就可以完成測試工作所需要的軟件/硬件/操作系統/數據配置/接口等環境的搭建。
此階段的難點和重點：
● 測試環境的搭建需要從實際出發：
△ 根據項目的實際需求組成恰當的測試環境，不同的質量標準/行業應用/公司狀態都可能搭建出不同測試環境。搭建環境之前，需要先列出測試計劃中的各種環境需求，然后針對每一個需求進行分析，哪些是目前已有的，哪些是需要請其他部門幫助協調的，然后逐一完成。針對于不能完成的部分，列出對項目的風險以及是否還有其他補救措施等等。
● 測試環境不是一成不變的：
△ 項目實際執行過程中，測試環境是經常變化，比如測試軟件版本更新、測試人員流失等等，需要隨時跟蹤和改進，盡量將可控的資源進行分類整理。可控資源包括：測試環境配置手冊、測試硬件信息、環境變更記錄等等。目的是盡量將測試環境進行備份，方便出現未知問題時快速的還原。
2.4 測試規程/用例設計
測試規程（test procedure）是一個提供詳細的測試用例執行指令的文檔。測試規程應該更注重測試的流程、方法等比較泛的內容，以方便我們對測試用列的編寫有一個整體的概念和把握。不同的公司規范、要求和詳盡程度可能不同。
測試用例（test case）對一項特定的軟件產品進行測試任務的描述，體現測試方案、方法、技術和策略。內容包括測試目標、測試環境、輸入數據、測試步驟、預期結果、測試腳本等，并形成文檔。
測試規程與測試用例的區別：理想化的測試用例確實需要很多測試數據集合，但是現實中對某一軟件進行測試時，由于涉及的面太廣，無法一一列舉出所有數據，所以要根據公司的規范來做相應的調整。所以，測試規程的文檔編輯量較輕，但是只適合熟練的測試人員執行，而測試用例的執行者可以使任何人。
測試用例的設計：
測試用例可以分為基本事件、備選事件和異常事件。
● 設計基本事件的用例：參照用例規約（或設計規格說明書），根據關聯的功能、操作按路徑分析法設計測試用例。而對孤立的功能則直接按功能設計測試用例。基本事件的測試用例應包含所有需要實現的需求功能，覆蓋率達100%。
● 設計備選事件和異常事件的用例：采用的基本方法仍然是等價類劃分、邊界值、因果圖等，根據軟件的不同性質和測試的不同目標靈活運用，至于最終設計的測試用例是否能暴露更多的隱藏缺陷，全憑用例設計人員的豐富經驗和精心設計了。例如，測試一個手機終端的電話本模塊。測試人員需要考慮，將相同的號碼A存儲到不同聯系人名B和C 中，號碼A呼入和呼出時，顯示的聯系人名應該是B還是C呢。類似這樣的備選事件，往往在需求階段描述的并不詳盡，需要測試人員及早提出并與項目組達成一致。
測試用例在軟件測試中的作用 ：
● 指導測試的實施
● 規劃測試數據的準備
● 編寫測試腳本的“設計規格說明書”
● 評估測試結果的度量基準
● 分析缺陷的標準
此階段的難點和重點：
測試用例設計的幾大基本點
● 使用合理的語言
– 測試人員該做什么，系統輸出什么應該寫得很清楚明白，也就是說首先要分清楚測試用例的輸入和預期輸出
– 一種最好的避免含義混淆的方法是在操作步驟中采用動詞+名詞的結構，動詞總是測試人員要做得事情，名詞總是測試人員操作的對象、事物
– 將同一個事物命名為同一個名稱，不管這個事物是否通過不同的方式出現
● 測試用例的易測性
– 簡潔性
簡潔性的衡量方法就是執行測試花費時間的長短以及在測試過程中是否能保持整個測試的純凈
– 正確性
正確性意味著測試人員根據測試用例進行的測試獲得的測試結果（通過或不通過）是正確的
● 控制測試用例的長度
– 在Step-by-step用例中一個比較好的長度是不多于15步：
△ 執行每個測試用例花費更少的時間
△ 測試人員很少犯錯誤、丟失步驟或需要幫助
△ 測試經理能夠準確地估計測試的時間
△ 測試結果更容易跟蹤
● 控制測試用例的操作時間
– 對于Matrix用例，一個好的測試用例的長度的衡量標準是是否能再20分鐘內測試完畢
● 測試用例依賴關系的利弊
– 具有依賴關系的測試用例是一些需要依靠先前的測試用例執行的結果來執行的用例
– 考慮是否真的需要其他的測試的結果作為數據輸入，如果是，那么測試必需是累積的。應盡量避免這種情況
– 保持測試用例依賴關系的正確性和一致性
– 以一種合理的順序來安排測試用例的順序
測試用例設計的五大誤區
● 過分追求“能發現到目前為止沒有發現的缺陷的用例是好的用例”
實際測試中，很多人一心想要設計出發現“難于發現的缺陷”而陷入盲區，忘記了測試的真實目的所在。測試只 需要保證兩點就能達到測試目的：1）、程序做了它應該做的事情 ；2）、程序沒有做它不該做的事情。在做好這兩點基礎上，才談得上改進測試用例，使其“發現沒有的缺陷“。
● 過分抬高測試用例設計標準，達到“使一個沒有接觸過系統的人員也能進行測試“的程度
不知道有沒有公司真正做到這點，能夠將每個測試用例都寫得如此詳細。之前看了微軟關于一個工具的GUI 測試用例，它分了幾部分，第一部分是一些啟動/進入模塊的case，感覺確實很詳細，基本達到能認識英文就能操作的層次。然后在后期關于具體功能測試時，依然出現前置條件（測試環境）不充分的問題，比如在某一部分的Case中，測試環境中要求將文件A 先拷貝到指定目錄下，然后在進行Test Step。在這部分的第一個 Case中有這關測試環境環境的搭建，但是后面幾個Case就沒有了（如果只做后面幾個Case的話，按照Step來操作直接就Fail了）…微軟尚且如此，偶相信其他公司也不會高明到哪里去。
測試的目的是盡可能發現程序中存在的缺陷。每個公司實際情況不同，每個項目的實際情況也不同，所以需要因地制宜，根據實際情況制定測試用例的設計標準。如果項目周期短，工作量大，甚至可以考慮使用測試規程來代替測試用例指導實際的測試執行。
● 測試用例沒有包含實際的數據
先看一個例子，某測試人員需要檢查編輯框內是否不允許輸入英文，他設計的測試步驟為“輸入任意英文字符”。大家覺得是否很熟悉？
測試用例是“一組輸入、執行條件、預期結果”、毫無疑問地應該包括清晰的輸入數據和預期輸出，沒有測試數據的用例最多只具有指導性的意義，不具有可執行 性。當然，測試用例中包含輸入數據會帶來維護、與測試環境同步之類的問題，這就有回到測試用例的設計標準上了，還是那句話：根據實際情況選擇適合自己團隊的規范標準。
● 需求/設計變更，而測試用例確沒有修改
看似明顯的錯誤，卻是在在執行階段經常出現的老毛病。往往在軟件需求和設計已經變更了多次，測試人員覺得這些問題自己知道就行，測試用例沒有任何修改。結果導致新加入的測試人員在執行測試用例不知所措，也使測試用例間接變成一堆廢紙。
● 測試用例中預期輸出過于簡單
很多測試用例中，“預期輸出”僅簡單描述為應用程序的直觀反映，其實，“預期輸出”還需要更深一層的描述。例如，對一個存儲系統， 輸入存儲數據，點擊確定，預期輸出為“系統提示成功”。這樣的用例完整嗎呢？系統提示成功就表示數據成功存儲了？顯然，還需要去相應界面查看數據是否更新。