请看下面一个性能测试小案例:

  某公司OA产品的新版本即将发布。为了看看系统的性能,决定安排测试工程师A君执行性能测试任务。A君做法如下:

  1. 找到一台PC机,CPU主频1G,内存512M,……;

  2. 在找到的PC机上搭建了测试环境:安装了Oracle9i、Weblogic等系统软件;

  3. 在自己的工作机上安装了LoadRunner7.8;

  4. 然后录制了登陆、发布公告等功能;

  5. 开始设置30、50、100、500不同的并发用户数目进行并发;

  6. 后得出结论:系统只能运行80个左右的并发用户……。

  无疑上面的做法存在很多不合理的地方,例如测试内容太少、测试服务器配置太低等。现实工作中,尽管性能测试以其在测试中独特的地位越来越为软件测试人员、开发人员和用户所重视,但是不管是测试人员还是开发人员,仍然在认识上存在这样或者那样的误区。

  误区1:提高一下硬件配置可以提高性能了,因此性能测试不重要。

  这是以前系统规模不大时期留下来的认识。DOS时代以及后来Windows操作系统流行的初期,软件规模一般较小,而硬件的更新却是日新月异,软件性能一般不是突出问题,因为只要升级一下硬件,很容易解决了性能问题。

  现在随着软件规模的扩大,提高硬件配置只是解决性能问题的一个基本手段。因为如果软件自身存在性能问题,再多的资源可能也不够用,例如内存泄漏问题,随着时间的增加,内存终究会被耗尽,后导致系统崩溃。

  因此,如果用户对软件的性能要求较高,这将意味着不但要从硬件方面来提供性能,还要从数据库、WebServer、操作系统配置等方面入手来提高性能,同时开发的软件系统本身也要进行优化,以便全面提高性能。

  误区2:性能测试在所有其它测试完成后,测试一下看看可以了。

  这是目前特别普遍的一种现象,例如前面的A君,这种现象主要是没有意识到性能测试的重要性。这种做法严重的后果是如果性能问题是由软件系统本身产生的,可能会无法根治性能问题。例如架构设计方面的失误,可能意味着软件系统将被废掉。

  当然这并不意味所有的性能测试都要尽早进行,性能测试的启动时间要由软件特点来决定。性能测试策略的制定问题可以参考《程序员》第10、11期的《治疗软件亚健康》。

  误区3:性能测试独立于功能测试。

  功能测试可以发现性能问题,性能测试也能发现功能问题。性能测试和功能测试是紧密联系在一起的,原因之一是由于很多性能问题是由软件自身功能缺陷引起的。如果应用系统功能不完善或者代码运行效率低下,通常会带来一些性能问题。功能测试通常要先于性能测试执行或者同步进行,软件功能完善可以保证性能测试进行得更加顺利。

  误区4:性能测试是用户并发测试。

  仍然有很多人(尤其是开发人员和部分项目实施人员)一提到性能测试,会联想到并发用户测试,进而认为性能测试是“测试一下多用户的并发情况”。严格地讲,性能测试是以用户并发测试为主的测试。实际性能测试还包含强度测试、大数据量测试等许多内容。

  误区5:在开发环境下进行一下性能测试可以了。

  很多时候,在软件开发完成后会进行性能测试,看一看软件的性能。实际上大多数的开发环境因为硬件条件比较差,所以反映不了过多的性能问题。

  因此性能测试要尽量在高配置的用户投产环境下进行。但是有两种可以例外的情况:一种是为了发现某些功能方面的问题,例如为了发现并发算法的一些缺陷;另外一种是有非常好的硬件资源或者实验室作为开发环境。

  误区6:系统存在瓶颈,不可以使用。

  系统发现了瓶颈,的确是很让人担心的一件事情。不过不要紧,很多的瓶颈可以不必去理会。发现瓶颈的目的主要是为了掌握系统特性,为改善和扩展系统提供依据。因此在性能方面给系统留有30%左右的扩展空间可以了。

  例如,1000个用户并发时发现了系统瓶颈,而客户的大并发用户数量在500左右,这样的性能问题完全没有必要处理,要是550或者600个并发用户出现性能问题应该认真地调整系统性能了。

  误区7:不切实际的性能指标。

  这种现象主要归结于对软件应用需求的不了解。很多时候,尤其是用户会提出很多不切实际的性能指标,例如,针对500个用户使用的OA系统,可能有的用户负责人会提出要满足100个甚至500个用户并发的性能目标,而实际并发数量不会高于50。这种情况只有和用户进行沟通才可以解决。

  上面列举的都是日常性能测试工作中相关人员常犯的错误,这些观点只在极其特殊的情况下才正确。希望读者了解这些常见的性能测试误区后,能在以后的工作中避免类似的情况。