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