Let's Go!

淘宝测试blog推荐_01

上一篇 / 下一篇  2011-07-29 16:25:43 / 个人分类:性能测试理论

1.  我眼中的性能测试工程师

许久以前就答应悟石要分享一下我眼中的性能测试工程师,结果托来托去快托过年了,囧…

想想来杭州有半年了,也对目前主站的性能评测团队工作模式有些许了解了,再加上以前在上家雇主也做过几年自认还算很有技术含量的性能测试工作,我想我还算有点资格说的吧:)

性能测试说的装B点儿,其实没啥,就是和Response Time(或者说latency)、throughput(也可以说capacity)以及scalability打交道。弄懂了这三个要素,应该就算是一个合格的性能测试工程师了。

当然,我不会装B,只是一介武夫,所以我接下来只想从偏技术层面聊聊我心目中真正的主站性能测试工程师是啥样的:

  1. 大局观。性能测试工程师一定要有系统化的思维,要站在整个系统测试的角度看问题。一个优秀的性能工程师必须要有相当的知识广度。否则在测试期间,你必须依赖外界援助(比如DBA,Dev或OPS)来协助,效率不高,更关键的是可能会被误导,漏掉很多性能BUG。我常常看到组里的童鞋们在压测时一看到TPS降了,就死盯着应用,就着急的去分析线程或做CPU Profiling。找不到原因后有时问到我时,我习惯的第一句总是 你看过DB么?确认DB端正常么?看过压测客户端么?确认压测端正常么? 我个人意见:不要老凭经验,一有重复症状就思维定式;一定要坚持先从全局看问题,隔离到是应用层面、DB层面抑或是压测客户端层面后再进一步深入定位问题。
  2. 技能深度。在性能测试工具方面有自己独特的理解;同时也应该在操作系统数据库、应用程序等方向的配置管理与调优方向上非常的熟悉。
  3. 敏感。这个一方面是天赋,一方面是经验积累吧, 很多隐蔽的性能问题确实是需要丰富的经验才能发现,极容易漏掉:)
  4. 兴趣。  其实这条才是最重要的^-^

如果说具体些通俗些,我眼里主站真正的性能工程师是这样的:

  1. 熟悉Java(包括JVM内在机理)/c/c++。理由很简单,主站大部分的外围应用和中间件都是JAVA写的,底层核心系统是c/c++写的。
  2. 精通linux管理和shell编程。理由更简单,我一直觉得,shell熟练与否非常大程度决定了一个工程师的工作效率。
  3. 对数据库管理和性能优化有自己的实践和心得(数据库永远是个性能要点)
  4. 精通某一个性能测试工具。不止是使用,更包括原理,如何改造扩展。
  5. 熟悉linux kernel的实现(比如内存管理、文件系统、系统调用… )。 这条感触在最近两个月特别深,可能是受到褚霸、子团等大侠们的影响吧,如果不熟悉kernel,确实很难在底层系统的性能测试上有所真正建树。其实这块也算是整个质量保证部的技术短板吧,现在淘宝的linux内核组都是自测+他人review的形式,如果。。。^-^
  6. 了解常见硬件,特别是存储相关。这块主要是受国外Percona公司的Peter和Vadim影响,他们能成为世界公认的mysql性能专家,他们熟悉mysql源码当然很重要,但也与他们那非常渊博的底层硬件知识是分不开的。

当然以上都是我个人意见,从我自己的角度出发看的问题。其实性能测试还有很多领域,比如前端性能测试这块,我是小白,就不发表任何相关意见了^-^    但说到底,做性能这块关键一是经验积累二是掌握相关底层技术

至今还记得百淘65期让我最为难忘的细节,达人青云在分享他的牛P经历时总结到的:

  • 结合优势,做别人做不了的
  • 发现问题,做别人没做过的
  • 主动出击,做别人不爱做的

希望自己能一直铭记这三句话,有天能成为一个真正的性能工程师

VN:F [1.9.7_1111]

转载务必注明出处Taobao QA Team,原文地址:http://qa.taobao.com/?p=8308

 

2. 项目性能测试体验感想二

最近有幸和云帅参与了新江湖的性能测试, 这个项目中,由于测试时间紧,性能点多,我们从开发提交测试后就进行性能测试。提早介入测试导致我们后来遇到很多问题。我主要的工作是协助云帅,申请性能测试服务器,验证搭建好的性能测试环境和功能,准备性能测试数据,后期我参与了好友最近更新的相册这个性能点的执行,下面说下具体是怎么做上面的事情的:

(1)申请性能测试服务器:
先找总的开发负责人给出本阶段性能点所需要信息,包括 性能点,服务名,Hsf版本号,数据源,data-pool设置,jdk版本号,apache版本号,jboss版本号,jvm设置,代码库路径,压测页面链接,依赖系统和该性能点对应的开发负责人。收集完这些信息后我们可以向悟石他们申请机器啦。申请时除了上面最后三点,其他内容都需要提供。这样做是为了之后让scm参照上面的信息部署环境。

(2)验证搭建的环境/功能:
1、验证jdk、apache、jboss的版本:可以通过拷贝文件valid-env,执行check.sh来快速验证jdk、apache、jboss的版本。或者通过如下的方法来依次验证。
a、jdk版本查看 先通过jbosscle文件查找到使用的JAVA_HOME地址,然后根据目录查找 /opt/taobao/java/bin/java -version 或者 /opt/taobao/java/bin/java1 -version;
b、apache版本查看 /opt/taobao/install/httpd/bin/httpd -version;
c、jboss版本查看 jboss启动日志jboss_stdout.log中有,只要看前面几行就能查找到。
2、证数据库配置:数据库的配置,一般存放在应用下的conf目录下,orcle-***-ds.xml/mysql-***-ds.xml文件里。检查它是否连接了正确的数据库schema,连接数是否正确。
3、查看apache的访问日志是否屏蔽掉。查看conf目录下,httpd.conf文件里——CustomLog这个配置项。
4、验证功能:需要确保所要测试的性能点的功能及相关功能正确。执行几个主流程查看或者跑一下接口是否通。

(3)准备测试数据:
1.向DBA讨教了如何快速准备大量的性能测试数据。两种方法。写存储或者设置autoincrement。我这次主要用的是后者。将表的主键设置autoincrement,这样可以通过insert into 表(字段1,字段2…) select value1,value2… from 表 执行一次可以成倍增长当前的数据。这种方法简单快捷,如果只是为了纯粹增加表的数据流这个方法还是比较好的。当然除了数据库的方法还可以通过接口去插数据,在lr中执行下也是不错的选择。
2.性能测试环境下什么数据也没有,所以通过导入功能测试环境的数据来充当,mysql工具中有一个很好的功能:可以将功能测试数据库库的表结构和数据复制到性能测试数据库,如果性能测试数据库中已经存在该表,就drop掉该表,执行速度很快,大大方便我们准备数据。推荐大家用SQLyog Enterprise这个工具,真的不错。方法如下:打开mysql的数据库,连接到功能测试库上,点击File——New Conections,连接到性能测试库上,选择你要操作的表,右击选择第二项——Copy Table To Diffierent Host/Database,在界面中左边是源数据库,也就是我们的功能测试数据库,选择你要复制的表,支持多选,右边选择目标数据库,也就是我们的性能测试数据库及对应的用户,如果表已经存在,勾选选项:Drop table if exists in target ,具体要拷贝表结构和数据或者只是表结构都可以自己选择,最后点击copy,数据库表结构和数据很快可以复制完。

(4)录制脚本:
淘江湖二期很多页面是采用了异步方式调用,所以录制完一个页面后,通过抽取每个请求作为一个脚本。接口测试这块采用http的方式去模拟测试,这样方式最大的好处是脚本准备比较方便。

(5)测试执行:
1、一个页面通过加载该页面所有的异步请求,逐步增加各个脚本的并发用户数,调整并发用户数,查看是否满足预期的tps。
2、测试过程中时刻关注lr的运行情况,曲线有没有波动很大,几个日志信息,debug日志,超时日志和velocity日志,是否有大量日志出现。监控java虚拟内存是否正常释放,曲线是否平稳,而不是往上的趋势。一般如果有问题的话,刚开始运行脚本就会出现频繁报错,这时需要马上停下来查看问题原因。排查原因有很多,由于我们介入较早,有一些是因为数据库表结构没有建索引,或者是应用的版本没更新导致(初期bug比较多,版本经常更新),所以经过这次测试,深刻体会到性能测试的前提需要在sql审核通过,索引加好,功能比较稳定的前提下进行,也就是功能测试第二阶段开始,此时功能相对稳定,表结构也不会怎么变化,会少走很多弯路。
3.由于这次页面性能测试依赖的应用比较多,最多有用到13台应用服务器,当测试某个性能点的时候,需要查看与该应用交互的应用的情况,可以用netstat -nal命令。查出来后,监控这些相关的服务器,cpu,load,日志情况等。
4.用lr监控cpu这些数据时发现有一台服务器监控到的cpu有问题,空闲状态cpu就已经达到60%了,具体原因也不清楚,所以换了方式采用我们这边的一个监控cpu和load的shell脚本来做。

(6)关于性能测试计划:这次测试有11个性能点,6个接口和5个页面,计划中根据测试优先级高低分三个阶段进行,分阶段搭建测试环境和准备数据和脚本,先接口后页面的顺序执行。

(7)关于性能测试日报:日报中主要记录目前所处的测试阶段,当天的测试工作,测试结果和结果分析,BugList,问题和风险,以及明天的计划。

最后非常非常感谢云帅,像老师一样,非常细心和耐心,教我很多很多,让我受益很多很多,更让我体会到了一个优秀的性能测工程师认真严谨的工作态度。

VN:F [1.9.7_1111]

转载务必注明出处Taobao QA Team,原文地址:http://qa.taobao.com/?p=3676

 

3. TPS真的重要吗

TPS 每秒成功事务数,做过性能测试的人都知道这个词,那么TPS真的重要么,除了它我们就不需要关注其它的指标了吗?
带着疑问,我们一起看一下这次的性能测试我们的过程,我们先是通过线上的访问统计整理出高峰时段的访问量,然后经过算出每台机器的访问量,把这个访问量作为目标TPS,测试过程就是验证系统能否达到这个目标。
然而,线下测试达到目标后,系统上线却出现了性能问题,而 TPS并没有线下测试的高,认真分析后,发现问题在于,我们测试的场景还是与线上有很大的差异,线上是很多Client请求造成的压力,而线下测试Client数量去只有一台,虽然并发请求的量可能相同,可对系统造成的压力去有很大的不同,为什么压力不同,线上的情况就是一个有力的证明,探究原因,应有不少,比如线上测试时,单台client自身压力比较大,对服务器压力有影响,1台Client并发40个请求与10台Client并发4个请求对服务器进行施压的效果一定是不同的。
总结起来,我感觉性能测试并不是那么简单,简单的只关注TPS这一个指标,应做到的是尽可能符合现实的场景,综合考虑各个关键指标。

VN:F [1.9.7_1111]

转载务必注明出处Taobao QA Team,原文地址:http://qa.taobao.com/?p=3784

 

4. 性能测试总结

加入底层平台测试大概有一年了,接触了比较多的项目,做了各种测试,其中觉得最难做得就是性能测试。曾经迷茫过、曾经犯过错、曾经失败返工过,尽管底层平台系统的测试产品业务很如此的单纯。深知性能测试的博大,把自己的一点小小经验整理下,让自己和别人以后少走些弯路。
要做好性能测试首先要明确性能测试的目标。性能测试主要目标是发现系统的瓶颈,找出系统的性能基线,对系统进行调优,确认所测系统是否满足需求方的性能要求。有了准确的目标,性能测试才能测试准确。
产品性能测试通常粗的分,我会将性能测试分为两类:可靠性测试(压力测试、负载测试等)和性能测试。这两种测试有很多的不同点:
1)可靠性测试往往模拟的用户的使用情况,强调的为时间的延续性,要求产品没有不可接受的失败。
2)性能测试往往需要和硬件条件联系在一起,寻找性能的最好发挥以及最优的方案
通常性能测试需要在产品设计时就要进行简单性能测试,以对产品进行性能初期评估和调优,早于可靠性测试。同时在系统稳定时,常常还需要做详细的性能测试,以给应用方以数据参考。
那如何做性能测试那?
1) 性能测试应该早期就积极介入。介入代码审查和分析性能目标,多提出疑问,早期发现潜在的性能问题
2) 性能测试考虑全局,他是一个系统的测试。需要在产品的每个部件都做了一个测试,并全部成功后才开始系统测试执行。需要考虑多种因素:环境的、硬件的、软件的等等。
3) 测试前一定要检查确认配置。参数一定要配置对,否则测试无效。最好对于每个测试都有一个checklist,每次检查前都一一检查。这一步骤一定不可以省略,并需要被开发review。
4) 数据预热和数据准备很关键。一开始系统并不是一个干净的环境。我们需要在性能测试开始前预存一定的数据,并且让其有个增量。而且也要考虑到哪些方面数据多少(要更具实际情况)。
5) 准备测试脚本和工具要考虑实际情况。比如人的思考时间,场景的设计,不同操作的比例,数据的随机性等都要仔细设计,最和可以开发以及应用方进行讨论和确认。
6) 测试执行前一定要确保服务器独占,执行中如果是5-7天的测试,最好拿出一天先跑一个一天压力不高的测试,潜在一天发现可发现的问题。
7) 多种测试结果的分析发现问题。
a) Log日志的分析
b) 系统状态的分析
c) 数据一致性的分析
性能测试需要长时间的经验积累,我知道的只是些皮毛,后面还会继续探索,喜欢性能测试并将会在实践中不断积累和成长

VN:F [1.9.7_1111]

转载务必注明出处Taobao QA Team,原文地址:http://qa.taobao.com/?p=9339

 

 

 

5. 服务器性能测试典型工具介绍 性能测试工具

 

服务器性能测试典型工具介绍 性能测试工具

众所周知,服务器是整个网络系统和计算平台的核心,许多重要的数据都保存在服务器上,很多网络服务都在服务器上运行,因此服务器性能的好坏决定了整个应用系统的性能。

   现在市面上不同品牌、不同种类的服务器有很多种,用户在选购时,怎样从纷繁的型号中选择出所需要的,适合于自己应用的服务器产品,仅仅从配置上判别是不 够的,最好能够通过实际测试来筛选。而各种的评测软件有很多种,你应该选择哪个软件测试?下面就介绍一些较典型的测试工具:

  (一)服务器整机系统性能测试工具

  一台服务器系统的性能可以按照处理器、内存、存储、网络几部分来划分,而针对不同的应用,可能会对某些部分的性能要求高一些。

  Iometer(www.iometer.org):存储子系统读写性能测试

   Iometer是Windows系统下对存储子系统的读写性能进行测试的软件。可以显示磁盘系统的最大IO能力、磁盘系统的最大吞吐量、CPU使用率、错误信息等。用户可以通过设置不同的测试的参数,有存取类型(如sequential ,random)、读写块大小(如64K、256K),队列深度等,来模拟实际应用的读写环境进行测试。

  Iometer操作简单,可以录制测试脚本,可以准确有效的反映存储系统的读写性能,为各大服务器和存储厂商所广泛采用。

  Sisoft Sandra(www.sisoftware.co.uk):WINDOWS下基准评测

  SiSoft发行的Sandra系列测试软件是Windows系统下的基准评测软件。此软件有超过三十种以上的测试项目,能够查看系统所有配件的信息,而且能够对部分配件(如CPU、内存、硬盘等)进行打分(benchmark),并且可以与其它型号硬件的得分进行对比。另外,该软件还有系统稳定性综合测试、性能调整向导等附加功能。

  Sisoft Sandra软件在最近发布的Intel bensley平台上测试的内存带宽性能并不理想,不知道采用该软件测试的FBD内存性能是否还有参考价值,或许软件应该针对FBD内存带宽的测试项目做一个升级。

  Iozone(www.iozone.org):linux下I/O性能测试

  现在有很多的服务器系统都是采用linux操作系统,在linux平台下测试I/O性能可以采用iozone。

  iozone是一个文件系统的benchmark工具,可以测试不同的操作系统中文件系统的读写性能。可以测试Read, write, re-read, re-write, read backwards, read strided, fread, fwrite, random read, pread ,mmap, aio_read, aio_write 等等不同的模式下的硬盘的性能。测试所有这些方面,生成excel文件,另外, iozone还附带了用gnuplot画图的脚本。

  该软件用在大规模机群系统上测试NFS的性能,更加具有说服力。

  Netperf(www.netperf.org):网络性能测试

   Netperf可以测试服务器网络性能,主要针对基于TCP或UDP的传输。Netperf根据应用的不同,可以进行不同模式的网络性能测试,即批量数 据传输(bulk data transfer)模式和请求/应答(request/reponse)模式。Netperf测试结果所反映的是一个系统能够以多快的速度向另外一个系统发送数据,以及另外一个系统能够以多块的速度接收数据。

  Netperf工具以client/server方式工作。server 端是netserver,用来侦听来自client端的连接,client端是 netperf,用来向server发起网络测试。在client与server之间,首先建立一个控制连接,传递有关测试配置的信息,以及测试的结果;在控制连接建立并传递了测试配置信息以后,client与server之间会再建立一个测试连接,用来来回传递着特殊的流量模式,以测试网络的性能。

  对于服务器系统来说,网络性能显得尤其重要,有些服务器上为了节省成本,采用了桌面级的网络芯片,性能怎样,用这个软件一测便知了。

  以上介绍的这几款测试工具都是可以免费从网上下载的非商业软件,但是其测试结果和认可程度均是为大多数使用者所认同的。你可以根据自己的应用需求选择不同的软件进行测试。

(二)针对应用的测试工具

   随着web应用的增多,服务器应用解决方案中以Web为核心的应用也越来越多,很多公司各种应用的架构都以web应用为主。一般的web测试和以往的应 用程序的测试的侧重点不完全相同,在基本功能已经通过测试后,就要进行重要的系统性能测试了。系统的性能是一个很大的概念,覆盖面非常广泛,对一个软件系 统而言包括执行效率、资源占用率、稳定性、安全性、兼容性、可靠性等等,以下重点从负载压力方面来介绍服务器系统性能的测试。系统的负载和压力需要采用负载测试工具进行,虚拟一定数量的用户来测试系统的表现,看是否满足预期的设计指标要求。负载测试的目标是测试当负载逐渐增加时,系统组成部分的相应输出项,例如通过量、响应时间、CPU负载、内存使用等如何决定系统的性能,例如稳定性和响应等。

  负载测试一般使用工具完成,有LoadRunner,Webload,QALoad等,主要的内容都是编写出测试脚本,脚本中一般包括用户常用的功能,然后运行,得出报告。

  使用压力测试工具对web服务器进行压力测试。测试可以帮助找到一些大型的问题,如死机、崩损、内存泄漏等,因为有些存在内存泄漏问题的程序,在运行一两次时可能不会出现问题,但是如果运行了成千上万次,内存泄漏得越来越多,就会导致系统崩滑。

  Loadrunner:预测系统行为和性能的负载测试工具

  目前,业界中有不少能够做性能和压力测试的工具,Mercury(美科利)Interactive公司的LoadRunner是其中的佼佼者,也已经成为了行业的规范,目前最新的版本8.1。

  LoadRunner 是一种预测系统行为和性能的负载测试工具,通过模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题,LoadRunner 能够对整个企业架构进行测试,LoadRunner 适用于各种体系架构,能支持广范的协议和技术(如Web、Ftp、Database等),能预测系统行为并优化系统性能。它通过模拟实际用户的操作行为和实行实时性能监测,来帮助您更快的查找和发现问题。Loadrunner是一个强大有力的压力测试工具,它的脚本可以录制生成,自动关联。测试场景面向指标,实现了多方监控。而且测试结果采用图表显示,可以自由拆分组合。

文章来源于领测软件测试网 http://www.ltesting.net/

VN:F [1.9.7_1111]

转载务必注明出处Taobao QA Team,原文地址:http://qa.taobao.com/?p=4091


TAG:

mylin的个人空间 引用 删除 mylin   /   2014-07-14 00:27:59
赞一个
 

评分:0

我来说两句

Open Toolbar