性能测试

SEI 负载测试计划过程（SEI Load Testing Planning Process）是个关注于负载测试计划的方法，其目标是产生“清楚、易理解、可验证的负载测试计划”。SEI 负载测试计划过程包括6 个关注的区域（Area）：目标、用户、用例、生产环境、测试环境和测试场景。

SEI 负载测试计划过程将以上述6 个区域作为负载测试计划需要重点关注和考虑的内容，其重点关注以下几个方面的内容：

RBI（Rapid Bottleneck Identify）方法是一种用于快速识别系统。

性能瓶颈的方法。该方法基于以下一些事实：

1. 发现的80%系统的性能瓶颈都由吞吐量制约；

2. 并发用户数和吞吐量瓶颈之间存在一定的关联；

3. 采用吞吐量测试能够更快速定位问题。

RBI 方法首先访问服务器上的“小页面”和“简单应用”，从应用服务器、网络等基础的层次上了解系统吞吐量表现；其次选择不同的场景，设定不同的并发用户数，使其吞吐量保持基本一致的增长趋势，通过不断增加并发用户数和吞吐量，观察系统的性能表现。

在确定具体的性能瓶颈时，RBI 将性能瓶颈的定位按照一种“自上而下”的分析方式进行分析，首先确定是由并发还是由吞吐量引发的性能表现限制，然后从网络、数据库、应用服务器和代码本身4 个环节确定系统性能具体的瓶颈。

RBI 方法在性能瓶颈的定位过程中能发挥良好的作用，其对性能分析和瓶颈定位的方法值得借鉴，但其也不是完整的性能测试过程。

不论哪种软件生命周期模型，需求分析、设计、编码、测试和运行维护这几个阶段都是其中的基本要素，只是在不同的软件生命周期模型中可能迭代、合并、拆分或重组这几个阶段，在此不做过多的描述。与其他几个阶段相对应，测试从软件开发过程按阶段可以划分为：单元测试、集成测试、系统测试，在其他的书上可能还能见到诸如确认测试、验收测试等名词，但是前3种测试确实是最基本的测试活动，而其他的测试活动只是在某些软件开发过程中会发生。

值得注意的是，通常在谈论单元测试、集成测试和系统测试时，其实仅仅谈论的是不同阶段的功能测试；而当讨论性能测试时，绝大多数的情况是，一个已经开发完毕或基本开发完毕的软件，测试人员用一种或几种性能测试工具，以尽量模拟真实用户行为的方式对该软件进行并发操作，收集并比较不同场景的结果，然后对软件的性能进行分析，这个活动通常发生在系统测试阶段，甚至更往后的阶段，如运行维护阶段。

1．同样的缺陷在不同阶段被发现，其修复成本差异极大，而越早发现缺陷，修复成本越小；

2．某些缺陷几乎只能在某个阶段被发现，即在其他阶段需要投入巨大的人力才能发现这些缺陷或根本不可能发现这些缺陷。

1．在单元性能测试中运行一遍后就能发现的内存泄漏问题，如果这个问题遗留到系统测试阶段，可能需要花费几天的时间才能找到问题的所在，尤其是当Dump 内存信息后发现大量对象是到处都在使用的基本对象时，欲哭无泪可能是性能优化人员此时的真实写照，这点笔者曾有幸体验过；而实际上运行一遍单元测试的时间可能也就几分钟，此时发现问题极易解决。

2．异构系统之间的接口，通常是先完成接口，而调用接口的系统可能过很久才会完成。当然，可以等完成调用接口的系统后直接对该系统进行测试，接口的性能自然被测试到了，但是万一很不幸——性能测试结果不佳，再花费一番力气后终于确定是接口性能不佳，那可能就得大费周折地重新写接口了。更倒霉的是别的系统已经在用新的接口了，而不巧的是新老接口又不兼容（比如差一个参数什么的），那代价可就大了；如果进行过接口性能测试，问题早就发现并解决了，这时候真是想想都会笑了。

3．越早开始性能调优，调优工作就会越容易。当组件小规模的集成后即可运行并调优时，由于系统复杂度低，自然而然地性能调优的难度会比较低。很显然，性能调优是以性能测试为基础的，那么较早阶段的性能测试就很有必要了。

4．在运行维护阶段，系统已经在稳定地为用户提供服务了，这时候还需要进行性能测试吗？需要。因为生产系统可能会表现出疑似性能问题的症状，这时候性能测试是查找问题的有效手段，有助于为用户提供更好的服务；性能再好的系统也会有极限，当用户数不断增长的时候，通过性能测试来评估系统的容量，以确定系统应如何进行扩容或者需要更换新的架构，通常这称之为容量评估。

单元性能测试

集成性能测试

系统性能测试

多系统性能测试

容量评估

接口性能测试。

　　有基准：性能测试的目标更多地是通过测试以获得合理的基准测试结果，用来作为与以后应用改变后性能测试结果比较的基准。

　　无基准：此时的性能测试目标是通过测试保证应用能够在一定测试环境下满足已定义的性能能力。

　　在 NFR 文档中定义了一些关键性能指标，这些性能指标能够帮助测试人员检测应用程序是否能够满足性能需求。下面将介绍几个比较重要且常见的在 NFR 中定义的关键性能指标：

　　响应时间定义为从发送事务请求到收到该事务请求回应的时间间隔。响应时间的需求定义并不是一个固定的数值，这是因为对于一个 SOA 应用程序，事务的复杂程度以及使用频率是完全不同的，如果要求所有事务的响应时间都达到同一指标，这是非常不合理的。因此需要对不同复杂程度和不同使用频率的事务定义相应的响应时间需求。下面为响应时间需求的实例：

建立性能目标

了解应用软件状况

了解应用部署平台

建立系统负载模型

制定项目计划

制定测试方案

选取协议

增强脚本

调试脚本

试运行脚本

调试脚本_验证工具

监控操作系统/网络/数据库多个层面

监控应用运行状况/日志

确认施压机资源充分，确保尽力施压

抽查关键功能确认可用

建议运行12小时以上，确认无内存泄露/任务累积

监控工具

收集LR测试数据

收集应用日志

收集系统日志 (如/var/log/*，oracle: *.trc)

分析LR性能结果与OS/DB/中间件/APP参数之间的匹配度（little定律）

评估测试用例覆盖度对测试结论的影响面

编写测试报告 （技术与格式审核）

项目总结 （技术以及过程改进）

如何提高脚本重用率

调优与硬件扩容的平衡

实际运营与系统负载建模的差异度

测试方编制需求框架，需求方或运营方明确需求细节

关键点结对审核

技术攻关先行

重视数据异常，数据分析结合SA/DBA专家意见

结合知识栈，提取系统调优的合理建议

Loadrunner对高层协议支持良好，但对底层协议与加密/随机算法/异步通信支持较差

性能测试难点不在Loadrunner工具本身，难在技术攻关以及对系统的全局把握

建立软件各个层面的知识库/工具箱

MI KB： http://support.mercury.com/cgi-bin/portal/CSO/index.jsp

Loadrunner.info：http://www.wilsonmar.com/1loadrun.htm

51testing：http://www.51testing.com/

描述了如何按照性能的需求从架构设计开始，进行单元测试，集成测试，和生产分段（productioin staging）测试等。描述了实现正规容量评估(capacity assessment)所需的过程，该量化过程可以明确指出你何时需要向你的计算环境增加额外资源。此外，该方法论还阐述了验证你的测试场景是否很好地模拟了你的最终用户的操作行为所需的必要步骤。

通过提供的一套全面的解决方案, 本文描述Quests Application Management Suite for Java and Portals是如何与该方法论相集成，从而在应用开发生命周期的每个阶段保证您的成功。运用这套方法论和Quest的应用管理解决方案,您将充满信心地把符合性能规范的应用展现给您的用户。

为了量化性能要求，我们假设您已经定义了SLA。在深入分析问题之后，关键的负责人员应该系统地定义SLA。SLA 的主要推动者应该是应用业务负责人和应用技术负责人。 应用业务负责人，有时是应用产品经理,他负责分析商业案例并把客户的需求转化为SLA。其实, 只要满足SLA, 客户的需求也会满足。应用技术负责人，有时是应用构架师,分析必要的技术需求，解释用例并'真实地检验'SLA。因此，技术业务负责人的责任就是确保服务等级是可达到的。有效的SLA具有三个关键特性:

一个有效的SLA 必须是一个具体的值。一个用例必须在大约五秒内完成是不准确的，因此很难检验--5.25秒钟是否是大约的五秒。一个具体的值便于QA在应用上线前进行测试，当应用上线后，SLA将提供对主动监测和被动监测两种警报(Alert)的规范。同时，一个有效的SLA在分布式的变化环境中必须也是灵活的。考虑到一些未预料到的情况，我们需要对灵活性进行测量，因此用例必须采用预先定义的时间百分比的方式满足具体的SLA值。例如，您每天使用的常用搜索引擎。当您执行一次查寻,在95%的时间里可以在2秒内完成；在每20次查询中，有一次的响应时间是7秒；通常这种变化的范围是可以接受的。但是如果每20次查询中，有10次超过7秒，你可能就会考虑换个搜索引擎了。SLA不仅必须是具体的, 也要灵活,同时必须也是现实的。你可以通过要求应用业务负责人和应用技术负责人共同制定SLA的方式保证SLA是现实的。这是一个有效用例的特别关键的特性，这是因为在大多数情况下，SLA只由应用业务负责人单方面确定，没有考虑应用技术负责人的意见。当技术小组接到这些性能需求时，他们往往会忽略，一个不现实的SLA比根本没有还要糟糕。

为了保证调优努力的成功你能做的最重要的事就是安排时间了解你的用户和理解他们在使用你的应用时的行为情况。很少会在生产环境中调优应用服务器，而更多的情况是,通过写测试脚本再现为虚拟用户，在上线前的环境中执行负载并进行调优。当在上线前环境中完成调优后, 就可以安全地把配置信息应用到生产环境中。多数公司无法在上线前的环境中充分地再现生产负载。如果您在这些公司中工作,没必要失望。多数大型的公司并没有对他们的用户行为有很好的理解并且在测试环境中不能产生有代表性的负载。

有两个共同的似是而非的理由：

编写一个典型用户负载脚本的困难之处是发现你的用户是怎么使用的应用的。 这不是一门精确的学问。但是为得到一个合理的可靠的结果,第一步是看看您的访问日志。现在,我不会推荐手工做这件事，因为对于一个中型的Web应用，工作量也是巨大的。现在有大量商业或免费工具可为您分析访问日志。

最后，有一个值得重视的问题，我们了解到目前客户在编写负载测试脚本时最大的错误是：用户不知道怎样退出应用系统。不管你把退出按扭作的多大，至多只有20%用户会使用。这是由于现在将Web作为主要业务平台的必然结果。商业Web站点正式基于此而得以快速发展并统治了Internet.

因此，现在用户习惯以下面方式退出网站：

第一章

第二章

第三章

缓存

分片

存储

列队

无锁化

零拷贝

序列化

池子化

并发化

异步化

测试分析工具

1、负载测试（可置性测试）

2、压力测试

3、验收性能测试

4、配置测试

5、并发测试

6、可靠性测试

7、失效恢复测试

8,容量测试

9，异常测试

1、具体的性能指标分为以下几类：

2、熟悉并且理解整个系统的业务逻辑、实现原理，然后进行需求拆分，得到性能测试需求点

3、多个渠道得到具体性能要求，分析评估风险，优先级，是否进行测试等

4、编写性能测试方案和用例，并进行评审通过，然后执行

PS:一些性能测试的测试点

信息收集来源

收集信息

性能优化思路

V3性能调优

9000性能调优

RAID性能

LAN-Base

LAN-Free

Server-Free

Server-Less

备份类型

答题思路

业务规划考虑因素

原则

处理基本方法

双LUN性能不同

8G FC HBA卡亮红灯

COW

ROW

对比

特点

作用

定义

容灾

HyperMetro双活

1.通用接口

2.断言

3.参数化

4.关联

5.上传下载

6.压力测试

vugen

controller

analysis

提高用户满意度，作为业务谈判的指标

保障软件质量，对质量的一种提升

节约成本的手段

性能测试是通过自动化的测试工具，模拟多种正常、峰值以及异常负载条件，来对系统的各项性能指标进行测试

性能测试不等于软件测试，软件测试包含性能测试

目的：性能测试验证各项性能指标是否符合要求，验证系统是否具备你所宣称的能力

软件测试的目的价值

质量模型

用户角度

性能测试、功能（系统）测试，自动化测试

负载

压力

稳定

可靠

一般性能

基准

配置

容量

并发

并发

并发用户数

并发与用户数

实际用户数

虚拟用户数

响应时间

事物

事务响应时间

吞吐量

吞吐率

TPS

每s点击数==点击率

性能计数器

资源利用率

初中高

初级：性能测试搭建环境，采用性能测试相关工具按照测试流程： 模拟用户行为，依据测试场景，执行测试用例，手机相关测试数据

中级：测试需求的分析，测试场景的设计，测试结果的分析，测试流程的监控

高级：测试计划，测试谈判，性能分析与调优，测试过程的改进，性能验收，性能报告