软件测试之性能测试实践 、关键词解释 、测试方法
一、关键词
性能测试中的关键词有响应时间、并发用户数、吞吐量、性能计数器、思考时间，这是性能测试中常用的几个概念，必须要有清晰的认识。
（1）响应时间
响应时间指的是客户发出请求到得到响应的整个过程。在某些工具中，请求响应时间通常会被称为“TTLB”(Time to laster byte)，意思是从发起一个请求开始，到客户端收到最后一个字节的响应所耗费的时间，我们把响应时间作为用户视角软件性能的主要体现。
在进行性能测试时，合理的响应时间取决于实际的用户需求，而不能依据测试人员的设想来决定。
（2）并发用户数
在同一时间段内访问系统的用户数量。在实际的性能测试工作中，测试人员一般比较关心业务并发用户数，也就是从业务角度关注究竟应该设置多少个并发数比较合理。
究竟怎样确定一个实际系统的并发用户数呢？并发用户数取决于具体的业务场景，因此，在确定并发用户数之前，必须先对用户的业务进行分解，分析出其中的典型业务场景（也就是用户最常使用、最关注的业务操作），然后基于场景采用某些方法获得其并发用户数。
例：被测系统是一个QQ群，用户总是就是全体群成员，在线用户数就是在线的成员，并发用户数就是在聊天的成员。这么一来就很明显了，我们都知道一个QQ群里真正活跃的往往是少数人，所以被测系统的并发用户数也是远小于系统用户总数的。
如何确定并发用户数，这个问题常见的答案就是看具体情况，或者用户总数的10%~20%。事实上，确实没有可以适用于大部分软件的确定并发用户数的方法。一般而言，针对于企业内部的信息系统而言，采用经验公式选择10%~20%的用户总数作为并发用户数是比较合理的。
（3）吞吐量（TPS）
吞吐量直接体现软件系统的性能承载能力，是指在所有加载的用户稳定运行后，目标系统在单位时间内完成被请求的交易数量。一般来说，吞吐量用请求数/秒或页面数/秒来衡量，从业务的角度，吞吐量也可以用访问人数/天或处理的业务数/小时等单位来衡量。对于非交互式应用，用“吞吐量”来描述用户对系统性能的期望可能更加合理。
注意：要区分这里的吞吐量与loadrunner的analysis的吞吐量概念并不完全相同，loadrunner中的吞吐量是字节数/秒，而且引入了平均事务响应时间TPS的概念，分别从不同维度展示被测系统的吞吐量。
（4）性能计数器&资源利用率
性能计数器（Counter）是描述服务器或操作系统性能的一些数据指标。计数器在性能测试中发挥着监控和分析的关键作用，尤其是在分析系统的可扩展性、进行性能瓶颈的定位时，对计数器取值的分析非常关键。
与性能计数器相关的另一个属于是“资源利用率”，该术语指的是系统各种资源的使用状况。为了方便比较，一般用“资源的实际使用/总的资源可用量”形成资源利用率的数据，用以进行各种资源使用的比较。
例：包括很多种类，通常需要我们关注的就是服务器的资源占用率、内存使用率、磁盘I/O，当然还有其他很多的性能计数器，这里不详细赘述。通过这些资源的占用情况我们能得到表征，但是具体的性能瓶颈还需要深入的分析。
由于服务器使用操作系统不同，所以需要选择不同的工具，对于Windows系统可以使用系统自带的资源监视器，对于Linux系统可以使用nmon工具，这类的工具有很多选择适用的就可以。
（5）思考时间
ThinkTime也叫思考时间，该功能或机制的设计初衷是用于模拟实际生产环境下业务请求压力的不同形态。
从业务的角度来说，该时间指的是用户在进行操作时，每个请求之间的间隔时间。在测试脚本中，思考时间体现为脚本中两个请求语句之间的间隔时间。不同的测试工具提供了不同的函数或方法来实现思考时间。在实际测试中，设置多长的思考时间最为合理是许多性能测试工程师关心的问题。
例：关于思考时间，很多时候我们都认为设置成0是最合理的，因为这样可以模拟一种尽量大的压力，以研究系统在巨大压力下的表现；但是如果要验证系统具有预期的能力，则需要尽量模拟真实用户在处理业务时的思考时间。
二、测试的方法
性能测试的方法主要包括验收性能测试、负载测试、压力测试、配置测试、并发测试、可靠性测试、失败恢复测试。
（1）验收性能测试
验收性能测试的主要目的是验证系统是否具有所宣称的能力，这需要在被测系统有确定的性能目标，以及确定的被测环境。性能测试人员在确定的条件下，通过模拟生产运行的业务压力量和使用场景组合的方式来进行验收性能测试。
（2）负载测试
负载测试指通过在被测系统上不断增加压力，直到性能指标例如响应时间超过预定指标或者某种资源已经达到饱和状态。这种测试的目的是找到系统的处理能力极限，另一方面这种方法可以了解系统的容量，为性能调优提供依据。
（3）压力测试
压力测试的主要目的是检查系统在一定压力下的性能表现。通过模拟负载等方法，使得系统资源占用达到较高水平。压力测试一般也用来验证系统的稳定性
（4）配置测试
配置测试的目的是通过对系统软硬件调整，了解不同配置对系统性能影响程度，从而找到最优分配原则。这种测试一般在对系统的性能表现有了一定了解后进行，用于系统的性能调优和规划能力。
（5）并发测试
并发测试的主要目的是发现系统中可能隐藏的并发访问问题，通过模拟用户并发访问实现，主要关注内存泄露、线程锁、资源争用等。并发测试可以在开发的各阶段针对不同的对象使用。
（6）可靠性测试
可靠性测试主要的目的是验证系统能否支持长时间稳定运行。通过给系统加载一定的业务压力（如资源在70%~90%使用率），让应用持续运行一段时间，通过关注系统的运行状态测试系统是否稳定。
这里我认为需要对负载测试、压力测试、可靠性测试加以区分，通过测试的目的区分这三个概念是比较容易的，负载测试的目的在于发现系统的性能瓶颈；压力测试的目的是在一定压力下验证系统性能表现，重点关注响应时间等内容；可靠性测试则是近乎破坏式地让系统保持在业务的高峰期，关注的是系统能否正常工作，这时就不那么关注系统的响应时间了。
（7）失效恢复测试
失效恢复测试针对有冗余备份和载均衡的系统设计，可以用来检验如果系统局部发生故障，用户能否继续使用系统，以及用户将受多大程度的影响。一般只有对持续运行指标有明确需求的系统才需要这类性能测试。
三、应用领域
性能测试的应用领域主要有能力验证、规划能力、性能调优、发现缺陷和性能基准比较五个领域。其中性能基准比较使用于敏捷开发过程中，在这里不做讲述。下面主要讲述常用的四个领域。
（1）能力验证
能力验证通常是对已部署系统的性能进行验证。一般采用性能测试，可靠性测试，压力测试，失效恢复测试
（2）规划能力
规划能力主要用于了解系统的性能并且获得扩展性能的方法，如系统能否支持未来一段时间内的用户增长，是一种探索性测试。一般采用负载测试，配置测试和压力测试
（3）性能调优
性能调优通常是确定基准的环境和性能指标，通过调整环境和实现方式进行测试，进而发现性能优化的方式，一般采用配置测试，负载测试，压力测试和失效恢复测试
（4）缺陷发现
这一领域的目的就是发现系统中可能存在的性能缺陷，没有需要达到的性能指标，因此主要采用并发测试，如果需要关注压力或者失效恢复过程中的问题，也可以采用压力测试和失效恢复测试。
（5）性能测试应用领域和测试方法的关系
通过下方的表格，可以帮助读者更好地理解应用领域与测试方法的关系。
|
应用领域 |
主要用途 |
典型场景 |
特点 |
性能测试方法 |
|
能力验证 |
关注在给定的软硬件条件下，系统能否具有预期的能力表现 |
在要求平均响应时间小于2秒的前提下，如何判断系统是否能够支持50万用户/天的访问量？ |
a)要求在已确定的环境下运行 |
a)性能测试 d)失效恢复测试 |
|
规划能力 |
关注如何使系统具有我们要求的性能能力 |
某某系统计划在一年内获客量在到xxx万，系统到时候是否能支持这么多用户量？如果不能需要如何调整系统的配置？ |
a)它是一种探索性的测试 |
a)负载测试 |
|
性能调优 |
主要用于对系统性能进行调优 |
某某系统上线运行一段时间后响应速度越来越慢，此时应该如何办？ |
每次只改变一个配置，切忌无休止的调优 |
a)负载测试 |
|
缺陷发现 |
发现缺陷或问题重现、定位手段 |
某些缺陷只有在高负载的情况下才能暴露出来，如线程锁、资源竞争或内存泄露。 |
做为系统测试的补充，用来发现并发问题，或是对系统已经出现的问题进行重现和定位 |
a)并发测试 c)失效恢复测试 |
四、性能测试过程模型ptgm
性能测试过程模型PTGM（Performance Testing General Model），将性能测试过程分为测试前期准备、测试工具引入、测试计划、测试设计与开发、测试执行和管理以及测试分析等6个步骤。另一种模型是敏捷性能测试模型（APTM），通常敏捷开发的项目如果存在性能需求才会用到这样的性能测试模型，由于目前本人的性能测试经验都是集中在系统或者验收测试的阶段展开，因此本文中只介绍性能测试过程模型PTGM。
1.测试前期准备
前期准备工作主要完成的工作是确保系统稳定和建立性能测试团队具体的活动包括如下的几个方面：
（1）系统基础功能验证
这一步的目的是确定系统功能能够正常使用，毫无疑问性能的基础就是系统可以使用，如果系统的正常使用都存在问题，那追求性能也不具备太大的意义。因此，性能测试展开的前提就是确保被测系统经过至少一轮的功能测试。通常接近验收阶段的项目的测试顺序是功能测试→安全测试→性能测试，因为如果系统需要引入安全策略或者某些设备的话同样会对被测系统的性能产生影响。
（2）组建测试团队
一个性能测试团队包括的角色如下表，组建性能测试团队时可以根据如下的表格，选择具有相应能力的成员。
|
角色 |
职责 |
技能 |
|
测试经理 |
1.和用户等项目干系人交互，确保测试的外部环境 |
1.计划执行和监控能力 |
|
测试设计 |
1.定义性能规划 |
1.业务把控能力 |
|
测试开发 |
1.实现已设计的性能场景 |
1.脚本编码和调试能力 |
|
测试执行 |
1.部署测试环境 |
1.搭建测试环境的能力 |
|
测试分析 |
1.根据测试结果，性能指标的数值，性能计数器值进行分析 |
1.掌握性能测试工具的使用方法 |
|
系统支持 |
1.系统支持，协助解决测试工程师无法解决的系统问题 |
1.处理系统问题的能力和技能，最好有专职的系统管理员担任这个角色 |
|
网络支持 |
1.网络方面的支持，协助测试工程师解决网络方面的问题，在必要时为测试分析角色提供网络方面的分析支持 |
1.网络方面的能力和技能，最好有专职的网络管理员担任这个角色 |
|
数据库支持 |
1.数据库方面的支持，在必要时为测试分析角色提供数据库方面的支持 |
1.数据库方面的能力和技能，最好由专职的DBA担任这个角色 |
（3）测试工具选择
关于性能测试使用的工具，本人想要向读者说明，性能测试中工具并不会起到决定性的作用，通常在进行测试工具的选择时，需要考虑被测系统的环境，如操作系统环境、应用服务器环境、数据库环境、应用使用的协议、网络环境等，只要性能测试工具满足这些环境的需求，无论是使用loadrunner或者是jmeter都是可以的。
（4）性能预备测试
这一步是探索性的测试，是非正式的测试，其目的主要是用来对被测系统的性能表现建立初步印象，得到的结论也是各有不同。当然，如果对被测系统已经有了初步的印象，这一步也是可以跳过的。
2.测试工具引入
（1）选择工具
对于性能测试来说，没有合适的工具配合简直是不可能实现性能测试的，虽然说选择了好的测试工具也不一定就能做好性能测试，但是选择一个适合的测试工具显然是更利于测试活动的开展与实现的。通常是选定几种测试工具，根据被测系统的环境来选择最适合项目的测试工具。
（2）工具应用的技能培训
工具使用方面的培训主要是针对测试开发、测试执行、测试分析三类角色，目的是保证测试活动参与者具备测试所需的技能。
（3）确定工具的应用过程
这个步骤主要是明确工具可以完成的功能，测试工具使用过程中出现了问题如何解决、测试脚本如何管理等各种相关的问题，这些问题是测试过程中必须解决的问题。
3.测试计划
（1）性能测试领域分析
性能测试计划就是为了实现性能测试的目标，根据性能测试的目标我们就可以分析出本次性能测试的领域。不同应用领域的性能测试的性能测试目标和性能目标如下表
|
应用领域 |
性能测试目标 |
性能目标 |
|
能力验证 |
验证系统在给定环境中的性能能力 |
重点关注关键业务响应时间、吞吐量、资源等 |
|
规划能力 |
验证系统的性能扩展能力，找出系统能力扩充的关键点，给出改善其性能扩展能力的建议 |
业务的性能瓶颈 |
|
性能调优 |
提供系统的性能表现 |
重点关注关键业务的响应时间、吞吐量、资源等 |
|
发现缺陷 |
发现系统中的缺陷 |
无 |
（2）用户活动剖析业务建模
用户活动剖析的方法主要分为系统日志分析和用户调查分析。
系统日志分析是指通过应用系统的日志了解用户的活动，分析出用户最关注、最常用的业务功能，以及达到业务功能的操作路径；用户调查分析是在不具备系统日志分析条件的时候（例如，该系统尚未交付用户运行实际的业务）时采用的一种估算方法，可以通过用户调查问卷、同类型系统对比的方法获取用户最关注、最常用的业务功能等内容。
业务建模主要是采用流程图画出各进程之间的交互关系和数据流向，对业务复杂的系统来说，业务建模可以清晰地呈现系统业务，为性能测试提供指导作用
（3）确定性能目标
性能测试目标根据性能测试需求和用户活动分析结果来确定，确定性能测试目标的一般步骤是首先从需求和设计中分析出性能测试需求，结合用户活动剖析与业务建模的结果，最终确定性能测试的目标。
对于性能目标，不能是一句响应时间不能太慢，或是要能稳定运行就完了的，因为这样的目标在测试执行时会遗留下无尽的麻烦。一个较为详细的性能目标如下：
系统在5秒响应时间内处理100个并发用户对业务A的访问，此时服务器的CPU占用率小于75%，内存使用率小于70%。
当然客户给出的需求可能只关注响应时间，或者关注其他的某些场景下的性能指标，但都需要保证确定的性能目标，这样才能保证性能测试良性地进行下去。
（4）制定测试时间计划
主要是给出性能测试的各个活动起止时间，为性能测试的执行给出时间上的估算。
4.测试设计与开发
（1）测试环境设计
测试环境设计是测试设计中不可缺少的环节。性能测试的结果与测试环境之间的关联性非常大，无论是哪种领域内的性能测试，都必须首先确定测试的环境。
对于“能力验证”领域的性能测试来说，测试首先就已经明确了是在特定的部署环境上进行，因此不需要特别为性能测试设计环境，只需要保证用于测试的环境与今后系统运行的环境一致即可。
对于“规划能力”领域的性能测试来说，测试环境不特定，但也需要设计一个基准的环境。
对于“性能调优”领域的性能测试来说，需要有性能测试来衡量调优的效果，因此必须在开始就给出一个用于衡量的环境标准，并在整个调优过程中，保证每次测试时的环境保持不变。
这里的测试环境包括的不仅仅是软件环境和硬件环境，还有一个大家都容易忽略的数据库环境，在一个几乎为空的数据库和一个已有50000条数据库的环境上，同样执行查询、增加和删除数据的操作得到的响应时间明显是不同的。因此如果保证数据库环境稳定，建议备份数据库，每次性能测试开始时恢复相同的数据库备份。
（2）测试场景设计
测试场景模拟的一般是实际业务运行的剖面，其包括业务、业务比例、测试指标的目标以及需要在测试过程中进行监控的性能计数器。测试场景的示例如下：
|
场景名称 |
场景业务及用户比例分配 |
测试指标 |
性能计数器 |
|
用户登录 |
登录业务，100%用户 |
响应时间 |
服务器CPU Usage |
|
标准日常工作 |
增加数据，40％用户 |
响应时间 |
服务器CPU Usage |
在性能测试执行中有时是执行单独的某一功能的性能测试，这样只能对某一功能验证，也就是说，其他业务几乎不产生压力的情况下，某一功能具有什么样的性能表现，这显然是不符合实际的运行环境的，体现的结果也无法反映被测系统的性能表现。
（3）测试用例设计
测试用例是对测试场景的进一步细化，细化内容包括场景中涉及业务的操作序列描述、场景需要的环境部署等内容。
性能测试的测试用例与功能测试的用例相似，下面是一个登录业务的测试用例。
1、用户进入登录页面
2、用户输入正确的用户名和口令
3、用户点击“登录”按钮
4、等待直到出现登录成功的页面，判断该页面成功显示的方法是HTML页面内容中的“欢迎”文本
（4）脚本开发
一个测试脚本一般包含一个业务操作，如登录的脚本就包含上述测试用例中的登录业务的程序化描述。测试脚本的开发通常基于“录制”，依靠工具提供的录制功能，可以将需要性能测试关注的业务在工具的录制下操作一遍，然后基于该录制后的脚本，对其进行修改和调试，确保其可以在性能测试中顺利使用。最常用的脚本修改和调试技巧是“参数化”、“关联”和“日志输出”等。
5.测试执行和管理
（1）建立测试环境
该活动用于搭建需要的测试环境。在设计完成用例之后就会开始该活动，该活动是一个持续性的活动，在测试过程中，可能会根据测试需求进行环境上的调整。
建立测试环境一般包括硬件、软件系统环境的搭建，数据库环境建立，应用系统的部署，系统设置参数的调整，以及数据环境准备几个方面的工作内容。
测试环境的维护，指的是为了测试结果的可比性，一般都需要在每次运行测试结束后恢复初始的测试环境。
（2）部署测试脚本和测试场景
在建立和合适的测试环境之后，接下来的工作是部署测试脚本和测试场景。部署测试脚本和测试场景活动通过测试工具本身提供的功能来实现。
部署活动最终需要保证场景与设计的一致性，保证需要监控的计数器都已经部署好了相应的监控手段。
（3）执行测试和记录结果
准备好环境和部署好测试脚本以及场景后，就可以执行测试并记录测试结果了。在测试工具的协助下，测试执行是非常简单的操作，一般只需要使用菜单或是按钮就可以完成；记录测试结果也可以依靠测试工具完成，通过测试工具的Monitor模块，可以获取并记录需要关注的性能计数器的值。
在测试工具本身不提供对需要关注的性能计数器进行监控的功能时，可以用一些操作系统的工具，自行编制部分脚本解决这个问题，一般的方法是用脚本调用操作系统提供的工具，在脚本实现中将各性能计数器值分析出来并按照一定格式记录在本地文件中。
6.测试分析
测试分析过程用于对测试结果进行分析，根据测试的目的和目标给出测试结论。
性能测试的挑战性很大程度上体现在对测试结果的分析上，可以说，每次性能测试结果的分析都需要测试分析人员具有相当程度的对软件性能的了解、对软件架构的了解、对各性能指标的了解。
测试分析过程是一个灵活的过程，很难给出一种具体的、能适应各种性能测试需要的统一的过程活动列表。
性能分析的通用方法之一是“拐点分析”的方法。“拐点分析”方法是一种利用性能计数器曲线图上的拐点进行性能分析的方法，该方法的基本思想是基于这个事实：性能产生瓶颈是由于某个资源的使用达到了极限，此时的表现是随着压力增大系统性能表现急剧下降，因此，只要关注性能表现上的“拐点”，获得“拐点”附近的资源使用情况，就能够定位出系统的性能瓶颈。
