软件性能的产生
1、从“经济学”的角度来考虑软件产品，这是一个意味深长的变化。
2、要运用投入产出的关系分析和指导软件工程的各种活动和环节，软件运行不能以硬件不计成本为假设，要尽可能地少占用各种硬件资源。
3、软件运行的速度也要尽可能地快，每秒5000次加法运算是根本不可想象的，也是不可能被用户接受的。这些就是用户最原始的性能需求。
功能与性能的关系
1、软件的性能和功能的源头来自于用户的需求。
2、（如书本例子P4）功能：邮件系统能够支持收发以30种语言为标题和正文的邮件，并支持粘贴10MB的邮件附件。
3、性能：邮件系统能够在2G RAM/1GHz CPU的服务器上，支持10000注册用户，日均处理10000邮件，响应时间不超过5秒/封。
功能需求说明和性能需求说明区别
1、功能需求中名词和动词多，描述软件主体和动作行为，比如“标题”、“正文”、“收发”、“粘贴”等。
2、性能需求中对涉及容量和时间词汇多，如“2GB RAM服务器”、“10000注册用户”、“5秒/封”等。
软件性能和功能区别本质
功能：焦点在于软件“做什么”，关注软件物质“主体”发生的“事件”。
性能：焦点在于软件物质“做得如何”，这是综合“空间”和“时间”考虑的方案（资源和速度），表现为软件对“空间”和“时间”的敏感度。
用户眼里的软件性能
五点：计算性能、资源的利用和回收、启动时间、伸缩性、稳定性（如书本例子P7）。
通常，衡量一个软件系统性能的常见指标有：
1、响应时间（服务器端响应时间、网络响应时间、客户端响应时间）
那客户感受的响应时间其实是等于客户端+服务器端网络响应时间
2、吞吐量
软件系统在每单位时间内能处理多少个事务/请求/单位数据等
3、资源使用率
常见的资源有：CPU占用率、内存使用率、磁盘I/O、网络I/O
4、点击数
点击数是衡量WebServer处理能力的一个指标，客户端向WebServer发起多少次http请求计算，一次鼠标可能触发多个http请求，这需要结合具体的Web系统实现来计算
5、并发用户数
是用来度量服务器并发容量和同步协调能力，在客户端指一批用户同时执行一个操作。并发数反映了软件系统的并发处理能力，与吞吐量不同的是，它大多是占用套接字、句柄等操作系统资源
软件人员眼里的软件性能
1、消除对空间和时间不必要的浪费
如：内存泄漏问题，被开发人员看做是大忌
2、以空间换时间
软件人员只好“偷梁换柱”，做一下调整，而这种调整往往是很灵活的。
3、以时间换空间
该方案解决性能问题的情形比较少，对内存要求十分苛刻。如：嵌入式操作系统中
现实要远远复杂得多，不可能完全自己开发程序，很多时间是利用已有的平台和中间件资源，在这种场景下，需怎样考虑性能的问题？
1、软件系统设计的架构及技术平台
在设计阶段决定采用哪种架构和技术，其性能也就注定只能在一定的范围内进行变动
2、中间件的设置和优化
包括操作系统、数据库、Web服务器、消息服务器等
3、硬件的配置
包括服务器硬件配置和网络环境。
服务器硬件包括：内存、CPU等
网络环境包括：交换机、路由器等
性能测试在软件测试的周期位置
如图：一个软件的生产过程通常遵循V型图
对应软件开发过程，软件测试步骤分为：代码审查、单元测试、集成测试、系统测试
性能测试属于软件系统级测试，目的是验证用户的性能需求是否达到
性能测试自身的特点：
1、性能测试不是功能测试
性能测试不要求也无法做到覆盖软件所有的功能，通常只是对系统中某些功能或模块做性能测试
（1）基本常用的功能有注册、登录、收邮件、查询邮件，用户使用频率较高的功能，要做性能测试
（2）对响应时间要求苛刻，从手机呼叫开始，经过基站、核心网，再到被叫手机响铃，整个系统的处理时间应该在用户能接受的范围内
2、性能测试属于系统级测试
（1）性能测试“两头在外”，软件性能需求不仅直接来自用户，最终目的也是服务于用户
（2）性能测试开始的必要条件是软件系统处于一个比较稳定的状态，系统架构、主要代码、中间件等不会再有大的变化，否则会给性能测试带来很大的风险
性能测试策略揭秘
谈到“策略”，这是如今很火、使用较多的一个词。且讲述的策略是性能测试设计策略
WHY（为什么会有不同的策略）
用户的软件性能需求可能是多种多样的，对软件人员，做性能测试也要因地制宜，根据不同性能需求，选择不同的测试策略
WHAT（什么是性能测试设计策略）
验证性能需求是测试目的，测试策略即已经被证明是行之有效的测试方法
HOW（怎样实施）常见的测试方法有：
1、负载测试
负载测试是站在用户的角度去观察在一定条件下软件系统的性能表现
负载测试的预期结果是用户的性能需求得到满足，指标一般体现为：响应时间、交易容量、并发容量、资源使用等
2、压力测试
压力测试是为了考察系统在极端条件下的表现，可以是超负荷的交易量和并发用户数
压力测试和负载测试不同的是：压力测试的预期结果就是系统出现问题，而要考察的是系统处理问题的方式
3、并发测试
验证系统的并发处理能力，一般是和服务器端建立大量的并发连接，通过客户端的响应时间和服务器端的性能检测情况来判断，系统是否达到了既定的并发能力指标。这是特别注意，必须测试
4、基准测试
软件系统中增加一个新的模块时，需要做基准测试，判断新模块对整个软件系统的性能影响
5、稳定性测试
稳定性测试是：系统在一定负载下运行长时间后是否会发生问题，有些问题是不能一下子就暴露出来的，或者说是需要时间积累才能达到能够度量的程度
6、可恢复测试
软件系统能否快速地从错误状态中恢复到正常状态，可恢复测试通常是要结合压力测试一起来做
如何做性能测试
1、性能测试过程从何开始、从何结束？
这是基本而重要的问题，比如LoadRunner手册中提供的过程是：
计划测试→测试设计→创建VU脚本→创建测试场景→运行测试场景→分析结果
而在Segue中提供的性能测试过程，是一个try-check过程：
评估需求→ 开发测试→建立基线→执行测试→分析结果→回归测试→测试结束
上述各自的性能测试过程最大区别不在于工具部分，而是在于两者过程的入口和出口条件不一致，使得它们其实在描述两件事情，或者说是在描述一个事情的两个部分。
因此，应该突破已有的理论束缚，寻找更合适的性能测试过程模型
2、性能测试本身有没有质量？
（1）性能测试耗费的资源，包括时间、人力、物力
（2）性能测试中发现的bug数目，以及各自的级别
（3）软件系统交付用户，在生产环境运行后发现的性能bug数目、级别
一个好的性能测试过程模型对提高性能测试质量是很有帮助的
GAME（A）性能测试过程模型：
G：Goal，目标
A：Analysis，分析
M：Metrics，度量
E：Execution，执行
（A）：Adjust，调整。E执行失败后才进入A阶段，并且涉及的大多是有关开发和系统管理工作，因此A设为隐式
Goal（定义目标）制定一个明确而详细的测试目标是性能测试开始的第一步，也是性能测试成功的关键。
步骤的开始时间：需求获取阶段
步骤的输入：性能需求意向
步骤的输出：明确的性能测试目标和性能测试策略
常规的性能测试目标有以下几种：
（1）度量最终用户响应时间
查看用户执行业务流程以及从服务器得到响应所花费的时间
（2）定义最优的硬件配置
检测各项系统配置（内存、CPU速度、缓存、适配器、调制解调器）对性能的影响
（3）检查可靠性
确定系统在连续的高工作负载下的稳定性级别，强制系统在短时间内处理大量任务，以模拟系统在数周或数月的时间内通常会遇到的活动类型
（4）查看硬件或软件升级
执行回归测试，以便对新旧版本的硬件或软件进行比较，可以查看软件或硬件升级对响应时间（基准）和可靠性的影响。查看新版本的效率和可靠性是否与旧版本相同
（5）确定瓶颈
运行测试以确定系统的瓶颈，并确定哪些因素导致性能下降，如文件锁定、资源争用和网络过载。
（6）度量系统容量
确定系统在不降低性能的前提下能提供多少额外容量，如：图，要查看容量，可以查看现有系统中性能与负载间的关系，并确定出现响应时间显著延长的位置。该处为响应时间曲线的“拐点”
根据测试目标，选择合适的性能测试设计策略。
如：“度量最终用户响应时间”，可以采用“负载测试策略”
“检查可靠性”，可以用“压力测试策略”等等
Analysis（分析）
步骤开始时间：需求分析阶段和性能测试启动阶段
步骤的输入：性能需求
步骤的输出：达成一致的性能指标列表，性能测试案例文档
1、分析性能需求
测试的对象是什么、系统配置如何、应用系统的使用模式是什么。最后得出性能测试指标标准至少包含测试环境、业务规则、期望响应时间等
2、分析系统架构
对硬件和软件组件、系统配置以及典型的使用模型有一个透彻的了解，结合性能测试指标标准，生成性能测试用例
Metrice（度量）
步骤的开始时间：性能测试设计阶段
步骤的输入：细化的性能指标和性能测试案例
步骤的输出：和工具相关的场景度量、交易度量、监控器度量和虚拟用户度量等
“度量”是非常重要的一步，它把性能测试本身量化。这个量化的过程因测试工具的不同而异。
（1）场景的定义，pass/fail 的标准
测试场景包含了性能测试的宏观信息，有测试环境、运行规则和监控数据等。具体可表现为历史数据记录数、虚拟用户数、虚拟用户加载方式、监控指标等
（2）事务（Transaction）的定义，pass/fail的标准
事务用来度量服务器的处理能力。
事务定义应该从性能指标标准而来，是性能指标的具体体现。
事务的定义是很重要的，不同的定义会导致不同的TPS结果。
（3）虚拟用户pass/fail的标准
虚拟用户是性能测试工具中的一个普遍的概念，虚拟用户负责执行性能测试脚本，在这里应该定义虚拟用户遇到何种情况，选择fail或pass，即退出或通过
Execution（执行）
步骤的开始时间：软件测试执行阶段
步骤的输入：场景、交易、虚拟用户等设置信息
步骤的输出：测试报告
执行测试包含两个工作：
1、指标测试环境、数据和脚本
测试环境：硬件平台和软件平台
测试数据：初始测试数据和测试用例数据，表现为SQL脚本、Excel文件
测试脚本：用性能测试工具生成脚本
2、运行场景和监控性能
运行性能测试场景，并监控设定好的数据指标，最终生成测试报告。按照定义好的场景pass/fail标准来判断性能测试是否通过
Adjust（调整）
步骤的开始时间：第一轮性能测试结束后，且没有通过的条件下
步骤的输入：测试报告和测试结果数据
测试的输出：性能问题解决方案
调整包含两个意思：应用程序修改，中间件调优
中间件调优可考虑如下因素操作系统调优：
数据库调优、内存升级、CPU数量、代码调优、Cache调优
性能测试工具的评估和选择
性能测试和一般功能测试不同的是，性能测试的执行是最基本功能的重复和并发，同时性能测试的结果不是那么显而易见，需要对数据进行分析，这些特点决定了性能测试更适合通过工具来完成。
主要的性能自动化测试工具
对于测试人员来说，要么自己开发性能测试工具，要么选择购买市场上已有的性能测试工具
测试预算 VS 工具价格
性能测试的成本与收益比是选择性能测试工具的根本条件。其实考虑“要不要用”的问题。
如果买一套价格10几万的测试工具只是为了几万元预算的性能测试项目，那么无论这个工具再强大，也不会被采用。
协议、开发技术、平台、中间件 VS 工具的支持
1、确定性能测试工具是否支持我们的被测系统
2、是在考虑“能不能用”的问题，原因：被测软件系统使用的协议、采用的技术、基于的平台、调用的中间件。这些都是需要性能测试工具有效的支持
工具可使用的复杂程度 VS 项目计划的影响
1、熟悉并使用一个性能测试工具，是需要花费人力和时间等资源的
2、项目计划中要有相应的资源准备
3、这就是在弄清楚“如何用”的问题
LoadRunner是Mercury Interactive 公司开发的一款成熟的性能测试工具，它作为性能测试的实现者，涉及了性能测试流程、性能测试技术和软件体系架构等众多方面的知识点，学习LoadRunner是理解和学习性能测试的非常好的切入点。
从性能测试到LoadRunner的映射
如果没有性能测试工具，手工将如何做性能测试，首先需要一个测试执行指挥官和一群测试人员，测试指挥官负责指挥和协调整个测试过程，而测试人员则按照指挥官口令一起去操作自己的终端。各自测试人员开始按照测试案例步骤来执行，并把自己的操作时间记录下来，测试完毕后，记录下来汇报给测试指挥官，测试指挥官把结果数据进行计算，得出性能测试是否通过的结果。
这样做应该最符合软件系统的实际操作使用情况的，但是实际上在做性能测试的时候，必须要提前考虑几个问题
（1）资源。手工性能测试需要多个测试人员和多台终端设备，如果需求说明软件系统的用户可能来自不同网络配置，如局域网、ADSL、拨号等，那么性能测试还要考虑制造这些条件，无疑会增加测试的成本
（2）协调。指挥官需要协调各个测试人员，让他们同时开始，如果出现了问题，测试指挥官应立即决断，是继续测试，还是立即中断，去解决问题
（3）重复。性能测试不可能一次通过，需要多轮测试，如何在相同条件下重复第一轮测试，手工测试必然会带来误差
（4）分析。测试指挥官需要分析结果数据，得出性能测试结果是否通过，如果没有通过，最好还要指出是软件系统的哪个节点出了问题，提供解决问题的线索
MI的LoadRunner是怎样解决这些问题的
测试人员：被LoadRunner的Vuser代替（虚拟用户），测试人员执行的操作以VuserScript（虚拟用户脚本）的方式固化下来。而一台计算机可以运行多个Vuser，因此LoadRunner又减少了性能测试对硬件的要求
测试指挥官：被LoadRunner的Controller替代，Controller就是运行性能测试的“司令部”，Controller负责生成性能测试场景，管理和协调多个虚拟用户，在实际运行时，Controller运行任务分派给各个LoadGenertator，同时还联机检测软件系统各个节点的性能，并收集结果数据，提供给LoadRunner的Analysis
Analysis会对数据进行整合，分析出它们之间的关系，并把这些关系以图表和报告的形式展现出来，使得性能测试的结果一目了然
这些概念之间关系，可以用下面比喻说明
性能测试比作盛大的演出，虚拟用户（Vuser）就是演员，导演（Controller）规定了参加演出的有多少个演员，各自如何在台上表演，这种规则就是剧本（性能测试场景）。导演要子啊各个方面保证剧情不能离谱、脱离现实，否则就要砸锅了。因此，导演不仅要确保演出能顺利结束，而且还要同时观察和手机观众的反馈信息（联机监测功能），以分析（Analysis）、确定这次演出是否成功（性能需求是否到达）。
