引用来源
① 步骤一. 标识识别关键场景
从性能的观点来定义被测试程序的场景，如果你已经有了用例和用户描述的文档，你可以用这些文档来定义你的场景，关键场景包含以下2个：
1) 关键场景
关键场景需要指定性能预期值和需求，有些已经包含在SLAs（服务水平协议）中，有些需要特定的性能目标。
2) 重要场景
重要场景一般没有指定性能目标，如响应时间目标等，但他们可以影响其他关键场景。鉴别重要场景主要的几个特征。
并行运行的场景。
经常被执行的场景。
占高比例操作的场景。
预期需要消耗的系统资源场景。
不要忽视重要场景，重要场景会影响到你的关键场景是否能满足性能目标。同时，要记得考虑如果众多不同并发用户运行不同的关键场景和重要场景的时候，被测试系统的会表现的怎么样。这个“并行集成”经常驱使你程序单元工作的决定。例如，保持的响应及时，你可能需要同时提交在线物品订单。
② 标识负载
明确本程序的需要支持的人数，同时在线人数和并发数量。
负载时从市场数据推导出来的，包含以下这些：
所有用户。
并发活动活跃用户。
数据容量
事务容量和混合事务
在性能模型里面，需要识别负载在每一个单独场景中的作用，例如：
你可能需要支持100个并发浏览用户。
你可能需要支持100个并发订单处置的用户。
注意：
并发用户：是那种严格同一时间点击一个网站的用户。
同时用户：同时活跃连接访问同一个网站的用户。
③ 标识性能目标
为每一个关键场景定义一个性能目标，这些性能目标来自于业务需求。
在步骤1定义的场景中，写下每一个场景的性能目标。
性能目标由业务需求决定。
性能目标包含以下内容。
响应时间，如产品目录必须在3秒内展示。
吞吐量，如系统必须支持每一秒完成100个交易。
资源利用率，一个经常忽略的问题是被测试系统消耗了多少资源，例如，CPU，内存，磁盘I/O和网络I/O。
在建立性能目标的时候考虑以下问题：
负载需求。
服务水平协议。
响应时间。
项目增长。
项目的生命周期。
项目增长，你需要考虑6个月或1年后之后你的设计是否还能满足项目的需求，如果你的项目生命周期是6个月的话，你会因为性能去扩展你的系统吗？如果你的系统肯能有一个长的生命周期的话，你打算花什么样的代价去做性能维护。
④ 标识预算
标识你的预期和限制条件，包含每一个操作必须完成的最长的时间还有资源利用率限制，包含CPU，内存，磁盘I/O和网络I/O。
预算其实就是限制，例如，多长时间完成一个操作是可以接受的，超出这个时间的话，你的应用系统就达不到性能目标。
你的预期通常由下面的术语来定义：
执行时间。
资源利用。
执行时间
你的执行时间包含最大限度的时间必须包含单独的操作
资源利用
资源利用需求定义了每一类资源的利用率的阈值，例如，处理器的峰值是限制在75%，同时内存消耗不能超过50MB，一般的资源包含：
CPU。
内存。
网络I/O。
磁盘I/O。
执行时间和资源利用状况在性能目标的上下文环境中是很有作用的。预期目标有几个方向的。其他因素需要考虑到有 ：
网络，网络需要考虑的因素包含带宽。
硬件，硬件需要考虑的因素包含服务器，内存和CPU的配置。
依赖资源，依赖的资源包含以下这些，如到数据库的可用连接和web服务连接数量。
共享资源，共享的资源包含以下这些，如网络带宽，一个网络带宽和一台服务器中CPU的个数。
项目资源，从一个项目的预期来看，预算也是个限制，例如时间和成本。
⑤ 标识处理步骤
将关键场景进行拆分成组件处理步骤。
项目资源，从一个项目的预期来看，预算也是个限制，例如时间和成本。
逐条列举场景，并将这些场景分解成处理过程，类似UML中的用例和顺序图。可以将场景作为输入条件。
处理步骤：
1. 客户端提交的一个订单的请求。
2. 客户认证生效。
3. 订单生效。
4. 商业规则对订单进行验证。
5. 订单被传到数据库。
6. 处理订单。
7. 一个响应信息被传送到客户端。
识别处理步骤的一个附加的好处就是帮助你识别程序中哪些是需要增加自定义检测点，检测点可以在测试的时候提供实际开销和时间
⑥ 预算分配
为了满足性能目标，将你的预期值分派到所有的处理步骤中。
满足性能目标，将你的预算分派到所有的处理步骤中，你需要考虑执行时间和系统资源利用状况，有些预算只包含一个步骤，但有些预算直接应用到场景中，有些会交叉一些场景。
将执行时间分配到步骤中：
将执行时间分配到处理过程中，如果你不知道该分配多长时间，可以先将时间平均分配到这些步骤中，在这时候，各种的分配值是否精确不是特别重要，因为在实际测量后可以重新调整预算，但是否有这个分配值的观念很重要，不要执著于完美，但在过程中要求自己达到一个合理的完美程度为目标。
在应用程序被建造之前你拿不到实际的数据，你不想被拖入泥潭的同时也不想等待，但你拿不到执行时间等数据，你可以将时间平均分配，考察一下那里会有问题或哪里会紧张。
如果将预算分划后，每一个步骤都有充裕的时间，那样就不需要进一步测试了，但那些看起来风险较大的部分，引进一些实验（如原型），验证你需要做的是可能的，然后执行。
注意其中一个或多个步骤可能有一个确定范围的时间，例如，你有一个数据库访问步骤的话，你知道这个访问时间不超过3秒，但其他时间是不在确定定范围内的。确定和不确定步骤的开销不能大于或等于这个场景分配的预算。
将资源利用分配到需求中：
在给处理步骤分配资源的时候，考虑以下这些内容：
了解技术的成本，如那一个技术X和另外一个技术Y相比的成本。
了解硬件分配的预算，这里定义好所有可利用资源。
了解已经在适当位置的硬件系统。
了解你的应用系统的功能。
处理可能需要更多的CPU，频繁的数据库访问和网站服务。
通讯可能需要更多的网络带宽，大文件上传可能需要更多的磁盘I/O。
⑦ 评价
再一次评价你的在性能目标和预期值，评价这些值是否在一个合理的范围内。有可能需要修改设计值或将分布响应时间，系统资源预期值等来满足你的性能目标。
在付出时间和努力在原型和测试之前评估预算的可行性和效率。
评估可行性和效率，审核性能目标并且考虑以下问题：
预算能满足目标吗？
这个接近现实吗，在评估阶段你可以定义一个新实验可以拿到更详细的预算数值。
模型标识了资源上最关键的点吗？
还有更加有效的方法吗？
为了达到目标模型设计或特征可以减少或变更吗？
你可以提高效率也就是说可以减少资源或时间的消耗吗？
用其他的模式，设计或开发拓扑有没有可能提供更好的解决方法？
为了性能目标，付出了什么代价？你是否为性能耗费了部分生产力，可测量性，可维护性和安全性。
需要考虑一下的活动：
修改你的设计。
重新评估需求。
换一种方法进行预算分配。
⑧ 验证
验证性能模型和你的估算。这个是一个正在进行的活动，它包含原型活动，评估活动和测量活动。
对模型和估算进行验证，继续创建原型和通过获取计数器测量用例的性能。这个是一种持续的活动包含原型和测量，继续进行验证检查直到满足性能目标。
在你的项目生命周期内，越早进行验证，验证的准确性将越高，验证是基于可获得的基础和原型代码，或许仅仅是被证明的代码，应用程序的开发的时候你可以测量实际的代码。
总结：
在项目的早期进行性能模型的分析活动为你揭示关键问题，可以使你在设计阶段快速找到需要进行代价转换的位置，或为你标识出你需要付出劳动的地方。在正确的方向上的一个实践步骤就是简单的将场景分解成逻辑上的操作和步骤。最重要的是，你性能目标标识出来了，如响应时间，吞吐量，和在每一个场景中的系统资源利用率。
明了系统的预算，在术语来说就是被测试系统允许消耗多少CPU，内存，磁盘I/O和网络I/O。在设计阶段就要准备好代价转换，例如启用其他可选的技术和远程通讯机制。采用一个主动的性能管理方法，一个性能模型化过程，标识好以下内容：
性能成为开发过程中的一个重要特征并非开发后的过程。
在软件生命周期的早期基于计量进行代价转换的评估。
在整个生命周期中，测试用例显示你是逼近还是远离性能目标。
① 步骤一. 标识识别关键场景
从性能的观点来定义被测试程序的场景，如果你已经有了用例和用户描述的文档，你可以用这些文档来定义你的场景，关键场景包含以下2个：
1) 关键场景
关键场景需要指定性能预期值和需求，有些已经包含在SLAs（服务水平协议）中，有些需要特定的性能目标。
2) 重要场景
重要场景一般没有指定性能目标，如响应时间目标等，但他们可以影响其他关键场景。鉴别重要场景主要的几个特征。
并行运行的场景。
经常被执行的场景。
占高比例操作的场景。
预期需要消耗的系统资源场景。
不要忽视重要场景，重要场景会影响到你的关键场景是否能满足性能目标。同时，要记得考虑如果众多不同并发用户运行不同的关键场景和重要场景的时候，被测试系统的会表现的怎么样。这个“并行集成”经常驱使你程序单元工作的决定。例如，保持的响应及时，你可能需要同时提交在线物品订单。
② 标识负载
明确本程序的需要支持的人数，同时在线人数和并发数量。
负载时从市场数据推导出来的，包含以下这些：
所有用户。
并发活动活跃用户。
数据容量
事务容量和混合事务
在性能模型里面，需要识别负载在每一个单独场景中的作用，例如：
你可能需要支持100个并发浏览用户。
你可能需要支持100个并发订单处置的用户。
注意：
并发用户：是那种严格同一时间点击一个网站的用户。
同时用户：同时活跃连接访问同一个网站的用户。
③ 标识性能目标
为每一个关键场景定义一个性能目标，这些性能目标来自于业务需求。
在步骤1定义的场景中，写下每一个场景的性能目标。
性能目标由业务需求决定。
性能目标包含以下内容。
响应时间，如产品目录必须在3秒内展示。
吞吐量，如系统必须支持每一秒完成100个交易。
资源利用率，一个经常忽略的问题是被测试系统消耗了多少资源，例如，CPU，内存，磁盘I/O和网络I/O。
在建立性能目标的时候考虑以下问题：
负载需求。
服务水平协议。
响应时间。
项目增长。
项目的生命周期。
项目增长，你需要考虑6个月或1年后之后你的设计是否还能满足项目的需求，如果你的项目生命周期是6个月的话，你会因为性能去扩展你的系统吗？如果你的系统肯能有一个长的生命周期的话，你打算花什么样的代价去做性能维护。
④ 标识预算
标识你的预期和限制条件，包含每一个操作必须完成的最长的时间还有资源利用率限制，包含CPU，内存，磁盘I/O和网络I/O。
预算其实就是限制，例如，多长时间完成一个操作是可以接受的，超出这个时间的话，你的应用系统就达不到性能目标。
你的预期通常由下面的术语来定义：
执行时间。
资源利用。
执行时间
你的执行时间包含最大限度的时间必须包含单独的操作
资源利用
资源利用需求定义了每一类资源的利用率的阈值，例如，处理器的峰值是限制在75%，同时内存消耗不能超过50MB，一般的资源包含：
CPU。
内存。
网络I/O。
磁盘I/O。
执行时间和资源利用状况在性能目标的上下文环境中是很有作用的。预期目标有几个方向的。其他因素需要考虑到有 ：
网络，网络需要考虑的因素包含带宽。
硬件，硬件需要考虑的因素包含服务器，内存和CPU的配置。
依赖资源，依赖的资源包含以下这些，如到数据库的可用连接和web服务连接数量。
共享资源，共享的资源包含以下这些，如网络带宽，一个网络带宽和一台服务器中CPU的个数。
项目资源，从一个项目的预期来看，预算也是个限制，例如时间和成本。
⑤ 标识处理步骤
将关键场景进行拆分成组件处理步骤。
项目资源，从一个项目的预期来看，预算也是个限制，例如时间和成本。
逐条列举场景，并将这些场景分解成处理过程，类似UML中的用例和顺序图。可以将场景作为输入条件。
处理步骤：
1. 客户端提交的一个订单的请求。
2. 客户认证生效。
3. 订单生效。
4. 商业规则对订单进行验证。
5. 订单被传到数据库。
6. 处理订单。
7. 一个响应信息被传送到客户端。
识别处理步骤的一个附加的好处就是帮助你识别程序中哪些是需要增加自定义检测点，检测点可以在测试的时候提供实际开销和时间
⑥ 预算分配
为了满足性能目标，将你的预期值分派到所有的处理步骤中。
满足性能目标，将你的预算分派到所有的处理步骤中，你需要考虑执行时间和系统资源利用状况，有些预算只包含一个步骤，但有些预算直接应用到场景中，有些会交叉一些场景。
将执行时间分配到步骤中：
将执行时间分配到处理过程中，如果你不知道该分配多长时间，可以先将时间平均分配到这些步骤中，在这时候，各种的分配值是否精确不是特别重要，因为在实际测量后可以重新调整预算，但是否有这个分配值的观念很重要，不要执著于完美，但在过程中要求自己达到一个合理的完美程度为目标。
在应用程序被建造之前你拿不到实际的数据，你不想被拖入泥潭的同时也不想等待，但你拿不到执行时间等数据，你可以将时间平均分配，考察一下那里会有问题或哪里会紧张。
如果将预算分划后，每一个步骤都有充裕的时间，那样就不需要进一步测试了，但那些看起来风险较大的部分，引进一些实验（如原型），验证你需要做的是可能的，然后执行。
注意其中一个或多个步骤可能有一个确定范围的时间，例如，你有一个数据库访问步骤的话，你知道这个访问时间不超过3秒，但其他时间是不在确定定范围内的。确定和不确定步骤的开销不能大于或等于这个场景分配的预算。
将资源利用分配到需求中：
在给处理步骤分配资源的时候，考虑以下这些内容：
了解技术的成本，如那一个技术X和另外一个技术Y相比的成本。
了解硬件分配的预算，这里定义好所有可利用资源。
了解已经在适当位置的硬件系统。
了解你的应用系统的功能。
处理可能需要更多的CPU，频繁的数据库访问和网站服务。
通讯可能需要更多的网络带宽，大文件上传可能需要更多的磁盘I/O。
⑦ 评价
再一次评价你的在性能目标和预期值，评价这些值是否在一个合理的范围内。有可能需要修改设计值或将分布响应时间，系统资源预期值等来满足你的性能目标。
在付出时间和努力在原型和测试之前评估预算的可行性和效率。
评估可行性和效率，审核性能目标并且考虑以下问题：
预算能满足目标吗？
这个接近现实吗，在评估阶段你可以定义一个新实验可以拿到更详细的预算数值。
模型标识了资源上最关键的点吗？
还有更加有效的方法吗？
为了达到目标模型设计或特征可以减少或变更吗？
你可以提高效率也就是说可以减少资源或时间的消耗吗？
用其他的模式，设计或开发拓扑有没有可能提供更好的解决方法？
为了性能目标，付出了什么代价？你是否为性能耗费了部分生产力，可测量性，可维护性和安全性。
需要考虑一下的活动：
修改你的设计。
重新评估需求。
换一种方法进行预算分配。
⑧ 验证
验证性能模型和你的估算。这个是一个正在进行的活动，它包含原型活动，评估活动和测量活动。
对模型和估算进行验证，继续创建原型和通过获取计数器测量用例的性能。这个是一种持续的活动包含原型和测量，继续进行验证检查直到满足性能目标。
在你的项目生命周期内，越早进行验证，验证的准确性将越高，验证是基于可获得的基础和原型代码，或许仅仅是被证明的代码，应用程序的开发的时候你可以测量实际的代码。
总结：
在项目的早期进行性能模型的分析活动为你揭示关键问题，可以使你在设计阶段快速找到需要进行代价转换的位置，或为你标识出你需要付出劳动的地方。在正确的方向上的一个实践步骤就是简单的将场景分解成逻辑上的操作和步骤。最重要的是，你性能目标标识出来了，如响应时间，吞吐量，和在每一个场景中的系统资源利用率。
明了系统的预算，在术语来说就是被测试系统允许消耗多少CPU，内存，磁盘I/O和网络I/O。在设计阶段就要准备好代价转换，例如启用其他可选的技术和远程通讯机制。采用一个主动的性能管理方法，一个性能模型化过程，标识好以下内容：
性能成为开发过程中的一个重要特征并非开发后的过程。
在软件生命周期的早期基于计量进行代价转换的评估。
在整个生命周期中，测试用例显示你是逼近还是远离性能目标。
性能测试模型是指为预计或估算软件的性能所建立的性能框图和数学模型，是一种在目标应用程序中测试中应用的模型，包含用于测试的测试用例、测试过程和测试脚本，同时还包含系统关键资源和系统处理。
性能测试模型为分布式系统的性能分析和规划提供了一种有效的分析方法和仿真工具，同时还告诉执行人员的具体的执行方法。即使在特殊情况下，通过模型作出的预测并不是很精确的话，只要根据模型提出的方法实施，也具有很高的参考价值。
建立这个模型是为了将复杂系统的性能分解并标识为简单明了的符号，以便定量预计、分配、估算和评价复杂系统的性能状况。
性能测试模型使我们容易识别系统的关键资源，系统的负载能力，和资源需求。那些资源是相对紧缺的，哪些是相对丰裕的，运行时系统将会处于的状况，如果系统扩张，再有多大的负载会造成系统存在瓶颈资源。
通过怎么样的方法调整本应用系统和运行的环境，包含软件部署和硬件配置。
软件性能模型的建立的基本方法：根据系统的业务需求和处理过程，推导系统处理业务的基础资源开销，以及可能存在的临界资源争夺和事务竞争问题，对整个应用系统性能进行统一的评估和预算，将系统性能相关的信息通过一个统一的模型表示出来。
性能模型是一个动态的预测性质的模型，根据被测试应用系统在负载运行时可能出现的情况，对服务器重要性能计数器和系统响应时间等参数，在平均的、最佳和最差的情况下分析，找出最大限度避免这些极端情况出现的应对方法，预测被测试应用系统应该满足的独立的、排他的资源需求，提出在软件生命周期的业务需求阶段和设计阶段就应该考虑和解决这些问题。
一个设计的实用软件性能测试模型，可以以较少的企业资源成本产生比较好的经济效益，特别是在测试团队内部和其他企业支持资源的沟通方面。对参与人员而言，性能测试模型是一种将软件性能问题结构化，直观表示的一种方法，通过性能测试模型，可以很方便的浏览被测试软件中，每一个业务需求以及所需要达到的性能目标。对公司为参与性能测试的不同职位的支持人员而言，性能测试模型可以让不太内行的人，都可以直观的了解测试对象和即将采用的测试方法，方便的熟悉性能测试的工作。通过增加人们对性能测试工作的认识理解，为即将进行实施提供了一个共同的认识基础。
性能测试模型为分布式系统的性能分析和规划提供了一种有效的分析方法和仿真工具，同时还告诉执行人员的具体的执行方法。即使在特殊情况下，通过模型作出的预测并不是很精确的话，只要根据模型提出的方法实施，也具有很高的参考价值。
建立这个模型是为了将复杂系统的性能分解并标识为简单明了的符号，以便定量预计、分配、估算和评价复杂系统的性能状况。
性能测试模型使我们容易识别系统的关键资源，系统的负载能力，和资源需求。那些资源是相对紧缺的，哪些是相对丰裕的，运行时系统将会处于的状况，如果系统扩张，再有多大的负载会造成系统存在瓶颈资源。
通过怎么样的方法调整本应用系统和运行的环境，包含软件部署和硬件配置。
软件性能模型的建立的基本方法：根据系统的业务需求和处理过程，推导系统处理业务的基础资源开销，以及可能存在的临界资源争夺和事务竞争问题，对整个应用系统性能进行统一的评估和预算，将系统性能相关的信息通过一个统一的模型表示出来。
性能模型是一个动态的预测性质的模型，根据被测试应用系统在负载运行时可能出现的情况，对服务器重要性能计数器和系统响应时间等参数，在平均的、最佳和最差的情况下分析，找出最大限度避免这些极端情况出现的应对方法，预测被测试应用系统应该满足的独立的、排他的资源需求，提出在软件生命周期的业务需求阶段和设计阶段就应该考虑和解决这些问题。
一个设计的实用软件性能测试模型，可以以较少的企业资源成本产生比较好的经济效益，特别是在测试团队内部和其他企业支持资源的沟通方面。对参与人员而言，性能测试模型是一种将软件性能问题结构化，直观表示的一种方法，通过性能测试模型，可以很方便的浏览被测试软件中，每一个业务需求以及所需要达到的性能目标。对公司为参与性能测试的不同职位的支持人员而言，性能测试模型可以让不太内行的人，都可以直观的了解测试对象和即将采用的测试方法，方便的熟悉性能测试的工作。通过增加人们对性能测试工作的认识理解，为即将进行实施提供了一个共同的认识基础。
