响应时间、并发用户数、TPS、吞吐量、CPU利用率、内存使用率、在线并发用户数等

性能测试报告里需要包含哪些指标

最大并发用户数；HPS（点击率）、事务响应时间、每秒事务数、每秒点击量、吞吐量、CPU使用率、物理内存使用、网络流量使用等；

前端需主要关注的点是：

**响应时间：**用户从客户端发出请求，并得到响应，以及展示出来的整个过程的时间。

**加速速度：**通俗的理解为页面内容显示的快慢；

**流量：**所消耗的网络流量；

后端需主要关注的是：

**响应时间：**接口从请求到响应、返回的时间；

**并发用户数：**同一时间点请求服务器的用户数，支持的最大并发数。

内存占用；也就是内存开销；

**吞吐量（TPS）：**每秒事务数。在没有遇到性能瓶颈时：TPS=并发用户数*事务数/响应时间；

**错误率：**失败的事务数/事务总数；

**资源使用率：**CPU占用率、内存使用率、磁盘I／O，网络Ｉ／Ｏ;

那么在日常的测试工作中，对于软件性能测试都有哪些评判指标？主要从以下3个方面考量：

1、负载测试；通过自动化测试工具模拟程序或者软件系统在超强负荷条件下，观察系统各项性能指标的变化情况，一般与压力测试共同进行。

2、强度测试；指系统在资源条件很差工作环境下的运行情况，如人为限制网络带宽，内存等。

3、容量测试；一般指模拟用户不断增加时，确定系统可以处理同时在线的最大用户数量。

一、分析提取指标；

二、建立业务模型；

三、评审确定指标。

分析提取指标

建立业务模型

评审确定指标

响应时间：**用户从客户端发出请求，并得到响应，以及展示出来的整个过程的时间。

**加速速度：**通俗的理解为页面内容显示的快慢；

**流量：**所消耗的网络流量；

后端需主要关注的是：

**响应时间：**接口从请求到响应、返回的时间；

**并发用户数：**同一时间点请求服务器的用户数，支持的最大并发数。

内存占用；也就是内存开销；

**吞吐量（TPS）：**每秒事务数。在没有遇到性能瓶颈时：TPS=并发用户数*事务数/响应时间；

**错误率：**失败的事务数/事务总数；

**资源使用率：**CPU占用率、内存使用率、磁盘I／O，网络Ｉ／Ｏ;

一、确定测试目标

性能测试调优是是无止境的，所以在测试之前应确定一个明确性能测试目标，这也是“评估性能”的一个基准，也是性能测试终止的一个基准。

如，在本案例中目标设定为：在相同系统环境配置下，30个并发用户，在1～5秒钟内完成各类在线操作。

二、测试需求分析

性能测试需求分析主要目的是要分析性能测试需求，为后面的性能测试用例设计提供保证。

分析影响系统性能有很多种原因，在此应关注如下几个关键点:

· 用户使用情况需求:

例如用户分布情况; 哪些模块用户使用比较频繁; 在用户操作的数据有哪些特点等。

· 应用配置需求:

例如应用整体框架、涉及到哪些第三方的组件、应用层与数据库层的接口、使用了什么数据库等。

· 系统配置需求:

例如用户客户端配置、客户端与服务器端的网络配置、应用服务器或数据库服务器操作系统等。

这方面工作是非常繁杂的，而且要求测试人员具有挖掘可能造成系统瓶颈因素的洞察力和敏锐感，但是很多测试人员在接手测试之后，很快进入到测试用例设计阶段。实践证明，这样做往往都适得其反，要么工期延期，要么项目开发失败。这个过程在测试整体过程中是非常关键的一环。

性能测试需求分析有个特点: 它关注的是应用的整体，或者会仔细分析围绕着应用的各种外部因素，比如说它所涉及到的硬件、第三方软件，而不会深入到项目具体的内部。这是因为性能测试关注的是项目整体、是一种黑盒测试方法，我们关心一个项目的整体在运行时所暴露出来的问题。

三、性能测试用例设计

性能测试用例设计主要目的是设计出一些合理的场景，去验证在需求分析阶段获得的可能影响性能的因素是否是造成系统瓶颈的因素。

性能测试用例设计一般包括性能测试策略、性能测试案例、性能测试内容。

性能测试策略一般包括对比测试环境与真实的业务操作环境，真实业务操作环境又可能涉及局域网测试环境与机房测试环境等。

性能测试案例主要是根据测试需求分析的结果制定出在测试执行时系统的执行方法，比如“5个人同时录入不同的新客户信息，以及具体的模拟步骤”。

在测试案例设计时应注意如下几点:

· 虚拟用户的操作步骤要尽量类似于真实用户的操作。

· 操作的数据要类同于真实用户实际使用数据，例如在案例中用户录入客户信息时，根据需求得到的结果，我们可以设计有3～4个虚拟用户在录入一些小客户的信息，1～2个虚拟用户在录入大客户的信息等。

· 在案例设计时要充分考虑到需求中用户对模块的使用频率。使得在模拟时每个模块使用情况尽量地类似于真实环境。

性能测试内容一般包括：基准测试、压力测试、负载测试、系统容量测试、并发性能测试、稳定性测试、浪涌测试、疲劳强度测试、可靠性测试、异常测试、批处理性能测试、混合测试（容量）、大数据量测试以及系统资源监控等。性能调优测试时，主要是做并发性能测试，从对系统产生并发性能测试过程中监控系统中各种资源的变化，进行性能瓶颈分析，来判断导致性能瓶颈的原因，然后再调优和回归测试验证。

四、脚本开发数据的准备以及测试执行与监控

测试执行与监控的主要目的是根据设计方案去验证系统是否存在瓶颈，给测试分析提供各种分析数据。此过程会与下面的“测试分析”过程不断进行重复执行，直至真正确定出系统瓶颈所在。

在此过程中如果有测试工具能够满足测试要求，那么应尽量使用测试工具，例如:LoadRunner、Robot、QALoad等，不要手工去开发测试程序，因为做企业项目往往时间紧张，而且测试工具毕竟是一个成熟的产品，在各方面都得到验证。使用工具将会缩短测试周期，而且现在市场上有很多成熟的测试软件。在这个案例中我使用的是LoadRunner。

技术细节就不再赘述了，这里主要提两点：

一是数据的准备。数据准备一定要关注数据的质量和数量，不要出现一些不符合业务逻辑的废数据，并且数据量要满足测试运行的需要。例如测试需要100组数据，但是实际只准备了50组，从而导致测试执行结果出现大的偏差。

二是测试执行。除了正确按照设计的要求去设置各种参数之外，还要关注系统是否存在功能问题，这往往成为性能测试的“盲点”。原则上性能测试之前必须确保功能测试已经完备，但是任何事情都不绝对，所以一般做性能测试之初，都会模拟一个用户去运行设计的场景，主要是确保“测试脚本正确性”、“在设计的场景中应用系统不存在功能上的问题”。很多性能测试过程往往因为功能问题导致性能测试失败，或者是测试延期的现象。

五、测试结果数据分析

测试分析的主要目的是要根据测试执行获取到的数据去判断造成系统出现瓶颈的位置，挖掘造成系统瓶颈的真正原因。这个过程是技术含量最高的一环，因为在测试执行过程获取到的数据会涉及到各个方面，在这个案例中就涵盖了网络方面的知识、系统方面的知识、应用方面的知识等，测试人员需要从这些繁杂的数据中挑出异常，系统越大越复杂在这个方面对测试人员要求会更高。但是这里面也有一些技巧:

· 在做性能测试分析时人员组成建议为: 开发人员、系统人员、性能测试人员共同组成。这样会在技术上填补个人技术上的不足。实际每个项目涉及到的技术都可能各有不同，对于个人来说不可能每样都精通。

· 反复比较一个类型的性能参数在不同时间的跳跃值，或者不同场景下同一个类型性能参数值的变化。

· 在发现参数值有异常变化时，不要轻易下结论，而是要尽量挖掘可能影响这个参数的其他参数值。在长期的测试过程中发现往往发现第一个所谓的瓶颈都是因为其他因素造成的。

· 在测试分析时使用较多的一种方式是排除法，根据开始获取到的信息大概能将问题定位在某一层面上。但具体在什么地方，就可以采取排除的方法去定位。

· 尽量使用一些比较成熟的工具协助分析工作，这样将大大减轻工作负担。

· 在确定出真正的性能瓶颈时，可以做一些小的测试模型去做验证，确定分析的正确性。

在本案例中，在测试结果经过各种比对之后，最后确定是数据库层上出现问题。但是问题究竟出现什么地方呢？我在分析过程中采用了许多排除法，比如更新索引的统计值、将数据库中的表从页级锁改为行级锁等，但是都效果甚微。

所以，我们回到上面看与数据库层相关的需求:

1. 因为业务需要，需要使用很多模糊查询。此类操作会进行表扫描。为了防止脏读，会向数据库申请表级意向锁。

2. 因为客户关系复杂，所以数据库设计的时候，存在多表关联。

3. 在应用开发时，我们使用了Hiberate这个组件，这些组件对于开发人员来说是一个黑盒，而且存在一些局限性: 在更新记录时会同步更新所有相关联的表，即使关联表不需要更新; 同步更新的记录操作会涵盖一个事物处理过程中，会产生大事务操作; 无法利用SQL优化技术去优化他所产生出来的SQL语句。

研究之后发现: 在进行模糊查询与大客户信息录入与修改的操作时，由hiberate这个组件产生的大事务SQL导致了数据库的互锁，是系统瓶颈所在。为了验证这一判断的正确性，需要做了一个小的模型去验证。

假设库中有A、B、C三张表，现在有三个虚拟用户同时在上面进行操作: 用户Vuser1需要查询客户信息，他只知道客户的姓氏，所以他采取了模糊查询; 用户Vuser2正在修改一个客户信息，正准备保存; 用户Vuser3正在查询客户办公信息，也需要模糊查询。

Vuser1操作先得到执行，在表扫描中出现表级意向锁; 此时Vuser2进来需要修改A、B、C三张表对应记录，并成功的锁定了B、C两张表对应的行（因为是行级锁），然后进行了修改，但是无法修改表A，所以Vuser2此时等待Vuser1释放锁; 此时Vuser3进来了，需要查询C表，因为Vuser2并没有释放锁，此时Vuser3也处在等待状态。验证显示，在出现大数量的操作并且在多用户的操作下，此瓶颈将不断地暴露出来。

六、系统调优与验证

将获取的分析数据交付到开发组进行调优，经过调优后，一般都需要再次进行验证，验证主要关注调优后的结果是否解决了所发现的系统性能瓶颈，是否产生了新的性能瓶颈。这方面的工作主要由开发人员来完成。在本案例中，去掉了Hiberate组件，改为由应用自身控制，尽量减少了大事物的出现概率，并同业务部门商议，降低了模糊查询操作的次数。在后来再做“性能评测”时确认系统达到了预期目标。

那么在日常的测试工作中，对于软件性能测试都有哪些评判指标？主要从以下3个方面考量：

1、负载测试；通过自动化测试工具模拟程序或者软件系统在超强负荷条件下，观察系统各项性能指标的变化情况，一般与压力测试共同进行。

2、强度测试；指系统在资源条件很差工作环境下的运行情况，如人为限制网络带宽，内存等。

3、容量测试；一般指模拟用户不断增加时，确定系统可以处理同时在线的最大用户数量。

一、验收测试的内容

验收测试(Acceptance Testing)是在产品完成功能测试和系统测试之后、产品发布之前所进行的软件测试活动，它是技术测试的最后一个阶段，也称为交付测试。验收测试的目的是确保产品准备就绪，并且可以让最终用户将其用于执行产品的既定功能和任务。

验收测试的主要内容包括：制定验收测试的标准、复审配置项和执行验收测试。

1.1 制定验收测试的标准

与系统测试一样，验收测试也需要一系列的测试计划和方案。首先需要确定本次验收测试需要测试哪些种类，即测试哪些方面，如性能测试、可安装性测试、可移植性测试、易用性测试、文档测试等;然后依据测试种类安排相应的测试进度。

测试计划确定后，需要确定验收测试过程中使用的测试用例，关于测试用例的确定，一般有两种方法：一是在原系统测试阶段设计的测试用例抽取一部分，作为验收测试的用例(因为验收测试不可能对整个系统进行一次完整的测试，一般可能会抽取部分测试用例作为验收测试的用例)，但该方法的缺点是，由于系统测试阶段设计的测试用例都已经过了测试，所以这些测试用例正常情况下都能正确地通过测试;二是在抽取部分测试用例的基础上添加一些特殊的测试用例，这种方法虽然花费的时间相对较长，但是验收会更全面，添加的特殊测试用例可以更好地验收需要关注的功能点。

验收测试主要关注以下几个方面的内容：

(1)软件是否满足合同规定的所有功能和性能。

(2)文档资料是否完整。

(3)人机界面是否准确，并与合同规则相一致。

(4)其他方面(如可移植性、兼容性、错误恢复能力和可维护性等)是否令用户满意。

验收测试的结果有两种：一种是功能和性能指标满足软件需求说明的要求，用户可以接受;另一种是软件不满足软件需求说明的要求，用户无法接受。项目进行到这个阶段才发现严重错误和偏差，一般很难在预定的工期内改正，因此必须与用户协商，寻求一个妥善解决问题的方法。

1.2 复审配置项

验收测试的另一个重要环节是配置项复审，在进行验收测试之前，必须保证所有软件配置项都能进入验收测试，只有这样才能保证最终交付给用户的软件产品的完整性和有效性。复审的目的是保证软件配置齐全、分类有序，并且包括软件维护所必需的细节。

对于一个外包的软件项目而言，软件承包方通常要提供如下相关的软件配置内容：

(1)可执行程序、源程序、配置脚本、测试程序或脚本等;

(2)开发类文档，主要包括《需求分析说明书》《概要设计说明书》《详细设计说明书》《数据库设计说明书》《测试计划》《测试报告》《测试用例》《程序维护手册》《程序员开发手册》《用户操作手册》《项目总结报告》等;

(3)管理类文档，主要包括《项目计划书》《质量控制计划》《配置管理计划》《用户培训计划》

《质量总结报告》《评审报告》《会议记录》《开发进度月报》等;

(4)在开发类文档中，容易被忽视的文档有《程序维护手册》《程序员开发手册》。《程序维护手册》的主要内容包括：系统说明(包括程序说明)、操作环境、维护过程、源代码清单等，编写目的是为将来的维护、修改和再次开发工作提供有用的技术信息。《程序员开发手册》的主要内容包括：系统目标、开发环境使用说明、测试环境使用说明、编码规范及相应的流程等，相当于程序员的培训手册。

对上述的交付文件，需要在合同中规定阶段提交的时间，以免发生纠纷。

在实际的验收测试执行过程中，文档审核是比较难的工作，主要原因有两个方面;一方面是由于市场需求、时间等方面的压力，文档工作被延迟和弱化，将更多的时间和精力花费在产品的研究过程中，而忽略了文档的编写;另一个方面是文档评审往往没有标准可循，不易把握其完善的好与坏。

1.3 执行验收测试

验收测试标准和复审配置项都准备好后，即可开始执行验收测试，验收测试的对象主要包括复审配置项(即文档)的测试和可执行程序的测试。验收测试是整个验收过程中的核心部分。