Hi, 如果有任何想法与我沟通， 请用: lifr_nj 在 msn.com

发布新日志

  • JMeter插件开发

    2013-06-12 12:26:09

    前言：JMeter，不仅仅是性能测试

     

    JMeter是用Java开发的开源性能测试工具。其官网在此， jmeter.apache.org。 经过多年的发展， JMeter已经成为支持较多协议， 功能比较完善的性能测试工具。当然和主流的商业性能测试工具比较， 它的功能和使用界面都略显粗糙， 但因为其开源且免费的特性， JMeter在性能测试领已经是相当流行的工具， 特别是对于中小型的项目， 它完全能够胜任的。

    JMeter最大的优点之一是其开放的插件(Plugin)体系。 它允许你针对非常见的， 或者非标准的协议开发性能测试模拟器，而通用的封闭的商业性能测试工具对此是无能为力的（除非购买针对性的商业工具）。比如有一个Client-Server项目， 前端是Java Swing开发的， 通讯协议类似于RPC， 基于HTTP协议， 但是传输数据是序列化后的Java对象，是二进制的。我使用了XStream+Java Sampler, 甚至不用写一行GUI代码， 就在JMeter上实现了模拟器。 

    JMeter另外一个优点是它具有比较完善的TestCase的管理功能，测试运行的管理功能， 测试报告的生成功能。 这就使得JMeter不但是一个性能测试工具， 而且还能成为一个自动化测试 工具的开发平台。曾经有一个失败的自动化项目，该项目测试的产品是C-S架构，客户端 通过XML-RPC调用服务器端的服务。因为当时不了解JMeter， 所以我用了JUnit来作为测试框架，ant作为测试执行管理。 这种设计在功能上没有问题， 但是使用起来却是问题， 因为它需要code， 需要配置xml文件， 这一点即使对于普通的QA工程师来说学习曲线也比较陡峭, 所以项目最终没能成功。 如果是现在， 我肯定会使用JMeter， 用户通过GUI就能完成所有testcase设计，执行工作。 

    所以， 我觉得，至少在目前， JMeter是一个非常值得学习的工具平台。 特别你测试的产品是CS架构，而且能够基于协议来测试功能，JMeter是首选的 性能测试/自动化测试 平台。

    请注意， 这些文章的内容更多是我的经验的总结， 而不是对JMeter插件开发的完整的介绍。 而且， 你需要一些Java经验，因为有很多地方都有JMeter源代码的片段。

    查看(3444) 评论(6) 收藏 分享 管理

  • 性能测试模型分析：总结

    2013-06-02 00:25:34

    从前面的描述，我们可以看到， 性能测试的参数， 输入场景， 关键性能指标都是和性能测试的目的密切相关。 比如， 为了验证是否满足一个重要客户的性能要求， 性能测试可以很复杂， 测试环境包括应用服务器Cluster， DB Cluster， 专用的存储服务器，测试耗时一个月； 为了验证是否在版本之间有性能下降， 性能测试也可以很简单， 所有软件都部署在同一个机器上， 且测试集成在DailyBuild里面。

     

    不同的性能测试目的决定了不同的性能测试方法。 好的性能测试不是求大求全， 而是用最小的成本， 满足测试的要求。

     

    下面是对性能测试目的的总结。

     

    性能参数

    输入场景

    目的

    执行成本

    执行者

    性能基准

    在一个给定的性能影响参数集合上，，

    运行一个给定的输入场景

    获得一个性能基准。 这个基准可以作为性能比较的基准， 或者参考的数值。

    中

    QA

    性能验证/性能规划

    通常是在一个贴近客户的软硬件平台上，

    运行贴近客户系统的输入场景

    验证客户系统能否满足客户的要求。

    高

    QA/Support

    性能调优

    通常对基础软件硬件无特别的要求。 对某个系统本身的参数，或者应用服务或者数据库参数进行变化。

    输入场景可以灵活变化， 根据调优的关注点不同。

    发现瓶颈， 优化性能

    低

    QA/Dev

     

    使用性能测试模型分析方法的性能测试流程如下。

     

    Task

    输出文档

    计划

    确定软件性能模型

    确定性能测试目的

    确定性能测试参数

    确定输入场景

    确定关键性能指标和选择性能计数器

    测试计划

    测试案例

    准备

    开发测试脚本

    部署测试环境

    脚本

    测试环境清单

    实施

    执行TestCase

    性能计数器原始数据

    报告

    分析测试结果

    制作测试报告

    测试报告


    ======================================================

    后记：

    真实世界的性能测试项目是复杂的。 这是我半年性能测试的体会， 其中最令人纠结的是如何能让性能测试让各方满意。 当性能测试项目刚开始的时候， 每个人都在提出自己的意见， 那时我入道尚浅， 所以分不清轻重缓急， 识别不出重点， 因为自己对性能测试理解不深， 所以工作中总是被外界牵引得团团转， 每天很忙的工作， 想让每一个人都满意， 结果却是大家都不满意。

    慢慢的， 在失败和挫折中吸取教训， 不断的梳理思路， 总结出来了这样的性能测试模型分析方法。 我希望能通过这样的分析方法在性能测试中能够抓住主线， 能够知道要做什么和不要做什么，能够设计出有效率的性能测试案例。

    因为自己的性能测试经验范围其实还是相当窄的， 所以文章的内容是相当粗糙； 而且这样的分析方法可能在其他的项目并不一定适用。无论怎样， 希望能对阅读过这些文字的你有所启发， 并欢迎任何指正和交流。  

     

     

     

     

    查看(925) 评论(0) 收藏 分享 管理

  • 性能测试模型分析：压力输入场景

    2013-06-02 00:23:54

     

    压力输入场景描述了系统输入压力的构成情况。 和性能参数类似， 压力输入场景也是多种多样的。 那么到底选用什么样的压力输入场景呢？

     

    对于大多数性能测试， 压力场景一般从客户真实环境获得， 然后经过合理的简化，应用在性能测试中。

     

    要注意， 压力输入场景并不是说越真实越好。 因为如果要构造非常真实环境的压力输入场景， 会需要更多的开发成本和执行成本。 合理的简化能够在不偏离测试目标的情况下，提高测试的效率。 我之所以提到这点是因为， 有时候，有来自客户或者高层的这方面的压力， 因为他们不太了解系统的原理和怀有对性能不良造成后果的恐惧。 作为性能测试工程师， 应该要深入理解系统， 甄别出有意义的压力输入场景。

     

    也有一些性能测试对压力输入的真实性要求不高， 比如对于获取性能Benchmark的测试，对于压力输入场景要求是简单和易于执行。 常见的对于CPU， Disk的Benchmark测试， 测试压力都是简单直接的， 并不是模拟真实使用场景。 但这不会影响这些Benchmark数值的可信度。

     

    因为压力输入的千差万别， 所以并没有统一的获取压力输入场景的方法。 对于一般的OLTP类型软来说， 在分析压力输入场景时， 要考虑下面一些方面。

     

    Description

    输入的量

    单位时间有多少request进入系统

    输入类型

    这里指Request的类型. 比如一个在线购物网站, 每一次交易涉及到3次查询, 或者5次查询, 会对性能造成影响.

    用户数目

    还是以在线购物为例, 10个用户10分钟产生100个交易, 和100个用户10分钟100个交易, 其Response Time可能会不一样.

    Think Time

    上一个Response和下一个Request之间的等待时间。

    高峰时段

    高峰时段的输入场景需要单独考虑

    查看(764) 评论(0) 收藏 分享 管理

  • 性能测试模型分析：性能参数(Performance Factor)

    2013-06-02 00:22:25

    性能参数是包括所有会对性能产生影响的因素.  比如软件参数设置， 硬件的能力， 输入的类型等等。 性能测试的结果只有在给定性能参数的条件下， 才有意义。
     
    在性能测试中， 性能参数类似于功能测试中的”输入组合“， 所以，设计时都会面对同一个问题， 不可能穷举的可能。 即使对于一个小的软件， 性能参数的组合也可能是一个非常庞大的数字。 这一点对于 企业应用软件产品 尤其是一个问题。 因为客户的部署环境是千差万别的。
     
    在性能测试分析中，
    1） 首先要识别出所有性能参数， 重要的和不重要的。 需要注意的是， 性能参数的重要性并不是绝对的， 而是取决于性能测试的目的。 比如对于验证客户环境的性能， 硬件配置是很重要的参数；对于性能调优为目的的测试， 硬件配置并不重要， 软件的参数设置时很重要的参数。
     
    2） 然后对性能参数打包。既然不能覆盖所有组合， 当然只能选择典型的组合来测试。
     
    分类

    影响性能参数是包括所有会对性能产生影响的因素. 这其实会包括非常多的因素. 他们可以分为下面一些类型.

     

    Factor

    Samples

    服务应用程序配置

     

    服务应用程序的一些参数配置会对性能造成影响.

    l  比如某种工作线程的数量,

    l  比对于流水线类型的性能模型. 一个Data配置了几个模块进行处理显然会影响Processing Time.

    l  比如后台运行的报表程序

     

    同步调用的第三方应用程序

     

    比如银行交易处理时, 会同步调用Core Banking System, 那么CBS的性能也会直接影响交易处理的Response Time)

     

    基础软件

     

    比如应用程序服务器, 操作系统, Database服务器

     

    硬件配置

     

    CPU, Memory, Storage

    百兆网络还是千兆网络.

     

    其他

    其他一些系统特定的因素.

    总之, 有非常多的因素会对系统的性能造成影响. 测试中不可能把每一个因素都涉及到, 更别说他们的组合了.  为了能进行有效的测试， 需要对性能参数打包。

    打包影响性能参数

    如何确定性能测试中的影响性能参数的具体的取值. 这是性能测试准备中最关键的步骤. 这就和功能测试设计testcase一样, 如何能设计出最有效率的testcase.

    这个时候, 需要把相关的因素打包, 这样在性能测试的时候就不用考虑每一个因素, 而是考虑有限的一些”因素的组合”.

    对”影响性能参数”打包的目的是, 在设计性能测试Case时, 不用处理如此庞大的因素所有组合, 而是挑选一些合理的预想定义好的组合.

    比如说, 对 基础软件, 硬件配置, 网络配置 进行打包, 归纳出三种组合: 小型系统, 中型系统, 大型系统.

     

    CPU/Mem/Storage

    OS/AppServer/DB

    Network

    小型系统

    2Cores/4G/7200RPM(SATA)

    Linux/JBoss/MySQL

    100M

    中型系统

    4Cores/8G/15000RPM(SAS)

    Windows2008/WAS/SQLServer

    1G

    大型系统

    4Node cluster, Each Node

    2Cores/4G/SAN

    Aix/WAS Cluster/Oracle

    APP-DB: 10G Ethernet

    Storage Network: 4G光纤

     

    对于输入类型和应用程序相关的配置, 参考典型用户的使用场景. 有下面的组合, 以一个监控系统为例

    使用场景

    监控

    命令

    监控为主型

    每个Device每天1000条数据

    每个Device每天接受2个命令

    发送命令为主型

    每个Device每天100条数据

    每个Device每天接受200条命令

    平衡型

    每个Device每天500条数据

    每个Device每天接受100条命令

    对于静态压力模型的性能因素, 例子如下

     

    Device

    Hierarchy Levels

    小型网络

    100

    		 查看(1024) 评论(0) 收藏 分享 管理

  • 性能测试模型分析：关键性能指标 和 性能计数器

    2013-06-02 00:17:49

    关键性能指标(Key Performance Indicator, KPI)

    关键性能指标是最能描述系统性能的一种数据。 关键性能指标的类型如下表所示。

    其中服务能力指标是最核心的指标。 也是用户最关心的指标。对于最常见的Web网站， 服务能力指标最常用的是“相应时间”和“吞吐量”

    分类

    举例

    服务能力指标*

     

    l  响应时间： 表示从发出request到收到response的时间

    l  吞吐量：表示单位时间系统处理的request的数量

    对于吞吐量，不仅仅限于单位时间Request的数量，比如对于一个文件服务器，单位时间读写的字节数也是“吞吐量

    资源利用率指标

     

    主要是CPU和Mem利用率

     

    稳定性指标

     

    长时间运行， 系统服务能力是否下降， 资源利用率是否非正常上升。

     

    可扩展性指标

     

    增加更高级的硬件(Scale up), 或者增加更多的节点(Scale out), 对于服务能力的提升程度。

     

    对于 流水线模型的软件， 其服务能力的获得相对OLTP模型的软件会比较困难。 对于Response Time， 需要收集信息入口和出口的时间；对于Throughput， 需要收集各个关键module的吞吐量。

    性能计数器  

    性能计数器是在性能测试执行时收集的数据。 关键性能指标其实就是从性能计数器中直接或者间接产生出来。 但是性能计数器不仅仅包括关键性能指标， 性能计数器的范围会宽广很多。

     

    从性能计数器的来说， 通常分为以下几类。

    l  压力模拟器的计数器

    单位时间比如Request的数量， 及其响应时间。

    l  被测试产品本身的计数器

    比如内部Queue的长度， 单位时间Queue的输入的量和消费的量。

    l  应用服务器和数据库的计数器

    参见相应文档。

    l  操作系统提供的计数器

    参见相应文档。

     

    性能计数器除了用来标示系统性能， 还可以用来分析性能瓶颈， 指导性能优化。比如说， 磁盘读写Queue的长度是衡量磁盘是否是瓶颈的关键信息。

     

    无论是OS还是商业性能测试软件， 都提供了海量的性能计数器。 通常来说性能计数器的问题是， 如何选择最有价值的性能计数器。这需要对被测试软件， Application服务器， DB服务器， 和操作系统有深入的了解。

    查看(1142) 评论(0) 收藏 分享 管理

  • 性能测试模型分析： 模型分类

    2013-06-02 00:16:24

    一提到性能模型， 可能大多数人马上就想到网站。 网站的性能模型属于“在线交易处理“模型（On-Line Transaction Processing Model），这是最常见的性能模型。

    此外我还总结出另外两种。 流水线模型(Pipe Line Model)和静态数据模型(Static Data Model)。

    不同的性能测试模型类型，其测试方法， 性能指标都会很不一样。 比如对于OLTP模型， Response Time是一个关键性能指标， 但对于 流水线模型， Response time就并不是一个关键性能指标。

    在开始性能测试项目的第一步就应该识别出其性能测试模型的类型。这样你的测试才可以有的放矢。

     
    在线交易处理型(OLTP)


    这是最常见的类型. 所有的Web网站都是这种类型. 银行, 股票等的交易系统也是这种类型. 这种类型的特点是客户发起一个Request, 然后等待Request被处理完成， 如下所示。 这种模型的特点是

    1）对于Client来说， Request是阻塞执行的， 也就是在发起下一个Request之前， 必须得到上一个Request的Response。

    2）信息的流动式封闭的， 也就是信息从Client发出， 回归于Client

     

                            +-------------+
                   request  | Server      |
           +-----+ +------->|             |
           |Client          |             |
           |     | response |             |
           +-----+<---------+             |
                            |             |
                            +-------------+

     


     

    流水线型(Pipe Line)


     

    流水线模型最常见的就是监控服务器. Agent采集数据然后发往服务器. 服务器在收到数据后, 马上告诉Agent数据已经收到. 但是这个时候该数据的处理才刚刚开始, 比如数据会被存到数据库, 数据可能会trigger一封Email, 等. 这种模型的特点是

    1）  对于Source端来说，　request的执行是异步的。也就是说无论上一次的Request是否已经完全处理，Source端都可以发起第二次request。

    2）  信息的流动式开放的。也就是信息的起点和终点不是同一个。

    3）  一般来说这种系统内部的信息处理模块有多个，而且模块间都是异步的, 通过Queue来串联. 就像流水线一样. 如果某一个模块处理能力慢了, 它的前端并不会受到直接影响.
                          +----------------+
                          |Server          |
            +-------+     | +---+ +--+ +--+|    +-------+
            |Source |+--->| |M1 | |M2| |M3||+-->|Target |
            |       |     | +---+ +--+ +--+|    |       |
            +-------+     |                |    +-------+
                          |                |
                          +----------------+

    现实生活, 快递物流系统就是典型的流水线模型的体现. 当你把物品交到快递公司的工作人员手里时, 你马上就能就能收到一张回执, 但是物品并没有到达目的地. 物品会先存放在本地仓库, 然后运输到目的地的仓库, 然后由目的地所在的快递人员吧物品派送到对方手中.


                      +----------------------------------+
                      |Express Company                   |
                      |                                  |
                      |                                  |
                      | +-------+                        |
          +---------+ | |Local  | +---------+            |
          |Customer||+->|Branch | |Warehource            |
          |         | | |       | +---------+            |
          +---------+ | +-------+                        |
                      |           +--------+             |
                      |           |Logistics             |
                      |           |Company |             |
                      |           |        |             |
                      |           +--------+             |
                      |                       +---------+|
                      |          +----------+ |Remote   || +------+
                      |          |Warehource| |Branch   +->|Target|
                      |          +----------+ |         || |      |
                      |                       +---------+| +------+
                      |                                  |
                      |                                  |
                      +----------------------------------+

     

    静态数据压力型(Static Data Load Model)

    静态数据压力型和前两种不一样. 它并没有一个所谓的输入端. 下面是两个例子

    l  在Console展现一个包含非常多元素的页面.

    l  提交一个非常耗时的产生Report的Request.

    这种类型的性能模型看上去并不像我们通常理解的性能模型, 它也不能被前面两种模型所覆盖. 所以单独定义为静态数据压力模型.

    值得指出的是, 这种压力模型往往被软件开发或者测试人员所忽略, 但是它却是客户非常关心的, 因为客户会去真正使用这些功能.

     

     

    查看(700) 评论(0) 收藏 分享 管理

  • 性能测试模型分析： 为什么需要性能测试模型

    2013-05-31 06:39:54

    前言：
    做了很长时间功能测试，自动化测试， 但性能测试一直都是蜻蜓点水的样子。 这半年终于， 能够对性能测试有了比较深入的了解，并积累了一些经验。 所以准备在这里记录下来。

    首先， 我想先指出的是， 我所测试的产品不是通常的网站， 而是 企业内部使用的监控类型的 软件产品。和网站相比， 其性能测试有自己的一些特点。

    总的来说， 性能测试的经验包括三个方面。
    • 性能测试模型分析方法
    • 性能测试工具开发(VBS)
    • Jmeter的应用和Plugin开发


    第一篇， 我想说说 “为什么需要对性能测试模型”

    ====================================================================

    模型的意义在于它化复杂为简单， 同时不丢失最关键的属性。 建立模型是为了帮助我们更好的理解一个复杂的事物。 那么问题是“性能测试很复杂吗?”, 接下来的问题是“如果说性能测试很复杂， 那么复杂性体现在什么地方?”

    性能测试复杂吗？ 一句很废话但是也是真话就是， 初看简单， 深入复杂。

    我认为性能测试的复杂性体现在三个地方。 第一个是性能参数， 第二个是输入场景， 第三个是性能测试的目的。

    性能测试的参数， 就是任何对系统性能有影响的参数。 比如不同硬件配置， 不同的应用服务器或者数据库服务器， 不同的系统的配置参数， 这些参数的变化都会影响最终系统的性能， 那么在搭建性能测试环境是， 到底如何对他们进行选择呢？选i5还是志强， 工作线程选5还是10？

    输入场景是对于性能测试时输入的描述。 比如对一个电子商务网站的性能测试， 每一次成功的购物应该包含几个request， 分别是什么类型？ 如果是大型打折活动， 用户的购物流程有什么变化?

    性能测试的目的更是令人头疼。 在开始一次性能测试之前，对软件产品的相关角色做一个调查， 会发现你收集到的结果是五花八门。

    • l  客户: 我觉得某个页面反应很慢.
    • l  客户: 某一个通知邮件本来应该在5分钟内收到, 但是半个小时都没有收到
    • l  技术支持: 客户问该系统到底能支持多少用户?
    • l  技术支持: 客户问如果交易量提高50%, 需要购买什么样的硬件?
    • l  Dev: 我希望性能测试能帮助我们找到系统的瓶颈.
    • l  Dev: 我想优化性能, 但是我需要得到不同参数下系统的性能, 你能提供吗?
    • l  产品经理: 客户对我们的系统性能抱怨很大, 你能不能告诉我系统的性能到底如何?
    • l  产品经理: 新版本性能提高了多少?

    作为性能测试项目的Owner， 你要考虑， 应该如何设计性能测试， 使得最少的测试能满足最多的要求？

    建立性能测试模型可以帮助我们处理上面所涉及到的复杂性。帮助我们生成最有效率的性能测试案例。


    查看(797) 评论(1) 收藏 分享 管理