性能测试学习day02---测试基础知识

一、测试分类

1.服务类型：B/S、C/S

2.测试内容：功能测试、负载测试、性能测试、压力测试、安装测试、易用性测试、安全性测试、恢复测试、大数据测试、兼容性测试、内存泄露测试、竞品测试、可靠性测试、文档测试。

3.服务类型：手机端测试、PC端测试

4.测试方法：白盒测试、黑盒测试、探索性测试

5.程序运行状态：静态测试、动态测试

6.软件阶段：单元测试、集成测试、系统测试、验收测试、回归测试、Alpha测试、Beta测试

 

二、性能测试流程

（1）业务学习：

通过查找文档，手工操作系统来了解系统功能

（2）需求分析：

分析系统非功能需求，圈定性能测试的范围，了解性能测试指标

（3）工作评估：

工作量分解，评估工作量，计划资源投入（即需要多少人力，多少工作日来完成性能测试工作）

（4）设计模型：

圈定性能测试范围后，把业务模型影射成设计模型

什么是测试模型呢？比如一个支付系统需要与银行的系统进行交互（充值或者转出），由于银行不能提供支持，我们会开发程序去替代银行系统功能（这就是挡板程序，Mock程序），保证此功能的性能测试能够展开，这个过程就是设计测试模型。

在比如，后面要讲到的实例项目Jforun论坛，根据需求我们了解一般大家发帖或回帖前都会先登录，那么我们在开发脚本时就要把登录与回帖场景绑定一起进行测试，这就是测试模型。通俗点说就是，性能测试用例设计+性能测试实现方案，用例只关注业务，模型还需要关注如何实现，是否具有可操作性，可验证性等问题，最后我们还得根据不同的测试目的组合成不同的测试场景。

（5）计划编写：

计划测试工作，在文档中明确列出测试范围，人力投入，持续时间，工作内容，风险评估，风险应对策略等。

（6）脚本开发：

录制或者编写性能测试脚本（现在很多被测系统都是无法录制脚本的，我们需要手工开发脚本），开发测试挡板程序，开发测试程序等，有时候如果完全没有第三方工具可用，甚至需要开发测试程序或者工具。

（7）测试环境准备：

性能测试环境准备包括服务器与负载机两部分，服务器是被测系统的运行平台（包括硬件与软件，比如应用服务器需要8Core，32G内存，中间件是Jboss7等），负载机是我们用来产生负载的机器，用来安装负载工具，运行测试脚本。

（8）测试数据准备：

根据测试模型来准备被测系统的主数据与业务数据（主数据是保证业务员能够运行通畅的基础，比如菜单、用户等数据；业务数据是运行业务产生的数据，比如订单；订单出库需要库存数据，库存数据也是业务数据。我们知道数据量变会引起性能的变化，在测试的时候往往要准备一些存量/历史业务数据，这些数据需要考虑数量与分布）

（9）测试执行：

测试执行是性能测试成败的关键，同样脚本不同执行人员得出的结果可能差异较大，这些差异主要体现在场景设计与测试执行上。

（10）缺陷管理：

对性能测试过程中发现的缺陷进行管理。

（11）性能分析：

对性能测试过程中暴露出来的问题进行分析，找出原因。

（12）性能调优：

性能测试工程师与开发人员一起来解决性能问题

（13）测试报告：

测试工作的重要交付件，对测试结果进行报告，主要包括常见的性能指标说明（TPS，RT，CPU Using.....），发现的问题等。

性能测试主要交付件：

测试计划、测试脚本、测试程序、测试报告或者阶段性测试报告

（14）评审：

对性能测试报告中的内容进行评审，确认问题，评估上线风险，有些系统虽然测试结果不理想，但是基于成本以及时间的考虑也会在评审会一直通过从而上线。

 

三、性能测试相关术语

（1）负载：

模拟业务操作对服务器造成压力的过程，比如模拟100个用户进行发帖。

（2）性能测试：

模拟用户负载来测试系统在负载情况下，系统的响应时间，吞吐量等指标是否满足性能要求。

（3）负载测试：

在一定软硬件环境下，通过不但加大负载（不同虚拟用户数）来确定在满足性能指标情况下能够承受的最大的用户数。简单说，可以帮我们对系统进行定容定量，找出系统性能的拐点，给予生成环境的规划建议。这里的性能指标包括TPS（每秒事务数），RT（事务平均响应时间），CPU USing（CPU利用率），Mem Using（内存使用情况）等软硬件指标。从操作层面上来说，负载测试也是一种性能测试的手段，比如下面的配置测试就需要变换不同的负载来进行测试。

（4）配置测试：

为了合理的调配资源，提高系统运行效率，通过测试手段来获取、验证、调整配置信息的过程。通过这个过程我们可以收集到不同配置反映出来的不同性能，从而为设备选择、设备配置提供参考。

（5）压力/强度测试：

在一定软硬件环境下，通过高负载的手段来使服务器资源（强调服务器资源，硬件资源）处于极限状态，系统测试在极限状态下长时间运行是否稳定，确定是否稳定的指标包括TPS，RT，CPU Using，MEM Using等。

（6）稳定性测试：

在一定的软硬件环境下，长时间运行一定负载，确定系统在满足性能指标的前提下是否运行稳定。与上面的压力/强度测试区别在于负载不是强调在极限状态下（很多测试人员会持保守观念，在测试时验证极限状态下的稳定性），着重强调的是满足性能要求的情况下，系统的稳定性，比如想要时间是否稳定、TPS是否稳定。一般我们会在满足性能要求的负载情况下加大1.5到2倍的负载量进行测试。

（7）TPS：

每秒完成的事务数，通常是指每秒成功的事务数，性能测试中重要的综合性性能指标。一个事务是一个业务度量单位，有时一个事务会包括多个子操作，但为了方便统计，我们会把多个子操作作为一个事务。比如一笔电子支付操作，在后台系统中可能会经历会员系统，账务系统，支付系统，会计系统，银行网关等，但对于用户来说只想知道正比支付花费了多长时间。

（8）RT/ART：

响应时间/平均响应时间，是指一个事务花费多长时间完成（多长时间响应客户的请求），为了使这个响应时间更具代表性，会统计更多的响应时间然后取平均值，即得到了事务平均响应时间，为了方便大家通常会直接用RT来代替ART，ART与RT是代表同一个意思。

（9）PV：

每秒用户访问页面的次数。此参数用来分析平均每秒用多少用户访问页面。

（10）Vuser虚拟用户：

模拟真实业务逻辑的虚拟用户，虚拟用户模拟的操作步骤都被记录在虚拟用户的脚本里，Vuser脚本用于描述Vuser在场景中执行的操作。

（11）Concurrency并发：

并发分为狭义和广义之分，狭义的并发，即所有的用户在同一时刻做同一件事情或操作，这种操作一般针对同一类型的业务，或者所有用户进行完全一样的操作，目的是测试数据库和程序对并发操作的处理。广义的并发，即多个用户对系统发出了请求或进行了操作，但是这些请求或操作可以是不同的。对整个系统而言，仍然有很多用户同时进行操作。狭义并发强调对系统的请求操作是完全相同的，多适用于性能测试，负载测试，压力测试，稳定性测试场景；广义并发不限制对系统的请求操作，多适用于混合场景、稳定性测试场景。

（12）场景：

性能测试过程中为了模拟真实用户的业务处理过程，在LoadRunner中构建的基于事务，脚本，虚拟用户，运行设置，运行计划，监控，分析等一系列动作的集合，称之为性能测试场景。场景中包含了待执行脚本、脚本组、并发用户数、负载生成器、测试目标、测试执行的配置条件等。

（13）思考时间：

模拟正式用户在实际操作的停顿间隔时间，从业务的角度来讲，思考时间指的是用户在进行操作时，每个请求之间的间隔时间。在测试脚本中，思考时间体现为脚本中两个请求语句之间的间隔时间

（14）标准差

该标准差根据数理统计的概念得来，标准差越小，说明波动越小，系统越稳定，反之，标准差越大，说明波动越大，系统越不稳定。包括响应时间标准差，TPS标准差，Runing Vuser标准差，Load标准差，CPU资源利用率标准差，Web Resources标准差等。举例响应时间标准差。