这些年,我的软件性能测试

很早之前就说好好总结一下自己的职业,一直忙于一些乱七八糟的事,现在这个时间难得偷得空闲,趁着有感觉,赶紧进行敲下“这些年,我的软件性能测试”来祭奠我这IT行业的几年......

  记得第一次做性能测试项目,心情是忐忑的,觉得,性能测试,做不好就背包滚蛋了都可能,不过当时带我做项目的老大给了我很大的信心和支撑,我在做的过程中,遇到的疑问,他都会耐心的给我以解答或者给我一个方向,让我去前行,解决,随着一个个问题的出现和解决,自己每一天也过的感觉很充实。也是在这个项目里面,这个老大告诉我,作为性能测试,如果仅仅只会用工具,这个只能算初级性能测试工程师,重要的还是设计能力,思想为王,于是,我从他口里听到了一个词:性能建模和容量规划......当时,我真心的不知道这个是什么,有的就是对老大的崇拜和对未来的路如何走的思考......

  第一个性能项目,如期完成,对google的GA插入的js代码进行测试,验证该js注入website之后,对性能的影响(因本身js需要做下载和数据上报,中间的过程需要看下情况如何),测试过程中,发现会有大部分的用户响应时间比较长,当时就是按照2-5-10法则来做的响应时间是否合理(想想,这个就是传说中的拍脑袋吧呵呵),想到该如何分析是哪里原因呢?第一次做性能测试,看到结果之后,欣喜的同时更多的是一种忐忑,不知道对着面前的report该如何下手?好在,有老大给予指导,分析了带宽,排除带宽的影响,查看server本身的资源,也无问题,同时细分验证,发现大部分的时间是消耗在server层,于是基于此基础,直接看了下apache(当时我们用的server)的队列等待(当时用的方法很简单,直接ps -ef|grep httpd|wc -l),发现随着虚拟用户的逐步增多,会造成排队的数也越来越多,初步怀疑是配置问题,咨询了运维,apache 的配置没有动,用的默认的配置方式,于是我们提出,需要查看并尝试调整该配置文件。在查看的过程中,参考网上朋友的资源,发现maxclient的确是默认的,修改之后,进行重启,回归,发现问题还是存在,,,难道是别的地方慢?怎么弄呢?这个时候运维告诉我们,apache只修改这个还不够,还需要修改一个隐藏变量,serverlimit,只有修改了它,maxclient修改超过1000的时候才会生效。于是也是瞎子摸象,动手试一试,发现,果真是这里,修改了之后,排队的用户减少了,超过5S以上响应时间的用户百分比也降低,于是开始准备性能测试报告(报告写了我十多次才发出去,那个苦啊~~~),顺便给予运维建议,因当时这一服务对应的apache是单点,建议去除单点,再申请一台机器作为热备,高峰时还可作为balance功能使用。于是,我的第一次性能测试,随着这第一份性能测试报告的发出,结束了.......也从此,我开始踏上了性能测试的路,开始爱上了性能测试

  在后面的工作中,大大小小的项目也接触了一些,零零散散的一些性能问题也跟研发,DBA一起定位,调优解决了,但是慢慢的我在思考,性能测试就是这样了吗?在随后而来的一次项目中,让我知道,其实性能测试并不如此,远非我之前看到的,之前看到的还不够深入......

  记得那次项目,是对c++开发的一个搜索服务server的测试,在测试的过程中,发现,开始没多久,磁盘就速度变大,内存也消耗的很快,cpu飙的特别快......可并发用户才5啊,,,,这个问题会在哪里呢?cpu飙的特别快,那一般是运算复杂,调度频繁,切换频繁等原因造成的,于是,找到研发,咨询相关的算法,是否过于复杂,可否再优化?研发也好沟通,给耐心的讲解了算法,并回复,当前无法再优化,只能后面逐步来看。那难道就这样放出去?反正公司不差服务器,堆服务器就是了,硬件解决性能问题似乎成了行业的潜规则,而且产品也说了,平常根本也没多少人会用这个,这样的问题,他们也可以接受......就这样发到外网?不,作为一名性能测试工程师,如果就这样洗洗睡了,那我们的价值在哪里?于是,跟研发建议,如果确实是算法的问题,在当前我们无法进行修改,调优的基础上,是否可以进一步请求资深和专家研发给予check和给予建议,对该风险进行分析?于是,研发开始进一步确认到底是算法哪一块,哪一处消耗最多,戏剧的是,分析到最后,发现该问题并不是算法是主要凶手,之前冤枉了算法,而是程序本身的一个bug,研发之前对于c++里面用到的hashtable,错误的认为是有序的,但实际该hashtable在处理的时候是无序的,从而造成每次都会生成新的追加的文件,这样文件越来越大,造成磁盘疯狂的长,同时写磁盘这个过程对cpu的占用也就飙的很高,再一个,读数据的时候,之前都是直接很疼的从磁盘上拿,没有做map处理,map处理之后使得程序都从内存里面读,这样响应时间也得到了有效的提升,并且,研发还对不该加锁的地方进行了顺序读的锁处理进行修复,导致server的吞吐率得到提升......最终,版本打回研发,研发自测后,再进行提测和验证

  在上个项目中,让我觉得,作为一名性能测试工程师,不要错误的将自己定义为架构师(很多行业的人都觉得性能测试工程师很牛逼,牛逼的过程中,不自然间就把这个职位等价成了架构师,其实我想说,架构师是高于性能测试工程师的),但是,一名优秀的性能测试工程师应该不断的靠近架构师,只有这样,才能真正的从根本上去发现,解决问题,才能在研发体系中更好的体现自己的价值.也在这个项目之后,我开始思考并有了后面我主导的一个虚拟项目,“BMW软件性能平台”(据说名字霸气点是好事:))......

  另:这些年的项目经验,还让我认识到,对于有的性能问题,在调优的时候,并不是说就一定需要用技术解决的,有的问题,技术不能解决的,需要思考和尝试业务需求上的调整,有的性能问题的定位和分析,并不是说就一定要那么费劲周折,高并发,查这里,看那里来定位和解决,有的只用单个用户,发个请求,抓个包,看下timechart,看下代码构成,就可以解决了.性能测试,我一直坚持,它跟监控是离不开的,有了监控,有了数据准备和数据收集,我们才能更快更好的发现问题,分析和解决问题(这个也是我弄“BMW软件性能平台”的原因)

  这些年,我的软件性能测试项目经验,让我获得了很多,也失去了很多,对于行业的认识也看的更加深入了些,开始接触并学习之前根本不知道的语言内核知识,TCP/IP原理等网络知识,深深的感觉到学海无涯,而吾身有涯......

  这些年,我的软件性能测试,写在我即将逝去的28岁......

====================================分割线================================

最新内容请见作者的GitHub页:http://qaseven.github.io/

时间: 2024-11-05 19:31:08

这些年,我的软件性能测试的相关文章

《精通软件性能测试与LoadRunner最佳实战》—第2章2.节

内 容 提 要 精通软件性能测试与LoadRunner最佳实战 本书在介绍软件性能测试概念的基础上,结合对实际测试案例的剖析,重点讲解了性能测试实战技术.LoadRunner工具的使用技巧和实践工作中的问题解答. 全书分为15章,内容从测试项目实战需求出发,讲述了软件测试的分类以及测试的流程等,还重点讲述了性能测试技术和LoadRunner 11.0工具应用的实战知识.为了有效地解决工作中遇到的问题,将实践中经常遇到的问题进行总结汇总成几十个解决方案.详细的项目案例.完整的性能测试方案.计划.用

软件性能测试的本质

  淘宝网每年的双11 活 动都是对其服务器性能的挑战.因为在这一天所有商品半价,购物的用户量剧增.做为淘宝网的高层更多的关心在线用户数,用户交易量,总交易金额等,做为一名 技术人员,我们可能更关心当天系统的吞吐量.每秒钟点击率以及系统资源的消耗情况等,对!这就是系统的性能.那么性能的本质是什么呢?我试抓住一些点来解 释.   基于用户体验的性能测试   但对于一个用户来说,他可以不关心上面这些(系统的性能参数),大约有一部分的消费者会因为网站过于技术化或者性能问题而选择了离开.换言之,如果你的

《精通软件性能测试与LoadRunner最佳实战》—第1章1.3节软件测试的定义

1.3 软件测试的定义 精通软件性能测试与LoadRunner最佳实战 随着计算机行业的不断发展,软件系统规模和复杂性不断扩大,先前由一两个人就可以完成的中小型项目已经不再适用于现在软件项目的开发模式和系统的规模.现行软件项目通常业务功能复杂,操作人数较多,软件厂商在激烈的市场竞争中不仅需要考虑产品的功能实用性.界面的美观性.易用性等,产品的健壮性,以及快速及时的响应.支持多用户的并发请求等性能测试方面的要求也越来越受到关注,软件的性能测试可以说是软件测试的重中之重.它是测试人员从用户角度出发对

《精通软件性能测试与LoadRunner最佳实战》—第1章1.4节软件测试的分类

1.4 软件测试的分类 精通软件性能测试与LoadRunner最佳实战 软件测试按照测试阶段.是否运行程序.是否查看源代码以及其他方式,可以用图1-1所示来描述软件测试的各种分类. 黑盒测试.白盒测试与灰盒测试 1.黑盒测试 黑盒测试(Black-box Testing)是软件测试的主要方法之一,也可以称为功能测试.数据驱动测试或基于规格说明的测试.测试者不了解程序的内部情况,只知道程序的输入.输出和系统的功能,这是从用户的角度对程序进行的测试.软件的黑盒测试意味着测试要在软件的接口处进行.这种

从用户感知谈软件性能测试

虽然,有一段时间没关注性能测试,但时常还能看到有同学讨论性能,对于一些概念的理解很想深入讨论,但三言两语说不清,于是,还是花点时间写写吧! 今天有一个同学问:"一个小的系统,用户并发数为20个,那事务平均响应时间大概在什么范围内?" 怕麻烦直接告诉他2/5/8原则,钻牛角尖的话,需要进一步确认什么样的小系统?提供的什么类型的业务?用户行为是什么样的?用户对系统的使用频率?就算同响应时时间一样,前端通过不同展现方法,用户的感知可能完全不一样.下面就真对这个问题延伸讨论一下从用户感知的角度

《精通软件性能测试与LoadRunner最佳实战》—第1章1.1节软件测试基础

第1章 软件测试概述 精通软件性能测试与LoadRunner最佳实战 1.1 软件测试基础 精通软件性能测试与LoadRunner最佳实战 本书的主要内容是关于软件性能测试相关理论和工具应用方面的知识,但考虑到有很多阅读本书的读者刚开始从事测试工作,这里用一章的内容,对软件测试的基础内容进行了概括性的介绍,如果您已经熟悉了这些基本知识可以略过此章,直接阅读后续章节. 1.朝阳行业--软件测试 随着软件行业的蓬勃发展,市场竞争也越来越激烈,软件质量越来越受到软件企业的重视.软件测试是软件质量的重要

《精通软件性能测试与LoadRunner最佳实战》—第2章2.10节系统性能调优

2.10 系统性能调优 精通软件性能测试与LoadRunner最佳实战 性能测试分析人员经过对结果的分析以后,有可能提出系统存在性能瓶颈.这时相关开发人员.数据库管理员.系统管理员.网络管理员等就需要根据性能测试分析人员提出的意见同性能分析人员共同分析确定更细节的内容,相关人员对系统进行调整以后,性能测试人员继续进行第二轮.第三轮--的测试,与以前的测试结果进行对比,从而确定经过调整以后系统的性能是否有提升.有一点需要提醒大家,就是在进行性能调整的时候,最好一次只调整一项内容或者一类内容,避免一

漫谈软件性能测试技术

1.引言 随着我国加入WTO,各行各业都面临更多的机遇和挑战.如何提高产品的质量,增 强市场竞争力,日益成为企业发展必须解决的迫切问题,对软件企业来说尤为重要.软件企业要直接参与国际软件市场的竞争,首要问题就是要保证软件的质量,同 时要加快软件产品的发布与交付使用.因此,如何提高软件质量,越来越成为当前软件产业发展中一个迫在眉睫的问题.本文只针对软件质量的性能方面,做一些探 讨. 2.软件质量 质量保证能力的强弱直接影响着软件业的发展和生存.那么,到底 什么是软件的质量呢?<GB/T 16260

《精通软件性能测试与LoadRunner最佳实战》—第1章1.2节软件相关概念解析

1.2 软件相关概念解析精通软件性能测试与LoadRunner最佳实战大家从上面的软件故障或缺陷的实例中不难发现,这些软件故障和缺陷拥有很多的共同特点.首先,软件的开发过程与预期设计目标不一致,如前面举的爱国者导弹的例子.其次,闭门造车,没有实际考察客户的真正应用环境,仅仅按照自己的想法进行实施,尽管进行了测试,但是并没有覆盖到大多数用户应用软件的所有场景,如狮子王游戏软件就是因为研发出来的软件没有考虑实际用户的应用环境而引发的问题:而奥运售票系统也反映出在没有考虑到实际用户的访问量的情况而造成