以前在某公司离职时，老大建议我写一个测试分析方法的文档，当时时间比较近只是做了一个分析图和简单的描述，今天整理以前的文档拿出来和大家再次分享并完善了一下内容。
上面这个测试分析图展示的在一个全新的项目开始准备测试时，如果进行测试分析的基本方法。
在开始接手一个新项目时，按照基本的测试生命周期流程（编写测试计划-测试方案-准备测试环境-编写测试用例-编写测试脚本-执行测试-反馈缺陷-调整或完善测试用例-回归测试-收集测试结果-编写测试报告）
在编写测试计划和测试方案前，应该还有个测试初始阶段-主要工作就是了解和分析系统，这是一个学习成本。在传统的开发方法和敏捷开发方法这个阶段的启动时间不同，在传统的开发方法中可能要等待需求说明书出来之后进行测试需求的分析，来确定测试范围，根据范围编写测试计划。 敏捷开发方法由于测试人员在需求讨论，那么了解和分析系统的事情在敏捷的需求讨论时就完成，而不在需要再等待需求说明书等需求文档。
不管是传统或是敏捷的开发方法，测试初始阶段都是理解测试需求，根据理解的需求准备相关的测试工作。 那么如何理解需求并根据需求来编写测试计划和测试方案？这就是本文重点要阐述的一些方法：
1、确定范围，任何产品的需求无非两种类型：功能需求和非功能需求
单元测试范围通常包括：单元功能正确性测试、单元功能容错性测试、单元代码结构性测试、单元测试代码性能测试
集成测试范围包括：模块或服务功能正确性，模块或服务接口一致性、模块或服务容错性、模块或服务的性能等
系统测试范围包括：系统可用性测试、系统稳定性测试、系统安全性测试、系统业务能力测试等等
当然还有用户验收测试： 用户核心业务支持能力测试等等
2、确定测试点，也就是确定测试具体内容：
测试通常是有测试参照物，例如需求分析，概要设计，详细设计等。
如何确定测试点，也就是如何分析测试需求并找出测试规则， 根据不同的系统对测试人员的技能也有不同的要求：
例如：
测试一个业务系统，在集成测试和系统测试、验收测试阶段的测试点分析和提取，测试人员需要充分的了解这个系统要支撑的业务规范或规则，例如保险系统，证券系统，ERP系统等等。 这类系统测试要求测试人员更偏重于业务的知识。举个证券的清算系统，测试它就要业务清算规则和流程。
测试一个技术性系统，例如云计算的测试，BI系统的测试，中间件的测试，网关系统的测试， 这类系统的技术性比较强，他的测试点或测试规则对应的是技术规范或技术规则。比如多媒体消息网关系统的测试，需要多种消息的传递和路由规则。不同协议消息的构造和解析规则。 些测试对测试人员的技术要求更强。
