web性能测试你问我答之测试执行

关于平台使用

Q：性能测试平台是什么

A： 性能测试平台是杭研质量保障部性能测试组和测试开发组共同开发的的一个平台。它的作用简单来说就是把脚本执行、资源监控、性能测试结果整合在一起，实现自动化性能测试。当然还有很多其他的功能，比如说性能数据的质量看板、版本质量报告等。

平台上有以下几个概念：

• 项目：通常一个产品就是一个项目，这些数据是和QA大平台打通的，只要你在其他的平台（如质量度量平台等）上有该项目的权限，就同样可以在性能测试平台上看到该项目，如果没有，也可以找管理员创建项目。
• 模块：通常模块都是产品内部已经定义好的，比如对于NOS产品来说，存在tobie、proxy等模块，其他的一些产品如果不存在这些内容也可以自定义。
• 场景：测试场景是我们在测试指定测试方案时设计好的，一般情况下一个测试点称之为一个场景，可以是单接口，也可以是组合场景或者混合场景
• 轮次：每一次测试执行我们都需要创建一个轮次，轮次中需要指定测试脚本、并发线程数、测试时长等。

四者之间的关系：轮次属于场景，场景属于模块，模块属于项目。

Q：如何使用性能测试平台

A： 根据上面介绍的平台的一些基本概念，那么使用性能测试平台时，首先要创建项目、模块、场景。然后在测试场景中创建轮次，设定并发线程数、执行时间和上传测试脚本等。

除此之外，还需要管理执行测试时需要的机器，机器的管理一般有以下步骤：

1. 首先需要提供两种机器，一种是运行grinder的压测机，一种是运行被测服务的服务器。这两种机器不应该是同一个机器。
2. 在所有的机器上部署staf，参考：一键式部署STAF文档
3. 在性能测试平台的机器管理地方，创建机器，注意添加时填写的ssh账号最好是公共账户，并且和运行STAF的用户是同一个，服务器地址推荐使用域名形式。
4. 添加完成后，可以勾选机器，运行检测STAF，查看是否成功。如果STAF运行不成功的话，是无法执行测试的。
5. 创建轮次的时候，是需要选择机器的，测试机即运行grinder的机器，服务器即运行被压测服务的机器。一定不要搞错。如果是多台测试机的话，并发数等于你设置的并发用户的两倍的：另外，请切记，如果是直接通过域名进行压测的话，需要记得在测试机/etc/hosts下设置对应的hosts

Q：平台上的一些指标是什么含义

A： 这儿我们主要介绍下测试轮次的结果数据。

业务指标

• TPS：每秒钟完成的请求次数
• MRT：所有成功请求次数的平均响应时间
• RT 90值：90%的请求小于的响应时间
• RT 99值：99%的请求小于的响应时间
• 失败率：请求失败的比例
• TPS曲线：测试执行过程中，基于TPS得到的曲线图
• 响应时间分布：测试执行过程中，基于响应时间得到的分布图，包含均匀分布和指数分布

资源指标：轮次中添加的所有数据都有资源使用情况的统计，这些统计基本上来源于sysstat统计的结果值，包含常见vmstat、iostat、top、sar等，主要包含：

• CPU：load average、CPU使用率、上下文切换等
• 内存：SI、SO等
• 磁盘：IO、wait、util等
• 网络：流量和连接数等

Q：使用平台遇到问题怎么办

A：

群：1221386

任何问题都可以在该群里反馈，嗯~

Q：测试过程中应该设置多少的并发

A： 一般我们测试一个产品时，会首先进行压力测试，而测试的第一阶段即进行冒烟测试，快速的发现可能存在的问题。所以在我们的测试脚本中，一般情况下不会设置sleep time。

这种情况下，一般可以设置20个并发作为第一次测试的并发数。如果测试结果显示系统资源未达到瓶颈点或者性能指标在可接受范围内（MRT小于200ms），那后续可以继续增加并发进行压测，如果测试结果显示某个资源成为瓶颈点或者性能指标不可接受，那么就需要通过各种手段去定位性能问题。

并发增加的幅度，一般情况下是可以成倍增加下看看的，比如说从20增加到40或50等，当然也要基于当期的系统指标等综合考虑。

Q：测试到什么程度可以终止测试

A： 并发数并不是越高越好的，测试轮次也不是越多越好，在测试过程中应该及时分析你的测试结果，终止测试。一般情况下，以下几种情况，需要终止测试

• 某个别资源已经成为瓶颈点，例如CPU使用率已经达到90%以上，继续增加并发的话，性能也不会提升很多。
• 响应时间已经达到不可接受的值，例如MRT的响应时间已经超过1s，继续增加并发的话，MRT变的更长。

这两种情况下，我们都没有必要继续增加并发再测试下去，因为后面的轮次都会成为无用轮次，浪费时间。

测试终止后，要分析下整体的测试结果，当前的结果是否满足预期，是否达到了期望值？

第一种情况：虽然CPU使用率已经达到90%，但是TPS值远远超过了产品方的预期，那么该测试结果是可以接受的，该接口不存在性能问题，测试可以结束。 但是如果CPU使用率比较高，但是TPS又没有达到产品的预期，那么就需要进一步定位原因。

第二种情况：同样需要查看下，是否已经达到产品方的预期。如果没有的话，就说明接口有性能问题了，我们需要借助哨兵等各种工具进行进一步定位。

日志监控

Q：测试过程中需要监控哪些日志

A：

1. grinder日志：在压测机对应的测试轮次所在的文件夹的logs目录下
2. nginx日志（前端代理服务器）：SA统一部署的话，一般在/var/log/nginx/ 目录下，需要同时注意access 和 error两种日志
3. tomcat日志（应用服务器）：可能在tomcat所以在的logs下，也可能是log4j配置文件中定义的其他位置，这个可以提前找开发确认好。
4. 后端依赖服务的日志：如果有权限的话，也可以去观察下依赖服务对应的日志。

观察日志是个好习惯：

1. 可以帮我们提前发现错误，提高测试效率：例如如果测试脚本写的有问题，及时观察了grinder日志就可以及早的指导，终止测试，修改好后重新再来。
2. 可以给定位问题非常有效的帮助：例如nginx的error日志，如果发现cannot assign address，那可以提示我们是连接建立的端口号不够用，或者 connect upstream timeout，可以提示我们可能是后端服务处理太慢，线程池满导致的。

总体来说，我个人认为，观察日志是最简单、最有效、也是必须掌握的一种技能。

Q：如何监控日志

A：

1. 一般情况下，我们自己tailf | grep Exception，或者偶尔vim上去find下错误，但是这样可能会导致系统磁盘等资源开销过大
2. 同时还可以借助哨兵的日志监控
3. 另外推荐下，性能测试组杰哥开发的：日志监控平台，也是个监控日志的好手段

Q：推荐的日志配置格式

A：

1. 针对grinder脚本：
   1. 使用grinder.logger输入日志
   2. 测试脚本正式执行时不要存在print大量的数据
   3. 判断结果的正确性，输出错误信息方便定位问题
2. nginx日志格式推荐：

   1. log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" "X" ''"$host" $upstream_response_time $request_time "$http_user_agent"';
      

   2. 配置upstream_response_time 以及 request_time
      1. upstream_response_time：nginx向后端建立链接开始到接受完数据的时间，主要只tomcat等应用层的处理时间
      2. request_time：从接收用户请求到发送完成返回数据的时间
      3. 通过这两个值的比较，可以分析到问题主要在哪一层
3. tomcat日志格式：
   1. 开启access日志
   2. log4j配置的使用：不要输出性能影响过多的参数，

资源监控

Q：测试过程中需要监控哪些服务器

A：

1. 运行grinder的测试机
2. 运行被测服务的服务器
3. 后端依赖服务

Q：需要监控服务器资源的哪些指标

A：

1. CPU
2. 内存
3. 网络
4. 磁盘

使用的监控命令；

1. vmstat
2. top
3. iostat
4. mpstat
5. sar

Q：什么情况下说明系统资源已经成为瓶颈点

A：

参见测试白皮书中的通过标准。

网易云新用户大礼包：https://www.163yun.com/gift

本文来自网易实践者社区，经作者侯本文授权发布。