以前在某公司離職時，老大建議我寫一個
測試分析方法的文檔，當時時間比較近只是做了一個分析圖和簡單的描述，今天整理以前的文檔拿出來和大家再次分享并完善了一下內容。
上面這個測試分析圖展示的在一個全新的項目開始準備測試時，如果進行測試分析的基本方法。
在開始接手一個新項目時，按照基本的測試生命周期流程（編寫測試計劃-測試方案-準備測試環境-編寫測試用例-編寫測試腳本-執行測試-反饋缺陷-調整或完善測試用例-回歸測試-收集測試結果-編寫測試報告）
在編寫測試計劃和測試方案前，應該還有個測試初始階段-主要
工作就是了解和分析系統，這是一個
學習成本。在傳統的開發方法和
敏捷開發方法這個階段的啟動時間不同，在傳統的開發方法中可能要等待需求說明書出來之后進行測試需求的分析，來確定測試范圍，根據范圍編寫測試計劃。 敏捷開發方法由于測試人員在需求討論，那么了解和分析系統的事情在敏捷的需求討論時就完成，而不在需要再等待需求說明書等需求文檔。
不管是傳統或是敏捷的開發方法，測試初始階段都是理解測試需求，根據理解的需求準備相關的測試工作。 那么如何理解需求并根據需求來編寫測試計劃和測試方案？這就是本文重點要闡述的一些方法：
1、確定范圍，任何產品的需求無非兩種類型：功能需求和非功能需求
測試需求范圍確定按照測試不同階段進行分層劃分為：
單元測試范圍、集成測試范圍、
系統測試范圍、驗收測試范圍；
單元測試范圍通常包括：單元功能正確性測試、單元功能容錯性測試、單元代碼結構性測試、單元測試代碼
性能測試 集成測試范圍包括：模塊或服務功能正確性，模塊或服務接口一致性、模塊或服務容錯性、模塊或服務的性能等
系統測試范圍包括：系統可用性測試、系統穩定性測試、系統安全性測試、系統業務能力測試等等
當然還有用戶驗收測試： 用戶核心業務支持能力測試等等
2、確定測試點，也就是確定測試具體內容：
測試通常是有測試參照物，例如需求分析，概要設計，詳細設計等。
如何確定測試點，也就是如何分析測試需求并找出測試規則， 根據不同的系統對測試人員的技能也有不同的要求：
例如：
測試一個業務系統，在集成測試和系統測試、驗收測試階段的測試點分析和提取，測試人員需要充分的了解這個系統要支撐的業務規范或規則，例如保險系統，證券系統，ERP系統等等。 這類系統測試要求測試人員更偏重于業務的知識。舉個證券的清算系統，測試它就要業務清算規則和流程。
測試一個技術性系統，例如
云計算的測試，BI系統的測試，中間件的測試，網關系統的測試， 這類系統的技術性比較強，他的測試點或測試規則對應的是技術規范或技術規則。比如多媒體消息網關系統的測試，需要多種消息的傳遞和路由規則。不同協議消息的構造和解析規則。 些測試對測試人員的技術要求更強。
3、測試執行準備和場景設計時 ，也就是設計測試用例和測試場景時要充分考慮系統的技術特點。
根據系統的設計和技術特點，來決定如何測試一個測試點或一個測試規則、一個場景。
根據測試點和系統架構和技術輸入，要有如下輸入：
1）測試上下文環境準備
2）測試數據構造（測試數據按照類型分為，直接輸入數據、規則數據、背景數據）
3）測試調用方法
4） 測試結果驗證方法和測試結果截取方法
4、確定工作量
測試分析基本是由大到小，由外到里的分析方法
確定大范圍，規則細分，技術確認 最后就要估算測試工作量
通常估算單個測試點的工作量再匯總的方式比較準確。
小結： 測試分析能力是保證被測試系統被正確測試的保證， 測試分析就要確定測試范圍和測試方法。 范圍和方法決定了測試的正確性與否。 針對不同系統的測試分析時，對測試人員的技能有專向要求和知識儲備。不要希望業務系統測試人員，能夠做好云系統的測試。