对软件测试WEB性能测试的那点研究
随着网络技术的迅速发展，尤其是WEB及其应用程序的普及，各类基于WEB的应用程序以其方便、快速，易操作等特点不断成为软件开发的重点。与此同时，随着需求量与应用领域的不断扩大，对WEB应用软件的正确性、有效性和对WEB服务器等方面都提出了越来越高的性能要求，对WEB应用程序进行有效的系统的测试也逐渐成为人们研究的重要课题。
目前可以见到各种WEB服务器平台，然而根据Mereury的研究报告，98%的WEB服务器都没能达到人们所期望的性能，平均只能发挥人们所期望性能的1/6左右。WEB性能测试能够确定影响WEB服务器性能的关键因素，从而可以有针对性地进行分析和改进，避免WEB服务器研究和优化过程中的盲目行为；同时，它也是选取不同的WEB服务器的重要参考。
随着WEB应用程序使用越来越广泛，针对其性能测试的要求也越来越多，然而由于WEB程序综合了大量的新技术，诸如HTML、JAVA、Javascript、VBScript等，同时它还依赖很多其它的因素，比如Link、Database、Network等，使得WEB应用程序测试变得非常复杂。例如：WEB压力测试是评价一个WEB应用程序的主要手段，它的测试就是一个代表性的方面。
WEB应用程序的测试有别于传统软件的测试，它有其自身的特点。下面我们进行比较深入的讨论。
一个Web站点为了个人消费者、商业客户、企业合作伙伴或者内部用户，都必须提供可靠、快速的性能，这是在评价一个Web应用是否满足用户需求和期望的关键指标。在这个竞争激烈的Internet 世界里，如果缺乏严格的过程，Web系统可能会在开发、发布和维护的过程中碰到一系列问题，甚至系统无法使用。而且如果一个企业的Web 应用没有良好的性能，就意味着它会失去潜在的用户。所以，必须对Web 应用进行负载测试，了解它在不同的负载下的响应情况。但是，由于Web应用的复杂性和不可预测性，使得负载测试难度较大。如果负载测试不够准确，测试结果就是没有任何用处的，甚至会产生误导，使企业高估或者低估Web 应用的能力[1]。因此,负载测试的设计是至关重要的，只有在设计的负载真正地模拟了现实用户的工作负载，并且模拟的用户行为真正模拟了现实用户的行为，负载测试的结果才是可靠的，从测试结果得出的结论也才会正确。
2 负载测试
负载测试在不同负载下测试客户端或者服务器端的响应时间。负载测试也可以用来帮助测试人员计算在给定时间内服务器可以处理的最大数量的事务数。此外，当C/ S 系统使用了工作负载均衡或者分布式体系结构，负载测试就应评估负载均衡或者分布式方法和设计是否一致[2]。
负载产生器模拟浏览器的行为，不断地向Web 应用发送请求，然后在Web 应用发送一个应答之后，等待一段时间，接着发送新的请求。负载产生器可以模拟成千上万个并发用户来测试Web 应用的稳定性。在负载测试中，每一个模拟浏览器称为虚拟用户，一个虚拟用户就是脚本的一个实例。
对Web 应用进行准确的负载测试时，首先要准确、客观地了解Web 应用的负载情况。Web 应用的负载情况是设计负载测试的前提和基础。了解用户的各种行为和动作是负载测试设计的关键，一个设计良好的负载测试要尽可能准确地模拟用户的动作。Web 应用的日志文件和日志文件分析器是完成这个任务最重要的资源。
通过使用日志分析器对Web 应用日志文件的分析，鉴别和跟踪与Web 应用通信量( traffic) 有关的用户会话(user session) 变量集,其中主要包括的变量有：会话长度(以页面数度量) 、会话持续时间(以分钟和秒度量) 、会话期间访问的页面类型等等。页面请求分布是用户会话变量中需要特别关注的变量[4] 。这个变量显示了每个页面访问的频率,是设计测试场景的重要依据。除了这些主要变量外，那些会引起负载很小变化的其他变量也需要跟踪。在确定了需要跟踪的用户会话变量之后，用日志分析器得到这些变量值的范围和分布。
估计Web 应用的负载水平，主要是Web 应用的通信量如何增长、Web 应用的最高负载、Web 应用负载多长时间可以上升到最高负载、最高负载持续时间[4] 。一般情况下，最高负载的水平和通信量的水平大致成正比。如果一个Web 应用每个星期的用户会话数为10 万个，在高峰期每小时的用户会话数为1500 个，那么可以预计如果每个星期的用户会话数为20 万个时,高峰期每小时的用户会话数也将翻倍，即为3000个。
3 负载测试的设计
准确掌握了Web 应用的负载情况之后，就根据获得的各项信息进行负载测试设计，准确模拟用户的动作，其中主要包括用户导航建模和用户延迟建模。
3.1 用户导航建模
用户导航建模是对用户在Web 应用上的动作进行建模。现实中，用户在一个Web 应用的行为可能包括一系列的动作。例如，一个在线书店的用户登陆Web 应用之后，先浏览网页查看有关信息，然后再搜索要购买的书，最后购买需要的书。从客户端的角度看，是一个用户执行了所有这些动作。但是，在负载测试中，不可能和现实完全一致地模拟所有用户的动作。负载测试的目的在于当用户给服务器施加不同水平的负载时，根据考察服务器端的各项度量指标找出系统的瓶颈，提高整个系统的性能。所以，负载测试时虚拟测试者只要模拟与实际负载相同的负载水平，而不用将虚拟测试者和实际用户一一对应，模拟每一个用户的具体动作。设计负载测试时可以把用户的一系列行为划分为若干子行为，然后虚拟测试者以适当的方式执行每一个子行为[5,6] 。例如，在上面的例子中，将用户行为可以划分为3个子行为——浏览信息、搜索图书、购买图书，然后用3 个不同的虚拟测试者以适当的次序执行3个子行为。从服务器端看来，这3个虚拟测试者给服务器施加的负载和实际使用中一个真实用户给服务器施加的负载是相同的。
在了解了用户的行为模式后，还需要知道不同用户所占的数量或者百分比。因为用户的每一类动作给系统施加的负载都是不尽相同的，因此为了准确地模拟实际用户的动作，必须确定各种用户的数量或者百分比。各种以不同的百分比组合到一起的动作，应该满足预期的页面请求分布。例如，服务器施加很小的负载。而另一方面，购买图书时要和数据库通信，甚至要和其他子系统通信，这个动作对服务器施加的负载要比浏览信息大得多。因此，要根据掌握的Web应用负载情况，明确不同用户的数量或者百分比，这样才能准确地模拟实际用户对服务器施加的负载。
3.2 用户延迟建模
在进行负载测试的设计时，用户的延迟的建模也是重要的一个方面。由于不同的用户对Web应用的熟悉程度不同、阅读速度和输入速度不同，所以不同的用户在完成相同的行为时延迟的时间也就不同，为了更加真实地模拟用户的行为，必须对用户延迟进行准确地建模[7]。在根据用户导航建模录制的脚本中，要考虑用户延迟建模，对脚本进行修改。首先，可以根据用户的延迟不同将用户分为比重不同的若干组。例如，在一个用户登陆页面中，可以根据用户对Web 应用的熟悉程度不同将用户分为新用户、返回用户和有经验的用户，它们所占比重分别是35%、55%和10%。以用户延迟的不同对用户进行分类，根据划分的细致程度，模拟的用户延迟的准确度就不同，划分类别越多越细，模拟的用户延迟就越准确。相反，如果划分的类别很少，模拟的用户延迟准确性就比较差。为了尽可能地和真实用户的延迟相同，使用数学模型可以更好地实现。所以，在设计性能测试时为了很准确地模拟用户延迟，需要认真地分析真实用户的延迟情况，找到一种能够和其很好吻合的数学模型，例如，常用的有均匀分布、正态分布和负指数分布。均匀分布模型就是从最大值和最小值之间随机地选择数据，正态分布是从最大值和最小值之间以不同的概率选取数据,越靠近中间的数字选取的概率越大。
4 基于LoadRunner的负载/压力测试实例
4.1 并发性能测试
基于客户端应用的性能，测试的入口是单机客户端。
并发性能测试的过程，即是一个负载测试和压力测试的过程。它的基本原理是逐渐增加并发虚拟用户数，直到系统的瓶颈，通过综合分析监控指标数据来确定系统性能。负载压力测试有助于确认被测系统是否能够支持性能需求，以及预期的负载增长，并找出系统出现异常的原因，从而对系统性能进行调优。
并发用户测试主要是对系统的核心功能和重要业务进行测试，要以真实的业务数据作为输入，选择有代表性和关键的业务操作来设计测试用例。
其目的是：在真实或者仿真环境下检测系统性能，评估系统性能以及服务等级的满足情况；预见系统负载压力承受力，在应用实际部署之前，评估系统性能；帮助分析系统瓶颈、优化系统自动化负载压力测试实现机制。在多种服务器配置环境下测试，则配置成本，测试时间和人力资源必然会更多的消耗。但在很多情况下可以通过一种硬件配置下的压力测试结果来预测不同配置下的Web应用程序的性能。
4.2 进入负载测试
由于条件的限制，本次实验Web服务器和web客户端同机。这就与网络无关，即减少了网络系统这个环境因素，直接与服务器连通。下面是录制基本的用户脚本。
(1)启动VuGen(Visual User Generator虚拟用户生成器)，其方法：“开始”→“程序”→“Loadrunner”→“Visual User Generator”。通过菜单“new”新建一个用户脚本，选择通信协议。这里用的是Web应用，所以选择web(HTTP/HTML)协议。如下图1。
(2)进入VuGen主窗口
(3)点击Start Record按钮,进入开始录制窗口设置，如下图3。
(4)在开始录制录制窗口中，URL设为http://127.0.0.1/xitong/default。Action序号可自定义，也可以用默认值如：Action4。点击”OK”按钮后,在web浏览器里打开网站首页。
(5)在浏览登录网页的同时,VuGen自动生成脚本.用户一般性登录并浏览网页中的信息。相应地脚本是在这样的情况下自动录制的，因此脚本也是一般性的登录浏览。如下：
(6)优化脚本如事务。LoadRunner有两种和事务相关的概念： Action和Transaction。Action是用户的一系列操作的组合；Transaction是用户某一具体的动作，为了衡量服务器的性能而需要定义的。例如：在脚本中有一个数据查询操作，为了衡量服务器执行查询操作的性能，就把这个操作定义为一个事务，这样在运行测试脚本时，LoadRunner 运行到该事务的开始点时，LoadRunner 就会开始计时，直到运行到该事务的结束点，计时结束。这个事务的运行时间在结果中会有反映。Action通常会包含一系列功能相关的Transaction。事务有三种执行结果：pass(通过)可执行全部虚拟用户脚本；fail(失败)执行过程中发生了错误；stop（停止）因到测试结束时间等而停止执行脚本。
本文事务定义为登录某个子网页，考查登录子网页的系统响应情况。
录制用户进行系统登录访问的脚本.在controller中选择脚本，设置虚拟用户数量并运行，运行时，将以设置的虚拟用户数(每次增加用户)为并发数，并发进行网站访问操作，初步预计最大的并发量为20个用户。
测试过程中记录的部分数据，事务登录某个子网。列表综合分析：
从图6所得数据，容易看出：
平均响应时间较快、平稳；访问最大并发量为16；当增加至50时，系统登录失败。
5 结论
(1)被测小系统性能比较差。测试运行的环境未显异常，测出的实际最大并发数量少于预期数量。因此，可初步确定被测系统是性能问题的关键。对于一个小系统，它的反应时间较快可能够承受的最大并发用户数比较小，并且还不能很好地持续工作。系统开发者应该进一步提高性能如：优化代码、核心功能模块等，以支持更大并发用户数。因为系统核心功能很大程序影响其性能。
(2)性能测试也能发现功能问题。系统有些功能和按键并不很完善，这也会影响性能的提升。性能测试和功能测试是紧密联系在一起的，原因之一是很多性能问题是由软件自身功能缺陷引起的。如果应用系统功能不完善或者代码运行效率低下，通常会带来一些性能问题。功能测试通常要先于性能测试或者同步进行，软件功能完善可以保证性能测试进行得更加顺利。
(3)尽最大努力无限接近正确值。做任何实验所得结果都不能保证其百分之百的准确，同样本论文的实验也是如此。因为在不同的时间用户的动作事务是极不相同的，运用不同的脚本或者场景，测试所得的结果往往是不一样的。更何况，实验结果与测试工具、方法和环境（操作系统，服务器，内在及CPU等）也有关，而工具和测试环境本身就无法完美无缺。为取得无限接近正确值，本文多次反复实验测试，摘录一些平均稳定结果数据，再进行列表比较，最后得出结论。
任何一种工具，相对而言也就很容易上手其它工具。
目前，国外对性能测试的研究己经取得了许多成果，提出了一些模型、方法和策略，并相应开发了测试工具。国内在Web性能测试方面的研究和开发才刚刚起步，没有比较完善的测试模型和良好的测试工具。这对我们来说是个极大的挑战，同时也是机遇。
文章来源于领测软件测试网 https://www.ltesting.net/
