1、性能测试策略通用方法

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

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

用户一般可以分为四类：即对性能特别关注、中等重视、一般关注、不怎么关注四类。这里这么划分并不意味着用户不关注性能测试人员就可以忽略性能测试。不过，用户如果特别关注性能，测试人员也应该特别重视性能测试。表1列出了性能测试策略制定的基本原则。（注意：这里的用户是广义范围的用户，包括所有和我们的产品有利害关系的群体。因而不单单指最终使用产品的用户，这些用户既可以是为我们提出需求的产品部，也可以是公司的董事会，甚至是我们研发人员自己。）

表1：性能测试策略制定对照表
软件类别
用户重视程度系统类软件应用类软件
一般应用特殊应用
高度重视设计阶段就开始针对系统架构、数据库设计等方面进行讨论，从根源来提高性能;系统类软件一般从单元测试阶段开始性能测试实施工作，主要是测试一些和性能相关的算法或者模块。设计阶段开始进行一些讨论工作，主要在系统测试阶段开始进行性能测试实施。设计阶段就开始针对系统架构、数据库设计等方面进行讨论，从根源来提高性能;系统类软件一般从单元测试阶段开始性能测试实施工作，主要是测试一些和性能相关的算法或者模块。
中等重视可以在系统测试阶段的功能测试结束后进行性能测试。
一般重视可以在系统测试阶段的功能测试结束后进行性能测试。
不怎么重视可以在软件发布前进行性能测试，提交测试报告即可。


表1性能测试策略制定对照表

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

软件的特点决定性能测试策略另外一个重要原因就是“一般应用类软件”通常耗费资源较少，因此可以通过提高硬件配置，进而改善运行环境来提高“一般应用类软件”的性能。从硬件方面解决性能问题往往更容易做到，同时可以降低我们的开发成本，不过也不能过分让用户进行较大的硬件投入，否则会降低我们的“客户满意度”。我们调整性能最好的办法还是软硬件相结合。

用户对待系统性能的态度影响性能测试策略，但不起决定作用的根本原因是我们最终要把产品交付给用户来使用，而不是做出来给用户欣赏。因此不管用户是否重视性能测试，即使根本不关心，对于性能要求高的软件产品我们都应该按照测试上面的策略进行合理的安排。同时，如果我们的上帝——用户如果特别重视，这意味着我们需要进行更多的性能测试方面的投入，因为我们有义务使我们的用户满意。

2、性能测试策略实例

下面我们可以看一些性能测试策略制定的案例。

案例一：一个银行项目的性能测试策略的制定案例，性能测试策略从立项时开始确定，贯穿整个项目的执行过程。该软件属于特殊应用软件，用户高度重视性能，因而采取的策略是从设计阶段就开始进行性能测试的准备工作，案例具体内容如下：

表2：某银行项目测试制定案例

产品类型银行卡审批业务系统，使用非常频繁，业务量每年达到200万左右，属于银行领域的特殊应用软件。
项目背景系统属于第二次重新开发，前一开发商在系统开发完成后没有通过性能测试，100个左右用户并发访问系统时数据库服务器崩溃。因此新的系统从项目启动开始，性能测试成为用户关注的焦点。
用户要求用户提出性能方面首先过关，否则功能再好也不会投产。
性能测试策略从系统设计阶段开始进行性能测试准备工作，主要是参加系统的设计、评审。重点讨论了数据库的设计，前一开发商失利的重要原因是数据库设计不合理。
系统设计阶段，完成了性能测试方案的设计。
单元测试阶段通过测试工具对一些重要模块的算法进行测试。主要是一些并发控制算法的性能问题，测试对象是一些核心业务模块。
集成测试阶段进行组合模块的测试。
整个系统测试阶段都在进行性能测试，性能测试和功能测试同步进行。对功能测试引起的一些相关修改，立刻进行性能测试。
验收测试阶段时，在用户现场的投产环境进行性能测试，根据测试结果对系统运行环境进行调优，达到较佳的运行效果。

表2某银行项目测试制定案例
-------------------------------------------------------------------------

在实际的性能测试中，经常接触到的与并发用户数相关的概念还包括“并发用户数”、“系统用户数”和“同时在线用户数”，下面用一个实际的例子来说明它们之间的差别。
        假设有一个OA系统，该系统有2000个使用用户——这就是说，可能使用该OA系统的用户总数是2000名，这个概念就是“系统用户数”，该系统有一个“ 在线统计”功能（系统用一个全局变量记数所有已登录的用户），从在线统计功能中可以得到，最高峰时有500人在线（这个500就是一般所说的“同时在线人数”），那么，系统的并发用户数是多少呢？

        根据我们对业务并发用户数的定义，这500就是整个系统使用时最大的业务并发用户数。当然，500这个数值只是表明在最高峰时刻有500个用户登录了系统，并不表示实际服务器承受的压力。因为服务器承受的压力还与具体的用户访问模式相关。例如，在这500个“同时使用系统”的用户中，考察某一个时间点，在这个时间上，假设其中40%的用户在较有兴致地看系统公告（注意：“看”这个动作是不会对服务端产生任何负担的），20%的用户在填写复杂的表格（对用户填写的表格来说，只有在“提交”的时刻才会向服务端发送请求，填写过程是不对服务端构成压力的），20%部分用户在发呆（也就是什么也没有做），剩下的 20%用户在不停地从一个页面跳转到另一个页面——在这种场景下，可以说，只有20%的用户真正对服务器构成了压力。因此，从上面的例子中可以看出，服务器实际承受的压力不只取决于业务并发用户数，还取决于用户的业务场景。

       在实际的性能测试工作中，测试人员一般比较关心的是业务并发用户数，也就是从业务角度关注究竟应该设置多少个并发数比较合理，因此，在后面的讨论中，也是主要针对业务并发用户数进行讨论，而且，为了方便，直接将业务并发用户数称为并发用户数。

        （1）  计算平均的并发用户数： C = nL/T     

        （2）  并发用户数峰值： C’ ≈ C+3根号C

         公式（1）中，C是平均的并发用户数；n是login session的数量；L是login session的平均长度；T指考察的时间段长度。

        公式（2）则给出了并发用户数峰值的计算方式中，其中，C’指并发用户数的峰值，C就是公式（1）中得到的平均的并发用户数。该公式的得出是假设用户的login session产生符合泊松分布而估算得到的。

实例：
本帖隐藏的内容
假设有一个OA系统，该系统有3000个用户，平均每天大约有400个用户要访问该系统，对一个典型用户来说，一天之内用户从登录到退出该系统的平均时间为4小时，在一天的时间内，用户只在8小时内使用该系统。

则根据公式（1）和公式（2），可以得到：

               C = 400*4/8 = 200

               C’≈200+3*根号200 = 242
－本文出自天天软件测试社区(http://www.×××/bbs/)，原文地址：http://www.×××/bbs/thread-10935-1-1.html

由某产品线组织架构调整引发的思考