《软件性能测试从零开始》要点摘录
- 什么是软件的性能？
我们可以把软件作如下简单的理解：
主体：程序，是人类逻辑思维的物化，表现形式为一系列指令代码。
时间：即使计算机速度再快，任何软件程序每一段代码的运行都是需要时间的，例如从用户的感受来讲，就是程序将运行结果响应给用户的速度。
空间：软件运行的环境，以资源的方式存在，通常是软件以间接或直接的方式占用并使用硬件资源和其他软件资源。
硬件资源主要指运行该软件的硬件平台，有CPU、内存和存储系统等，如果软件是基于网络架构的，那么硬件还有网络硬件，如交换机、路由器等。
软件资源包括操作系统、开发平台、中间件和数据库等，它们以库文件和API的方式提供给应用软件使用。
事件：软件按照用户的要求运行，运行的同时必然要占用时间资源和空间资源。
2、功能与性能的关系
首先，软件的性能和功能的源头都是来自于用户的需求。简单地说，性能就是在空间和时间资源有限的条件下，软件系统还能不能工作。软件性能和功能区别的实质是，软件功能焦点在于软件“做什么”，关注软件物质“主体”发生的“事件”；而软件性能则关注于软件物质“做得如何”，这是综合“空间”和“时间”考虑的方案（资源和速度），表现为软件对“空间”和“时间”的敏感度。
另外，我们也要认清一个事实，软件的性能实现是建立在功能实现的基础之上的。
2.1 用户眼里的软件性能
测试人员在做性能测试时，往往要把响应时间、内存利用率、I/O占用率等写在最后测试报告里，因为这是用户最关心的东西。
细分如下：
计算性能——即软件系统有多快。比如，用户会关注软件系统执行一个典型的业务需要花多少时间。我们要给出用户答案，我们的系统完成用户典型操作，比如业务的交易计算，数据的增、删、改、查时间是不是在用户可以接受的范围内。
资源的利用和回收——就是马儿少吃草。软件系统的“草料”就是其依存的硬件和软件资源，硬件资源包括客户端硬件、服务器硬件和网络硬件；软件资源包括操作系统、中间件和数据库等。其中要特别说的是，运行软件系统需要使用到的服务器内存数量，对于整个系统的性能表现是至关重要的。因此，软件系统能否在运行时有效地使用和释放内存是我们考察软件性能的一个重要因素。
启动时间——用户希望系统进入正常工作状态的时间越短越好，尤其在主备系统中，软件的启动时间直接影响主备的切换效率。而不同软件系统启动时间会不同的。
伸缩性——马儿要能快能慢。伸缩性是分析系统性能经常被忽略的一个方面。比如一个系统在50个并发用户访问的时候表现正常，但是当并发用户达到1000的时候，系统表现如何？服务器的性能是逐渐下降呢，还是在某个拐点附近急剧下降呢？
稳定性——尤其是金融和电信系统，这些系统基本上都是每天24小时运转，时时刻刻准备着为用户提供服务。如果它们在运行一段时间后出现了问题，不能响应用户的请求甚至破坏或丢失了数据，那么系统为用户带来的损失是巨大的。这种稳定性问题应该在软件系统上线之前就被考虑并得到解决。
性能指标：用户感官量化
响应时间（Response time）：响应时间就是用户感受软件系统为其服务所耗费的时间，对于网站系统来说，响应时间就是从点击了一个页面计时开始，到这个页面完全在浏览器里展现计时结束的这一段时间间隔。等于客户端响应时间+服务器端响应时间+网络响应时间
吞吐量（Throughput）：吞吐量反映的就是软件系统的“饭量”，也就是系统的处理能力。具体说来，就是指软件系统在每单位时间内能处理多少个事务/请求/单位数据等。。吞吐量的大小由负载（如用户的数量）或行为方式来决定。
资源使用率（Resource utilization）：常见的资源有：CPU占用率、内存使用率、磁盘I/O、网络I/O。
点击数（Hits per second）：点击数不是我们通常理解的用户鼠标点击次数，而是按照客户端向Web Server发起了多少次http请求计算的，一次鼠标可能触发多个http请求，这需要结合具体的Web系统实现来计算。
并发用户数（Concurrent users）：并发用户数用来度量服务器并发容量和同步协调能力。在客户端指一批用户同时执行一个操作。并发数反映了软件系统的并发处理能力，和吞吐量不同的是，它大多是占用套接字、句柄等操作系统资源。
另外，度量软件系统的性能指标还有系统恢复时间等，其实凡是用户有关资源和时间的要求都可以被视作性能指标，都可以作为软件系统的度量，而性能测试就是为了验证这些性能指标是否被满足。
2.2软件人员眼里的软件性能
第一，软件系统设计的架构及技术平台
第二，中间件的设置和优化
第三，硬件的配置
3、软件性能测试
性能测试就属于软件系统级测试，其最终目的是验证用户的性能需求是否达到，在这个目标下，性能测试还常常用来做：
（1）识别系统瓶颈和产生瓶颈的原因；
（2）最优化和调整平台的配置（包括硬件和软件）来达到最高的性能；
（3）判断一个新的模块是否对整个系统的性能有影响。
性能测试具有软件测试的共性：
（1） 确定预期输出是测试必不可少的一部分
（2） 必须彻底检查每一个测试结果
（3） 穷举测试是不可能的
性能测试自身特点：
性能测试不是功能测试
性能测试不要求也无法做到覆盖软件所有的功能，通常我们只是对系统中某些功能或模块做性能测试。一般的，我们在选择性能测试案例时需要遵循以下的原则：
（1） 基本且常用的
（2） 对响应时间要求苛刻的
性能测试属于系统级测试
性能测试开始的必要条件是软件系统已经处于一个比较稳定的状态，系统架构、主要代码、中间件等都不再有大的变化，否则会给性能测试带来很大的风险。
4、性能测试策略
性能测试设计策略，执行策略，调优策略
常见的性能测试方法：
负载测试：
主要是考察软件系统在既定负载下的性能表现。我们对负载测试可以有如下理解：
（1）负载测试是站在用户的角度去观察在一定条件下软件系统的性能表现。
（2）负载测试的预期结果是用户的性能需求得到满足。此指标一般体现为响应时间、交易容量、并发容量、资源使用率等。
压力测试：
压力测试是为了考察系统在极端条件下的表现，极端条件可以是超负荷的交易量和并发用户数。压力测试和负载测试不同的是，压力测试的预期结果就是系统出现问题，而我们要考察的是系统处理问题的方式。压力测试是能让我们识别系统的弱点和在极限负载下程序将如何运行。
并发测试:
验证系统的并发处理能力。一般是和服务器端建立大量的并发连接，通过客户端的响应
时间和服务器端的性能监测情况来判断系统是否达到了既定的并发能力指标。负载测试往往就会使用并发来创造负载，之所以把并发测试单独提出来，是因为并发测试往往涉及服务器的并发容量，以及多进程/多线程协调同步可能带来的问题。这是要特别注意，必须测试的。
基准测试:
当软件系统中增加一个新的模块的时候，需要做基准测试，以判断新模块对整个软件系统的性能影响。按照基准测试的方法，需要打开/关闭新模块至少各做一次测试。关闭模块之前的系统各个性能指标记下来作为基准（Benchmark），然后与打开模块状态下的系统性能指标作比较，以判断模块对系统性能 的影响。
稳定性测试:
测试系统在一定负载下运行长时间后是否会发生问题。
可恢复测试:
测试系统能否快速地从错误状态中恢复到正常状态。可恢复测试通常结合压力测试一起来做。
5、如何做性能测试
实际情况下, 软件性能需求往往进入了性能测试阶段还不明确。这会给性能测试项目带来很大的风险。经过对多个性能测试项目的实践经验总结，我们在本节提出GAME（A）性能测试过程模型，其开始于软件需求分析阶段，非常符合目前国内的性能测试实践。
GAME（A）性能测试过程模型：
G：Goal，目标
A：Analysis，分析
M：Metrics，度量
E：Execution，执行
（A）：Adjust，调整。E执行失败后才进入A阶段，并且涉及的大多是有关开发和系统管理工作，因此A设为隐式。
Goal(定义目标):
本步骤的开始时间：需求获取阶段
本步骤的输入：性能需求意向
本步骤的输出：明确的性能测试目标和性能测试策略
制定一个明确而详细的测试目标是性能测试开始的第一步，也是性能测试成功的关键。
常规的性能测试目标有以下几种：
度量最终用户响应时间
定义最优的硬件配置。检测各项系统配置（内存、CPU速度、缓存、适配器、调制解调器）对性能的影响。了解系统体系结构并测试了应用程序响应时间后，您可以度量不同系统配置下的应用程序响应时间，从而确定哪一种设置能够提供理想的性能级别。
检查可靠性。确定系统在连续的高工作负载下的稳定性级别。强制系统在短时间内处理大量任务，以模拟系统在数周或数月的时间内通常会遇到的活动类型。
查看硬件或软件升级. 执行回归测试，以便对新旧版本的硬件或软件进行比较。您可以查看软件或硬件升级对响应时间（基准）和可靠性的影响。注意：此回归测试的目的不是验证升级版的新功能，而是查看新版本的效率和可靠性是否与旧版本相同。
确定瓶颈。您可以运行测试以确定系统的瓶颈，并确定哪些因素导致性能下降，例如，文件锁定、资源争用和网络过载。
度量系统容量。度量系统容量，并确定系统在不降低性能的前提下能提供多少额外容量。如发现用户数与响应时间图的拐点。
Analysis（分析）
本步骤的开始时间：需求分析阶段和性能测试启动阶段
本步骤的输入：性能需求
本步骤的输出：达成一致的性能指标列表，性能测试案例文档
主要工作
分析性能需求。要定义性能测试的内容，细化性能需求。比如，对于负载测试来说，可以从以下角度来细化需求，逐步找出测试关键点。
测试的对象是什么，例如“被测系统中有负载压力需求的功能点包括哪些？”；“测试中需要模拟哪些部门用户产生的负载压力？”等问题。
系统配置如何，例如“预计有多少用户并发访问？”；“用户客户端的配置如何？”；“使用什么样的数据库”；“服务器怎样和客户端通信？”。
应用系统的使用模式是什么，例如“使用在什么时间达到高峰期？”；“用户使用该系统是采用B/S运行模式吗？”；“网络设备的吞吐能力如何，每个环节承受多少并发用户？”等问题。
最后得出的性能测试指标标准至少要包含测试环境、业务规则、期望响应时间等。
分析系统架构。对硬件和软件组件、系统配置以及典型的使用模型有一个透彻的了解。结合性能测试指标标准，生成性能测试用例。
Metrics（度量）
本步骤的开始时间：性能测试设计阶段
本步骤的输入：细化的性能指标和性能测试案例
本步骤的输出：和工具相关的场景度量、交易度量、监控器度量和虚拟用户度量等
度量是非常重要的一步，它把性能测试本身量化。这个量化的过程因测试工具的不同而异。
（1）场景的定义，pass/fail的标准
测试场景包含了性能测试的宏观信息，有测试环境、运行规则和监控数据等。具体可表现为历史数据记录数、虚拟用户数、虚拟用户加载方式、监控指标等。
（2）事务（Transaction）的定义，pass/fail的标准
事务用来度量服务器的处理能力。事务定义应该从性能指标标准而来，是性能指标的具体体现。事务的定义是很重要的，不同的定义会导致不同的TPS结果。
（3）虚拟用户pass/fail的标准
虚拟用户是性能测试工具中的一个普遍的概念，虚拟用户负责执行性能测试脚本，在这里应该定义虚拟用户遇到何种情况，选择fail或pass，即退出或通过。
Execution（执行）
本步骤的开始时间：软件测试执行阶段
本步骤的输入：场景、交易、虚拟用户等设置信息
本步骤的输出：测试报告
执行测试包含两个工作：
1．准备测试环境、数据和脚本
测试环境：硬件平台和软件平台。
测试数据：包括初始测试数据和测试用例数据两部分。表现为SQL脚本、Excel文件等。
提示：测试环境直接影响测试效果，所有的测试结果都是在一定软硬件环境约束下的结果，测试环境不同，测试结果可能会有所不同。需要注意：如果是完全真实的应用运行环境，要尽可能降低测试对现有业务的影响；如果是建立近似的真实环境，要首先达到服务器、 数据库以及中间件的真实，并且要具备一定的数据量，客户端可以次要考虑。实施负载压力测试时，需要运行系统相关业务，这时需要一些数据支持才可运行业务，这部分数据即为初始测试数据。有时为了模拟不同的虚拟用户的真实负载，需要将一部分业务数据参数化，这部分数据为测试用例数据。
测试脚本：用性能测试工具生成脚本。
2．运行场景和监控性能
运行性能测试场景，并监控设定好的数据指标，最终生成测试报告。按照定义好的场景pass/fail标准来判断性能测试是否通过
Adjust（调整）
本步骤的开始时间：第一轮性能测试结束后，而且没有通过的条件下
本步骤的输入：测试报告和测试结果数据
本步骤的输出：性能问题解决方案
调整包含两个意思：应用程序修改和中间件调优。
中间件调优可考虑如下因素操作系统调优：
数据库调优；
内存升级；
CPU数量；
代码调优；
Cache调优