如何对Web应用程序进行负载测试

1 "简单"的应用,可以用apache自带的工具ab测试 也可以试试>

Web 测试会激活集成的 Web 测试记录器，同时启动 Internet Explorer。Web 测试记录器作为 Visual Studio Team System Test Edition 的一部分进行安装，可用于记录您在浏览网站时执行的 *** 作。随着您在网站上四处移动，记录下的请求便会添加到 Web 测试中。在记录一个 Web 测试后，可以通过使用 Web 测试编辑器更改该测试以及向其中添加属性。有关更多信息，请参见。在停止记录之前，不能编辑 Web 测试。Web 测试记录器不会捕获客户端与服务器之间发送的通信量。这类工具有时称为“代理记录器”。因此，不会记录类似图像、CSS 和 JavaScript 的依赖性请求。Web 测试查看器而是在运行时确定这些依赖性请求。这样就可以获得一个适应性更强的测试，而不会由于一些图像请求而导致混乱。提升动态参数运行 Web 应用程序时，此应用程序会动态生成数据，如会话 ID。在很多情况下，Web 应用程序还会以查询字符串参数值和窗体发布参数值发送动态数据。Web 测试可以使用生成的参数值，方法是通过提取规则从 >

第一，分析产品结构，明确性能测试的需求，包括并发、极限、配置和指标等方面的性能要求，必要时基于LOAD测试的相同测略需同时考虑稳定性测试的需求。

第一，分析应用场景和用户数据，细分用户行为和相关的数据流，确定测试点或测试接口，列示系统接口的可能瓶颈，一般是先主干接口再支线接口，并完成初步的测试用例设计。

第三，依据性能测试需求和确定的测试点进行测试组网设计，并明确不同组网方案的重要程度或优先级作为取舍评估的依据，必要时在前期产品设计中提出支持性能测试的可测试性设计方案和对测试工具的需求。

第四，完成性能测试用例设计、分类选择和依据用户行为分析设计测试规程，并准备好测试用例将用到的测试数据。

第五，确定采用的测试工具。

第六，进行初验测试，以主干接口的可用性为主，根据测试结果分析性能瓶颈，通过迭代保证基本的指标等测试的环境。

第七，迭代进行全面的性能测试，完成计划中的性能测试用例的执行。

第八，完成性能测试评估报告。

第一，分析产品结构，明确性能测试的需求，包括并发、极限、配置和指标等方面的性能要求，必要时基于LOAD测试的相同测略需同时考虑稳定性测试的需求。

第一，分析应用场景和用户数据，细分用户行为和相关的数据流，确定测试点或测试接口，列示系统接口的可能瓶颈，一般是先主干接口再支线接口，并完成初步的测试用例设计。

第三，依据性能测试需求和确定的测试点进行测试组网设计，并明确不同组网方案的重要程度或优先级作为取舍评估的依据，必要时在前期产品设计中提出支持性能测试的可测试性设计方案和对测试工具的需求。

第四，完成性能测试用例设计、分类选择和依据用户行为分析设计测试规程，并准备好测试用例将用到的测试数据。

第五，确定采用的测试工具。

第六，进行初验测试，以主干接口的可用性为主，根据测试结果分析性能瓶颈，通过迭代保证基本的指标等测试的环境。

第七，迭代进行全面的性能测试，完成计划中的性能测试用例的执行。

第八，完成性能测试评估报告。

在进行性能测试的时候，我们需要知道一些有效的性能指标，下面我们来列出一些主要的性能指标：

一是，通用指标（指Web应用服务器、数据库服务器必需测试项）：

ProcessorTime：指服务器CPU占用率，一般平均达到70%时，服务就接近饱和；

Memory Available Mbyte：可用内存数，如果测试时发现内存有变化情况也要注意，如果是内存泄露则比较严重；

Physicsdisk Time ：物理磁盘读写时间情况。

二是，Web服务器指标：

Avg Rps：平均每秒钟响应次数＝总请求时间/秒数；

Avg time to last byte per terstion（mstes）：平均每秒业务角本的迭代次数；Successful Rounds：成功的请求；

Failed Rounds：失败的请求；

Successful Hits：成功的点击次数；

Failed Hits：失败的点击次数；

Hits Per Second：每秒点击次数；

Successful Hits Per Second：每秒成功的点击次数；

Failed Hits Per Second：每秒失败的点击次数；

Attempted Connections：尝试链接数。

三是，数据库服务器指标：

User 0 Connections ：用户连接数，也就是数据库的连接数量；

Number of deadlocks：数据库死锁；

Butter Cache hit：数据库Cache的命中情况）。

可用性测试：1导航测试（Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。）2图形测试3内容测试3整体界面测试4客户端兼容性测试（1平台测试2浏览器测试）5安全性测试（测试重点：（1）现在的Web应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。（2）Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。（3）为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。（4）当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。（5）服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。 ）

在开发中大型的JavaEE项目时，前后端分离的框架逐渐成为业界的主流，传统的单机部署前后端在同一个项目中的工程项目越来越少。这类JavaWeb项目的后端通常都采用微服务的架构，后端会被分解为诸多个小项目，然后使用bbozookeeper或者springCloud来构建微服务，前端则会是一个单独的项目，前台的请求通过微服务来调用。但是，不同与传统的web项目，这类前后端分离的项目如何在开发中部署和运行呢？

当前后端分离时，后端项目一定会被加载到tomcat的webapp目录下面，但是前端的资源院该如何被访问到呢？这里以tomcat这个中间件为例，探讨在开发这类项目的时候，如何让前后端分离的项目部署并且运行起来，即后端项目部署在tomcat之后如何在运行时访问静态资源（非上线部署）。

主要有两种方案：1在本地通过Nginx来处理这些静态资源。2、将静态资源统一放入一个javaweb应用中，并将自动生成的war包随后端项目一期丢入tomcat。下面详细介绍

一、使用Nginx来访问静态资源。

在本地安装nginx并且修改nginxconf，修改相关配置，将web访问的端口的资源进行更改，配置如下：

server{listen80;server_namelocalhost;charsetutf-8;#aess_loglogs/hostaesslogmain;

location/{proxy_passtomcat_pool;proxy_redirectoff;

proxy_set_headerHOST$host;

proxy_set_headerX-Real-IP$remote_addr;

proxy_set_headerX-Forwarded-For$proxy_add_x_forwarded_for;

client_max_body_size10m;

client_body_buffer_size128k;

proxy_connect_timeout90;

proxy_send_timeout90;

proxy_read_timeout90;

proxy_buffer_size4k;

proxy_buffers432k;

proxy_busy_buffers_size64k;

proxy_temp_file_write_size64k;

}

location~(html|htm|gif|jpg|jpeg|bmp|png|ico|txt|js|css|woff|woff2|ttf|eot|map)${

rootD:Workspacesesop-html;indexindexhtml;

}

listen对象改为你本地的tomcat访问端口，最下面location中的root改为你前端项目中静态资源的位置，这样就可以实现只部署后端的项目就能访问前端的页面了。

二、将前端项目转换为动态的web项目，随后端项目一起丢入tomcat

这个方案省去了在本地安装和配置nginx，但是也只适用于开发阶段项目的部署运行和调试，真正在生产环境通常前后端项目会部署在不同的服务器。

如果是IntellijIdea,在导入前端项目之后，右键项目addframeworksupport-->webapplication，这时将会把前端项目转换为一个javaweb项目，然后将静态资源放在生成的web目录下即可。

如果是eclipse，可以新建一个javaweb项目然后将静态资源放入web或者webcontent目录下，或者直接先导入前端项目，然后通过projectfacts将项目转换为dynamicweb项目并勾选js等相关配置。

然后，运行项目时把后端的war包和前端的war包一同添加到deployment中运行即可。

贴一篇我们内部的文章：

随着浏览器功能的不断完善，用户量不断的攀升，涉及到web服务的功能在不断的增加，对于我们测试来说，我们不仅要保证服务端功能的正确性，也要验证服务端程序的性能是否符合要求。那么性能测试都要做些什么呢？我们该怎样进行性能测试呢？

性能测试一般会围绕以下这些问题而进行：

1 什么情况下需要做性能测试？

2 什么时候做性能测试？

3 做性能测试需要准备哪些内容？

4 什么样的性能指标是符合要求的？

5 性能测试需要收集的数据有哪些？

6 怎样收集这些数据？

7 如何分析收集到的数据？

8 如何给出性能测试报告？

性能测试的执行过程及要做的事儿主要包含以下内容：

1 测试评估阶段

在这个阶段，我们要评估被测的产品是否要进行性能测试，并且对目前的服务器环境进行粗估，服务的性能是否满足条件。

首先要明确只要涉及到准备上线的服务端产品，就需要进行性能测试。其次如果产品需求中明确提到了性能指标，那也必须要做性能测试。

测试人员在进行性能测试前，需要根据当前的收集到的各种信息，预先做性能的评估，收集的内容主要包括带宽、请求包大小、并发用户数和当前web服务的带宽等

2 测试准备阶段

在这个阶段，我们要了解以下内容：

a 服务器的架构是什么样的，例如：web服务器是什么？是如何配置的？数据库用的是什么？服务用的是什么语言编写的？；

b 服务端功能的内部逻辑实现；

c 服务端与数据库是如何交互的，例如：数据库的表结构是什么样的？服务端功能是怎样 *** 作数据库的？

d 服务端与客户端之间是如何进行交互的，即接口定义；

通过收集以上信息，测试人员整理出服务器端各模块之间的交互图，客户端与服务端之间的交互图以及服务端内部功能逻辑实现的流程图。

e 该服务上线后的用户量预估是多少，如果无法评估出用户量，那么可以通过设计测试执行的场景得出这个值；

f 上线要部署到多少台机器上，每台机器的负载均衡是如何设计的，每台机器的配置什么样的，网络环境是什么样的。

g 了解测试环境与线上环境的不同，例如网络环境、硬件配置等

h 制定测试执行的策略，是需要验证需求中的指标能否达到，还是评估系统的最大处理能力。

i 沟通上线的指标

通过收集以上信息，确定性能测试用例该如何设计，如何设计性能测试用例执行的场景，以及上线指标的评估。

3 测试设计阶段

根据测试人员通过之前整理的交互图和流程图，设计相应的性能测试用例。性能测试用例主要分为预期目标用户测试，用户并发测试，疲劳强度与大数量测试，网络性能测试，服务器性能测试，具体编写的测试用例要更具实际情况进行裁减。

用例编写的步骤大致分为：

a 通过脚本模拟单一用户是如何使用这个web服务的。这里模拟的可以是用户使用web服务的某一个动作或某几个动作，某一个功能或几个功能，也可以是使用web服务的整个过程。

b 根据客户端的实际情况和服务器端的策略，通过将脚本中可变的数据进行参数化，来模拟多个用户的 *** 作。

c 验证参数化后脚本功能的正确性。

d 添加检查点

e 设计脚本执行的策略，如每个功能的执行次数，各个功能的执行顺序等

4 测试执行阶段

根据客户端的产品行为设计web服务的测试执行场景及测试执行的过程，即测试执行期间发生的事儿。通过监控程序收集web服务的性能数据和web服务所在系统的性能数据。

在测试执行过程中，还要不断的关注以下内容：

a web服务的连接速度如何？

b 每秒的点击数如何？

c Web服务能允许多少个用户同时在线？

d 如果超过了这个数量，会出现什么现象？

e Web服务能否处理大量用户对同一个页面的请求？

f 如果web服务崩溃，是否会自动恢复？

g 系统能否同一时间响应大量用户的请求？

h 打压机的系统负载状态。

5 测试分析阶段

将收集到的数据制成图表，查看各指标的性能变化曲线，结合之前确定的上线指标，对各项数据进行分析，已确定是否继续对web服务进行测试，结果是否达到了期望值。

6 测试验证阶段

在开发针对发现的性能问题进行修复后，要再执行性能测试的用例对问题进行验证。这里需要关注的是开发在解决问题的同时可能无意中修改了某些功能，所以在验证性能的同时，也要关注原有功能是否受到了影响。

想看原文或者有测试其他相关的问题可以关注下 搜狗测试 微信公众号，我们上面有不少关于性能测试分享~

以上就是关于如何对Web应用程序进行负载测试全部的内容，包括:如何对Web应用程序进行负载测试、Web自动化测试入门、如何：记录 Web 测试等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！