建立性能测试模型的步骤

① 步骤一. 标识识别关键场景
从性能的观点来定义被测试程序的场景，如果你已经有了用例和用户描述的文档，你可以用这些文档来定义你的场景，关键场景包含以下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。在设计阶段就要准备好代价转换，例如启用其他可选的技术和远程通讯机制。采用一个主动的性能管理方法，一个性能模型化过程，标识好以下内容：
性能成为开发过程中的一个重要特征并非开发后的过程。
在软件生命周期的早期基于计量进行代价转换的评估。
在整个生命周期中，测试用例显示你是逼近还是远离性能目标。

若需转载或其他需要，请跟作者朱汉强联系。
联系邮箱：johannes_zhu@yahoo.com。
广州益标软件技术有限公司为您提供高质量的软件测试和咨询服务。
欢迎访问：http://www.3rdtest.com/。

概说软件性能测试模型

性能测试模型是指为预计或估算软件的性能所建立的性能框图和数学模型，是一种在目标应用程序中测试中应用的模型，包含用于测试的测试用例、测试过程和测试脚本，同时还包含系统关键资源和系统处理。性能测试模型为分布式系统的性能分析和规划提供了一种有效的分析方法和仿真工具，同时还告诉执行人员的具体的执行方法。即使在特殊情况下，通过模型作出的预测并不是很精确的话，只要根据模型提出的方法实施，也具有很高的参考价值。
建立这个模型是为了将复杂系统的性能分解并标识为简单明了的符号，以便定量预计、分配、估算和评价复杂系统的性能状况。性能测试模型使我们容易识别系统的关键资源，系统的负载能力，和资源需求。那些资源是相对紧缺的，哪些是相对丰裕的，运行时系统将会处于的状况，如果系统扩张，再有多大的负载会造成系统存在瓶颈资源。通过怎么样的方法调整本应用系统和运行的环境，包含软件部署和硬件配置。
软件性能模型的建立的基本方法：根据系统的业务需求和处理过程，推导系统处理业务的基础资源开销，以及可能存在的临界资源争夺和事务竞争问题，对整个应用系统性能进行统一的评估和预算，将系统性能相关的信息通过一个统一的模型表示出来。性能模型是一个动态的预测性质的模型，根据被测试应用系统在负载运行时可能出现的情况，对服务器重要性能计数器和系统响应时间等参数，在平均的、最佳和最差的情况下分析，找出最大限度避免这些极端情况出现的应对方法，预测被测试应用系统应该满足的独立的、排他的资源需求，提出在软件生命周期的业务需求阶段和设计阶段就应该考虑和解决这些问题。
一个设计的实用软件性能测试模型，可以以较少的企业资源成本产生比较好的经济效益，特别是在测试团队内部和其他企业支持资源的沟通方面。对参与人员而言，性能测试模型是一种将软件性能问题结构化，直观表示的一种方法，通过性能测试模型，可以很方便的浏览被测试软件中，每一个业务需求以及所需要达到的性能目标。对公司为参与性能测试的不同职位的支持人员而言，性能测试模型可以让不太内行的人，都可以直观的了解测试对象和即将采用的测试方法，方便的熟悉性能测试的工作。通过增加人们对性能测试工作的认识理解，为即将进行实施提供了一个共同的认识基础。

若需转载或其他需要，请跟作者朱汉强联系。
联系邮箱：johannes_zhu@yahoo.com。
广州益标软件技术有限公司为您提供高质量的软件测试和咨询服务。
欢迎访问：http://www.3rdtest.com/。

响应时间

响应时间是指从一个请求被发送出去后到它接收到响应的时间。处于系统中不同的角色的人，对响应时间的关注点是不一样的。从系统管理员的角度来看，系统响应时间指的是服务器收到请求的时刻开始计时，到服务器完成执行请求，并将请求的信息返回给用户这一段时间的间隔。这个“服务器”包含的范围是给用户提供服务的接口服务器，中间的一些业务处理的服务器和排在最后面的数据库服务器。这里并不包含请求和响应在网络上的通讯时间。
从用户的角度来看，响应时间是用户发出请求开始计时，（如按下“确认”或“回车”键的时刻），到用户的请求的相应结果展现在用户机器的屏幕的时候的这一段时间的间隔。这个时间称为“客户端的响应时间”，它等于客户端的请求队列加上服务器的响应时间和网络的响应时间的总和。可以看出，从用户角色感受的“响应时间”是所响应时间中最长的。很多影响因素不在应用系统的范围内的。如数据包在网络上的传输时间、域名解析时间等。
响应时间超出预期太多的应用系统系统会导致使用者的反感，因为系统在让他们等待，这样会降低他们的工作效率，延长他们的工作时间。位于互联网上的网站也是存在同样的问题，有调查表明，如果一页网页不能在八秒钟内下载到访问的用户端，访问者就会失去耐性，他们有的尝试其他同类型的网站，有的可能访问竞争者的网站，并且可能影响他们圈子里面的人访问这个网站的兴趣和取向。对于一个指望这些访问者变为客户的网站站点而言，响应时间带来的后果等同于销售额的损失。
在性能测试中，响应时间也是个非常关键的指标。判断一个系统是否正常的标准，首先是看这个系统的处理某个业务的响应时间是否在一个正常的范围内。“健康”运行的应用系统的响应时间在一个预期的范围内的。所有不正常的运行的应用系统，首先表现出来的是在响应时间上远远超出预期值。正如正常的体温代表健康人的体温一样。
在一个应用系统里面，存在各种各样、大小不一的事务，每个事务的响应时间不一样，在工作时间内同时有很多用户在使用，每个用户都在根据业务要求，输入一些业务数据后提交，系统服务端在接受到用户的后进行处理，处理完毕后将适当的信息返回。事务的响应时间对每个用户来说都是不一样的，以下这些因素会影响系统的平均响应时间：
（1）和业务相关，处理不同的业务会有不同的响应时间；
（2）和业务组合有关，业务之间可能存在依赖关系或其他，也会相互影响；
（3）和用户的数量有关，大并发量会严重影响应时间。
有很多种方法可以用来测试响应时间。常用的有两种方法：首字节响应时间（度量首字节的响应时间，指向服务器发送请求与接收到响应的第一个字节之间的时间）。末字节响应时间（度量末字节的响应时间，指向服务器发送请求与接收到响应的最后一个字节之间的时间。）通过测量响应时间，可以知道所有客户端用户完成一笔业务所用的时间以及平均时间、最大时间。通过对响应时间数据的分析，你可以大概的知道系统的整体性能。


若需转载或其他需要，请跟作者朱汉强联系。
联系邮箱：johannes_zhu@yahoo.com。
广州益标软件技术有限公司为您提供高质量的软件测试和咨询服务。
欢迎访问：http://www.3rdtest.com/。

组件测试

组件测试是将被测试应用系统的各个组件的分别进行性能测试，确保单个组件的性能达到设计指标，然后将已经通过性能测试的组件再进行测试，按照应用系统业务的需求，将组件从简单到复杂进行组合。这种测试方法适合集成了比较多组件或子系统的大型程序，如大型多人在线角色扮演的网络游戏。
满足组件测试的条件是，系统中的组件很松耦合的，可以相对独立，并可以作为一个独立的软件进行测试。组件测试适应的情况，之一是：性能测试直接对整个庞大的应用程序，没有办法执行测试，或测试的执行的效果不好。之二是：因为开发和软件复用等多方面的原因，被测试的系统中有些组件或子系统是现成的，做少量的修改就可以整合到新的系统里面，而有些组件还需要全新的开发。通过首先对组件进行测试，逐个找出系统组件内部和组件之间调用可能存在的性能问题，预先找出和解决整个系统中可能存在的“短板”，减轻项目后期的工作压力。组件测试是首先对每一个组件进行单独的性能测试，确认每一个组件的性能满足设计目标后。再按照不同的组合条件，将所有的组件进行“集成”测试，从简单的两个组件的“集成”到相对复杂的“集成”，找出定位并消除两个或两个以上子系统集成时性能互相影响的地方。直到最后系统组件的总“集成”，这个时候，就基本形成了这个被测试的应用系统。

若需转载或其他需要，请跟作者朱汉强联系。
联系邮箱：johannes_zhu@yahoo.com。
广州益标软件技术有限公司为您提供高质量的软件测试和咨询服务。
欢迎访问：http://www.3rdtest.com/。

并发测试

并发在负载测试或压力测试测试的核心部分。但为了比较真实的运营生产的过程，一般不在负载测试和压力测试时，针对某个特别关注的点设置很大的并发量，而将并发测试作为一种独立的测试方法单独执行。
应对来自多客户端并发的请求，应用系统服务端对应派生出多个线程实例进行处理，线程大多是以互斥的方式访问服务器端共享数据和临界资源的。大量的并发加大了数据竟争，对共享数据造成访问冲突，加大了数据库等临界资源死锁的可能；同时，并发的线程意味着一个线程中的代码有可能被其他线程中的代码中断，可能引发一连串的线程等待，以及其他因并发引起的错误。大量来自客户端的并发的操作会导致应用系统服务端性能低下，有可能会对应用系统造成巨大破坏。
并发测试的关键点有3个：首先是测试应用系统服务器能否与客户端快速建立并发连接，这个是并发测试的前提条件；然后再测试应用系统能否在既定的并发量的条件下快速处理业务，使响应时间也在预期的范围内。根据测试的应用程序的不同，不同的系统有很大的差别，这个是并发处理的关键；最后测试系统能否及时释放这些连接，如果系统不能及时释放连接的话，系统的关键资源之一，文件描述符将在很短的时间内被消耗殆尽，如果这样的话，系统将没有足够的文件描述符来建立新的连接。
在执行测试的时候，需要测试脚本或测试程序中的检查点之前设置“集合点”，测试脚本或测试工具执行到这个“集合点”时，在这里等待稍执行较慢的线程，然后以设置的并发量通过这个检查点。并发请求以不同速度通过这个检查点后，然后再在下一个检查点聚集。直到退出系统，释放链接。

若需转载或其他需要，请跟作者朱汉强联系。
联系邮箱：johannes_zhu@yahoo.com。
广州益标软件技术有限公司为您提供高质量的软件测试和咨询服务。
欢迎访问：http://www.3rdtest.com/。

负载测试

进行负载测试的应用系统，要求最终用户需要有一定数量，但这个数量可以预知或可以限制在既定范围内，因为这些系统在生产时候将要面对的最高的负载是确定的。如一个企业的内部业务处理系统，政府机关办公系统，最终用户的数量都在一个预定的范围内。多人在线网络游戏，为了保证服务器为玩家提供良好的服务，在一组服务器中就限制了最高点上限人数，对用户数量实现技术限制。
应用系统在处理多个用户同时操作的时候，系统要为每一个用户派生一个线程（进程）处理不同的请求，当系统忙于处理各种不同请求的时候，有可能出现各种各样的缺陷。负载测试可以使那些只有在负载的情况下才能出现的缺陷有了提前“露脸”的机会，特别是那些有可能导致死锁或使系统崩溃的问题将会暴露出来。
负载测试一般通过测试工具模拟真实的多用户的操作的场景，根据业务流程的需要，适当设置业务处理流程的长度，设置合适的思考和运行时间，请交易求的频率，事务的大小，业务数据，在线用户数量，活动用户数量等，模拟不同类型的用户的行为，检验系统在预定负载条件下的处理效率及其状况，发现和定位在系统资源开销超出预期的地方，判断能否系统是否满足被用户接受的基本条件之一。
负载测试是针对整个产品系统进行的，目的是验证系统是否满足了需求规定的性能指标，提前了解真实运行时的系统性能状况，找出并发现造成这些性能瓶颈的地方，最终目的是解决本来存在的性能瓶颈。负载测试需要搭建与实际使用环境相类似的测试环境，被测试系统的数据库的数据量也需要跟在运行时候的同样一个数量级别的，使负载测试结果比较真实地反映出软件的负载性能，这样测试出来的性能数据才具有比较高的评估价值。

若需转载或其他需要，请跟作者朱汉强联系。
联系邮箱：johannes_zhu@yahoo.com。
广州益标软件技术有限公司为您提供高质量的软件测试和咨询服务。
欢迎访问：http://www.3rdtest.com/。

关于压力测试

系统在超出预期的负载的时候，应用系统比正常状态下接收到更多来自于用户的请求，由于系统不能按正常的速度处理和响应用户的请求，有很大部分比例的用户的操作也是不正常的，如他们会不停的刷屏，重复的点击“确定”或“提交”按钮等，这些操作会引起系统处理上的混乱。在这种情况下，有些系统仅仅是处理速度慢一些，这个是在响应时间上不能满足用户的需求；有些系统则会出现灾难性的失败，并有可能扩散到整个服务器群，这是系统级的异常。
超出预期的压力在在现实生活中是经常存在的，在前几年中央某个电台向公众传播了“威客”的概念并播放了他们采访“威客”网站的CEO后，节目中提到的几个网站在几个月内都不能正常提供服务，用某些人的话来说，是“网络暴民”将这几个网站给压垮了。恰当的说法是突如其来的访问量，远远超过了网站的承受范围，导致不能提供正常的服务。
面对公众的应用服务程序，如网站和网络游戏，都应该将压力测试列入进行常规测试列表中，在上线生产前检查应用系统可以承受的压力强度，根据系统的表现作为评价系统压力性能、核实被测系统的性能行为在异常或极端条件之下的可接受性。
应用系统软件在处理超出设计指标的负载时，所反映出来的信息是非常丰富的，涉及到整个系统的各个方面，如普通用户看响应时间超出预期，业务管理人员看它的生产效率很低，系统管理员看到部分临界系统资源被消耗殆尽。这些情况的出现，除了跟被测试的应用系统本身，运行该应用软件机器硬件配置有关外，还与系统结构、重要的代码和算法、编译优化、编程工具，甚至与测试方法等都有关系。
压力测试也是需要实际使用环境相类似的测试环境进行，通过向应用系统发送超出系统处理能力的交易请求，测试系统在超出设计指标的压力情况下的处理效率及其状况。在执行测试的时候，首先是执行负载测试，在压力提升超出了设计指标就成了“压力测试”，再增加压力直到系统不能正常处理为止。分析压力测试中所获得的计数器信息，结合具体的测试用例，可以快速定位出现瓶颈的地方，如某个模块中不当的算法，或系统中不当的配置等。使开发人员或系统管理人员能快速的找到需要修改的地方等，对系统进行有针对性的优化。

若需转载或其他需要，请跟作者朱汉强联系。
联系邮箱：johannes_zhu@yahoo.com。
广州益标软件技术有限公司为您提供高质量的软件测试和咨询服务。
欢迎访问：http://www.3rdtest.com/。