一、性能测试接口文档准入
1、系统架构设计文档（系统基础架构图、业务架构图、数据流图）
2、非功能性需求文档（性能测试指标如：PV、用户数、TPS、并发、响应时间、系统峰值CPU、内存消耗…等等）
3、资源动作分解表（申请压测环境，包含硬件配置及数量信息）
4、测试场景（核心业务）
二、准备系统环境：
1、生产环境
生产环境衡量的精准度更高，但是需要删除测试生成的日志等测试数据，同时要保证数据删除的完整性，基础数据的构造参考后续数据量部分生产环境压测时，尽量挑选低峰期进行，避免对生产业务产生影响
2、测试环境
风险可控，但是环境构建比较复杂，规模和生产一致的成本是最高的。理想状态下的比例是测试：生产=1：2或测试测试：生产1：4（这里的比例是整体架构的数量或者硬件配置，但基础架构不能改变）
但是当现实条件不满足时，也可以在生产部分应用独立部署测试集群、数据库共用进行测试。如若搭建压测环境，在环境搭建完成之后，需要从生产脱敏导入基础数据，一般存量数据为三年、测试用例数据查询类交易至少准备5w条，提交类每条数据应不重复，nas等存储数据需准备三年业务量（如若业务量的归档时间小于三年，则按照归档时间准备）
三、测试计划
测试计划尽量简洁明了，并将每个任务的具体负责人交代清楚。划分任务时，条理要清晰，按照整个性能测试的流程的进行划分一般持续迭代的项目按一周作为项目周期，以一周后为结束时间，向前推。 新项目的时间一般为两到三周，具体时间具体对待
四、测试方案
通过前期的接口文档中得到的信息，编写测试方案，其中包括本次测试的背景、目的、指标、测试范围、系统架构…等等信息。出测试方案时，不是简单的登记信息就完了，还需要理解系统的整体架构，核心业务流程等等。只有这样，在面对可能出现的性能问题时或其他问题时，才会得心应手，无所畏惧
五、测试执行
1、测试脚本
测试脚本分两种。一种是录制脚本，主要针对业务系统。另一种是接口类脚本，根据研发提供的接口文档编写对应得脚本脚本的部分没啥好说的，与研发积极沟通，把脚本调通就完了
#软件测试工程师##软件测试##性能测试#
1、系统架构设计文档（系统基础架构图、业务架构图、数据流图）
2、非功能性需求文档（性能测试指标如：PV、用户数、TPS、并发、响应时间、系统峰值CPU、内存消耗…等等）
3、资源动作分解表（申请压测环境，包含硬件配置及数量信息）
4、测试场景（核心业务）
二、准备系统环境：
1、生产环境
生产环境衡量的精准度更高，但是需要删除测试生成的日志等测试数据，同时要保证数据删除的完整性，基础数据的构造参考后续数据量部分生产环境压测时，尽量挑选低峰期进行，避免对生产业务产生影响
2、测试环境
风险可控，但是环境构建比较复杂，规模和生产一致的成本是最高的。理想状态下的比例是测试：生产=1：2或测试测试：生产1：4（这里的比例是整体架构的数量或者硬件配置，但基础架构不能改变）
但是当现实条件不满足时，也可以在生产部分应用独立部署测试集群、数据库共用进行测试。如若搭建压测环境，在环境搭建完成之后，需要从生产脱敏导入基础数据，一般存量数据为三年、测试用例数据查询类交易至少准备5w条，提交类每条数据应不重复，nas等存储数据需准备三年业务量（如若业务量的归档时间小于三年，则按照归档时间准备）
三、测试计划
测试计划尽量简洁明了，并将每个任务的具体负责人交代清楚。划分任务时，条理要清晰，按照整个性能测试的流程的进行划分一般持续迭代的项目按一周作为项目周期，以一周后为结束时间，向前推。 新项目的时间一般为两到三周，具体时间具体对待
四、测试方案
通过前期的接口文档中得到的信息，编写测试方案，其中包括本次测试的背景、目的、指标、测试范围、系统架构…等等信息。出测试方案时，不是简单的登记信息就完了，还需要理解系统的整体架构，核心业务流程等等。只有这样，在面对可能出现的性能问题时或其他问题时，才会得心应手，无所畏惧
五、测试执行
1、测试脚本
测试脚本分两种。一种是录制脚本，主要针对业务系统。另一种是接口类脚本，根据研发提供的接口文档编写对应得脚本脚本的部分没啥好说的，与研发积极沟通，把脚本调通就完了
#软件测试工程师##软件测试##性能测试#
