【www.shanpow.com--工作报告】
篇一:[性能测试报告]性能测试报告（实例）
http://www.cnblogs.com/fnng/archive/2011/11/20/2255161.html
2011
上一篇博文主要通过两个例子让测试新手了解一下测试思想，和在做测试之前应该了解人几点，那么我们在如何完成一次完整的性能测试呢？
测试报告是一次完整性能测试的体现，所以，这里我给出一个完整的性能测试报告，相信通过这个报告，我们会整性能测试有个整体的了解，知道我们在以后做性能测试时需要做哪些工作。
注明：1.性能测试报告模板很多，这不是一个空洞的模板，是一个完整的测试报告。
2.由于商业原因，关于项目明，用XXX代替
3.我一直觉得，关于性能工具重要，但不是很重要，要学习性能测试，需要了解的知识面很多，工具只是工具，是为我们服务的，会用性能测试工具并不代表你就会做性能测试了
----//性能测试报告（某网站用户登陆性能测试）
1 概述
1.1 目的
本测试报告为XXXX网站的性能测试报告，目的在于总结测试阶段的测试以及分析测试结果，描述网站是否符合需求。
1.2 背景
XXXX网站，XXXXXX科技有限公司目前正在进行性能测试。考虑到用户数量及数据的增多给服务器造成压力不可估计，因此计划对XXXX网站负载性能测试，在系统配置不变的情况下，在一定时间内，服务器在高负载情况下的性能行为表现，便于对系统环境进行正确的分析及评估。
1.3 范围
本次测试主要是XXXX网站系统的性能测试。
1.1 引用文档
下表列出了执行测试过程所引用的文档：
文档名称
版本号
作者
备注
XXX系统压力测试方案
虫师
2 测试概要
2.1 测试环境
下图描述测试该项目所需要的硬件环境：
客户机
Intel(R) Xeon(TM) CUP 3.06GHz 四核至强处理器、内存：4GB RAM
NAS服务器
PowerVault(TM) NAS1950,
四核至强处理器 E5430, 2.66GHz, 2x6M缓存，1333MHz前端总线，80W 数量1
8GB（2x4G）,DDR-2 667MHz ECC 4R Memory
1TB 3.5-inch 5.4K RPM SATA II Hard Drive with interposer 数量12
数据库服务器
Intel(R) Quad Core E5504 Xeon(R) CPU, 2.0GHz, 4M Cache, 4.86GT/s QPI 数量2
500GB 7.2K RPM Near Line SAS 3.5” Hot Plug H ard Drive 数量2 RAID
8GB Memory(4x2GB),1066MHz, Dual Ranked RDI MMs for 1 Processor
下图描述测试网络的拓扑结构：
客户机测试环境 服务器测试环境
测试机与被测服务器在同一局域网进行，排除了网速限制及网速度不稳定性。
系统采用B/S架构模式，客户端通过中间件访问数据库，中间件和数据库分别部署在两台服务器上。
2.2 人力资源
下表列出了所有参与此项目的测试人员：
角色
资源数量/具体人员
测试员
XXXX科技有限公司：虫师
2.1 测试工作量
任务
开始时间
结束时间
总计（天数）
总计（人时）
计划
2011-11-19
2011-11-19
1
实际
2011-11-19
2011-11-19
1
3 测试内容及方法
3.1 测试需求/目标
在大用户量、数据量的超负荷下，获得服务器运行时的相关数据，从而进行分析，找出系统瓶颈，提高系统的稳定性。
3.2 测试内容
本次测试主要是对XXX网站“首页登录”、后台“成长记录”及网站信息页面访问操作在大负荷情况下处理数据的能力及承受能力。
测试方法：
场景
并发用户数量
运行场景设置
测试点
登录
200
40分钟
服务器稳定性及操作响应时间
注释：所有用户登陆、没有权限限制。
3.3 测试工具
主要测试工具为：LoadRunner性能测试工具
辅助软件：截图工具，Word
4 测试结果及分析
4.1 XXX处理性能评估
这次测试属于局域网环境进行，排除了外网的网速限制及不稳定性。
并发登录用户测试
测试内容：
这次测试属于模拟真实环境，加入思考时间（think time）；用户输入网址登录首页，加入1~5秒思考时间，输入用户名密码，点击登录按钮。
说明：用户的整个执行流程都录制在Action(循环)部分，所以Vuser_int (开始)和Vuser_end(结束)部分为空。Action_Transaction部分的时间为运行整个Action脚本所需的时间。
整个Action的平均响应时间为：3.945秒；登录操作的平均响应时间为：1.185秒。
说明：所有响应事务数为：8720次(个)
服务器平均每秒响应事件：6.664次/秒；其中登录的平均每秒响应事件为：3.257次/秒
结果分析：
此次测试用户操作流程简单，所以并未对服务器造成高度负载，从NAS服务器服务器曲线图来看，0到70%区间浮动，运行相当平稳。从模拟环境来看，加入1到5的思考时间，更符合真实用户的操作。
从设置200人的压力分析，响应速度很快，完全在用户的感觉快速响应时间内，从整个Action脚本分析，把整个Action时间减去登录时间为：2.76秒，首页的访问时间相比较长，首页部分图片和动画较多，如果用户量访问量继续加大，必定会影响系统性能。
篇一:[性能测试报告]1.1 目的
篇一:[性能测试报告]1.2 背景
篇一:[性能测试报告]1.3 范围
篇一:[性能测试报告]1.1 引用文档
篇一:[性能测试报告]2.1 测试环境
篇一:[性能测试报告]2.2 人力资源
篇一:[性能测试报告]2.1 测试工作量
篇一:[性能测试报告]3.1 测试需求/目标
篇一:[性能测试报告]3.2 测试内容
篇一:[性能测试报告]3.3 测试工具
篇一:[性能测试报告]4.1 XXX处理性能评估
篇二:[性能测试报告]性能测试报告模板
×××系统
性能测试报告
深圳市XXXXXXX限公司
二零一七年一月
工件版本变更记录：
版本号
拟制/修改日期
拟制/修改人
修改记录
批准人
1.0
2017-01-18
XXXXX
新建
XXXXX
目录
1 文档说明 1
1.1 测试目的 1
1.2 读者对象 1
1.3 参考资料 1
1.4 术语解释 1
2 测试环境 2
2.1 测试环境 2
2.2 测试工具 2
3 测试需求 3
3.1 测试功能点 3
3.2 性能需求 3
4 工作准备 4
5 测试完成准则 5
6 测试风险 6
7 测试设计策略 7
7.1 关键资源不处于阻塞状态 7
7.2 组合测试用例策略 7
8 业务模型 8
8.1 场景一 8
8.2 场景二 8
9 测试报告输出 9
1 文档说明
1.1 编写目的
本次测试报告为xxx系统的性能测试总结报告，目的在于总结性能测试工作，并分析测试结果，描述系统是否符合xxx系统的性能需求。
1.2 测试目的
本次性能测试的目的是检测xxx系统的性能情况。即：为了xxx系统上线后能够稳定运行，有必要在上线前对核心业务场景的压力情况有充分了解。因此，希望在模拟生产环境的情况下，模拟上线后的用户并发数，对系统核心业务进行压力测试，收集相应的系统参数，并最终作为上线的依据。
1.3 读者对象
预期参考人员包括用户、测试人员、开发人员、项目管理者、质量管理人员和需要阅读本报告的高层经理。
1.4 参考资料
名称
是否可用
备注
XXX性能测试方案
是
1.5 术语解释
线程数：并发用户数
请求数Samples：发出了多少个请求，例：模拟10个用户，每个用户迭代10次，就是100次
平均响应时间Average：单个请求平均响应时间（毫秒）
中位数Median： 50％ 用户的响应时间（毫秒）
90% Line：90％ 用户的响应时间
Min：最小响应时间（毫秒）
Max：最大响应时间（毫秒）
错误率Error%：出现错误的请求的数量/请求的总数
吞吐量Throughput：表示每秒完成的请求数（Request per Second），是指在没有帧丢失的情况下，设备能够接受的最大速率
KB/Sec：每秒从服务器端接收到的数据量；1GB＝1024MB，1MB＝1024KB，1KB＝1024Bytes。
1.6 系统压力强度估算
Ø 并发用户的经验公式为：使用系统的用户数量*（5%~20%）。
Ø 系统响应时间判断原则（2-5-10原则）如下： Ø
系统业务响应时间小于2秒，判为优秀，
用户对系统感觉很好； Ø
系统业务响应时间在2-5秒之间，判为良好，用户对系统感觉一般； Ø
系统业务响应时间在5-10秒之间，判为及格，用户对系统勉强接受； Ø
系统业务响应时间超过10秒，判断为不及格，用户无法接受系统的响应速度；
2 测试环境
2.1 测试环境
网络环境：lan（100M）
软件环境：
Ø 操作系统：Windows Server 2008，Windows XP SP3
Ø 应用服务软件：WebSphere，Tomcat5.5
Ø 数据库：DB2,Oracle 10g
硬件环境：
硬件名称
数量（台）
型号
CPU
内存
备注
应用服务器
1
数据库服务器
测试客户端
2.2 测试工具
性能工具：Jmeter3.0
脚本录制：Badyboy2.1
3 测试需求
3.1 测试功能点
×××××××
3.2 性能需求
注：1. 如果未提出实际性能需求可简写或省略该项
2. 此项根据产品需要可适当修改
Ø 并发用户数达到？时，登录系统平均响应时间不超过？秒；
Ø 并发用户数为？时，操作主要的业务流平均响应时间在用户接受的范围内，系统 运行正常；
Ø ？小时运行组合测试用例时，系统正常运行不崩溃；
Ø 若系统容量不能达到要求的并发数或运行时间时，验证一下达到哪一个数值时，系统将不能支持
4 测试策略
4.1 人力资源
名称
测试时间
执行人员
备注
开始时间
结束时间
测试方案
测试脚本
环境、数据准备
结果分析、测试报告
4.2 测试用例
用例编号
T_login_0001
验证功能
系统登录
测试目的
被测系统是否能够满足大并发用户数登录的要求
前置条件
已注册用户的账号与密码
方法
设置并发用户数为100个，模拟用户登录系统的负载压力情况，进行30分钟的连续压力测试，记录系统登录事务交易的平均响应时间、成功率，应用服务器、数据库服务器和网络的各项性能指标，作为系统在实际使用情况中的性能表现依据。对失败交易发生时的各项指标数据进行分析，定位问题发生的原因。
用例名称
并发用户数
响应时间期望<
备注
系统登录并发
100
5s
用例编号
验证功能
测试目的
前置条件
方法
用例名称
并发用户数
响应时间期望<
备注
5 测试结果与分析（图文）
5.1 情景一
6 测试结论
篇二:[性能测试报告]1.1 编写目的
篇二:[性能测试报告]1.2 测试目的
篇二:[性能测试报告]1.3 读者对象
篇二:[性能测试报告]1.4 参考资料
篇二:[性能测试报告]1.5 术语解释
篇二:[性能测试报告]1.6 系统压力强度估算
篇二:[性能测试报告]
篇二:[性能测试报告]2.1 测试环境
篇二:[性能测试报告]2.2 测试工具
篇二:[性能测试报告]3.1 测试功能点
篇二:[性能测试报告]3.2 性能需求
篇二:[性能测试报告]4.1 人力资源
篇二:[性能测试报告]4.2 测试用例
篇二:[性能测试报告]
篇二:[性能测试报告]5.1 情景一
篇三:[性能测试报告]干货 | 论性能测试在软件开发生命周期的重要性
为什么要进行性能测试？什么是好的与坏的性能？为什么性能测试在软件开发生命周期(SDLC software development life cycle)中很重要？
性能不佳的应用通常无法实现企业预期利益，花费了大量时间和金钱，但是却在用户中失去了信誉。
相比功能测试和验收测试(OAT operational acceptance testing)，性能测试容易被忽略，往往在发布之后碰到性能和扩展性问题才意识到重要性。
最终用户眼中的性能
性能”是用户最终的感受。性能优异的应用在最终用户执行某项任务时不会产生过度的延迟而引起用户的不满。好的应用不会在登录时显示空屏，不会让用户走神。比如偶然的用户在购物网站上寻找和购买他们所需要的东西时，客户中心不会收到差性能的投诉。
多数应用系统在峰值时性能表现不佳。从高层看，应用由客户端软件和基础设施组成，后者包括了运行软件所需的服务器硬件和网络基础设施。另外有些应用还有第3 方服务。任何一个组成部分中出现问题，整个系统的性能就将面临灾难。您可能会简单地认为，为了保证应用性能，观察应用每个部分在负载压力下的运行状况并且 解决所出现的问题即可。这种做法往往“太少”和“太迟”了，因此只能是治标不治本。
性能度量
关键业绩指标(KPIs key performance indicators)有服务和效率两种。 基于服务的：衡量应用系统为用户服务的好坏。
可用性(Availability): 终端用户可以使用的应用的总时间。可用性很重要，小小的故障也会导致大量的商务上的花费。用户无法有效地使用该应用系统，比如应用不响应或者响应慢到无法接受。)
响应时间(response time)：一般指系统响应时间。即用户发起请求到收到结果的时间。响应有异步和同步两种。
基于效率的：衡量应用对基础设施的利用。
吞吐量(Throughput)：应用处理速度，比如一定时间内某个页面的点击数。
利用率(Utilization)：理论资源的使用率。当1000个用户同时在线时，应用消耗了多少网络带宽及在服务器内存和cpu等使用情况。
性能标准
没有正式的行业标准，但是有许多非正式的标准，试图对系统的性能好坏做出评价，尤其是B/S应用。比如“页面最小刷新时间”从20秒到8秒，现在是2秒最佳。用户和企业都希望系统能够“即时响应”，但现在这样的性能很难达到的。(Martin et al.,1988)的研究表明：
超过15 秒：基本上不适合交互。某些特定的应用，一些用户可能坐在终端等待超过15秒的时间去等待查询结果的返回, 比如公安局的网上预约系统。然而繁忙的呼叫中心运营商或期货交易商，超过15 秒无法容忍的。如果真的发系统就应该设计成可以让用户转向其他的操作，后面异步响应。
超过4秒：对于要求用户保存短暂记忆里的会话来说太长，当然交易完成之后，4-15秒的延迟是可以忍受的。
2-4 秒：超过2秒很难引起用户的高度关注。买家在输入了她的地址和信用卡号码后等待2-4秒的时间可以接受。然而如果是在早先的阶段，当她正在比较不同产品的差异时，却又是不可容忍的。
低于2 秒: 用户需要记住几个响应信息时，响应时间必须很短，如果要记住更为详细的信息，则要求就更高了。
亚秒: 思想密集型的工作来说（比如写一本书），尤其是一个图形应用程序，响应时间要非常短才能够保持用户的兴趣和长时间的关注。当艺术家将图片拖曳到另一个位置时，程序必须能够立即响应。
马上响应：按键并在屏幕上出现相应的字符，或者用鼠标点击，这种响应必须几乎是瞬时的。比如游戏。
由此可见，响应时间临界点是2秒。
糟糕的性能：为何如此普遍？
IT 商业价值曲线
性能问题通常会比较晚才发现，而且越晚发现，解决成本就越高。 实线(计划)表示预期结果。方块表示部署。虚线(实际)表示实际结果，延迟上线，上线后因为性能问题产生负面效果。
性能测试成熟度
Forrester在 2006年对典型应用系统上线后发现的性能缺陷进行了调查：
图中定义了三种性能测试。
第一种是救火(Firefighting)，发布前很少或从来没有性能测试。所有性能缺陷在生产环境上发现解决。这是最不可取的，却依然比较普遍。
第二种是性能验证(performance validation)。公司为性能测试在产品的后期安排了时间，生产环境会发现30%左右的性能bug。这个当前绝大多数公司的做法。
第三种是性能驱动(performance driven),生命周期中的每一阶段都考虑了性能, 生产环境会发现5%左右的性能bug。
系统设计阶段缺少性能方面的考虑
设计的时候考虑性能有望产出好性能的应用，至少也能使应用在出现意想不到的性能问题时灵活地能进行修改或重新配置。设计相关的性能问题后期才发现就很难解决，有时候甚至需要重新开发。多数的应用基于可独立测试的组件进行开发的，组件在单独执行的时候性能可能都不错，切记必须从整体来考虑。这些组件之间的交互必须高效且扩展性好，集成后才会有好的性能。
直到最后一刻才进行性能测试
性能验证模式下，性能测试直到系统发布前才会进行，并且很少考虑到性能测试所需的时间及失败后所造成的后果。可能无法发现一些严重的性能缺陷或发现了性能问题但却没有时间解决。
扩展性
可能忽略了用户的地理分布和规模等。需要考虑如下问题：
有多少终端用户会实际使用？
用户位于何处？
多少用户会同时使用？
用户如何连接到应用？
后期有多少额外的用户需要访问应用？
应用的服务器数量及网络拓扑？
将应用对网络容量产生什么影响？
了解流行度
很多公司低估其应用的人气，人是好奇的，系统发布的第一天，你估计1万次点击，结果却是100万次点击，您的应用系统就这样崩溃了！需要考虑高峰访问。令人震惊的失败：一个真实的例子在很多年以前，英国政府决定在互联网上公布1901年人口普查的结果。这涉及到大量的将旧文档转换成现代的数字格式文档的工作，并且还需要创建一个应用以供公众访问。很多希望了解家族历史,24小时之后网站崩溃了。在之后的几个星期里始终无法访问，直到最后重新发布。
性能测试还不规范
目前性能调优的书籍很多，但是对医生而言，最重要的是识别病情，识别性能瓶颈比解决问题有时更难。
不使用自动化的测试工具
不使用自动化的测试工具和自动化：单单使用手工是很难完成性能测试的。
应用程序使用技术的影响
应用程序使用技术的影响：某些新技术不太方便进行测试。
如何选择性能测试工具？web方面的测试工具比较多。但是非web的，尤其是涉及到加密和压缩的，就很少了，甚至是https，很多工具都处理不好。
性能测试工具架构
常见的性能测试工具架构：
脚本：描述用户的活动，支持不同协议。
测试管理模块: 创建并执行性能测试会话或场景。
负载生成器: 生成负载。
分析模块: 分析数据，有些还有自动分析的专家模式。
其他模块: 监控服务器和网络性能的同时，与其他软件集成。
选择性能测试工具
选择性能测试工具：除了HTTP/S支持比较广泛，JavaScript, JSON和 Microsoft Silverlight就不一样了。
协议支持
授权：比如最大虚拟用户数；能支持的额外协议；附加插件集成和特定的技术栈监控，比如Oracle, Python等，)可以与APM(application performance monitoring)与CI(continuous integration)集成。
脚本支持：稍微复杂一点的测试就需要深入脚本。考虑脚本修改的难度；考虑测试团队的技术水平，比如团队如果有python高手，直接用python功能会比具体的工具要强大得多。
解决方案与负载测试工具: 有些厂商只提供个负载测试工具，而有些提供性能测试解决方案。解决方案产花费更多，但通常功能更强大，可能包括自动需求管理，自动数据创建和管理，预性能 测试的应用程序调试和优化，响应时间预测和容量建模，APM提供类和方法层面的分析，集成用户体验（EYE）监控，管理测试结果和测试资产等。
外包：可以免去工具选型等。但是次数太多的成本太高。
其他：基于云平台的测试。节约硬件成本。缺点：次数太多的成本太高，性能指标监控未必方便。程序不稳定时代价很高。
备注：Loadrunner之类的性能测试工具，中文化和文档都做得不错，对于通用的http协议效果也可以。但是扩展性差、效率低下、价格极其昂贵。所以一般认为一谈性能就谈Loadrunner的人没有真正入门性能测试。功能测试的QTP也和Loadrunner类似。
性能测试工具集：概念验证(POC Proof of Concept)
POC至少要有两个用例：读数据和写数据。目的如下：
对性能测试工具是否适合目标应用进行技术评估。
识别脚本数据要求
评估脚本需要的编写和修改时间
展示测试工具的容量。
POC检查表
一般不建议超过2天。
准备：
成功或退出标准，客户已经签字。
工具的软硬件准备ok。
安装任何需要监控软件的权限。
理想情况下保证环境专有性
应用技术支持：产品专家。
应用技术支持：技术专家(比如开发)可以咨询或者应用中间件级别的架构宣讲。
用户帐户：可以安装访问
至少两套凭据登录目标应用程序。因为需要并发执行等。
两个用例，简单的读和复杂的写。
过程
录制用例并比较异同，注意运行时和会话数据等。
修改脚本，确认用户和多用户模式都可以执行，结果正确。确保脚本无内存泄露等不良行为。
交付：
通过或者不通过
生成了数据需求。
脚本开发时间
如果是售前，要能说服客户
有效应用性能测试的基础需要考虑的问题：
发布时要支持多少用户？6个月，12个月，2年后呢？
用户分布及如何将它们连接到应用？
发布时用户的并发？ 6个月后，12个月，2年后呢？
回答会引出一些问题, 比如：
每个应用层需要的服务器规格及数量是什么？
服务器的位置？
网络基础设施的类型？
回答不出来没有关系，但是你已经开始考虑容量和扩展性了。从广义上讲，功能需求定义系统是应该做什么，非功能需求定义系统是什么样子(来自维基百科)。在软件测试中，性能测试基于基准衡量系统对性能和容量质量，包括以下内容：
项目计划
应用够稳定
足够的时间
代码冻结
基本的非功能需求
设计合适的性能测试环境
设置现实合适的性能目标
确定并脚本化的关键use case
测试数据
负荷模型
精确的性能测试设计
KPI(Key Performance Indicator)
应用准备OK
功能要运行稳定，不能10次运行，2次失败。避免性能测试成为频繁的bug修改实践。功能等问题会掩盖性能问题。要有严格的单元和功能测试保证。衡量标准如下：
大量数据(High data presentation)：比如大量图片和冗余会话。
低效SQL(Poorly performing SQL)
大量应用的网络来回：容易导致延迟、带宽限制和网络拥塞等。
应用错误：比如HTTP 404，500等。
足够的时间
以下工作需要时间：
准备测试环境
配置负载注射器
识别user case(数天到数周)和脚本化
确定和创建测试数据(数天到数周)
测试环境安装配置
问题解决
代码冻结
不冻结可能会导致脚本失效或不能代表用户行为等。
设计性能测试环境
理论上要与生产环境完全一致，但是很多原因导致不太可能，下面列出部分原因：
服务器的数量和规格: 服务器内容和架构难以复制，尽量保持规格一致，以方便提供基准。
带宽和网络基础设施：地理位置难以复制。
部署层次：建议完全一致。
数据库大小：建议完全一致。
也有公司直接在生产环境同时部署测试环境或者直接拿生产环境做性能测试，后者注意不要影响用户，包含数据和服务等。
性能测试的环境类型有：
生产环境非常接近的副本：通常不太现实。
生产环境的子集，层次一致，服务器规格一致，但是数量有所减少：建议达到的方案。
生产环境的子集，层次有缩减，服务器规格一致，但是数量有所减少：最常见的方案。
虚拟化
虚拟化的概念请参考：https://en.wikipedia.org/wiki/Virtualization 和 https://en.wikipedia.org/wiki/Docker_(software) 等。 注意：
虚拟机管理程序层有管理开销
总线和网络的通信方式不同。前者没有带宽和延迟限制。在网络跨地理位置的情况尤其需要注意。建议虚拟化与生产环境一致。特别注意不要跨层虚拟化在同一机器。
物理与虚拟NIC：后者的开销更大。
云计算
可以简单理解云计算为商品化的虚拟主机，它便宜，容易部署。相关概念介绍参见：https://en.wikipedia.org/wiki/Cloud_computing 。
优点：
可以生成大量负载注射器。
便宜
快速
可扩展
易部署
缺点
不及时关闭很贵
有时不可靠，比如配置的机器无法启动，IP被墙等。
负载注入容量
单机能模拟的虚拟用户是有限的，特别注意测试机的CPU和内存等使用率不要过载，尽量使用多的机器机进行测试。注意以下几点：
负载均衡：一些基于IP分配服务器。所以必要的时候需要使用IP欺骗。
用户会话限制：比如一个IP只能一个会话。
其他问题：
有些中间件不能用脚本表示。解决办法，从表示层入手；改用瘦客户端；自行开发工具。
衡量表示层性能：性能测试通常工作在中间件层。比如想计算用户点击复选框的时间，建议使用前端测试工具。
网络部署模式
广域网的速度通常只有256 Kb左右，网络延迟也比较大。延迟的产生基于光速：1ms/130公里以及交换机、路由器等网络设备和服务器的时延。
如果有必要，可以：1，从WAN进行性能测试；2，测试工具模拟；3，网络模拟。
环境检查表
服务器数：物理或虚拟服务器的数量。
负载均衡策略：负载均衡机制的类型。
硬件清单：CPU的类型和数目，内存，网卡的类型和数量。
软件清单：标准版本的软件清单(不包括中间件)。
中间件清单。
内部和外部链接
软件安装约束
比如安全考虑。
务实的性能目标
目标部分来自服务级别协议(SLA service-level agreement)。无论如何目标必须明确。
一致
一致且尽早介入。
业务
C级管理负责预算和策略决定：·首席信息官（CIO Chief information officer）·首席技术官（CTO Chief technology officer）·首席财务官（CFO Chief financial officer (CFO)）·部门负责人
IT
·开发人员·测试·架构团队·服务提供者（内部和外部）·终端用户
·IT或运维
性能目标定义
主要包含可用性、响应时间、吞吐量、并发、网络利用率和服务器利用率。
在性能测试中并发是同时在线的用户。要注意并发虚拟用户和并发实际用户不一定是同一回事。估算时需要基于二八原理和峰值等。
吞吐量通常更适合衡量无状态的行为。比如浏览购物时通常不会登录，看中之后才会登录，浏览购物可以认为是无状态的。
响应时间不要随着并发的增加而大幅度增加，可以基于单个用户做基准测试。
网络利用率需要关注数据量、数据吞吐量(可能会导致吞吐量突然下降是容量问题)和数据错误率。
服务器利用率主要关注CPU、内存和I/O(磁盘和网络等)
确定和脚本化关键业务user case
关键的user case一般不会超过10个。
Use-Case检查表
记录每个步骤
输入数据和期望的响应
用户类型：新的或老用户，超级用户，客户，客服等类型。
网络：LAN或WAN
主动还是被动
脚本验证
基于抓包工具或录制工具书写脚本，然后单用户到多用户调通。注意脚本不要影响到并发的执行，尽量使用不同的用户等。
检查点
业务较复杂时尤其重要。
是否需要登入登出
尽量符合实际情况。
共存
注意共存的应用和网络共享
测试数据
输入数据
用户凭据：比如用户名和密码。
查找规则：通过客户的姓名和详细地址，发票号和产品码甚至是通配符进行查询。
相关文件：比如图片。
目标数据
需要考虑数据容量是否符合规格的大小，数据回滚等。
会话数据
比如token。
数据安全
数据要保密，同时性能测试工具要实现与服务器端通信的加密方式。
性能测试设计
性能测试的类型
1.pipe-clean测试。2.容量测试。尽量接近用户实际使用。3.隔离测试。4.压力测试。退出标准：没有更多的用户可以登录，响应时间难以接受，或应用程序变得不可用。
5.浸泡测试，又叫稳定测试。发现内存泄漏等问题。
6.冒烟测试，只测试修改的部分。注意和其他地方的概念不一样。
pipe-clean, volume, stress和soak test通常都需要进行。
负载模型
负载模型定义了user case的负载分布及并发和吞吐量的目标。通常先基于容量测试，再扩展到其他类型。注意测试数据、思考时间和步长的影响。比如搜索数据分类：
小数据模型：具体的产品名称或ID。
中数据模型：局部产品名称。
大数据模型: 通配符或最小的产品名称的内容。
需要模拟真实情况下各种user case的分布:
吞吐量模型对于已有一个用需要参考Google Analytics或WebTrends，新应用的需要估计。
思考时间代表着延迟和暂停。步长是循环之间的间隔。
负载注入方式有：Big Bang、Ramp-up、Ramp-up (with step)、Ramp up (with step), ramp down (with step)、Delayed start。注意"with step"主要是为了方便观察。
KPI
服务器KPI
Windows 性能工具。Linux有monitor、top,、vmstat、sar等工具。监控分为业务层、中间件层和系统层等。通用模板如下：
Total processor utilization %
Processor queue length
Context switches/second
Available memory in bytes
Memory pages faults/second
Memory cache faults/second
Memory page reads/second
Page file usage %
Top 10 processes in terms of the previous counters
Free disk space %
Physical disk: average disk queue length
Physical disk: % disk time
Network interface: Packets Received errors
Network interface: Packets Outbound errors
Web和应用服务器层：比如nginx、WebLogic、WebSphere、Apache、JBOSS等。数据库层：比如MYSQL、Oracle等。MongoDB, Cassandra和DynamoDB可以视为应用设计的一部分。大型主机层：比如Strobe、Candle主机层：比如亚马逊的CloudWatch。网络层：网络错误、延迟、带宽。
性能测试过程
性能测试的方法
范围和非功能需求捕捉：通常需要几天。
性能测试环境准备
user case脚本化：一个user case通常需要半天。
创建和验证性能测试场景。1-2天。前提是创建了精确的负载模型，定义每个性能测试的结构和内容。
执行性能测试。通常需要5天左右。如果频繁重测，耗时更多。
收集数据和卸载软件。通常需要1天左右。
最后分析和报告。通常需要2-3天左右。
非功能需求分析
先决条件如下：
性能测试的截止期限
内部或外部资源OK。
测试环境的设计。尽量接近真实环境。
代码冻结。
专有的测试环境，
目标。
关键用例。识别、记录并准备脚本。
用例中的检查点。
选择的use case的输入、目标和会话数据。同时还需要考虑数据安全。
负载模型OK。
性能测试场景的数量、类型、use-case内容和虚拟用户的部署已经确定。还可能需要考虑时间，步长，注入细节等。
识别和记录应用、服务器和网络的KPI。注意需要关注基础设施。
性能测试的输出。
bug提交方式。涉及测试团队成员和报告结构。工具、资源、技术和授权。另外还有培训，在外包的时候尤其重要。常见的架构如下：
基于上述信息，可以输出：1.制定包括资源，时间线和里程碑的高层计划2.包括所有的依赖、相关时间线、详细的场景和use case，负荷模型和环境信息的性能测试计划。3.风险评估。另外还需要注意迭代。
性能测试环境准备
步骤如下：
1.足够的时间来采购设备，配置和构建环境。2.考所有部署模型要在LAN和WAN环境实验。3.考虑外部链接。4.提供足够的负荷注入容量。比如云主机。5.确保应用正确部署到测试环境。6.软件授权。7.部署和配置性能测试工具。8.部署和配置KPI监控。
Use-Case脚本
针对每个user case：
确定会话数据的要求。其中一些可能来自概念验证(POC)。
确认并应用输入数据的要求。
检查点。
修改脚本
脚本单用户和多用户都可以执行。
性能测试场景构建
测试类型是什么(pipe-clean, volume, soak, or stress？)，通常是针对user case进行单个用户(pipe-clean)测试，产生基线数据。然后加大并发和吞吐量。之后进行混合user case的容量测试。然后可能有soak和stress测试，最后还可能结合负载均衡和容灾等测试。
思考时间和步长(尤其是压力测试)。
负载注射器和虚拟用户的数量。
注入方式：Big Bang, ramp-up, ramp-up/ramp-down with step, or delayed start。注意这几种方式可能是连接的。比如下图：
测试执行控制：执行一段时间段、到达一定界限或测试数据耗尽停止或是用户介入。
是否需要IP欺骗?
您是否需要模拟不同的波特率？
监控需求。
Web的性能测试需要考虑浏览器缓存。还需要考虑新用户，活跃用户，回归用户等。
技术影响，比如SAP比较消耗资源。
性能测试执行
1.pipe-clean测试。2.容量测试。3.隔离测试4.压力测试。5.浸泡测试，发现内存泄漏等问题6.其他测试，比如负载均衡，容灾等。
性能测试分析和报告
进行最后的数据收集(可能有软件卸载)。数据要有备份。
比较试验结果与目标，决定是否通过。
测试报告。
性能测试分析
相关术语
平均值和中值
标准偏差和正态分布: 高标准偏差表示用户体验不好。
百分比
响应时间分布
吞吐量不能增加，一般有瓶颈存在：
远程监控：Windows注册表、Web-Based Enterprise Management (WBEM)、Simple Network Monitoring Protocol (SNMP)、Java Monitoring Interface (JMX)、Rstatd（传统的基于RPC的监控工具）
客户端需要关注：CPU百分比、内存使用、页利用率、磁盘时间、磁盘空间。
查找原因
好的扩展性与响应时间：
差的扩展性和响应时间
特别注意值的突然跳跃，一般是有瓶颈存在。另外服务器的基线数据也可供参考。
性能测试与移动端
移动端的类型
移动网站
移动应用
混合移动应用
m. site: 很少用，IOS中用来避免Apple App Store，像移动应用，但是实质是移动网站。
设计考虑
耗电量：
运行一定时间，观察耗电量；
与其他应用同时使用，观察耗电量排行。
网络：
异步：
测试考虑
兼容性：系统、浏览器等组合。
API测试。
移动测试设计
移动网站：考虑浏览器。可以参考Google Analytics。
移动应用：考虑API。
混合移动应用
m. site: 很少用，IOS中用来避免Apple App Store，像移动应用，但是实质是移动网站。
终端用户体验监控与性能
主动监控
测试需要考虑：
参考网络图如下：
主动监控主要关注：可用性和响应时间。
文章转载自磁针石 http://my.oschina.net/u/1433482/blog/634047。
关于听云：国内最大的应用性能管理（APM）解决方案提供商，拥有听云App、听云Network、听云Server、听云Browser、听云Sys五条重要产品线。在真实用户体验视角下实现移动客户端、服务端与网络的性能监控与管理。
