qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

软件测试之性能测试浅谈(2)

 模拟演练

  写了一大堆,新手还是不知道如何去做。其实写本文的目的也不是讲具体操作,而是思想,思想。新手学性能测试,建议找一本从LOADRUNNER开讲的书比较好。如51TESTING上有连载的《性能测试从零开始》。

  不过还是尽量说点具体些的内容吧。

  普通BS架构的系统,一般都采用测试工具(如LR)直接录制手工操作的方式进行测试。这种方式简单有效,对测试人员要求不高。但在一些情况下,这种基于录制的方法可能无法完成,比如页面上有特殊控件、系统是CS架构、或者通讯的协议无法捕获等。这时就需要更复杂的测试方法,如手动编写模拟客户端的JAVA代码,而把测试工具当作一个调度控制台,去调度大量的虚拟用户线程执行编写好的代码。

  现在假设有一个简易版的12306网站,JAVA实现,中间件为TOMCAT,数据库为SYBASE,没有集群处理(一切从简,只有查询和订票功能)。如何对它进行性能测试呢?

  按照上面的几个步骤来想一想吧,这里只简单写几点。

  第一步,测试确认。海量并发,数据也应该是海量的,但基本都是简单查询,没有复杂的统计,所以主要困难还是在海量并发事务的处理上。中间件、数据库上都会承受巨大压力。此类高并发系统还需要对一些功能特别注意,比如一个车次有10张票,5个人同时购票,如何处理?如果是12个人同时点购票,又是如何处理?

  第二步,通过标准。无非是系统能够满足多少人同时在线,一分钟内能处理多少订单,用户最大等待时间是几分钟。注意这个标准一定要是经过各方面确认过实际可行的啊,定一个订单响应时间不超过5秒有意义么?确认了以后,就要按着这个目标来设计测试和执行。

  另一个需要注意的问题,按照预期的压力测试通过了以后,是不是就高枕无忧了?答案是否定的,因为很可能这个预期或者标准是不合理的,这个是非常可能的,只有长期的数据积累,才会一点点走向精确。想想奥运订票系统,开通后短短五分钟,网站就瘫痪了,你们以为这种系统没有经过专业的性能测试么?据我所知,奥运订票系统性能测试时制定的标准是每分钟处理四百万访问(具体数据记不住了,就假设是这个数吧),出事后的检查发现,每分钟的访问量超过了八百万。这种事故责任在谁呢?测试机构敢拍胸脯保证,每分钟处理四百万就是没问题的。而奥组委自己设定的每分钟四百万目标,和实际出现偏差也是正常的,毕竟这种系统是第一次上线。最后的处理方法就是,压力达到了预期最大值以后,再后来的访问就被排队了。好好体会这个案例吧,会有收获的。

  第三步,测试设计。设计用户模型,设计测试场景,设计测试用例。一个典型的用户是如何使用系统的?登录、查询车次余票、订票、付款,这是理想化的情况。实际更可能是这样的,登录(一次登不进去,重复多次)、查询A车次(未到放票时间、不断重试,时间到无票)、查询B车次(无票)、查询C车次(有票)、订票、付款、查询订单。两种交互方式对系统产生的压力,差别是很大的。

  将多个用户行动整合到一起,也就是用户模型,或者叫系统使用模型,是压力场景设计的依据。假设系统一天的访问量是一万个用户,这一万访问量是在24小时内平均分布的,还是分布在8小时内,还是在某一时间点上集中访问?这些具体到用例中也就是虚拟用户的加载策略,直接决定了压力的大小。

  除了这个压力场景,针对此系统还需要进行绝对并发测试,参考第一步的分析。

  第四、五步就不细说了,准备环境、数据,针对大量用户的并发进行一些预调优。按照第三步设计好的各个测试用例准备脚本、执行测试。

  第六步,发现问题了怎么办?比如1000人的压力下,系统响应就比较慢了,查询车次需要1分钟,下订单需要2分钟,接下来要做什么?能把这些作为一个性能缺陷提起么?显然是不可以的,这只是通过你的压力测试场景产生的一个现象,可能是测试脚本有问题、也可能是测试环境有问题。作为一个性能测试人员,需要尽量深入的定位到问题产生的原因。就像这个响应慢,只是一个表面现象,慢在哪?是中间件还是数据库?一些简单的测试方法就可以进行判断,如在页面上进行一些数据库无关的操作,如果依然比较慢,说明在中间件上压力就已经比较大了。还可以部署另一套中间件测试环境,连接之前相同的数据库,在压力测试出现问题的同时,手动访问新部署的应用(只有一个用户),如果同样很慢,那说明慢在了数据库端的处理上。还可以通过日志的方式更准确的进行判断,如应用日志和数据库SQL执行日志。总之方法是多种多样的,但目的只有一个,就是不断的排除无关部分、缩小问题范围。

  定位到了中间件和数据库之一,然后又该怎么办?此时恐怕就需要一些相关方面的专业知识了,但其实最常见的还是那些。中间件相关的一般是线程池、JVM、数据库连接池等,数据库相关的有锁、缓存、IO(一般就是SQL语句的问题)等。要进行全面的监控和分析,再做一些合理的调优并重复测试。

  问题定位到什么程度才行?我认为是要让人看了知道改哪就可以了。比如提一个“这个SQL语句进行了大量的物理IO,性能不好”,这就不是个好问题,物理IO是什么?怎么改?如果这么说就好多了“这个SQL语句没有使用索引,导致了全表扫描,进行了大量的物理IO,性能不好。如果要避免全表扫描,需要调整SQL语句或者添加XX索引”,这才是定位问题。

  当然了,上面只是一个非常简陋的举例,真实的性能测试要比这复杂的多。

  总的来说,我认为,性能测试的难度主要不在技术手段上,互联网时代技术都是共享的,要善于去搜索利用他人的成果。即使自己搞不定,团队内一定还有专业的开发工程师、数据库管理员、系统管理员可以帮你搞定。真正的难点在于,你要想出来如何去测是有效的、有保障的,这才是测试工程师最重要的能力。

  还是那个观点,思想才是根本。

posted @ 2013-01-05 13:33 顺其自然EVO 阅读(284) | 评论 (0)编辑 收藏

跟屌丝大哥学习DB2---DB2 runstats、reorgchk、reorg 命令

1、runstats

runsats可以搜集表的信息,也可以搜集索引信息。作为runstats本身没有优化的功能,但是它更新了统计信息以后,可以让DB2优化器使用最新的统计信息来进行优化,这样优化的效果更好。

 

runstats   on   table   <tbschema>.<tbname>   收集表   <tbname>   的统计信息。表名必须是用   <dbschema>   全限定的。

 

 

  2、reorg

 

 A、 reorg   table   <tbschema>.<tablename>   通过重构行来消除“碎片”数据并压缩信息,对表进行重组。表名必须是用   <dbschema>   全限定的。

  B、

reorg还有一个功能就是可以将表中的数据按照某个索引关键字的顺序排列,从而可以减少某些查询I/O的数量。

 

 

  执行REORG可以考虑分为表上有索引和没有索引两种情况: 

     a.如表名为DB2INST1.STAFF,索引名为DB2INST1.ISTAFF

      reorg table db2inst1.staff index db2inst1.istaff use tempspace1

    b.建议REORG时使用USE参数指定数据重排时使用的临时表空间,否则,REORG工作将会

       在表所在表空间中原地执行.如果表上有多个索引,INDEX参数值请使用最为重要的索

       引名.

    c.表上没有索引:

       reorg table db2inst1.staff use tempspace1

      reorg table sysibm.systables use tempspace1

 

http://weiruan85.javaeye.com/blog/317520

 

3、

 

让db2系统定时runstats、reorg

Q:定期runstats、reorg

A:在db2 v8.2以上可以使用 CALL SYSPROC.ADMIN_CMD来实现,

这里主要讲在v8.2以前的版本中利用shell或者批处理来实现同样的功能

因为在以前的版本中存储过程中是不能使用DDL操作语句的!(这点对于oracle刚转过来的人来说很是郁闷的)

然后可以利用db2自带的配置自动维护来做,但是java做的东西比较让人感觉头痛!尤其是速度和莫名的错误!

本代码使用操作系统的脚本来实现这部分功能!

1.windows下

如下:

下一个cmd文件s.cmd

内容如下:

db2 connect to ccp_dm

db2 -x "select 'runstats on table '||rtrim(tabschema)||'.'||tabname||' on all columns' from sysstat.tables where card=-1">tab.sql

db2 -f tab.sql

--其中where后的条件可以修改

然后就是定制任务:用windos的定制任务!每周或者每月运行,这个就不讲了哈!

这部分经测试,通过!

不过能,这里只提到了runstats,对于reorg同理也可以实现!

 

http://myfriend2010.itpub.net/post/29012/386779

 

 

4、reorgchk

 

C:\Documents and Settings\Administrator>db2 reorgchk update statistics on table all

 

正在执行 RUNSTATS ....

 

  reorgchk   on   table   all   确定是否需要对表进行重组。这对于对所有表自动执行 runstats很有用。   

 

 

1) 针对系统表进行REORGCHK

db2 reorgchk update statistics on table system

使用UPDATE STATISTICS参数指定数据库首先执行RUNSTATS命令。

 

2) 针对用户表进行REORGCHK

db2 reorgchk update statistics on table user

 

下面是执行的部分结果

db2 reorgchk update statistics on table user

执行 RUNSTATS ....

 

 

db2 reorgchk 命令是最重要的、也是经常被忽略的 DB2 调整命令之一。 db2 reorgchk 命令被忽略是因为它不是一个一次性调整项。由于更新是在 DB2 数据库上执行的,因此关于表的统计信息将不会是最新的。db2 reorgchk 命令更新 DB2 优化器所使用的重要统计信息。建议在大约每 10,000 次更新后重复 db2 reorgchk 命令。

 

在运行 db2 reorgchk 命令之前,您应该停止 IBM Directory Server 以防止在命令执行的同时发生任何 DB2 查询或更新。虽然这是可选的,但数据库查询和更新可能会非常缓慢并有可能超时。

 

 

 

请注意,运行 db2 reorgchk 命令所带来的性能益处是即时的。不必在 db2 reorgchk 命令之后重新启动 DB2。

 

除了提高性能之外,db2 reorgchk 命令还报告关于数据库中所有表和索引的统计信息。db2 reorgchk 命令还报告关于 DB2 表的组织的统计信息。

 

http://publib.boulder.ibm.com/tividd/td/ITAME/SC32-1351-00/zh_CN/HTML/am51_perftune66.htm

posted @ 2013-01-04 14:46 顺其自然EVO 阅读(444) | 评论 (0)编辑 收藏

详解:MySQL数据表损坏的正确修复方案

 修复以损坏的MySQL数据表的实际操作在实际中是我们经常用到的,以下的文章主要是介绍正确修复以损坏的MySQL数据表的实际操作步骤,以下就是正文的介绍,希望会给你带来一些帮助在此方面。

  于断电或非正常关机而导致MySQL(和PHP搭配之最佳组合)数据库出 现错误是非常常见的问题。有两种方法,一种方法使用MySQL(和PHP搭配之最佳组合)的check table和repair table 的sql语句,另一种方法是使用MySQL(和PHP搭配之最佳组合)提供的多个myisamchk, isamchk数据检测恢复工具。前者使用起来比较简便。推荐使用。

  1、check table 和 repair table

  登陆MySQL(和PHP搭配之最佳组合) 终端:

  MySQL(和PHP搭配之最佳组合) -uxxxxx -p dbname

  1.> check table tabTest;

  如果出现的结果说Status是OK,则不用修复,如果有Error,可以用:

  1.> repair table tabTest;

  进行修复,修复之后可以在用check table命令来进行检查。在新版本的phpMyAdmin里面也可以使用check/repair的功能。

  2、myisamchk, isamchk

  其中myisamchk适用于MYISAM类型的数据表,而isamchk适用于ISAM类型的数据表。这两条命令的主要参数相同,一般新的系统都使用MYISAM作为缺省的数据表类型,这里以myisamchk为例子进行说明。当发现某个数据表出现问题时可以使用:

  1.myisamchk tablename.MYI

  进行检测,如果需要修复的话,可以使用:

  1.myisamchk -of tablename.MYI

  关于myisamchk的详细参数说明,可以参见它的使用帮助。需要注意的时在进行修改时必须确保MySQL(和PHP搭配之最佳组合)服务器没有访问这个数据表,保险的情况下是最好在进行检测时把MySQL(和PHP搭配之最佳组合)服务器Shutdown掉。

  另外可以把下面的命令放在你的rc.local里面启动MySQL(和PHP搭配之最佳组合)服务器前:

  1.[ -x /tmp/MySQL(和PHP搭配之最佳组合).sock ] && /pathtochk/myisamchk -of /DATA_DIR/*/*.MYI

   其中的/tmp/MySQL(和PHP搭配之最佳组合).sock是MySQL(和PHP搭配之最佳组合)监听的Sock文件位置,对于使用RPM安装 的用户应该是/var/lib/MySQL(和PHP搭配之最佳组合)/MySQL(和PHP搭配之最佳组合).sock,对于使用源码安装则是/tmp /MySQL(和PHP搭配之最佳组合).sock可以根据自己的实际情况进行变更,而pathtochk则是myisamchk所在的位 置,DATA_DIR是你的MySQL(和PHP搭配之最佳组合)数据库存放的位置。

  需要注意的时,如果你打算把这条命令放在你的rc.local里面,必须确认在执行这条指令时MySQL(和PHP搭配之最佳组合)服务器必须没有启动!

  检测修复所有数据库(表)

  MySQL(和PHP搭配之最佳组合)check -A -o -r -p

  以上的相关内容就是对修复损坏的MySQL数据表的介绍,望你能有所收获。

posted @ 2013-01-04 14:32 顺其自然EVO 阅读(262) | 评论 (0)编辑 收藏

一种搭建分布式测试环境和批量性能测试的思路

 背景

  在搜索引擎的测试过程中,经常会遇到以下两个问题:

  ● 需要搭建和更新分布式测试环境

  ● 在性能测试时,我们需要测试不同集群规模和配置下的环境时,如何自动更新测试环境和批量进行性能测试

  因此,我们需要设计一个脚本,这个脚本可以帮我来完成这些事。

  在这里,我推荐使用Python,理由有:

  ● 写起来比较快(测试时间本来就比较紧张),不可能用C或者Java了

  ● 语法比较清晰,Shell、Perl这些维护起来太乱

  ● 自带的库、第三方的库比较丰富

  ● 另外,我个人比较喜欢Python的mako模版引擎和paramikossh2库。

  其实不用paramiko也可以,只要把机器ssh打通就可以。但我个人不太喜欢这种方式,觉得耦合性太强(只能在Linux下运行了)。

  设计

  批量性能测试的设计

  我很喜欢采用YAML格式,YAML格式的一大好处就是可以很方便的定义List、Map等类型

  1. tasks: 
  2.  # 第一个测试用例,我可能需要测试单线程的情况 
  3.  - 
  4.     id:1# ID的作用是你在脚本中可以拿id作为结果存放的目录 
  5.     parallelNum:1# 并发数 
  6.     seconds:1800# 压半个小时 
  7.     targetHost:10.20.137.22 # 目标主机 
  8.     targetPort:9999 
  9.     queryFilePath:/home/admin/access-log/add-600w.query  # 请求放在这儿 
  10.  # 第2个测试用例,我可能需要测试2线程的情况,这时我就只要再写一个,然后parallelNum: 2就可以了 
  11.  - 
  12.     id:1 
  13.     parallelNum:2 
  14.     seconds:1800 
  15.     targetHost:10.20.137.22 
  16.     targetPort:9999 
  17.     queryFilePath:/home/admin/access-log/add-600w.query

  在阿里的搜索平台这边,我们大多使用abench作为性能测试工具,它是一个命令行工具,只要命令+参数就可以了,比起JMeter要写JMeter脚本简单。因此,我再在配置文件中设计一下abench的命令格式。

  因为在运行命令中,有很多参数需要替换成上述测试用例设定的参数,因此需要采用模版引擎的方式。Python的模版引擎很多,我个人比较推荐mako。

  1. abenchPath:/opt/usr/bin/abench  # abench在哪儿? 
  2. abenchCommand:"${abenchPath} -p ${parallelNum} -s ${seconds} -k --http -o /dev/null ${targetHost} ${targetPort} ${queryFilePath}"
 配置文件设计好了,下面我们来写我们的Python脚本了(这里仅仅给出一些主要代码,大致明白意思就可以了)

  1. import subprocess 
  2. from mako.template import Template 
  3. import yaml 
  4.  
  5. # 运行一个测试任务 
  6. def runTask(config, task): 
  7.     runAbench(config, task) 
  8.  
  9. def runAbench(config, task): 
  10.      # 得到完成的abench运行命令 
  11.      command = Template(config["abenchCommand"]).render( 
  12.          abenchPath=config["abenchPath"], 
  13.          parallelNum=task["parallelNum"], 
  14.          seconds=task["seconds"], 
  15.          targetHost=task["targetHost"], 
  16.          targetPort=task["targetPort"], 
  17.          queryFilePath=task["queryFilePath"], 
  18.          ) 
  19.      pipe = subprocess.Popen(command, 
  20.          stdin=subprocess.PIPE, 
  21.          stdout=subprocess.PIPE, 
  22.          stderr=subprocess.PIPE, 
  23.          shell=True 
  24.          ) 
  25.      # 读取abench的运行结果,因为可能得保存下来吧 
  26.      result = pipe.stdout.read() 
  27.      # 下面可能是保存结果什么的 
  28.  
  29. if __name__ == "__main__": 
  30.     config = yaml.load(file(configFile)) 
  31.     for task in config["tasks"]: 
  32.        runTask(config, task)

  自动更新测试环境

  在我实际测试过程中,因为要更新的环境其实相当复杂,最多的时侯需要去10几台机器上做更新环境、停止/启动进程的操作。但我这里主要介绍思路,多一些机器和进程其实都一样。

  接着刚才的配置文件,我们只是在每一个task中设计了加压任务,但在加压前需要更新哪些环境没有涉及,按照阿里巴巴的ISearch架构,我 就启动一个一行两列的Searcher环境,2列Searcher上有一个Merger,然后再有一个clustermap来监控。

  1. abenchPath: /opt/usr/bin/abench  # abench在哪儿? 
  2. abenchCommand: "${abenchPath} -p ${parallelNum} -s ${seconds} -k --http -o /dev/null ${targetHost} ${targetPort} ${queryFilePath}" 
  3. # 关于Searcher的一些通用配置 
  4. searcher: 
  5.     templateConfigFile: /home/admin/access-log/searcher_server.cfg  # 因为启动时的监听端口等信息需要从下面的运行任务中读取,因此这个也设计成一个模版文件 
  6.     templateLogConfigFile: /home/admin/access-log/searcher_log.cfg 
  7.     # 在Search机器上操作的命令 
  8.     commands: 
  9.         - "${searchRoot}/bin/is_searcher_server -c ${configFile} -l ${logConfigFile} -k stop > /dev/null 2>&1" 
  10.         - "${searchRoot}/bin/is_searcher_server -c ${configFile} -l ${logConfigFile} -k start -d > /dev/null 2>&1" 
  11. # 关于Merger的一些通用配置,和Searcher差不多,就不写了 
  12.  
  13. tasks: 
  14.  # 第一个测试用例,我可能需要测试单线程的情况 
  15.  - 
  16.     id: 1 # ID的作用是你在脚本中可以拿id作为结果存放的目录 
  17.     parallelNum: 1 # 并发数 
  18.     seconds: 1800 # 压半个小时 
  19.     targetHost: 10.20.137.22 # 目标主机 
  20.     targetPort: 9999 
  21.     queryFilePath: /home/admin/access-log/add-600w.query  # 请求放在这儿 
  22.  
  23.     # 两台Search机器,定义一个List 
  24.     searchers: 
  25.        - 
  26.          host: 10.20.150.61 
  27.          port: 6322 # 监听的端口 
  28.          username: test # 因为需要通过ssh协议登录上去操作,因此需要用户名密码。如果你已经把机器ssh都打通了,那就不需要了 
  29.          password: 12345 
  30.          configFile: "${searchRoot}/scripts/conf/searcher_server.cfg" # 启动时运行的配置文件 
  31.          logConfigFile: "${searchRoot}/scripts/conf/searcher_log.cfg" # 启动时运行的日志文件 
  32.        - 
  33.          host: 10.20.150.60 
  34.          port: 6322 
  35.          username: test 
  36.          password: 12345 
  37.          configFile: "${searchRoot}/scripts/conf/searcher_server.cfg" 
  38.          logConfigFile: "${searchRoot}/scripts/conf/searcher_log.cfg" 
  39.  
  40.     # 我这边只有一台merger,如果merger也是有多台的话,也可以把这个设计成一个List 
  41.     merger: 
  42.        host: 10.20.137.22 
  43.        port: 6088 
  44.        username: test 
  45.        password: 12345 
  46.        configFile: "${searchRoot}/scripts/conf/merger_server.cfg"
然后比如关于Searcher的配置文件,在上面也是一个模版文件阿,我们可以把这个文件设计成:

  1. se_conf_file=${searchRoot}/scripts/conf/se.conf 
  2. simon_conf_path=${searchRoot}/scripts/conf/simon_searcher.xml 
  3. sort_config=${searchRoot}/scripts/conf/searcher_sort.xml 
  4. cache_size=0 
  5. cache_min_doc=0 
  6. conn_queue_limit=500 
  7. [services] 
  8. tcp ${port} # 主要就是为了替换监听的端口,其实要做得通用一点的话,很多配置都可以搞成变量,但就是可能你自己的配置文件变得很复杂。因此我们能不改的就尽量不改。 
  9.  
  10. [clustermap] 
  11. local_config_path=${searchRoot}/scripts/conf/clustermap.xml

  上述就是关于searcher和merger多行多列的配置,下面我们完善一下我们刚才的Python脚本

  1. # 得的一个ssh登录后的client对象,用于调用远程机器上的命令 
  2. def getClient(host, port, username, password): 
  3.     client = paramiko.SSHClient() 
  4.     client.load_system_host_keys() 
  5.     client.set_missing_host_key_policy(paramiko.WarningPolicy() 
  6.     client.connect(hostname, port, username, password) 
  7.     return client 
  8.  
  9. # 得到一个sftp对象,因为需要scp渲染好的配置文件什么的,因此需要sftp对象,它的put方法其实就类似scp 
  10. def getSftp(host, port, username, password): 
  11.     transport = paramiko.Transport((hostname, port)) 
  12.     transport.connect(username=username, password=password) 
  13.     sftp = paramiko.SFTPClient.from_transport(transport) 
  14.     return sftp 
  15.  
  16. # 更新和部署Searchers 
  17. def cleanSearchers(config, searchers): 
  18.     for searcher in searchers: 
  19.         # 得到渲染好的配置文件的内容 
  20.         templateLine = Template(file(config["searcher"]["templateConfigFile"]).read()).render( 
  21.             port=searcher["port"], 
  22.             searchRoot=config["searchRoot"] 
  23.             ) 
  24.         # 将渲染好的配置文件写入一个临时文件 
  25.         tmpConfigFile = tempfile.NamedTemporaryFile(delete=False) 
  26.         tmpConfigFile.file.write(templateLine) 
  27.         tmpConfigFile.file.close() 
  28.         # 将这个临时文件scp拷远程机器上的哪儿 
  29.         targetConfigFile = Template(searcher["configFile"]).render(searchRoot=config["searchRoot"]) 
  30.         sftp = getSftp(searcher["host"], 22, searcher["username"], searcher["password"]) 
  31.         sftp.put(tmpConfigFile.name, targetConfigFile) 
  32.         sftp.close() 
  33.         # 删除掉之前的临时文件 
  34.         os.remove(tmpConfigFile.name) 
  35.         # 运行启动searcher的命令 
  36.         client = getClient(searcher["host"], 22, searcher["username"], searcher["password"]) 
  37.         for command in config["searcher"]["commands"]: 
  38.             command = Template(command).render( 
  39.                 searchRoot=config["searchRoot"], 
  40.                 configFile=targetConfigFile, 
  41.                 logConfigFile=targetLogConfigFile 
  42.                 ) 
  43.             client.exec_command(cmd) 
  44.         client.close()
 关于clustermap的配置

  在阿里巴巴的ISearch架构中,searchers几行几列是由clustermap来配置的,我们这边也稍微简单话一点,不考虑 merger有多台的情况,就设计searchers几行几列的情况。更新一下刚才在task中的配置,加上关于clustermap的配置

  1.      clustermap: 
  2.        host: 10.20.137.22 
  3.        username: test 
  4.        password: 12345 
  5.        configFile: "${searchRoot}/scripts/conf/clustermap.xml" 
  6.        # 一台merge 
  7.        merger: 
  8.          host: 10.20.137.22 
  9.          port: 6088 
  10.        # 关于searcher的配置,其实是一个二维数组。第一个纬度是列,第2个纬度是行。以下这个例子是1列2行 
  11.        searchers: 
  12.          - 
  13.            servers: # 同一列下的机器 
  14.              - 
  15.                host: 10.20.150.61 
  16.                port: 6322 
  17.          - 
  18.            servers: 
  19.              - 
  20.                host: 10.20.150.60 
  21.                port: 6322

  上述是1列2行的例子,如果要配成2行2列就只要在searchers部分配成:

  1.        searchers: 
  2.          - 
  3.            servers: # 同一列下的机器 
  4.              - 
  5.                host: 10.20.150.61 
  6.                port: 6322 
  7.              - 
  8.                host: 10.20.150.59 
  9.                port: 6322 
  10.          - 
  11.            servers: 
  12.              - 
  13.                host: 10.20.150.60 
  14.                port: 6322 
  15.              - 
  16.                host: 10.20.150.62 
  17.                port: 6322
 然后为了迎合clustermap配置的这种设计,在clustermap的模版配置文件也需要改一下:

  1. <?xml version="1.0"?> 
  2. <clustermap> 
  3.     <!-- 关于Merger的配置,这里我暂时不考虑merger多台的情况 --> 
  4.     <merger_list> 
  5.             <merger_cluster name=m1 level=1> 
  6.                 <merger ip=${merger["host"]} port=${merger["port"]} protocol=http/> 
  7.             </merger_cluster> 
  8.     </merger_list> 
  9.  
  10. <!-- 下面是searcher的多行行列的配置,是一个二维数组 --> 
  11. <search_list> 
  12. <% 
  13. id = 1 # 这个值是纪录searcher列的名字 
  14. %> 
  15. <!-- 第一个纬度,同一列的 --> 
  16. % for searcher in searchers: 
  17. <search_cluster name=c${id} docsep=false level=1 partition=0> 
  18.     <!-- 第二个纬度,同一行的 --> 
  19.     % for server in searcher["servers"]: 
  20.     <search ip=${server["host"]} port=${server["port"]} protocol=tcp type=mix /> 
  21.     % endfor 
  22. </search_cluster> 
  23.     <% 
  24.     id += 1 
  25.     %> 
  26. % endfor 
  27. </search_list> 
  28.  
  29.     <merger_cluster_list> 
  30.             <merger_cluster name=m1> 
  31.                 % for i in range(1, id): 
  32.                 <search_cluster name=c${i} /> 
  33.                 % endfor 
  34.             </merger_cluster> 
  35.     </merger_cluster_list> 
  36. </clustermap>

  这样比如1行2列渲染出来成了:

  1. <?xml version="1.0"?> 
  2. <clustermap> 
  3.     <merger_list> 
  4.             <merger_cluster name=m1 level=1> 
  5.                 <merger ip=10.20.137.22 port=6088 protocol=http/> 
  6.             </merger_cluster> 
  7.     </merger_list> 
  8.  
  9. <search_list> 
  10. <search_cluster name=c1 docsep=false level=1 partition=0> 
  11.     <search ip=10.20.150.60 port=6322 protocol=tcp type=mix /> 
  12. </search_cluster> 
  13. <search_cluster name=c1 docsep=false level=1 partition=0> 
  14.     <search ip=10.20.150.61 port=6322 protocol=tcp type=mix /> 
  15. </search_cluster> 
  16. </search_list> 
  17.  
  18.     <merger_cluster_list> 
  19.             <merger_cluster name=m1> 
  20.                 <search_cluster name=1 /> 
  21.             </merger_cluster> 
  22.     </merger_cluster_list> 
  23. </clustermap>

  总结

  上述就是我在测试中,对分布式环境的自动更新和批量性能测试,这样大大减少了我们来回捣固机器、修改配置的时间。而且对测试结果的自动收集和解析也可以帮助我们来分析测试结果。我觉得这是一个不错的尝试,大家可以都可以试试看。

posted @ 2013-01-04 14:27 顺其自然EVO 阅读(917) | 评论 (0)编辑 收藏

开发自测模式实践

 背景:

  长期以来业务线测试有这种困扰:淘宝业务线传统的项目流程把开发、测试两个阶段分得比较明显,导致开发赶时间写代码,提测阶段测出一些低级bug;重新返工不仅测试时间延长,也导致开发、测试同学都累。

   在天彤的支持下,本人今年3月份来到C2B市场团队轮岗开发,实践了开发自测的项目模式。这是一个新产品团队,新模式比较容易落地。迄今经历了5个项目 (C2B公益概念版、C2B标准版、C2B公益版2期、C2B合买版和合买版双12活动),摸索了近1年,有过困难和困惑,总体看来实践效果还是挺不错 的,分享一下。

  分享分为实践案例、模式小结和展望3部分

  一、实践案例

  以时间为维度,实践中经历了以下3个阶段。每个阶段都是在前一阶段模式的基础上根据实际情况优化的

  阶段1:人人都是开发,没有专职测试

  有两个项目

  1、C2B团购概念版(3.20-4.15,开发测试比3:0),第1次实践成功

  这是第一次轻量级尝试,加上我有3个开发,功能全部自测,最后我主导验收了一下功能。项目流程如下

  说明:

  1)由于前端资源紧缺问题,所以后期才开始前端编码

  2)TC也要开发自己写。给开发培训了一下从UC到TC的转化方法

  3)整体验收包括代码review、PD验收和我再覆盖一下主流程

  效果:

  1)单测和接口测试覆盖很好地保证了质量

  在单测和接口测试阶段都发现了bug,避免遗留到功能测试阶段;后端编码的稳定性,能让开发在后期专注在前端功能的开发和联调上,不用担忧底层的质量

  2)功能测试时间大大缩短

  因为资源问题前端介入较晚,全部联调好后离计划发布日还剩2天,这两天的功能测试时间里我们找出了大部分问题并解决了,完成了验收和发布。项目总共花了19个工作日,开发时间稍微延长,测试时间大大缩短,总的项目时间是缩短的。

  3)项目质量稳定

  发布后,后端遗留一个因线上、daily环境不一致导致的bug;前台遗留1个bug。在时间很有限的情况下,总体质量不错

  问题:

  UC、TC有一定的重复工作量,初次编写TC的开发工程师写得不太好且消耗时间略多

 2、C2B标准版(5.15-7.13,开发测试比4:0)。暴露一个问题

  因为第一个项目比较成功,所以第二个项目继续沿用上一次的自测模式,项目流程基本不变。

  效果:

  关键词还是前端资源紧张,全部联调好后只剩下1天的daily测试时间。因为前期各自自测做得比较充分,所以依旧是后端稳定,前端小问题比较多。花了1天修复完大部分前端问题后,按时发布。

  问题:

  此次需求点很多,时间又紧,人员配置全部都是开发的情况下,没有一个人能够关注到整体业务,对所有的业务逻辑能比较清晰。导致

  1)系统方面:后面新需求过来评估时,要花费更多的时间,潜在bug发生的可能性增加

  2)业务方面:用户体验,对PD新需求的控制力什么的,照顾不太到

  3)流程方面:UC略不规范,导致转化成TC不太方便,也不方便别人看,不方便验收和测试

  阶段2:开发自测,测试关注整体业务

  1、公益版2期(7.13-8.3,开发测试比4:1)

  2、合买版(10.19-11.3,开发测试比4:1)

  这两个项目又新增了开发资源,吸取了前两次的经验教训后,继续优化一下项目模式。

  优化点:

  1)项目里我不再担任开发人员,全职做测试;因为前面两个项目自测效果不错,所以依旧坚持开发自测的思路

  2)强化UC,弱化TC。开发不再编写TC,但要详细写好UC。由我负责写一些主流程TC和容易出错环节的TC

  弱化TC的原因:

  i.和UC有重复工作量

  ii.黑盒功能用例写得再多也不能保证全部覆盖

  iii.TC也是给开发自测参考用的。开发自测习惯是根据代码逻辑做功能测试,流程性的一般根据自己的UC进行自测,然后再覆盖一下TC上容易遗漏的点,基本能满足自测期望达到的目标

  3)增强代码review

  测试从前期就介入代码review中,避免项目后面大家一起review的工作量太大。项目代码略稳定后,我每天花在代码review上的时间至少占工作量的三分之一

  4)完善回归系统

  效果:

  1)测试能对整体业务点都很了解,并且能在前期就review出一些bug

  2)从时间上可以看出,项目时间都在一个月内。这里测试时间压缩了很多,两个项目提测到发布都只花了4天

 阶段3:开发自测,优化流程,释放测试资源

  合买版双12活动(11.23-12.6,开发测试比4:1)

  阶段2进行得比较顺利,于是接下来的项目继续在此模式基础上优化

  优化点:

  1)测试全程介入技术方案评审和代码review

  从技术方案开始介入,review sql、业务层代码、vm层代码

  2)更加关注系统性能方面的东西

  测试同学能有时间学习性能测试,并为系统进行了性能调优,为双12做好准备

  问题:

  前端代码尚无能力review。

  二、模式小结

  有些人疑惑,开发自测后,测试干什么?

  这就回到了开头提到的困扰。开发自测模式,能把开发和测试从低级bug中解放出来,开发可以提高代码质量,测试可以关注更深层次的系统质量(比如性能和代码优化等),整个团队能提升效率,进入良性循环。

  那么写了那么多,经历了半年多的探索,目前我们项目组到达了什么程度呢?从项目模式、效果和测试同学的角色3方面来描述一下。

  1、产出了一个被现实考验过的项目模式(当然还在继续优化中)

  1)UC

  开发同学要写详细、标准的UC,方便后续测试和维护;测试同学根据UC简单得写一些TC,方便开发自测

  2)DAO层单测

  新增sql必须要写单测用例,修改sql必须要回归单测用例

  3)业务层单测

  已经有比较完善的单测环境,开发可以根据个人喜好,在manager层或ao层进行单测,无硬性要求

  4)代码review贯穿整个流程

  分为两类代码review,目前我们项目组两类并存

  i.测试同学主导的每日review

  项目里每天测试同学都会review开发提交的代码,这不仅仅是发现bug,目前我们的代码review已经能到优化代码或设计方案的阶段。例如:http://kelude.taobao.net/issues/206462?page=1

  ii.传统的项目组review

  在项目后期集中式得进行一两次review,有效果但量较大

  5)功能自测&验收

  功能自测开发根据UC和TC进行;验收是PD介入,页面有新需求可以及时改动

  6)整体测试

  主要由我来执行,进行主流程测试和随机测试,但不会覆盖所有点,其他功能点的质量开发同学自己保证

 2、效果

  1)工期缩短。这是最明显的,目前这几个项目的daily、预发测试时间加起来都没超过1周的

  2)质量提高。

  i.开发同学的代码质量提高了。以前测试同学都基本是保姆式的,现在测试介入得少了,遗漏bug会增加吗?刚开始开发会略感不适应,但长期来看对整个团队肯定是有益的

  ii.整个开发流程中,很多bug发现在前期,后期底层基本很稳定了

  3)释放测试资源

  目前我们团队的开发测试比是4:1,最高时是5:1。在开发大部分时间工作量饱和的情况下,测试资源基本能满足项目组需要

  4)周期快,能够满足一周多次发布的需求

  交易线标准的日常流程:上一周提需求,周五UC评审,下周二提测,周三预发,周四发布。1周发布1次

  目前我们日常主要靠 开发自测+代码review+脚本回归 保证质量,测试同学不用花太多精力进行功能测试。因此团队效率很高,甚至能达到一天一次的发布频率(当然发布多了不是好事)

  3、测试同学的任务

  从初级bug的痛苦中释放出来后,测试关注什么?

  1)业务方面

  了解整体业务和逻辑,review覆盖整个研发流程,包括技术方案、sql、业务代码、vm,做一个熟悉整个系统的角色

  2)持续回归

  这一直是测试同学的强项,维护一个成形的产品需要建立一套完善的回归体系

  3)其他方面

  系统性能?算法测试?单测回归?无线?随便,因为有时间有精力了,都可以去做

  三、展望。我们才刚开始

  明年测试策略需要怎样完善?产品在不断迭代,市场在不断增长,测试压力得到释放后,有更多的事等着我们去做。目前想到的有以下3点

  1)测试数据

  方便开发同学自测

  2)前端代码review

  这一直是痛点,前端没有成形的review机制。明年学习一下前端知识,希望在review上有所突破

  3)完善回归

  方便开发自测,最好开发能根据改动点进行定制的脚本回归

  做到了这些,就做成了一个完整的开发自测生态圈。明年继续努力!

posted @ 2013-01-04 14:25 顺其自然EVO 阅读(223) | 评论 (0)编辑 收藏

软件质量保证复审研究

  【摘要】软件质量保证软件开发的重要内容。软件质量保证复审则是软件质量保证的重要组成。本文就软件质量保证复审系统性和应用性做些探讨。

  【关键词】软件质量保证体系;系统性

  一、软件质量

   软件质量是“与软件产品满足规定和隐含需求的能力有关的全体特征(或特性)”。为满足软件的各项规定的或隐含的功能、性能需求,符合文档化开发标准,就 需要相应地设计出一些质量特性及其组合,质量目标,作为在软件开发与维护中的重要考虑因素。如果这些质量特性及其组合都能在产品中得到满足,则这个软件产 品的质量就是高的。这些被定义出来的特性及其组合就称之为软件“质量目标”。软件质量是各种特性的复杂组合,它随着应用的不同而不同,随着用户提出的量要 求不同而不同。承担保证软件质量的任。包括软件工程师、项目管理者、客户、销售人员和SQA(Software Quality Assurance)小组的人员。

  二、软件复审

  (1)软件复审:软件复审是软件工程过程中滤除缺陷的“过滤器”。在软件项目开发过程中的多个不同点上,软件复审活动能够起到及早发现错误进而引发排错活动的作用。软件复审目的是尽可能多地发现被复审对象中的缺陷,起到“净化”工作产品作用。由于发现别人生产工作产品中的缺陷比发现自己的缺陷要易,所以复审应在不同的工程师之间进行。任何一次复审都是借助人的差异性达到目标活动,目标包括:①指出一个人或一个小组生产的产品所需进行的改进。②确定被审核产品中不需要或者不希望改进的部分。

   (2)软件缺陷对成本的影响:在软件工程活动中,“缺陷”是指在软件交付给最终用户后发现的质量问题;而“错误”描述在软件交付前由软件工程师发现的质 量问题。很明显,缺陷带来的危害远大于“错误”带来的影响。因此,正式技术复审的主要目标就是在复审过程中发现错误,以便潜在的缺陷在交付之前变成“错 误”并得到纠正。正式技术复审的明显优点就是能够较早发现错误,防止错误传播到软件过程的后继阶段。“尽早”发现错误是我们的追求,因为同样的错误对成本 和工期产生的影响与发现错误、改正错误的时间是密切相关的。

  (3)缺陷的放大和消除:可以用“缺陷放大模型”来说明及时的复审在软件工 程中的作用。复审过程可能没有完全发现来自此步骤之前的和新发生的所有错误。从而可能在本阶段“继承”了一些错误,并将一部分错误引入下一阶段。其中,一 部分来自前一阶段的错误可能会误导本阶段的工作,导致在错误的基础上产生更多的错误,形成错误的“放大”效应。

  三、正式的技术复审

   正式技术复审(FTR)是一种由技术工程师进行的软件质量保证活动。FTR的目标是:①在软件的任何一种表示形式中发现功能、逻辑或实现上的错误。②证 实经过复审的软件的确满足需求。③保证软件的表示符合预定义的标准。④得到一种以一致的方式开发的软件。FTR是一类复审方式,包括“走查”、“审查”、 “轮查”以及其他软件小组的技术评估。每次FTR都以会议形式进行,经过适当地计划、控制和相关人员参与,FTR才能获得成功。

  (1)复审会议的组织:从保证会议效果出发,不论进行什么形式的FTR活动,会议的规模都不宜过大,控制在3~5人较好;每个参会人员都要提前进行准备,但是复审准备工作占用的工作时间应当少于两小时;会议的时间不宜长,控制在两个小时之内。

   FTR的焦点是某个工作产品,比如一部分需求规约,一个模块的详细设计,一个模块的源代码清单等等。负责生产这个产品的人通知“复审责任人”产品已经完 成,需要复审。复审责任人对工作产品的完成情况进行评估,当确认已经具备复审条件后,准备产品副本,发放给预定要参加复审的复审者。当发现错误和问题时, 记录员将逐一进行记录。在复审结束时,必须做出复审结论。结论只能是下列三种之一:①工作产品可以不经修改地被接收。②由于存在严重错误,产品被否决。③ 暂时接收工作产品(发现了轻微错误需要改正,但改正后无需再次评审)。

  (2)复审报告和记录保存:在FTR期间,一名复审者(记录员) 主动记录所有被提出来的问题。在会议结束时对这些问题进行小结,并形成一份“复审问题列表”。此外还要形成一份简单的“复审总结报告”。复审总结报告中将 阐明如下问题:复审对象是什么;有哪些人参与复审;发现了什么,结论是什么。复审报告是项目历史记录的一部分,可以分发给项目负责人和其他感兴趣的复审参 与方。复审问题列表有两个作用,首先是标识产品中的问题区域,其次将被用作指导生产者对产品进行改进的“行动条目”。 在复审总结报告中,复审问题列表应当作为附件。

  (3)复审指南:不受控制的错误的复审,比没有复审更加糟糕。所以在进行正式的复审之前 必须制定复审指南并分发给所有的复审参加者,得到大家的认可后,才能依照指南进行复审。正式技术复审指南的最小集合如下:①复审对象是产品,而不是产品生 产者。复审会议的气氛应当是轻松的和建设性的,不要试图贬低或者羞辱别人。通常,有管理职权的成员不宜作为复审者参加会议。②制订并严格遵守议程。FTR 会议必须保证按照计划进行,不要离题。③鼓励复审者提出问题,但限制争论和辩驳。有争议的问题记录在案,事后解决。④复审是以“发现问题”为宗旨的。问题 的解决通常由生产者自己或者在别人的帮助下解决。所以不要试图在FTR会议上解决所有问题。

  复审是贯穿于整个软件工程始终的保护性活 动。目的是通过对工作过程和阶段工作产品的审查与审核,尽量地预防错误,及早地发现和纠正错误,防患于未然。对生产过程的审核将及时发现和纠正违背已定义 的工程过程规范和组织标准的行为,防止因过程的偏离导致产品中出现错误。复审活动还包括对各类工作产品的复审与检查,以便及早发现和纠正已经发生的错误, 避免错误放大效应的发生。历史缺陷数据的积累、统计和分析有助于开展基于统计规律的SQA任务,能够帮助我们集中力量去解决导致发生错误和缺陷的最重要的 问题,取得事半功倍的效果。通过复审,我们能够基于统计规律,在度量基线的支持下,定量地评述软件的可靠性指标,从而满足用户提出的量化的可靠性性能需 求。

posted @ 2013-01-04 13:41 顺其自然EVO 阅读(246) | 评论 (0)编辑 收藏

软件测试的未来

 微软在自己的园区修建了一个非常酷的未来之家,在那里展示了未来科技和软件将如何改变家庭生活和 通讯方式。如果你曾参观过迪斯尼乐园的“旋转的进展”,你就会对微软的未来之家有个大致的印象,但微软的更先进。(迪斯尼乐园的展示是从上世纪60年代的 观点来描述未来,它过时了。)我有一天偶然发现,微软也制作了一系列的录像,来描述未来的零售业、医疗保健、工业、制造业以及其他各行各业。就像录像本身 制作精美一样,它们所描述的将来非常令人着迷,那里充满了计算机、射频卡和各式各样的软件。作为一名测试人员,我吓坏了,不禁想到,如今软件的质量如此糟糕,我们怎样才能测试好未来的应用程序呢?

  就这样,我开始了自己的未来探索。我跟公司的几十人交谈,然后开始做很多演示以便收集数百人的意见。其成果就是在Euro STAR的主题演讲和这一博客系列。我在本书中对这一愿景又加以更新,这可以帮助你看到该想法逐步完善的整个过程。

  外包。这是一个令人眼熟的术语,微软在2008年利用这种方式完成了很多测试。但是,事情并不总是如此,而且这种方式将来也并不可靠。在这篇文章里,我会谈论测试将来会以什么形式完成,外包作为软件测试的商业模式,会发生哪些根本性的改变。

  在一开始的时候,外包出去的测试很少。测试是由内部人力资源(即由编写软件的开发人员同一公司的雇员)来完成的。开发人员和测试人员(通常是同一批人执行两样任务)并肩工作,一起编写、测试并发布软件。

   在这种内包时代,供应商的角色是提供支持这种自助测试工具。但是,随着对工具之外的要求付出水面,供应商的角色很快就发生了改变。他们开始提供测试服务 本身,而不仅仅是提供工具给内部人力资源。我们将这一现象称为外包,他仍然是开发主顾们接触测试的基本模式,租用测试服务。

  因此,前两代的测试如下所示。

时代 

供应商角色 

(第一代)内包 

提供工具 

(第二代)外包 

提供测试服务(包括工具在内) 

   对于测试的这种改变,合乎逻辑的下一个步骤就是供应商们提供测试人员,这正是我们进入众包(crowdsourcing)的时代。昨天,软件测试外包公 司Utest的公告标志着这一时代的来临,观察它将如何发展会很有趣。众包模式未来会超过外包模式并赢得市场吗?显然,市场经济和提供众包服务的公司的能 力将会为这一问题提供答案,我个人的观点是众包模式的胜率较高。这并不是一个非此即彼的情况,而是测试领域的一种自然演变。较为陈旧的模式将随着时间的推 移,为新的模式让开道路。众包取代外包,将会成为达尔文自然选择的一个实例,只是它会在短短的几年就可以看出结果罢了。在由经济和质量约束共同决定的时间 范围内,适者生存。

  第三代的测试模式如下所示。

时代 

供应商角色 

(第三代)众包 

提供测试人员(包括工具、测试服务在内) 

   未来是怎么样的呢?在我们测试领域的DNA深处,是否埋藏有一个进化基因,它会使众包演变成更好的东西呢?我认为尽管可能需要几年时间和一些技术上的跨 越,它的确是这样的。现在我将衍生出一个新术语,这只是为这一概念取一个名字:测包(testsourcing),如下所示。

时代 

供应商角色 

(第四代)测包 

提供测试工件(包括工具、测试服务和测试人员在内) 

  没有跨越未知的关键技术,就无法解释什么是测包。这个技术就是虚拟化。

 为了让测包掌握未来的测试必须打破两个关键的技术壁垒:测试中产生的人工产品的重用性以及用户环境的可达性。让我解释一下这两个概念。      重用性:得益于20世纪90年代面向对象及其衍生技术的普及,软件开发所产生的人工产品实现了重用。我们今天开发的大部分软件都是由预先写好的库拼接在一 起所构成的一个整体。不幸的是,测试还没有这样做。写一个测试用例并简单的传递给另外一名测试人员让他重用,这样的想法在实践中很罕见。测试用例过于依赖 测试平台:他们是特定于某个待测的应用程序的;他们依赖于一些其他测试人员没有的工具;他们需要一个自动化测试架构、软件库以及网络配置等,而这些东西很 难被潜在的重用用户所复制。

  用户环境:全面测试需要针对不同的用户环境,这些用户环境的绝对数量让人生畏。假设我编写了一个应用程序打算让它在各种各样的手机上运行。我可 以从哪里得到这些电话来测试自己的应用程序呢?我如何配置这些手机,才能把它们看作是自己心目中客户所拥有的手机呢?其他类型的应用程序也会遇到同样的情 况。如果我写了一个web应用程序,我如何才能把这些不同的因素考虑进去:操作系统、浏览器、浏览器设置、插件、注册表配置、安全设置、机器设定和存在潜 在冲突的应用程序类型?

  对于这两个问题,目前浮现的答案是虚拟化技术,它正在有条不紊地变得更便宜、速度更快、功能更强大,它正在被应用于从实验室管理到IT基础设施部署的整个应用领域当中。

  虚拟化具有很大的潜力,使“众包者“能够提供众包服务。专业的测试套件、测试平台和测试工具都可以被一键化到虚拟机中,供任何人在任何地方使 用。正如今天的软件开发人员人员能够重用同事和前辈们的代码一样,众包者中的测试人员也可以通过这种方式,来重用测试套件和测试工具。重用让一个给定的开 发人员能够可靠地扩展应用程序的范围,同样地,它也会增加一个应用程序测试人员可以测试的类型。虚拟化使得重用复杂精密的测试框架能够在将来成为可能。

  对于用户环境的数量问题,虚拟化同样帮了测试人员的大忙。用户只需一键就可以将他们的整个计算机传到虚拟机,并通过云端计算提供给测试人员。如 果我们能够存储世界上所有的影片,给任何人在任何地方即时查看,我们为什么不能对虚拟用户环境做同样的事呢?虚拟化技术已经存在(对于个人电脑而言),或 者是近乎存在(对于移动设备或是其他特殊设定的用户环境而言)。我们只需要简单地将它应用到测试问题。

  最终这样做的结果是,任何测试人员,在任何地点,都可以广泛利用一个多样化的、可重用的自动化测试平台和用户环境。这样有助于众包者更好地提供 服务,并从技术角度来看,他们甚至可以和有特殊才能的外包者媲美,由于他们的人数远远超过外包者(至少在理论上,如果不是在实践中的话),这种新模式的优 势显而易见。

  市场也青睐那些得到虚拟技术支持的众包模式。用户环境将具有经济价值,众包测试人员人员为了获得竞争优势会对这些用户环境垂涎三尺。他们会激励 用户点击那些一键化按钮来虚拟并共享用户自己的环境(是的,这一模式会受到隐私问题的影响,但是那些问题都是可以解决的)。由于存在问题的环境比那些工作 良好的环境更有价值,假设遇到停工的驱动器和应用程序错误,此时,用户的态度将会完全颠倒过来:因为这意味着他们创造的虚拟测试更具有金钱价值……在那些 错误中有黄金!同样地,人们激励测试人员共享他们的测试宝藏,并使他们尽可能的被重用。市场力量的作用使得未来将是可重用测试产品的天下,而虚拟化使得这 一未来成为可能。

  那么,这个有着虚拟化技术支持的未来对测试人员本身意味着什么呢?嗯,让我们快进20~30年(或更长的时间,如果你对此表示怀疑),在那个时 候将会有以百万(或更多?)计的用户环境被收集、克隆、存储并共享。我能想象这些环境就像公共图书馆一样可以让测试人员可以免费浏览,或者像私人图书馆似 的进行订阅。测试用例和测试套件可以如法炮制,视其价值和可用性进行收费。

  也许,随之未来的时代将只有很少的人类测试人员,只有少数的东西和特质的产品(或者是像操作系统一样的极端复杂性的产品)需要他们进行干预。对 于大多数的开发者来讲,可以雇佣一名测试设计者从海量的可用虚拟测试环境中挑出所需要的,然后并执行他们:由于所有的自动化和最终用户配置已经设好并随时 可用,以百万人年计的测试将在几个小时内结束。这就是测包的世界。

  这是我们目前所知道的,软件测试的最后结局,但对于从事测试工作的人员来说,要对付其他有趣的挑战和问题,这只是一个全新的开端。这样的将来是 能够实现的,它并不需要除了虚拟化之外的以外的东西,其他所需要的那些技术要么已经存在,要么已经呼之欲出。这也意味着,随着我们转变成了设计人员(也就 是执行测试),或者担任开发人员的角色(也就是编写和维护可重用性产品),测试人员需要付出更加倍的努力。我们不要成为在软件开发晚期的“英雄”,测试人 员在虚拟化的未来世界中,应该是一等公民。

  这是我最钟爱的一个预测,THUD( THUD 是Tester's Head UP Display的缩写,测试人员的平视显示器,平视显示器(HUD)是将资讯投射于飞行员正前方玻璃上的飞行辅助仪器)是我们正在积极建造的一个工具。

  这是我们对于软件测试未来预测的第三部分,它要讨论的主题是信息的未来,测试人员在未来如何利用信息使他们的测试做得更好。

  预测1:测包

  预测2:虚拟化

  预测3:信息

  你使用哪些信息来帮助自己测试软件?测试规范?用户手册?在此之前(或与之竞争)的版本?源代码?网络协议分析器?进程监控器?这些信息是否有用?它们拿来就可以直接使用吗?

  信息是所有软件测试工作的核心。作为测试人员,对软件应该有哪些功能,它是如何实现的,了解的越多,我们的测试就会做的更好。如果测试人员对于 他们测试的软件知之甚少,并且了解到的信息都不是专门针对测试工作的,让它做的更加容易,这样的情况是不能接受的。我可以高兴的说,这样的局面正在迅速地 发生改变……并且在短期内,我们一定会实现在正确的时间,获得正确的信息。

  我从电子游戏中获得了测试信息的这些想法。在电子游戏中,我们在桌面上显示着相关信息并近乎完美地运用着它们。关于游戏、玩家、对手和环境的资 料,你了解得越多,你就会玩得更好,获得更好的分数。在电子游戏中,它们都显示在一个叫HUD或者成为平视显示器的玩意儿里。一个玩家的能力、武器和健康 值都显示在一个迷你地图中,对手的类似资料也可能会有(我儿子过去玩Pokemon时,他可以在游戏中通过访问Pokedex,了解他可能遇到的所有 Pokemon怪物)。这些游戏的思想很简单:你拥有并且可以使用的信息越多,你就越有机会在游戏中通关。

  我非常想把这个思想原封不动地转给软件测试人员,给他们更多的信息来增加他们成功的机会。但是,在测试世界里,由于缺乏这种丰富的信息基础构 造,所以大部分测试都陷入黑盒测试,哪里是我们的迷你地图,可以指出当前正在测试哪一个屏幕,它是如何使系统其它部分连接起来的?为什么我不能将鼠标悬停 在一个图形用户界面控件上以看到源代码,设置这个控件所包含的(以及我们可以测试的)属性列表?如果我在测试一个API,为什么我不能看到我和我的测试伙 伴们已经测试过的参数组合呢?我需要迅速得到所有这些信息,并以简洁易用的格式来帮助我进行测试,而不是去某些SharePoint站点或是数据库中乱翻 一气,因为那些地方充满了其他项目中的各种人为产品,与我的测试毫无关联。它们只会让我分心,我需要一个平视显示器。

  我在微软的同事乔艾伦穆哈尔斯基(Joe Allan Muharsky)把我渴望的这些信息称为THUD——测试人员的平视显示器——将测试人员找出软件缺陷并验证功能所需要的信息格式化,使之成为向其服务 的一种即时可用资料。你可以讲THUD看作是一层表皮,它将正在进行测试的应用程序包裹起来,随着应用程序的上下文环境,浮现出对其测试有用的资料和工 具。目前,THUD用的很少,甚至有的THUD没有包含正确信息。正如在游戏中,没有玩家会想着不用THUD就穿越不可预知的危险世界一样,到了将来,没 有测试人员会想着不用THUD就进行测试。

  如果这听起来有点像作弊的话,就随便你怎么向了。玩家通过HUD进行欺骗,相对那些没有这样做的,的确可以给他们带来更大的优势。由于内部测试 人员可以访问源代码、协议、后端、前端和中间件,所以我们确实可以进行这样的“欺骗”。我们可以利用这些欺骗获得的巨大优势,比普通黑盒测试人员和用户更 好地寻找软件缺陷。这正是我们想要的情形:比其他任何人更快、更有效地找到自己的软件缺陷。这是我全心全意认同的欺骗,可是目前,我们却没有利用这些欺骗 所需要的信息。

  在未来我们会这样做,与我们现在的信息饥渴相比,那样的未来将完全不同。

回顾过去,显示世界并不是完美无缺的,我们无法预测未来是美好的,所以,这个预测显得令人迷惑不解。但是,由于这是对未来的预测,我们不知道未来会 怎样,就还算过得去。许多人谈论着软件开发周期里的测试前移。据我所知,我们使测试人员参与规范审查等等已经几十年了。这是测试人员前移,而不是测试前 移。我们真正应该做的是,在软件开发周期中,尽早获得可测试的东西,使我们尽快开始测试。

  测试前移

  在测试中存在一个鸿沟,它在整个软件开发周期中蚕食着软件的质量、生产效率和其他可控特性。这个鸿沟就是从软件缺陷产生直到它被发现的时间鸿 沟。这个鸿沟越大,软件缺陷在系统中停留的时间就会越长。显然,这是很糟糕的,但是,我们过去所做的,仅仅是指出软件缺陷在系统中待的时间越长,清楚它的 代价也就越大。

  在将来,我们要做的是:消除这个鸿沟。

  但是,消除这个鸿沟意味着对我们目前测试方式的根本转变。在2008年,一名开发人员,完全是处于偶然,就可以引入一个软件缺陷,这一现象提醒 着你——我们的开发环境没有什么办法阻止它发生,直到二进制代码构建好以后,开发h饿测试人员很少会协调一致的努力寻找软件缺陷。我们引入软件缺陷并让它 们自由蔓延,直到在开发周期的最后阶段,依靠那些善于在软件开发后期寻找软件缺陷的英雄们,将我们带出困境。

  作为软件测试人员,我们提供了宝贵的软件缺陷寻找和分析技术,所以在今后,我们所要做的是,在软件开发周期中尽早应用这些技术,远远早于我们目 前所处的阶段,我预见有两种主要的方法会帮助我们达到这个目的。一个是不等二进制运行代码构建好,直接将测试应用于软件开发周期的早期开发阶段。第二个是 尽早地构建二进制运行代码,使我们能够尽快地测试。

  下面让我们从’早期开发阶段测试‘开始,就这两种方法逐个进行讨论。在开发周期的后期英雄主义阶段里,我们运用所有的软件缺陷寻找方法,在可运 行的二进制代码中根据发布的接口寻找软件缺陷。我们把编译好的二进制代码、程序集合和字节代码等拿来放到测试沙袋中,用数据和输入反复击打它,直到我们挖 出足够的软件缺陷病确定待测目标的质量足够好(在将来的博客里,我也许会介绍测量和发布标准)。但是为什么要等到二进制代码准备好呢?为什么我们不能应用 这些测试技术在产品架构阶段?……或是分析用户需求和场景阶段?……或是规范和设计阶段?莫非在过去半个世纪积累起来的所有测试技术,测试工艺和测试智 慧,只能用于软件运行阶段?为什么系统架构不能用同样的方法进行测试呢?嗯,答案是没有好的理由让我们不这样去做。事实上,我认为微软有很多先进的团队的 确将测试技术应用到早期开发阶段,在将来我们会找到这样做的系统方法。测试将会开始于,不像现在这样,当某样东西可测的时候,而是当某样东西出现了而需要 测试的时候。这是一个微妙但是重要的区别。

  “尽早构建二进制运行代码”是要讨论的第二部分,但是这样做代表我们需要克服一个技术上的障碍。在2008年的时候,我们一个接一个的编写软件 模块,如果缺乏所有模块中的其中之一,我们就不能构建出一个整体。这意味着,测试工作必须等到所有的模块完成到某种程度才能进行。软件缺陷可以存活几天或 者几周,知道测试开始并发现它们。我们可以用虚拟的模块来替代哪些部分完成的模块吗?或是用适配器来模仿外部的行为?我们能够构建通用的变色龙组件,让它 改变自己的行为去配合它们(暂时)嵌入的系统?我预测会的……因为我们必须这样做。虚拟组件和变色龙组件将可以使测试人员,在紧接着一个软件缺陷产生出来 后,就施展它们的检测手艺。这些软件缺陷将很少有机会在露面之后还能劫后余生。

  测试工作相当重要,不要等到开发周期结束才开始进行。是的,目前交互式开发和敏捷开发较早地创建了可测试代码(尽管功能较小,功能不完整),但 是发布软件后,我们仍然有很多的软件缺陷。我们现在所做的远远不够。未来必定会将测试应用到软件开发的早期阶段,使我们在代码完全建立之前就搭建好可行 的、可测试的环境。

  本文摘自James Whittaker所著《探索式软件测试》附录3

posted @ 2013-01-04 13:30 顺其自然EVO 阅读(260) | 评论 (0)编辑 收藏

Jmeter基础之——jmeter基础概念

 JMeter 介绍:一个非常优秀的开源的性能测试工具。

  优点:你用着用着就会发现它的重多优点,当然不足点也会呈现出来。

  从性能工具的原理划分:

  Jmeter工具和其他性能工具在原理上完全一致,工具包含4个部分:

  (1)负载发生器:用于产生负载,通常以多线程或是多进程的方式模拟用户行为。

  (2)用户运行器:通常是一个脚本运行引擎,用户运行器附加在线程或进程上,根据脚本要求模拟指定的用户行为。

  (3)资源生成器:用于生成测试过程中服务器、负载机的资源数据。

  (4)报表生成器:根据测试中霍地的数据生成报表,提供可视化的数据显示方式。

  测试计划元件

  --------------------------------------------------------------------------------

  Test Plan (测试计划):用来描述一个性能测试,包含与本次性能测试所有相关的功能。也就说本的性能测试的所有内容是于基于一个计划的。

  下面看一下一个计划下面都有哪些主要的功能模块(右键单击“测试计划”弹出菜单)。

  Threads (Users)线程 用户

  虽然有三个添加线程组的选项,名字不一样, 创建之后,其界面是完全一样的。之前的版本只有一个线程组的名字。现在多一个setUp theread Group 与terDown Thread Group

  1)setup thread group

  一种特殊类型的ThreadGroup的,可用于执行预测试操作。这些线程的行为完全像一个正常的线程组元件。不同的是,这些类型的线程执行测试前进行定期线程组的执行。

  2)teardown thread group

  一种特殊类型的ThreadGroup的,可用于执行测试后动作。这些线程的行为完全像一个正常的线程组元件。不同的是,这些类型的线程执行测试结束后执行定期的线程组。

  可能你还是不太理他们与普通的线程组有什么不同。 如果您用过junit,想必你不会对setup ,teardown这2个字眼陌生。 即时每用过,也没关系。 熟悉loadrunner的应该知道,loadrunner的脚本除了action里是真正的脚本核心内容,还有初始化“环境”的初始化脚本和测试完毕后对应的清除信息的脚本块。 那么这里 setup thread group 和 teardown thread group 就是分别指这两部分。  其实从本质上来看,他们并没有什么不同。

  3)thread group(线程组)

  这个就是我们通常添加运行的线程。通俗的讲一个线程组,可以看做一个虚拟用户组,线程组中的每个线程都可以理解为一个虚拟用户。线程组中包含的线程数量在测试执行过程中是不会发生改变的。

 测试片段(Test Fragment)

  测试片段是在2.5版本之后新加的一个选项。

  测试片段元素是控制器上的一个种特殊的线程组,它在测试树上与线程组处于一个层级。它与线程组有所不同,因为它不被执行,除非它是一个模块控制器或者是被控制器所引用时才会被执行。

  控制器

  JMeter有两种类型的控制器:取样器(sample)和逻辑控制器(Logic Controller),用这些原件来驱动处理一个测试。

  取样器(Sampler)

  取样器(Sample)是性能测试中向服务器发送请求,记录响应信息,记录响应时间的最小单元,JMeter 原生支持多种不同的sampler,如 HTTP Request Sampler、FTP  Request Sample、TCP  Request Sample、JDBC Request Sampler 等,每一种不同类型的 sampler 可以根据设置的参数向服务器发出不同类型的请求。(在jmeter 的所有sampler 中,Java Request Sampler 和 Beanshell Request Sampler 是两种特殊的可定制的 Sampler,后面会深入讨论。)

  逻辑控制器(Logic Controller)

  逻辑控制器,包括两类无件,一类是用于控制test plan 中 sampler 节点发送请求的逻辑顺序的控制器,常用的有 如果(If)控制器、switch Controller 、Runtime Controller、循环控制器等。另一类是用来组织可控制 sampler 来节点的,如 事务控制器、吞吐量控制器。

 配置元件(Config Element)

  配置元件(config element)用于提供对静态数据配置的支持。CSV Data Set config 可以将本地数据文件形成数据池(Data Pool),而对应于HTTP Request Sampler和 TCP Request Sampler等类型的配制无件则可以修改Sampler的默认数据。(例如,HTTP Cookie Manager 可以用于对 HTTP Request Sampler 的cookie 进行管理)

  定时器(Timer)

  定时器(Timer)用于操作之间设置等待时间,等待时间是性能测试中常用的控制客户端QPS的手端。类似于LoadRunner里面的“思考时间”。JMeter 定义了Bean Shell Timer、Constant Throughput Timer、固定定时器等不同类型的Timer。

  前置处理器(Per Processors)

  用于在实际的请求发出之前对即将发出的请求进行特殊处理。例如,HTTP URL重写修复符则可以实现URL重写,当RUL中有sessionID 一类的session信息时,可以通过该处理器填充发出请求的实际的sessionID 。

  后置处理器(Post Processors)

  用于对Sampler 发出请求后得到的服务器响应进行处理。一般用来提取响应中的特定数据(类似LoadRunner测试工具中的关联概念)。例如,XPath  Extractor 则可以用于提取响应数据中通过给定XPath 值获得的数据。

断言(Assertions)

  断言用于检查测试中得到的相应数据等是否符合预期,断言一般用来设置检查点,用以保证性能测试过程中的数据交互是否与预期一致。

  监听器(Listener)

  这个监听器可不是用来监听系统资源的元件。它是用来对测试结果数据进行处理和可视化展示的一系列元件。 图行结果、查看结果树、聚合报告。都是我们经常用到的元件。

  到此,我们已经简单了解了jmeter的基本组成原件,我们后序的性能测试工作也就是使用这些元件来完成测试任务。

相关链接:

posted @ 2012-12-31 12:52 顺其自然EVO 阅读(2024) | 评论 (0)编辑 收藏

JMeter基础之——录制脚本

JMeter基础之——录制脚本

Jmeter 是一个非常流行的性能测试工具,虽然与LoadRunner相比有很多不足,比如:它结果分析能力没有LoadRunner详细;很它的优点也有很多:

  ● 开源,他是一款开源的免费软件,使用它你不需要支付任何费用,

  ● 小巧,相比LR的庞大(最新LR11将近4GB),它非常小巧,不需要安装,但需要JDK环境,因为它是使用java开发的工具。

  ● 功能强大,jmeter设计之初只是一个简单的web性能测试工具,但经过不段的更新扩展,现在可以完成数据库、FTP、LDAP、WebService等方面的测试。因为它的开源性,当然你也可以根据自己的需求扩展它的功能。

  我觉得它更像一个瑞士军刀,小巧,且功能齐全。初次认识Jmeter的时候,我觉得它不好,是因为相比LR来说,它没有脚本录制功能,也许不是没有,只是我不知道,因为文档上介绍的是这样,我要做一个web性能测试的话,就手动的一个个添加循环控制器、http信息管理头、http请求等等各种元件。如果测试的脚本较多时,这无疑是个体力活。

  Badboy是一款不错web自动化测试工具,利用它来录制脚本,并且录制的脚本可以直接保存为JMeter文件来使用。我无疑给我们带来了很大我方便。

  ----------------------我的环境------------

  Badboy  version 2.1.1

  Apache  JMeter-2.3.4 (需要JDK环境来运行)

  --------------------------------------------

  第一种方法:通过bodboy来录制脚本。

  1、打开人badboy工具,点击工栏目上的红色圆形按钮,在地址栏目中输入被测试项目的地址。

  录制完成后,点击工具栏旁边黑色按钮,结束录制。

  选择“文件”--àExport to Jmeter…

  2、打开Jmeter工具,选择“文件”-->“打开”选择刚才保存的文件(.jmx类型),将文件导入进来了。



  第二种方法,通过JMeter自身设置来录制脚本。

  这种方法是我才发现的(鄙视一下自己的无知,嘻嘻~!),觉得方法比较简单。

  1、打开JMeter工具

  创建一个线程组(右键点击“测试计划”--->“添加”---->“线程组”)

  创建一个http代理服务器(右键点击“工作台”--->“添加”--->“非测试元件”--->“http代理服务器”)

  完整的设置参照下图:

  2、下面来设置一下IE浏览器

  IE--->“internet属性”--->“连接”--->“局域网设置”

  设置为本机IP就可以了,注意端口号要与Jmeter上的端口号一致。默认都是8080端口。

  3、现在点击jmeter上的“启动”按钮,打开浏览器输入需要录制web项目地址,jmeter会自动记录你IE所访问的页面。

  PS:第二种方法是我刚才知道的一种,关于这两种方法哪个更好,现在还不知道,但第二方法有通过IE浏览器辅助的,我想可能只要IE能打开的,它都能记录,但它录制的脚本看上去比较乱(感觉上)

  还就是http代理服务器的设置,(比如:分组:每一个组放入一个新的服务器---只有这一个选项才能正常录制),有时间再仔细比较一下两种方法的不同之处。


posted @ 2012-12-31 12:48 顺其自然EVO 阅读(1083) | 评论 (0)编辑 收藏

JMeter基础之——一个简单的性能测试

  上一节中,我们了解了jmeter的一此主要元件,那么这些元件如何使用到性能测试中呢。这一节创建一个简单的测试计划来使用这些元件。该计划对应的测试需求。

  1)测试目标网站是fnng.cnblogs.com  和 tt-topia.rhcloud.com

  2)测试目的是该网站在负载达到20 QPS 时的响应时间。

  QPS 解释

  QPS:Query Per Second 每秒查询率。是一台查询服务器每秒能够处理的查询次数。在因特网上,作为域名系统服务器的机器的性能经常用每秒查询率来衡量。

  为了达成预期的测目的,需要需要在jmeter中建立一个测试计划。因为本次测试仅要求完成对fnng.cnblogs.com  和 tt-topia.rhcloud.com 两个博客首页请求,因此只需要使用HTTP Request Sampler 即可。

  建立测试计划

  启动jmeter后,jmeter会自动生成一个空的测试计划,用户可以基于该测试计划建立自己的测试计划。

  添加线程组

  --------------------------------------------------------------------------------

  一个性能测试请求负载是基于一个线程组完成的。一个测试计划必须有一个线程组。测试计划添加线程组非常简单。在测试计划右键弹出下拉菜单(添加-->Threads(Users)--->线程组)中选择线程组即可。

  jmeter中 每个测试计划至少需要包含一个线程组,当然也可以在一个计划中创建多个线程组,那么多个线程组之间又会怎样的顺序执行(串行还是并行)?在测试计划下面多个线程是并行执行的,也就是说这些线程组是同时被初始化并同时执行线程组下的Sampler的。

  线程组主要包含三个参数:线程数、准备时长(Ramp-Up Period(in seconds))、循环次数。

  线程数:虚拟用户数。一个虚拟用户占用一个进程或线程。设置多少虚拟用户数在这里也就是设置多少个线程数。

  准备时长:设置的虚拟用户数需要多长时间全部启动。如果线程数为20 ,准备时长为10 ,那么需要10秒钟启动20个线程。也就是每秒钟启动2个线程。

  循环次数:每个线程发送请求的次数。如果线程数为20 ,循环次数为100 ,那么每个线程发送100次请求。总请求数为20*100=2000 。如果勾选了“永远”,那么所有线程会一直发送请求,一到选择停止运行脚本。

  设置合理的线程数对于能否达到测试目标有决定性的影响。在本例中,要求得到网站首页在20 QPS 负载情况下的响应时间,如果如果线程数量设置的过小,则很可能无法达到设定的QPS要求。另外,设置合理的循环次数也很重要,除了上面介绍的固定循环次数与永远外;也可以灵活的选择设定测试运行时间。勾选“调度器”,进行调度器配置。

  添加HTTP请求

  --------------------------------------------------------------------------------

  添加完成线程组后,在线程组上右键菜单(添加--->Sampler--->HTTP请求)选择HTTP请求。对于jmeter来说,取样器(Sampler)是与服务器进行交互的单元。一个取样器通常进行三部分的工作

  向服务器发送请求

  记录服务器的响应数据

  记录相应时间信息


  一个HTTP请求有着许多的配置参数,下面将详细介绍:

  名称:本属性用于标识一个取样器,建议使用一个有意义的名称。

  注释:对于测试没有任何作用,仅用户记录用户可读的注释信息。

  服务器名称或IP:HTTP请求发送的目标服务器名称或IP地址。

  端口号:目标服务器的端口号,默认值为80 。

  协议:向目标服务器发送HTTP请求时的协议,可以是http或者是https ,默认值为http 。

  方法:发送HTTP请求的方法,可用方法包括GET、POST、HEAD、PUT、OPTIONS、TRACE、DELETE等。

  Content encoding:内容的编码方式,默认值为iso8859

  路径:目标URL路径(不包括服务器地址和端口)

  自动重定向:如果选中该选项,当发送HTTP请求后得到的响应是302/301时,JMeter 自动重定向到新的页面。

  Use keep Alive:当该选项被选中时,jmeter 和目标服务器之间使用 Keep-Alive方式进行HTTP通信,默认选中。

  Use multipart/from-data for HTTP POST:当发送HTTP POST 请求时,使用Use multipart/from-data方法发送,默认不选中。

  同请求一起发送参数:在请求中发送URL参数,对于带参数的URL ,jmeter提供了一个简单的对参数化的方法。用户可以将URL中所有参数设置在本表中,表中的每一行是一个参数值对(对应RUL中的 名称1=值1)。

  同请求一起发送文件:在请求中发送文件,通常,HTTP文件上传行为可以通过这种方式模拟。

  从HTML文件获取所有有内含的资源:当该选项被选中时,jmeter在发出HTTP请求并获得响应的HTML文件内容后,还对该HTML进行Parse 并获取HTML中包含的所有资源(图片、flash等),默认不选中,如果用户只希望获取页面中的特定资源,可以在下方的Embedded URLs must match 文本框中填入需要下载的特定资源表达式,这样,只有能匹配指定正则表达式的URL指向资源会被下载。

  用作监视器:此取样器被当成监视器,在Monitor Results Listener 中可以直接看到基于该取样器的图形化统计信息。默认为不选中。

  Save response as MD5 hash?:选中该项,在执行时仅记录服务端响应数据的MD5值,而不记录完整的响应数据。在需要进行数据量非常大的测试时,建议选中该项以减少取样器记录响应数据的开销。

  在这里我们添加两个HTTP请求,分别用于对fnng.cnblogs.com  和 tt-topia.rhcloud.com发送请求。











 设置QPS限制

  --------------------------------------------------------------------------------

  本次性能测试的需求中提到测试的目的是“了解博客的首页在负载达到20 QPS时的响应时间”,因此需要控制向博客首页发送请求的负载为20QPS。

  一种可行的方法是逐步调整测试计划中的线程计算的数量以及为取样器(Sampler)添加定时器(Timer),以使HTTP取样器发出的请求的QPS保持在20个左右。但这种方法耗时耗力,需要经过多次尝试才能达到;另一方法,完全通过设置定时器来控制QPS,一旦取样器的响应时间发生改变(网络环境发生改变),就需要重新调整定时器的等待时间。

  Jmeter提供了一个非常有用的定时器,称为Constant Throughput Timer (常数吞吐量定时器),该定时器可以方便地控制给定的取样器发送请求的吞吐量。

  右键点击fnng.cnblogs.com ,弹出菜单(添加--->定时器--->Constant Throughput Timer)选择Constant Throughput Timer

  Constant Throughput Timer 的主要属性介绍:

  名称:定时器的名称

  Target throughput(in samples per minute):目标吞吐量。注意这里是每分钟发送的请求数,因此,对应测试需求中所要求的20 QPS ,这里的值应该是1200 。

  Calculate Throughput based on:有5个选项,分别是:

  This thread only:控制每个线程的吞吐量,选择这种模式时,总的吞吐量为设置的 target Throughput 乘以矣线程的数量。

  All active threads:设置的target Throughput 将分配在每个活跃线程上,每个活跃线程在上一次运行结束后等待合理的时间后再次运行。活跃线程指同一时刻同时运行的线程。

  All active threads in current thread group:设置的target Throughput将分配在当前线程组的每一个活跃线程上,当测试计划中只有一个线程组时,该选项和All active threads选项的效果完全相同。

  All active threads (shared ):与All active threads 的选项基本相同,唯一的区别是,每个活跃线程都会在所有活跃线程上一次运行结束后等待合理的时间后再次运行。

  All cative threads in current thread group (shared ):与All active threads in current thread group 基本相同,唯一的区别是,每个活跃线程都会在所有活跃线程的上一次运行结束后等待合理的时间后再次运行。

  如上图,该元件仅作用于fnng.cnblogs.com ,设置定时器的Target throughput为1200/分钟(20 QPS),设置Calculate Throughput based on 的值为All active threads 。

  当然,Constant Throughput Timer只有在线程组中的线程产生足够多的request 的情况下才有意义,因此,即使设置了Constant Throughput Timer的值,也可能由于线程组中的线程数量不够,或是定时器设置不合理等原因导致总体的QPS不能达到预期目标。




 添加监听器(Listener)

  --------------------------------------------------------------------------------

  脚本的主要部分设置完成后,需要通过某种方式获得性能测试中的测试结果,在本例中,我们关心的是请求的响应时间。

  Jmeter 中使用监听器元件收集取样器记录的数据并以可视化的方式来呈现。Jmeter有各种不同的监听器类型,因为上HTTP请求,我们可在添加聚合报告,更为直观的查看测试结果。

  添加聚合报告,右键点击线程组,在弹的菜单(添加--->监听器--->聚合报告)中选择聚合报告。

  运行脚本

  --------------------------------------------------------------------------------

  添加完成聚合报告后,我们来运行脚本,稍后介绍聚合报告的参数。

  在运脚本之前,我们来查看一下,各个元件的参数设置:

  ---------------------------------------------------------------

  线程组:

  线程数:20

  准备时长:10

  循环次数:10

  ---------------------------------------------------------------

  HTTP请求:

  名称:fnng.cnblogs.com。

  服务器名称或IP:fnng.cnblogs.com

  端口号:80

  Implementation:java

  协议:http

  方法:GET

  路径:/

  ---------------------------------------------------------------

  常数吞吐量定时器:

  Target throughput(in samples per minute):1200.0

  Calculate Throughput based on :All active threads

  ---------------------------------------------------------------

  点击工具栏上的运行按钮,或者点击菜单栏“ 运行--->启动 ” 或者使用快捷键ctrl+r 来运行程序。

  聚合报告分析

  --------------------------------------------------------------------------------

  查看聚合报告的运行结果:

  OK!到此一次完整的性能测试结束,如果你从中有所收获,推荐一记~!

相关链接:

JMeter基础之—录制脚本

Jmeter基础之——jmeter基础概念




posted @ 2012-12-31 12:47 顺其自然EVO 阅读(2745) | 评论 (2)编辑 收藏

仅列出标题
共394页: First 上一页 275 276 277 278 279 280 281 282 283 下一页 Last 
<2025年4月>
303112345
6789101112
13141516171819
20212223242526
27282930123
45678910

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜