昨天写完了,然后点发表,竟然什么都没了,真是惆怅啊。难道是长时间没响应?之前好象不会把今天重写把。

最近因为在公司因为搞性能测试的没什么人了,我也就逐渐转向性能测试方面的学习了。学习了大概有3个星期了,也用了LR跑了一些场景,不过觉得首先还是要把一些基本概念理解清楚,所以就把一些基本的东西写下来。让自己加深理解。也希望帮助大家了解一些。

 

 

一. 软件性能测试

 

在我们学习性能测试之前,首先要明白什么是性能。汽车有他的性能,比如速度,加速时间,稳定性;电脑硬件有他的性能,比如CPU的频率,处理的速度,游戏的性能。而计算机软件也有他的性能,比如软件运行速度如何,系统稳定性如何等等。性能的好坏不能凭空想象。必须有一些数据来说明来比较。所以我们软件性能测试就是通过得到软件在各种运行情况下的数据来进行分析,来判断软件的性能。一个软件对于不同的人群,他所关注的性能方面是不一样的。比如对于用户来说,他关心的是程序响应的时间,也就是他点一个提交按钮,多长时间可以得到结果。而对于系统管理员他关注的可能是软件在运行时,对系统资源的使用情况,在大量用户使用时的表现如何,能否长时间稳定的工作;而对于开发人员,他们更关心的是系统结构是否合理,SQL执行速度是否够快,有没有内存泄漏等情况。而对于我们测试人员来说,我们需要站在多个 角度来关心性能问题。

 

 

二 性能测试主要术语

 

1:响应时间:

 

响应时间的定义是:对请求作出响应所需要的时间。我们一般把响应时间作为用户角度衡量软件性能的主要指标。

毕竟系统是给用户使用的,用户对系统性能是否满意是用户说了算的。一般情况下响应时间是分为多个步骤的,首先从客户端发出请求,经过网络达到服务器N1,应用服务器处处理S1,访问数据库服务器N2,数据库服务器处理时间为D1,然后返回给应用服务器的网络时间为N3,应用服务器处理时间S2,在传个客户端的网络时间是N4。那么整个响应时间应该为T=N1+S1+N2+D1+N3+S2+N4,当然如果还用到其他服务器,还要加上其他时间。而实际上,除开这T,还有一个客户端的显示时间也要可以算做响应时间。所以时间Tx = T +Ts。但实际上Ts很大程度上是由用户的机器决定的,所以我们一般只关注T,所以通常把T称做响应时间。

一般一个网站,被普遍接受的响应时间是2/5/10,就是说2秒内给用户响应是很满意的,5秒是可以接受,而我一般是等不到10秒就会ALT+F4了!但不同的软件,响应时间的标准要根据实际情况来定。比如一个数据库备分软件,你能要求他5秒内搞定一个1G的数据库吗?

 

继续阅读

0

工作也快1年了,却一直没有写过一篇关于测试方面的文章。一直做功能测试,功能测试这个东西,也有他的一套理论,一套流程,以及测试过程中的一些方法,什么边界法,等价类。但实际工作中,因为真正把测试流程走的很好的公司毕竟很少。所以编写测试计划,写完整的测试用列,运用这些方法可能机会不多。而实际工作中,完全的功能测试重要的就是理解业务和需求。所以具体的什么流程就不说了,网上资料很多。

 

下面谈谈自己对功能测试的一点看法:

 

需求理解了,知道客户想要系统实现什么,理解了业务,就知道了系统是怎样一个流程来实现的。然后按照需求来进行测试的,不满足需求要求的都可以认为是BUG。但实际中,这样一个简化了过程都很难,毕竟想从开发那拿到一份完整详细的需求都是很不容易的(当然,可能也有比较规范的公司,但目前大多数应该是这个情况)。

 

当然功能测试也不是真的那么简单,要做好一个功能测试,前提是要对需求比较熟悉,各个业务细节都很了解。甚至做到比开发人员还要了解。这或许是测试人员唯一的优势了。个人做了快1年功能测试的一点看法。要做好功能测试,还需要对整个业务中数据库的操作比较清楚(针对信息管理相关的系统)。比如哪个业务需要用到那些表,做怎么样的操作。了解了这个就可以不单单从程序前台来看程序,看到数据库的过程,更有利于你找到隐藏的BUG。比如库表没有进行关联删除,日志表没有插如记录。这些是从前台看不出来的,但实际可能会导致程序出现问题。

继续阅读

0