性能测试爬坑之路22--性能测试方案设计

按照标准的测试流程

测试方案首先是要做出来的，有了方案以后，方案有了开发脚本，脚本以后再来执行场景，场景执行之后对结果进行分析，最终形成系统性能测试报告，

设计方案--》开发脚本--》执行场景--》结果分析--》测试报告

  设计方案后面讲解的原因：设计方案是要有一个整体的把控，无论是从技术层面还是从需求层面，都要有一个理解才能设计出方案，当我们把这些都搞明白了之后我们设计的方案才是可行的，后面所有的测试都是参考我们的测试方案，方案写的好不好直接决定了我们后面测试执行的时候是很顺畅还是很痛苦

    一个好的性能测试方案到底从哪里入手，到底应该怎么表述？这是我们重点关注的

    这节课给大家一个实际的展示，专门给大家准备的性能测试方案，包括性能测试报告，大家可以来看一看制定一个性能测试方案重点关注哪些层面的东西，其实性能测试方案有点类似我们的测试用例，只不过他除了涵盖测试用例的东西还涵盖了其他层面的东西，但是他们所处的地位和价值是差不多的，都是作为后面我们执行测试的重点参考的依据

   我们打开之前做好的性能测试方案跟大家梳理梳理，我们的性能测试方案到底做的是什么事情呢？

  《Discuz VS Phpwind 性能巅峰对决》测试方案

    所以这个方案的核心是对比两个系统的性能，那要达到两个系统可比，有一个前提就是处理系统本身不一样之外，其他所有的硬件环境，软件环境，都应该是一样的，这样才有可比性，这就是大方向的测试目标，我们首先要搞明白，对一个测试方案来说很重要的就是要明确测试目标，比如说做一个压力测试方案的话，我们测试目标就是：系统在高压情况下，系统的表现怎么样，一定要明确，不能说你做一个压力测试的方案你的测试方案是要评估一下他的性能指标好不好，这很明显目标本身就错了，所以目标先明确了我们后面所有的一切都围绕着这个目标展开

    我们看一看我们的这个样例方案到底包含了那几个步骤

    1.测试目标

    2.测试过程

    3.测试对象

    4.测试平台

    5.被测模块

    6.性能测试的脚本开发的方案

    7.性能测试场景设计的方案

    8.重要分析指标

    9.其他考虑

 基本上一个框架结构就是这样，我们以后真正自己要去自己设计这些方案的时候，可以根据自己的需要（测试目的的不一样）以及系统本身的特点，可以对这些方案有所调整，但是这是基本的框架，这些基本的内容基本都滴有

------------------------ 测试方案正文---------start-----

  《Discuz VS Phpwind 性能巅峰对决》测试方案

1.测试目标

    1.对比目前两个认为最高的论坛程序 Discuz 和 Phpwind 的性能，从性能角度对工具进行评估和选型提供一些数据上的支持

    2.位初学性能测试 和 LoadRunner 的朋友在如何制定测试方案，开发测试脚本和分析测试结果方面提供一些参考

2.测试过程

    a) 测试计划：暂时不适用于本文档（计划哪些人参与这次性能测试，需要哪些网络资源，需要哪些硬件资源，需要哪些团队的配合，我们什么时间做什么模块的测试，等等所有的这些计划都是要包含的，跟我们去做一个项目的测试计划是一样的，我们要计划一个项目，或者一个研发项目，或者一个产品，都是一样的道理，计划的都是人力资源，我们的成本预算我们的时间，等等，我们就是做这些方面的计划）

    b) 测试方案：

        i . 用于制定测试策略，理清测试思路，为测试实践和测试提供技术上的参考

        ii. 确认测试对象，测试场景和目标，避免在测试执行是临时抱佛脚

    c) 测试实施：

        i.搭建 XAMPP 服务器平台

        ii. 安装 Discuz  和 Phpwind 论坛程序

        iii. 开发 LoadRunner 测试脚本

    d) 测试执行：

         i. 根据方案中制定的场景策略运行场景，并监控相关指标

         ii.  根据相关指标进行分析，确认两者的性能，达成本次测试的目的

3. 测试对象

    a) Discuz 7.0.0 for PHP 版

        i. 现有帖子数：30377 ，现有回复数： 15049   数据库大小： 22.1 M

    b) Phpwind 7.3.2 

        i. 现有帖子数：31064 ，现有回复数： 15796   数据库大小： 26.7 M

（这个测试对象我们还可以继续详细到我们要测试系统的哪一个功能模块，甚至我们还可以在方案里面解释，为什么要测这个功能模块，他的原因在哪里，这就是我们方案里面需要详细考虑到的东西，其实做方案的过程我们就对性能测试有一个全局性的掌控了，我们都很清楚我们接下来做什么，后边的事情反而就变得简单了，所以方案做的好，后边做起来就会很顺畅，方案如果是稀里糊涂的或者压根就没有方案，后面我们就是一团乱，这是测试对象，因为这里是一个样例，所以这里写得没有特别的复杂，我们真正的性能测试希望大家写的更详细一点，测试什么版本，然后测试什么模块，为什么测试这个模块，我们还要考虑我们的测试手段，我们是知识测试负载测试还是知识压力测试，这些都有相应的方案来控制，比方说我们压力测试，压力测试测试什么模块，压力测试并发多少用户，这些东西在方案里面都应该体现）

4. 测试平台

    a) 软件：W新动物XP SP3 XAMPP 1.6.8 (Apache 2.2.9 + MySQL 5.0.67 + PHP   5.2.6)

    b) 硬件: CPU : P8400 2.26 GHz , MEM 3 GB  ,网卡： 千兆网卡

    c) 客户端：由于机器限制，本次测试的客户端与 服务器位于同一台电脑，由于只是对比测试，未牵涉到性能调优，所有硬件平台对于二者的结果判定是公平的

    d) 测试工具： LoadRunner 9.5 英文版

（就是我们的软硬件环境，这个是什么样的平台，用什么样的平台我们就把他确定下来）

5. 被测模块

    a) 论坛登录

    b) 论坛发帖

    c) 帖子回复

（测试这几个模块的原因我也没有去阐述，原因很简单，对于论坛来说，这几个模块使用户经常使用到的，那么对于我们自己的系统来说，最好在方案里面写明白为什么，因为这样做不但让我们性能测试的人员理解为什么做这个事情，而且让整个团队甚至客户都能够知道原因是什么，这样我相信我们后面的测试才能够得到更好的支持，因为毕竟我们在企业里面不是一个人再做一个事情，比方说，举个最简单的例子，咱们做性能测试，咱们就是一个性能测试工程师，我把这些事情搞定就行了，但是，性能测试发现问题了之后我们是不是应该找人调整优化？如果说硬件不行，我们是不是应该申请硬件，如果是算法不行，我们是不是应该请程序员把算法改进改进？其实是需要一个团队来配合的，如果说数据库发现很慢，我们是不是要找数据库管理员进行数据库参数的调整？甚至是 sql 语句的监控和分析，我们甚至可以更细化，不但要细化到模块甚至要细化到 sql 语句，甚至细化到代码层面，所以需要很多研发团队整个一个配合，所以我们把这些写的尽可能的详细一点，越详细越好，越详细证明我们对方案的考虑越充分，然后后面执行的过程中遇到的风险就越小）

6. 性能测试脚本开发方案：

    a) 总体方案：

        i.  手工定义事务，事务状态由 LR 自动判断，不使用 web_reg_find 进行手工检查（经预测试发现几个功能的出错率很小，所以不考虑脚本本身的健壮性，是脚本简单化）

       ii. 只关注三个 POST 请求（使用 web_submit_data 函数提交 POST 请求），为减少测试结果的干扰因素，不考虑打开某个页面的性能，（使用 web_url 函数提交的 get 请求），不模拟真实用户需要打开首页，打开登录页面才能登录，或者必须进入某个模块才能发帖等真实操作

      iii. 不使用集合点策略

      iv. 为避免两个系统在运行性能测试时的干扰因素，要确保两个测试脚本完全一致，需要实现如下要求：

            1. 相同的参数设置

            2. 相同的事务定义

            3. 相同的关联

            4. 相同的思考时间设置

            5. 相同的场景设计

            6. 每执行完一次测试，都重启一下 XAMPP 服务器，清理服务器环境

     b）论坛登录模块：

          i. 预先注册 50 个用户（密码相同），使用 For 循环来产生一个 1-50 的序列，注册后用户名为  lruser1 、 lruser2 、lruser3 ........lruser50

           ii. 从 lruser1 ......lruser50 中每次迭代随机去一个用户名（产生一个 1-50 的随机数并与 lruser 字符串拼在一起杰克用作登录用户名）

           iii. 直接发送 post 请求到服务器登录处理页面，不用先打开首页面和登录页面

    c) 论坛发帖模块

         i. 需要使用关联来解决客户端验证问题

         ii. 由于 Phpwind 使用 UTF-8 编码，而 Discuz 使用 GBK 编码，为降低影响因素，统一使用英语作为帖子的标题和内容（如果使用中文，在 Phpwind 上则需要使用 lr_convert_string_encoding 函数 来东台转换中文内容，增加了一个潜在的影响因素，所以不使用中文）

         iii. 不考虑对多个某块进行发帖，专门新建一个模块来进行发帖测试

         iv. 帖子标题和内容使用一个唯一数加上一段固定的英文的方式来产生不同的标题和内容

     d)帖子回复模块

         i. 直接使用发帖操作中关联出来的客户端验证码

         ii. 标题和内容与发帖相同

         iii. 从本版块随机抽取 100 个帖子作为回复的对象（100 个被回复的帖子的 ID 号通过创建 Random Number 类型参数并制定具体范围来实现）

7. 性能测试场景设计方案：

    a). 由于客户端和服务器端位于同一台电脑，经过测试发现CPU 很容易到达 100 % ，所以本次测试准备测试 50 -100 个虚拟用户两种负载

    b). 同时，也由于 CPU 使用率偏高的问题，我们所有的测试步骤都设置思考时间，统一设置思考时间为 2 秒，一次来降低CPU 的负载，并且将思考时间置于事务外，这样响应时间中将不包含思考时间（如将思考时间置于事务内也可以，那么记得在 Analysis 中将思考时间扣除）

    c). 使用 Ramp up  和 Ramp Down 策略，用于分析随着虚拟用户的增加两个系统在响应时间上的变化情况

    d) 对于 50 个虚拟用户，Ramp Up 设置为每 30 秒增加 5 个用户，Ramp Down 设置为每 30 秒减少 5 个用户

    e) 对于 100 虚拟用户，  Ramp Up 设置为每 30 秒增加 10 个用户，Ramp Down 设置为每 30 秒减少 10 个用户

    f) Ramp Up 完成后持续时间为 5 分钟，这样总体运行时间约为 15 分钟

8. 重要分析指标：

    a) 监控 CPU ： % Processor Time 和 Processor Queue Length 两个指标

    b) 监控内存：总体内存可用数

    c) web 页面的 HPS (Hits Per Second  - 每秒点击数，即每秒请求数)

    d) web 页面的 吞吐量（Throughout）

    e) 登录，发帖 和回复的 RT （Response Time --  平均响应时间 和 90 percent 的相应时间）

    f) 登录，发帖  和 回复 的 TPS （Transaction Per Second -- 每秒事务数）

    g) 帖子数和回复数： 相同场景下比较二者发送成功的帖子数量和回复数量，量多者胜

9. 其他考虑：

    a)  Discuz  和  Phpwind  自身都带了一些针对不同用户数量的优化参数共使用，对比测试时不使用任何优化设置，保持默认的设置即可

    b) Discuz  和  Phpwind  对发帖时间间隔有限制，请取消该限制，确保发帖没有时间间隔

    c) 使用机器名 或 真是的 IP  地址访问服务器而非 127.0.0.1 或 localhost

    d) 为避免

    

------------------------ 测试方案正文---------end-----

这是一个相对简介的性能测试方案，真实的性能测试方案会相对，内容会更加的多，会更加的详尽，

这里有另一个性能测试报告，我们简单的过一过，《新疆移动 ngboss1.0 性能测试方案》v 3.0，先看一看方案的一个目录：测试目的、测试范围（测试对象、需要测试的特性、不需要测试的特性）、测试准则、测试的方法、测试的输出、测试的任务、测试的环境、测试的风险分析、需要提供的资源，做性能测试有一个困境，不知道到底并发多少虚拟用户，是合理的，这是我们很难知道的，因为我们很难清楚的知道用户的行为到底是什么样子的，所以很多企业，很多性能测试人员，他考虑的是我能不能支撑这么多的用户，这么多的用户到底合不合理，而这种问题很难有明确的答案，所以针对这种性能测试需求，我们不要从并发多少虚拟用户的角度来考虑，网上能够找到关于并发用户的计算方法，他会告诉你一个很绕的公式，我想告诉大家的是，这个公式是错误的，无任何参考价值，

      解决方法：在 controller 这边我们就没有办法确认并发用户数是合适的，怎么办？第一个从业务的 tps 来看，假设每小时处理 10 万笔，那么 tps 就是 10 万笔/ 3600s  得到的就是每秒钟这个系统处理多少个业务，这就可以了，那么并发用户数是多少无所谓了，你并发个 1000 、2000、10000、20000 都没有关系，目的是这个系统能每秒钟处理到 10 万/3600就认为这个系统是合格的了，并发用户数是多少都没有关系，那么这个是第一个步骤，这是业务需求，业务需求一定是在评估的基础上做一些适当的增加，第二步，在 梯度递增，做一个预测试，我们把虚拟用户设置为 1000 个，让并发用户相对多一点，让她慢慢增加，在 ramp up  的过程中我们就可以监控一些性能测试指标，看一看在什么样的数量情况下用户达到了最佳的状态，在这种用户数量下，在看能不能达到我的业务处理目标，如果能达到证明这个系统是靠谱的，这种业务是对于已经上线的业务我们能够获取到业务的数据了

     对于新上线的业务怎么办？新上线的系统什么数据都没有，我怎么来评估她的业务处理量，我怎么来确定虚拟用户数，我也明确的来告诉大家所有的评估都是基于没有根据的假设，或者是没有真凭实据的，这种情况下怎么办？这种情况下就只能通过动态的来做了，首先我们通过现有的系统环境来评估一下，到底这个系统能支撑多少用户，业务处理能力怎么样，响应时间怎么样，评估出来以后评估的结果是否满足需求我们真的不太清楚，因为没有正式上线，正式上线的时候我们也及时的做好监控，比如说通过评估我们得到最佳或者最大，他的系统瓶颈在哪里，她的最大处理能力是多少，得出这个结论，上线之后我们及时的去监控来看用户有没有达到这样一个量级，达到用户数的最佳状态。我们的系统的指标有没有达到一个比较高的水平，如果太高，我们有意识去注意了，这个系统可能马上就会撑不住了，该添加硬件添加硬件，该提升带宽提升带宽，该做其他的调整我们及时的去做调整，保证运营的过程不会有大的性能问题，对于权限系统我们是没有办法有一个很好的需求来告诉这个性能是合理还是不合理，很难所有得出的结论其实都是没有根据的，还有一种是，我们在内部做性能测试把她的目标设置成，对于新上的系统，不是看他合不合格，而是看看有没有优化的地方，有没有需要祢补的地方，一些有漏洞的地方，有缺陷的地方，有瓶颈的地方，咱们尽可能在研发环境把能够优化的优化了，把参数该调整的调整，代码该优化的优化，数据库的结构该优化的优化，这个优化是优化前和优化后，保持相同的环境，部署上前后版本，看看他们性能有没有提高就可以了，我们在研发阶段做性能测试针对一个全新的系统主要是做这方面的事情，然后这些系统上线了以后我们也及时的做好监控，及时的尽早的预防这些风险，这样就可以了，没有必要纠结，