全国咨询热线：136-9172-9932
很多朋友错误的认为性能测试只需要学好性能测试工具LoadRunner即可，但实际测试过程中性能测试工具LoadRunner只是将性能测试策略转化为可执行的脚本并产生压力，但在进行性能测试前还需要确定性能测试策略，这个过程很重要，即性能测试设计和性能测试构建，只有正确的性能设计能可以保证性能测试的正确性，否则测试出来的数据不一定正确，所以有必要对性能测试的整个过程有一个详细的理解，性能测试的过程主要包括四个阶段：性能测试设计、性能测试构建、性能测试执行和性能测试分析、诊断、调节。本章节给大家介绍性能测试设计。
性能测试设计：
设计阶段是性能测试团队与业务领域的经理合作以收集性能要求的主要业务响应时间。可以将需要关注的问题分为四个方面：业务需求、技术需求、系统要求和团队要求，分析时主要从五个方面分析：需求调研、业务模型、场景模型、数据设计和环境设计，其中业务模型是该阶段工作中最重要的一项工作。
一：需求调研
需求调研主要是确定本次性能测试活动需要测试的对象以及被被测试对象的一些属性，在需求调研过程中需要完成以下几部分工作：
1、测试系统预研;
与项目经理访谈;
与业务专家访谈;
与技术专家访谈;
与数据库管理员访谈
与客户代表访谈;
2、测试系统预研
根据被测试系统的资料，尽可能多的了解被测试系统相关知识，通常包括系统建议目的、系统的技术架构、系统的业务架构等。在该阶段主要完成的工作内容如下：
确定被测试系统的开发组织和组织负责人;
向项目经理申请被测试系统相关资料;
一些其它的例外情况沟通;
3、与项目经理访谈
与项目经理访谈主要是需要获取性能测试实施工作开展的相关信息、当前开发状态和期望的性能目标，包括性能测试实施起止时间和被测试系统所处的生命周期。
4、与业务专家访谈
与业务专家访谈主要是为获取性能测试业务模型设计的相关数据，如被测试系统的关键业务、主要用户场景、用户交易发生概率、期望响应时间等业务层面信息，除此之外还需要从业务团队中获得相关的业务工程师来支持后续脚本的开发，以避免脚本开发失败或出现错误。
那么什么样的业务才是关键业务呢?分析关键业务主要考虑三个方面：该业务使用频率、业务的优先级和业务占用资源情况。
业务使用频率：是指客户操作该业务的频率，操作频率越大说明失效的概率越大。
业务的优先级：业务的优先级是指业务的等级，优先级越高说明客户操作该业务的概率越大，一般的从业务的角度来说，核心业务和基本业务的优先级比较高，所以性能测试时需要关注这两类业务。
业务占用资源情况：操作一次该业务对系统资源消耗的情况，如果业务对系统资源消耗高的，那么可能让系统处于高负荷的运行状态，这样业务失效的风险就变大了。
所以综上，关键业务是那些使用频率高、优先级高和消耗资源高的业务，这也是性能测试过程中需要重点关注的业务。
5、与技术专家访谈
与技术专家访谈需要确定以下内容：
获取关键业务的技术路径，完善被测试系统的关键业务和用户场景;
从技术经理处获取合适的技术支持工程师;
请技术经理确定关键业务是否覆盖到被测试系统的所有业务请求点;
确定这些业务所使用到的关键数据库表;
监控阶段，技术支持人员配合实施监控配置工作;
一些特殊技术的支持，如加密、压缩等;
6、与数据库管理员访谈
与数据库管理员访谈主要需要获取数据准备和测试数据建模的建议，主要包括以下几个方面的内容：
DBA辅助进行数据库的备份与恢复工作;
为数据建模提供建议;
为建基础数据模型做准备;
7、与用户代表访谈
与用户代表访谈主要是需要获取用户在业务建模上的支持，保证业务流程的正确性。
二：业务模型
业务模型主要是用于指导如何将具体的业务变成可重复运行的代码，主要从三个方面分析：业务流程列表、交易列表、百分比模型和交易量评估。
业务流程列表：创建关键业务流程列表，以反映最终用户在系统上执行的活动，见表13-1。业务流程表需要反映每个业务在高峰期时操作的用户数，这些问题主要是通常后台的历史数据来获取，获取这些历史数据的目的是做为新一轮测试的参考数据。
表13-1 任务分布表
交易列表：交易业务流程需要确定关键业务(如“登录”或“转移资金”等)的负载情况、交易量等相关信息，见表13-2。
表13-2 交易列表
通交易列表可以确定确定业务的优先级，这样在性能测试过程中可以确定哪些业务是需要优先测试的。如上例登录、更新订单、发货是优先级最高的业务。
如何获得这些指标是很重要的：
日常业务：可以通过后台数据来统计，可以分析三个月、半年或一年的数据，得到这些业务每小时或每秒钟操作的笔数。
高峰期业务：选择峰值情况下，单位时间内业务操作的笔数。
Web服务器和数据库服务器负载情况，这个测试很难得到，需要与开发工程师进行沟通，确定每个业务对Web服务器和数据库服务器负载的情况。
风险：是指当该业务失效或发生错误时，对客户的影响。
百分比模型：是指被测试的业务交易的笔数所占整个业务交易笔数的百分比，见表13-3。
表13-3 百分比模型
表13-3描述的是银行业务的百分比，但只是摘取了部分业务，在业务中可以看到一些业务名称一样但业务编号不一致，这是因为操作的方式不同，如查询，同样是查询有的是在柜台机上查询，有的是在ATM自动取款机上查询，所以都统称为查询，但业务的编号不同。
如果在场景设计过程中使用的是百分比模型那么在场景设计之前就必须先确定待测试业务的百分经模式，否则无法确定每个业务所占的百分比。每个业务操作的笔数主要是通过后台日志文件来获取，如果该系统是第一次测试那么可以参考其公司类似的系统，或者试上线运行一段时间，这样可以得到一个粗略的百分比模型。
交易量评估：通常历史数据来估算系统负载能力，通常使用的方法为80～20原理。
80～20原理是指每个工作日中80%的业务在20%的时间内完成。每年业务量集中在8个月，每个月集中在20个工作日中完成，每个工作日8小时，每天80%的业务在1.6小时完成。
实例：如去年全年处理业务约100万笔，其中15%的业务处理中每笔业务需对应用服务器提交7次请求;其中70%的业务处理中每笔业务需对应用服务器提交5次请求;其余15%的业务处理中每笔业务需对应用服务器提交3次请求。根据以往统计结果，每年的业务增量为15%，考虑到今后3年业务发展的需要，测试需按现有业务量的两倍进行。
每年总的请求数为：
(100x15%×7+100×70%x5+100×15%×3) ×2=1000万次/年
每天请求数为：1000/160=6.25万次/天
每秒请求数为：(62500×80%)/(8x20%×3600)=8.68次/秒
即服务器处理请求的能力应达到约9次/秒，如果需要满足3年后的业务增长，那么服务器处理请求的能力应达到约18次/秒。
三：场景模型
场景模型主要是用于指导在控制器中如何进行场景设计和场景监控。故关于场景模型包括两部分内容：场景设计和场景监控两部分。
场景设计需要确定的内容主要包括：使用的场景设计类型(手动场景或目标场景)、并发用户数、虚拟用户加载过程、脚本持续运行时间、虚拟用释放过程、使用的负载机、IP欺骗技术和RTS的设置。
关于使用的场景设计类型(手动场景或目标场景)、并发用户数、虚拟用户加载过程、脚本持续运行时间、虚拟用释放过程、使用的负载机、IP欺骗技术的设计见表13-4所示。
表13-4 场景设计
在场景设计完成后，一定需要记住还需要设置RTS的策略，关于RTS策略设置主要包括：迭代数、迭代时间间隔、日志收集方式、脚本运行的方式(进程或线程)，见表13-5。
表13-5 RTS设置
场景设计模型确定后还需要确定场景监控模型，场景监控包括：监控对象、服务器和相关计数器，见表13-6。
表13-6 监控模型
四：数据设计
数据设计主要是确定在整个性能测试过程中需要使用的数据，关于这部分的数据有两个方面的含义：一是性能测试前需要准备的基础数据;二是性能测试过程中参数化需要使用到的数据;
关于基础数据是指测试前数据库应该准备好的数据，准备数据的不同直接影响到性能测试的结果，例如，查询功能，数据库中已存在100条记录和已存在100万条记录，查询的响应时间肯定是不同的，所以在测试前一定要确定数据的所拥有的基础数据。
基础数据设计见表13-7。
表13-7 基础数据设计模型
参数化的过程中需要使用的数据来源也分有两种：一是自己构建的数据;二是历史数据;构建数据是测试过程中通过一些方法生成批量数据，制作数据的方法通常包括：Ultraedit结合Excel制作数据、数据库、Shell编程和Java编程等。
历史数据则是真实存在的数据，是调用客户的真实数据，一般历史数据都存储在数据库中，所以在使用真实数据时，需要确定相关的查询语句，否则在脚本开发过程中就无法从数据库中获取历史数据。
数据设计见表13-8。
表13-8 数据设计模型
不管是自己构建数据还是使用历史数据，获得的数据都应该遵守以下原则：
1) 全面性
全面性是指设计的数据应该包含所有类型的数据，需要覆盖客户操作过程中所有类型的数据，如测试移动BOSS系统中的计费功能，那么在测试过程中参数化的数据就不能仅仅使用某个网段的手机号(如135段的手机号)，使用的数据应该包含所有网段的手机号(如135、136、138等)。
2) 无约束性
无约束性是指数据与数据之不能存在相互约束的现象，如测试银行系统的存取款业务，如果一张银行卡正在存款，这样就必定不能同进进行取款操作，如果设计的数据恰好同时进行存取款操作，那么取款就一定需要等待存款结束后才可以进行，这样取款的响应时间就包括了存款的时间，而这个响应时间显然不是真实的取款时间。
3) 正确性
正确性是指设计的数据应该保证业务能被正确的运行，因为性能测试的目的是测试业务的响应时间，而非测试功能(有一些朋友容易将性能误解为验证功能测试)测试，所以设计数据时，不能因为人为的原因导致业务操作失败，如果是由于数据导致业务失败，那么在结果分析过程中分析事务的成功率时就不准确，导致影响性能测试的结果。如测试移动BOSS系统计费功能，如设计一个已注销的手机号进行计费结算，这样必然导致业务失败，而这个业务失败是人为原因引起的，不是系统性能测试导致的。
4) 数据量充足
准备的数据是否充足也会影响到性能测试结果，在一些业务场景中，如果准备的数据不够多，即准备的数据比脚本迭代的次数少，那么当数据不够用时，将会重新循环或一直使用最后一个数据，这样很容易导致一些业务失败，如注册功能，假设共准备了100条数据，但迭代了150次，那么第100到第150次迭代即没有数据可用，必须重新循环一次或一直使用最后一条数据，而同一个数据不可能注册多次，这样导致第100到第150次注册业务失败。
5) 无敏感数据
软件的安全性是软件特性中一个很重要的维度，在设计数据进行性能测试时，需要注册避免一些敏感数据，即使使用敏感数据也应该是密文显示而非明文显示。
五：环境设计
环境设计主要是确定性能测试执行过程中服务器和测试机所处的环境，关于环境设计包括三部分内容：系统运行的拓扑结构图、服务器和测试机环境、环境的备份与恢复。
系统运行拓扑结构图主要用于指导如何搭建测试环境，如图13-2所示的实例图。
图13-2 系统运行拓扑结构图
服务器和测试机环境包括两部分内容：一是服务器和测试机的硬件配置;二是服务器和测试机的软件配置;服务器的硬件配置是一个基准环境，而负载机的硬件测试配置则受每个虚拟用户运行时所消耗的内存资源的影响，服务器和测试机环境配置见表13-9。
环境备份和恢复是必须要注意的，在执行性能测试之前为了避免出现错误需要先将环境进行备份，当执行完成后需要恢复测试前的环境，之所以需要这样做主要有以下原因：
第一：测试前如果环境不确定那么可能导致一些数据运行失败，进而导致一些业务运行失败;
第二：如果不即时恢复环境，可以会影响到手工测试的数据;
具体如何备份与恢复可以与数据库管理员一起确定。
表13-9 服务器和测试机环境
本章的内容就和大家分享到这里啦，如果喜欢的话记得每天来这里和小编一起学习涨薪技能哦。（笔芯）
下一章学习内容预告：性能测试过程中的性能测试构建
川石学院零基础入门到精通课程免费学习即扫下方二维码，名师在线辅导!
