第一章 软件性能测试基本概念和流程
1.1 软件性能的定义
通常来说，性能首先是一种指标，表明软件系统或构件对其即时性要求的符合程度；其次是软件产品的的一种特性，可以用时间来进行衡量。性能的及时性用响应时间或吞吐量来衡量。响应时间是对请求做出的响应所需要的时间。
通常，对软件的关注是多个层面的。如果按使用者划分为：用户、管理员和产品的开发人员。于此还有一个重要的是Web的前端性能。
从用户的角度来说，软件性能就是软件对用户操作的响应时间。
从管理员的角度来看，软件系统的性能首先表现在系统的响应时间上，其次管理员还想要知道系统具有多大的可扩展性、处理并发的能力如何、系统可能的最大容量是什么、系统可能的性能瓶颈在哪里、通过更换设备或进行哪些扩展能够提高系统性能、系统在长时间的运行中是否足够稳定、是否能够不间断地提供业务服务等。管理员关注的部分性能如表1-1所示：
表1-1管理员关注的部分性能相关问题
从开发人员的角度来说，主要关心用户感受----响应时间；其次，系统的扩展性等管理员关系的内容。图表1-2开发人员关注的部分性能问题:
表1-2开发人员关注的部分性能问题
Web前端性能考察的主要是浏览器的展现和脚本执行时间，通常对前端性能的关注主要在浏览器展现页面的方式、浏览器各种执行机制的合理应用及脚本的合理性。如何提高浏览器下载和执行资源的并发性，如何让浏览器尽快渲染页面，如何让浏览器尽可能充分利用缓存等问题是前端性能关注的重点。
1.2 软件性能的几个主要术语
1.2.1 响应时间
响应时间是“对请求做出响应所需要的时间”，而且，通常把响应时间作为用户时间软件性能的主要体现。
1.2.2 并发用户数
在实际的性能测试过程中，测试人员一般比较关心业务并发用户数，也就是从业务的角度关注究竟应该设置多少并发用户数比较合理，因此性能测试中直接将业务并发用户数称为并发用户数。下面给出一些用于估算并发用户数的公式：
在公式（1）中，C是指平均的并发用户数；n是登录 session的数量；L是登录 session的平均时间长度；T指考察的时间段长度。例如，对一个典型的OA应用，考察的时间段长度应该为8h的工作时间。
在公式（2）则给出了并发用户数峰值的计算方式，其中，Ĉ指并发用户数的峰值；C是公式（1）中得到的平均并发用户数。
实例：假设一个OA系统，该系统有3000个用户，平均每天大约有400个用户要访问该系统，对一个典型用户来说，一只只在8h内使用该系统，且登录到退出该系统的平均时间为4h。根据公式（1）和公式（2）：可以得到:
C=400X4/8=200; Ĉ≈200+3X=242
1.2.3吞吐量
指单位时间内系统处理用户的请求数
从业务角度看，吞吐量可以用：请求数/秒、页面数/秒、人数/天或处理业务数/小时等单位来衡量；从网络角度看，吞吐量可以用：字节/秒来衡量；对于交互式应用来说，吞吐量指标反映的是服务器承受的压力，他能够说明系统的负载能力，以不同方式表达的吞吐量可以说明不同层次的问题，例如，以字节数/秒方式可以表示数要受网络基础设施、服务器架构、应用服务器制约等方面的瓶颈；已请求数/秒的方式表示主要是受应用服务器和应用代码的制约体现出的瓶颈。
当没有遇到性能瓶颈的时候，吞吐量与虚拟用户数之间存在一定的联系，可以采用以下公式计算：F=VU * R / T
其中F为吞吐量，VU表示虚拟用户个数，R表示每个虚拟用户发出的请求数，T表示性能测试所用的时间
1.2.3 性能计数器
是描述服务器或操作系统性能的一些数据指标，如使用内存数、进程时间，在性能测试中发挥着“监控和分析”的作用，尤其是在分析统统可扩展性、进行新能瓶颈定位时有着非常关键的作用。
资源利用率：指系统各种资源的使用情况，如cpu占用率为68%，内存占用率为55%，一般使用“资源实际使用/总的资源可用量”形成资源利用率。
1.2.4 思考时间
Think Time，从业务角度来看，这个时间指用户进行操作时每个请求之间的时间间隔，而在做新能测试时，为了模拟这样的时间间隔，引入了思考时间这个概念，来更加真实的模拟用户的操作。
在吞吐量这个公式中F=VU * R / T说明吞吐量F是VU数量、每个用户发出的请求数R和时间T的函数，而其中的R又可以用时间T和用户思考时间TS来计算：R = T / TS
下面给出一个计算思考时间的一般步骤：
A、首先计算出系统的并发用户数
C=nL / T F=R×C
B、统计出系统平均的吞吐量
F=VU * R / T R×C = VU * R / T
C、统计出平均每个用户发出的请求数量
R=u*C*T/VU
D、根据公式计算出思考时间
TS=T/R
1.3 性能测试的流程
该性能测试流程，以loadrunner性能测试设计与实现的。
1.3.1 性能测试需求分析
-
选定测试业务场景
根据用户需求中所描述的系统架构来分析，性能测试的重点表现在哪几个方面，如：并发访问的性能、数据交换的性能、批处理业务执行效率、系统处理的稳定性等，同时结合系统架构分析可能存在的性能瓶颈，这个也是选择测试业务场景的基础。
根据用户需求并结合实际，不要做到全部业务覆盖，但尽量做到对不同业务类型和操作类型的覆盖，操作类型的覆盖，如；对数据库的读操作（简单查询、复杂查询）、数据库的写操作（如：插入、删除和更新），选取一些典型的业务操作作为测试业务场景。
-
分析性能测试指标
1）根据用户需求和所选取的典型业务场景，首先选取性能指标项，如：并发用户数、交易响应时间、每秒交易数（TPS）、服务器资源占用率、网络吞吐量等；
2）在选取性能指标项后，根据用户需求或总体设计文档对性能指标进行分析，获得各个性能指标项值，如：用户需求中说明了某个业务使用的用户数为N，但没有说明并发用户数，可以按照10%N~20%N来谁都能够并发用户数；有的文档中会提到一年会处理多少业务量，那么可以按照28原则计算出每秒交易数（TPS）。
1.3.2准备工作
- 测试环境搭建
测试环境要尽量与系统运行的真实环境大致一致，也有一些要求：
1）测试环境时尽可能的模拟系统上线运行环境
搭建测试环境时应充分考虑用户的使用环境，尽可能模拟用户实际使用的软硬件环境，这对性能测试来讲尤为重要，如果生产环境和测试环境相差过大，则测试结果没有参考价值。要求被测系统的硬件配置应与生产部署一致，所安装的软件版本与预期测试的版本号一致。
2)营造独立的测试环境
被测系统在预期性能测试执行期间应保证其资源独占性，即测试过程中要确保我们的测试环境独立，避免测试环境被占用，影响测试进度及测试结果，比如设备连网后，如果其他开发组或测试组也在共用，这样就可能影响我们的测试结果。有时开发人员为确定问题会使用我们的测试环境，这样会打乱我们的测试活动，更严重的是影响测试进度。因此需要为本次测试搭建独立的测试环境。
3）构建可复用的测试环境
项目实际执行过程中，测试环境是经常变化，比如测试软件版本更新、测试人员流失等等，需要随时跟踪和改进，尽量将可控的资源进行分类整理。可控资源包括：测试环境配置手册、测试硬件信息、环境变更记录等等，目的是尽量将测试环境进行备份，方便出现未知问题时快速的还原。当刚搭建好测试环境，安装测试软件之前及测试过程中，对操作系统及测试环境进行备份是必要的，这样一来可以为我们下轮测试时直接恢复测试环境，避免重新搭建测试环境花费时间，二来在当测试环境遭到破坏时，可以恢复测试环境，避免测试数据丢失，重现问题。
- 测试数据准备
在实施性能测试时，需要运行系统相关业务，这时需要一些数据支持才可运行业务，这部分数据即为初始测试数据，数据准备和清理的工作量是非常大的，需要在测试前提前考虑。
为更加真实的模拟现实运行环境，我们在测试过程中，应尽可能准备与真实业务执行相一致的初始数据，如系统用户数据、业务数据、辅助数据等。
- 系统用户数据：登陆系统使用的帐户名-口令等，数量与虚拟用户数一致；
- 业务数据：每个虚拟用户模拟真实用户进行操作时使用到的数据；
-
辅助数据：为保证业务操作的正常进行而设置的基本信息资料。
此外，测试数据可分可重用和不可重用数据：
- 可重用数据：如客户信息等查询类的数据，此类数据只需一次准备即可；
- 不可重用数据：此类数据为一次性消耗数据，不可重用，一般应用在数据增加或修改类业务交易，此类数据如增加客户标识、帐户标识等。
- 测试环境配置
1）RPC服务。监控服务器资源利用率需要打开系统RPC服务，RPC打开步骤参考详见《监控配置文档》。
2）Agent process。该服务是loadrunner的服务，它的作用是实现控制多台机器同时进行并发，安装了loadrunner的每台机器都会有该服务，只要打开该服务，然后在loadrunner的控制台的Loadgenerator中加入打开该服务的机器的IP地址即可。
3）监控服务器资源利用率。在Loadrunnercontroller中加入所要监控服务器，选择监控的性能指标。
1.3.3设计并调试脚本
录制和调试脚本可以具体参见其他的资料，不过要注意静态关联和动态关联的问题。
1.3.4执行脚本
将所录制和调试好的加入到Loadrunner controller控制台中，设置好测试场景，如：并发用户数、调度和运行模式（真实运行模式还是经典模式、虚拟用户加载方式、运行周期）等。