一、前期准备工作
1、系统基础功能验证
性能测试在什么阶段适合实施？切入点很重要！一般而言，只有在系统基础功能测试验证完成、系统趋于稳定的情况下，才会进行性能测试，否则性能测试是无意义的。
2、测试团队组建
根据该项目的具体情况，组建一个几人的性能测试team，其中DBA是必不可少的，然后需要一至几名系统开发人员（对应前端、后台等），还有性能测试设计和分析人员、脚本开发
和执行人员；在正式开始工作之前，应该对脚本开发和执行人员进行一些培训，或者应该由具有相关经验的人员担任。
3、工具的选择
综合系统设计、工具成本、测试团队的技能来考虑，选择合适的测试工具，最起码应该满足一下几点：
①支持对web（这里以web系统为例）系统的性能测试，支持http和https协议；
②工具运行在Windows平台上；
③支持对webserver、前端、数据库的性能计数器进行监控；
4、预先的业务场景分析
为了对系统性能建立直观上的认识和分析，应对系统较重要和常用的业务场景模块进行分析，针对性的进行分析，以对接下来的测试计划设计进行准备。
需求分析：
整体流程图：
需求提取 -> 需求分析 -> 需求评审 -> 更新后的测试需求跟踪xmind
分析流程：
- 需求提取：
1.1 分析依据（包括：需求矩阵、产品交互图、需求说明书）
1.2 获取需求的纬度
1.2.1客户价值{
可以为客户带来哪些价值？
可以解决哪些问题？
根据以上问题定位功能是否合理
}
1.2.2 UI功能 - 展示功能
1.2.3 模块关联-历史模块{
新功能模块关联
考虑是否关联？耦合部分是否需要支持？
}
1.2.4 客户使用场景-部署方式{
网络特性
客户使用服务器常见外设
}
1.2.5 性能参数-性能要求{
网卡最低速率
}
1.2.6 硬件支持
1.3 输出（提取最原始的测试需求）
- 需求分析：
分析依据（五维分析）
●用户场景
--功能是否和场景强关联
--网络拓扑能否满足客户需求
--和竞争对手比较差异
--功能是否能满足客户实际应用场景
--是否考虑了用户的实际操作
●明确性
--范围明确性（参数、类型长度范围）
--清晰性限制等范畴
--无法预知影响的需求提出进行确定，风险
●二义性
--概念模糊【大概念、第三方支持、与上个版本相同】
--支持与不支持等范畴
--一个需求描述能出现多种理解
●完整性
--需求一致性【用户需求、需求规格、需求矩阵三者是否同意】
--需求完整【隐形需求】
--关联性【与新老功能、与外置软件设备】
●可测试性
--实现测试需要的工具、方法【调试、接口命令】
--定位方式【日志等形式观察】
--复杂环境、容量边界、操作时过程不可见
●输出
1、测试需求跟踪
2、缺陷预防bug
3、工具需求
4、整理出明确的需求点
5、测试地图
●分析思路误区：需求和实现的区别【现有需求才有代码实现，不能把代码实现当作需求】
●需求分析的意义
1、明确产品给客户带来的价值
2、明确产品支持和不支持的功能
3、明确产品各个功能的约束性
4、知道开发实现功能
5、知道测试分析和产出测试点
二、测试计划
测试计划阶段最重要的是分析用户场景，确定系统性能目标。
1、性能测试领域分析
根据对项目背景，业务的了解，确定本次性能测试要解决的问题点；是测试系统能否满足实际运行时的需要，还是目前的系统在哪些方面制约系统性能的表现，或者，哪些系统因素导致
系统无法跟上业务发展？确定测试领域，然后具体问题具体分析。
2、用户场景剖析和业务建模
根据对系统业务、用户活跃时间、访问频率、场景交互等各方面的分析，整理一个业务场景表，当然其中最好对用户操作场景、步骤进行详细的描述，为测试脚本开发提供依据。
3、确定性能目标
前面已经确定了本次性能测试的应用领域，接下来就是针对具体的领域关注点，确定性能目标（指标）；其中需要和其他业务部门进行沟通协商，以及结合当前系统的响应时间等数据，确定
最终我们需要达到的响应时间和系统资源使用率等目标；比如：
①登录请求到登录成功的页面响应时间不能超过2秒；
②报表审核提交的页面响应时间不能超过5秒；
③文件的上传、下载页面响应时间不超过8秒；
④服务器的CPU平均使用率小于70%，内存使用率小于75%；
⑤各个业务系统的响应时间和服务器资源使用情况在不同测试环境下，各指标随负载变化的情况等；
4、制定测试计划的实施时间
预设本次性能测试各子模块的起止时间，产出，参与人员等等。
-博客园：[老_张]