Web全面性能测试模型(3)

发表于:2014-11-13来源:uml.org.cn作者:不详点击数: 标签:性能测试
(1) 预期指标的性能测试; (2) 并发用户的性能测试; (3) 疲劳强度和大数据量的性能测试; (4) 服务器性能测试; (5) 网络性能测试; 在具体的Web性能测试用例设计

  (1) 预期指标的性能测试;

  (2) 并发用户的性能测试;

  (3) 疲劳强度和大数据量的性能测试;

  (4) 服务器性能测试;

  (5) 网络性能测试;

  在具体的Web性能测试用例设计中,往往和测试工具结合起来,把服务器、网络性能测试的用例设计与前三种类型性能测试的用例设计结合起来进行。例如MI公司的LoadRunner就能在进行压力测试的同时,完成后面两类测试的数据采集工作,因此后面两部分的测试用例设计可以和前面融会在一起,在第5章的案例多采用了这种方式来进行设计。

  Web性能测试用例设计模型在2.3节进行详细的讨论。

  第三部分:模型使用方法,本部分内容讨论如何在工作中使用“Web全面性能测试模型”,具体在2.4节进行详细的讨论。

  1.2 Web性能测试策略模型

  本节主要介绍Web性能测试策略制定方法。性能测试策略一般从需求设计阶段开始讨论如何制定,它决定着性能测试工作将要投入多少资源、什么时间开始实施等后继工作的安排。其制定的主要依据是“软件自身特点”和“用户对性能的关注程度”两个因素,其中软件的自身特点起决定作用。

  软件按照用途的不同可以分为两大类:系统类软件和应用类软件。系统类软件通常对性能要求比较高,因此性能测试应该尽早介入。应用类软件分为特殊类应用和一般类应用,特殊类应用主要指银行、电信、电力、保险、医疗、安全等领域类的软件,这类软件使用比较频繁,用户较多,一般也要较早进行性能测试;一般类应用主要指一些普通应用,例如办公自动化软件、MIS系统等,一般应用类软件多根据实际情况来制定性能测试策略,比如OA系统,可以早开始、也可以最后进行性能测试,这类软件受用户因素影响比较大。

  用户按对性能的关注度的不同一般可以分为四类,即特别关注、中等重视、一般关注、不怎么关注,这么划分主要是为了说明用户对性能测试的影响。实际上,用户不关注性能并不意味着测试人员就可以忽略性能测试,但是如果用户特别关注性能,测试人员也应该特别重视性能测试。表2-1列出了性能测试策略制定的基本原则(注意:这里的用户是广义范围的用户,包括所有和产品有利害关系的群体。因而不单单指最终使用产品的用户,这些用户既可以是提出需求的产品经理,也可以是公司的董事会成员,甚至是项目的研发人员)。

  表2-1性能测试策略制定基本原则

  从表2-1可以看出:(1)“系统类软件”、“特殊应用类软件”应该从设计阶段开始进行性能测试;(2)制定性能测试策略的主要依据由软件的特点来决定,用户的态度对策略会有一定的影响,但不是决定因素。

  软件的特点决定性能测试策略的另外一个重要原因是“一般应用类软件”本身对性能要求不高,发生性能问题概率不高,因此可以通过提高硬件配置来改善运行环境,进而来提高性能。不过这也不是绝对正确的观点,例如一个几千用户来使用的OA系统,仍然要高度重视性能,不管客户对待系统的性能是什么态度。

  虽然从硬件方面解决性能问题往往更容易做到,同时还可以降低开发成本,但是也不能过分让用户进行较大的硬件投入,否则会降低“客户满意度”,调整性能最好的办法还是软硬件相结合。

  “用户对待系统性能的态度影响性能测试策略,但不起决定作用”的根本原因是最终要把产品交付给用户来使用,而不是做出来给用户欣赏。因此不管用户是否重视性能测试,甚至根本不关心,对于性能要求高的软件产品也应按照表 2-1的策略来执行性能测试。只是如果用户如果特别重视性能这方面,这意味着测试团队可能将要进行更多的成本投入,因为有义务使用户满意。

  下面是一些Web性能测试策略制定的案例。

  案例一:一个银行卡审批系统的性能测试策略制定案例。这个项目的性能测试策略从立项时开始制定,贯穿整个项目的执行过程(在5.3节将会进一步讨论本案例)。

  银行卡业务系统属于特殊应用软件,加上用户高度重视性能,因而采取的策略是从设计阶段就开始进行性能测试的准备工作,案例详细信息如表2-2:

原文转自:http://www.uml.org.cn/Test/201106211.asp