许多人说，面向过程的工作是成功的关键。虽然我非常赞成这个说法，但我总是纳闷为什么人们对于性能测试的7个要点并没有特别关注，而这7个要点能左右性能测试项目的成败。
当一个测试人员被分配到性能测试项目组，项目经理会让他/她做的第一件事就是着手准备测试计划。但在测试计划的准备阶段，测试经理及其属下在准备文档时通常会掉以轻心，文档的大部分内容要么是从以前的项目中复制过来的，要么是从网上找来的任意模板；对测试计划中提到的需求说明不予任何关注就直接转移到下一阶段了。不可否认的是：作为公司流程标准中的必须项，测试计划通常只流于形式；因此它从来没有真正用于连接项目的执行。
我想说的是，用来准备测试计划的时间是整个项目实施期间非常有价值的部分。但不幸的是，所有这些多半都只是在理论上说说，很少用于实践。因此测试人员通常不会把测试活动和测试计划紧密的结合到一起，因为每个测试计划的实施都会受与此过程相关的费用影响，而且他们认为测试计划会延缓测试活动。
这无疑是一件坏事，但即使你否定了这个项目计划阶段—若测试工程师在项目执行阶段认真遵循性能测试的7个要点，我觉得我们还是能在最后看到希望。
7个要点：
1、知道SLA指的是什么。
SLA 服务等级协议
定义
SLA：Service-Level Agreement的缩写，意思是服务等级协议。 服务等级协议是关于网络服务供应商和客户间的一份合同，其中定义了服务类型、服务质量和客户付款等术语。 SLA: SoftWare License Agreement的缩写,意思也可为软件许可协议,像著名的GPL,BSD等均为典型代表. SLA: Second Language Acquisition的缩写，意思是第二语言习得。项目
典型的SLA 包括以下项目： 分配给客户的最小带宽； 客户带宽极限； 能同时服务的客户数目； 在可能影响用户行为的网络变化之前的通知安排； 拨入访问可用性； 运用统计学； 服务供应商支持的最小网络利用性能，如99.9%有效工作时间或每天最多为1分钟的停机时间。 各类客户的流量优先权； 客户技术支持和服务； 惩罚规定，为服务供应商不能满足 SLA 需求所指定。要求
按照 SLA 要求，服务供应商采用多种技术和解决方案去监控和管理网络性能及流量，以满足 SLP 中的相关需求，并产生对应的客户结果报告。 另一方面，客户本身也提出了自己的技术及解决方案去监控邻居的流量和服务，以确保提供他们答应的传送服务项目。 SLA概念已被大量企业所采纳，作为公司 IT 部门的内部服务。大型企业的 IT 部门都规范了一套服务等级协议，以衡量、确认他们的客户（企业其他部门的用户）服务，有时也与外部网络供应商提供的服务进行比较。定义
SLA 服务水平协议（简称：SLA，全称：service level agreement）是在一定开销下为保障服务的性能和可靠性，服务提供商与用户间定义的一种双方认可的协定。通常这个开销是驱动提供服务质量的主要因素。内容
一个完整的SLA同时也是一个合法的文档，包括所涉及的当事人、协定条款(包含应用程序和支持的服务)、违约的处罚、费用和仲裁机构、政策、修改条款、报告形式和双方的义务等。同样服务提供商可以对用户在工作负荷和资源使用方面进行规定。保障
传统上，SLA包含了对服务有效性的保障，譬如对故障解决时间、服务超时等的保证。但是随着更多的商业应用在Internet的广泛开展，越来越需要SLA对性能（如响应时间）作出保障。这种需要将会随着越来越多的商业在Internet 的开展而重要起来。实际上，SLA的保障是以一系列的服务水平目标（SLO）的形式定义的。服务水平目标是一个或多个有限定的服务组件的测量的组合。一个SLO被实现是指那些有限定的组件的测量值在限定范围里。SLO有所谓的操作时段，在这个时间范围内，SLO必须被实现。但是由于Internet的统计特性，不可能任何时候都能实现这些保障。因此SLA一般都有实现时间段和实现比例。实现比例被定义为SLA必须实现的时间与实现时段的比值。例如：在工作负荷<100 transaction/s前提下，早上8点到下午5点服务响应时间<85ms，服务有效率>95%，在一个月内的总体实现比例 <97%。
2、了解真实用户的使用模式。
3、知道如何加载服务器。
4、知道负荷服务器的最大负荷量。
5、明白自动化测试需要包含哪些类型。
6、了解你的测试工具以最大化其功能。
7、了解你的测试环境。
你只要在脑海中牢牢记住这些要点是专业范畴内的一部分。你既不需要把这些归档，也不用把它们交付客户，你只需要实践。因为最后，客户既不会想知道你的负载测试计划有多好或多坏，也不会因你遵循的标准不同而生气，相反，客户在意的是你提交的结果的准确度和这些统计资料对改善应用程序的性能有多大帮助。相信我，深入了解这些要点的每个方面并认真执行，对得到负载测试的真实结果肯定会有所帮助。