最后，重要的是，必须收集系统需求。这些是系统的高层次目标，决定着负载测试过程的通过/失败状态。这些一般在与LOB的项目经理工作中达成一致。系统需求包括对以下问题的回答：
1.系统在正常和最高峰时期必须支持多少用户？
2.每秒钟它必须处理多少个事务？
3.对于可业务关键事务最大和最小可接受的响应时间是多少？
4.用户群体如何联系？
5.生产中系统承受的工作负载是什么？以及混合的事务？
团队需求是进展到构建阶段前需要解决的最后一个问题。这只不过是决定适合的性能团队成员来参与到未来的负载测试。最初，这也许被自动的确定（例如，当只有一个团队）。然而，如果性能测试成为卓越中心（CoE）的一部分，那么资源分配，内部后勤就应该在设计阶段考虑和解决。
预先收集一套完整的业务，技术，系统，和团队需求是使负载测试有效和成功的基础。
构建
构建阶段将在设计阶段确定的业务过程和工作负载转变为自动化组件，这部分可以驱动可重复的，实际的负载。这可以分为两个方面：自动化设置和环境设置。自动化设置是由性能工程师完成的一系列连续的工作。
1.脚本：将确定的业务过程记录为自动脚本。
2.事务：插入定时器来产生业务所需的逻辑计时。
3.参数化：用一个池替代所有的输入数据，例如ID和密码，这样每个虚拟用户用唯一的数据访问应用。
4.场景：通过给用户组分配不同的脚本，连通性和用户行为等方法，创建生产工作负载。
5.监测器：确定负载下所要监控的服务器或机器。
环境设置由执行成功，现实的负载测试所需的硬件，软件，和数据组成。这些可能涉及到系统，DBA，运营和业务团队。
构建阶段的最终成果就是可以执行在可用的，已配置的环境上的一系列自动化“资产”。
执行
对于刚接触性能测试的新手来说，经常存在一个误解，就是执行是一个单一事件。实际上，它是一个由多种类型的性能测试组成的多步骤的过程。每种测试都提供了理解发布应用所带来风险的必要信息。负载测试的类型包括：
1.基线测试验证了系统和其周围环境可在合理的技术参数下运行。性能测试按5到10个用户执行，作为最终用户事务性能的基线。这些测试应该在性能测试的开始和结束时执行，来测量响应时间的绝对改进。
2.性能测试在环境中模仿负载，并确定系统可以支撑的最佳和最大用户数量。这些测试应该仿效平均和峰值时间的生产用法，他们应当最大限度地仿真用户的真实行为，例如思考时间，调制解调器的仿真，和各种类型的浏览器。同时，采用其它专用的监控和诊断工具，有效地查看系统内部行为，诊断系统衰变和瓶颈。
3.基准测试被设计来测量和对比理想情况下的各种机器类型，环境，或应用的版本。当系统经过扩展性测试后，执行这些测试可以帮助了解不同体系结构的影响。
4.渗透测试被设计用于在长时间的负载下检测系统的执行情况。
5.峰值测试被设计用于模拟系统在峰值负载下运行一段时间来保证应用和其硬件可以在合理的时间段内支持高负载
<<上一页
1
2
3
下一页>>
