写在前面：本人具有测试行业9年软件测试经验，其中对于Web端和移动端都有过丰富的项目经验。经常会有小伙伴来问我，他们的区别到底是什么，还有的没做过这方面的测试想去尝试一下，会来问我需要注意什么，写出来给需要的小伙伴参考一下，个人经验分享，欢迎大家来留言区讨论交流。


 

1、系统架构

WEB端：B/S结构，WEB端的前端一般不做端的区分。WEB端的上线不管是预发布还是N环上线，server上线后，前端同步更新，一般是不存在多个版本的问题；

移动端：C/S结构，移动端的前端分为安卓端&iOS端。移动端的server上线后，客户端还是存在多个版本，需要考虑旧版本兼容&回测问题

2、抓包工具

WEB端：WEB端有个比较方便的方法可以查看前端请求的接口：Chrome浏览器里打开检查，可以从network里直接查看前端请求的接口。当然也可使用抓包工具抓取请求。

移动端：移动端常用的的抓包工具有Charles、fiddler等，可以通过连接代理等方式抓取请求

3、UI自动化

WEB端：WEB端常见的就是 unnitest + selenium 了，需要安装所需要浏览器的driver

移动端：移动端常见 appium，是在selenium的基础上发展而来，当然还有一些封装的很不错的工具，例如网易出品的基于图像识别和 poco 控件识别的 Airtest

4、接口自动化

WEB端：WEB端的接口相对简单

移动端：需要带上version/productid等参数信息，因为可能会有新旧版本兼容等问题，不同版本可能会出现返回不一样的情况。需要有 client 信息，Android/iPhone/iPad，一般可以提取成环境变量单独存放

5、性能

WEB端：WEB端的性能更注重页面响应速度，一般会用JMeter

移动端：更注重并发、qps、耗电量等指标，同样也会用JMeter，另外也有集成好的PerfDog等工具可应用

6、兼容

WEB端：更侧重于电脑系统、浏览器类别/版本的兼容

移动端：更侧重手机系统版本、品牌、屏幕尺寸、分辨率等的兼容

7、安全

WEB端：常用工具：BurpSuite、appcheck、appscan等（目前我就接触过这几个哈哈）

移动端：有一些第三方的加固可以接入例如：360加固，爱加密等；可根据项目的需求调研选择，有一点副作用就是可能会带来crash率的一点点上升，接入后需要比较全面的回归测试

8、app测试更注重的一些方面


　　安装、卸载、覆盖安装（关注缓存）、冷启动/热启动等

　　中断事件（返回，画面、音频的打断，电话、锁屏、切后台等操作）

　　操作类型：手势（左滑右滑上滑下滑，拖动，长按，多点触控）

　　网络状况：4G/Wi-Fi，网络切换，弱网，断网

　　权限：拍照、录音等需要权限

　　安装包的大小

　　横竖屏翻转


　　app大多是直接面向用户的，所以交互体验比web端的要求要高许多，同时一些网络情况、内存等影响因素比较多且复杂，所以一些容错的处理也非常重要。

	

作为QA，你了解性能测试么？做过性能测试么？如果都没有，那你是否觉得性能测试很神秘呢？再细分到web性能测试我们又该如何测试呢？接下来我将主要介绍一下Web端性能测试各阶段需要注意和考虑的问题。希望对新手朋友有一些帮助。
1、对测试系统进行分析，明确需要对什么进行压力测试(接口？web页面？)
接口：接口中有哪些参数，各含义，是可选项还是必选项，取值范围，是计算密集型，还是IO密集型，期望性能等；
Web页面：包含哪些接口，涉及哪些服务，期望性能等；
2、明确被测对象后，考虑测试环境
a)   被测服务环境是否独立【一般情况下，被测服务的环境尽量与其他服务分开】
b)   被测对象是否有缓存【要根据实际情况，确定压测过程中是否开启缓存】
详细说明：首先要了解缓存的有效期，真实的环境中命中缓存的比例大概是多少；不带缓存压测，可知晓系统的最差性能。带缓存压测，数据集的选取非常重要。
c)   发压机与被测环境要在同机房【简单的ping命令，查看大概的访问延时】
d)   服务是否有些安全机制【例如：同一ip的访问次数限定，同一用户的操作频率限定】，影响性能测试的因素，在测试前需要关闭。
e)   host检查(避免压到线上)
3、详细分析被测对象，编写压测脚本
a)   请求是http还是https  (ssl, https压不去 | 走http请求  例如：大搜，走IE6 User-Agent)   (https   可以压页面)      
b)   服务是否与登录有关【登录用户的操作，需要在请求的header中增加cookie字段，标识用户的状态等信息】
详细说明：
  很多页面在登录与不登录的情况下处理方式是不同的；有些页面也只有登录用户才可以访问；页面的逻辑与用户的等级等状态有关。
  如何获取cookie，fiddler抓包，拷贝整个消息头部的cookie字段。
  涉及cookie字段的，要注意相关参数的有效期，压测前检查是否失效。
(jmeter设置cookie及相关cookie文件，如下图)
(Fiddler抓包，获取cookie信息，如下图)
c)   有些服务，会检查refer，hostname等参数，压测脚本中需要在header中增加这些字段
d)   前端页面，有时不同的User-Agent也会影响实际的业务。此时也需要固定请求header中的UA字段
e)   增加断言【检查业务错误率】
详细说明：
  jmeter错误率统计的是请求返回非200的情况，但是对于web端而言，在有异常情况的时候，都会有相关的处理方式(例如：302重定向到其他页面)，最终不会返回非200。需要设置断言，判断返回页面是否符合预期。
  设置断言，检测返回结果中，是否包含某些参数或值
(jmeter设置断言举例，如下图)
f)   设置日志【设置相关内容的记录与否】
g)   利用jmeter常用函数，提高效率
常用函数介绍：
时间：
${__time(,)} 1450056496991   //无格式化参数，返回当前毫秒时间为整数 
${__time(yyyyMMdd,)} 20151214 //返回年月日 
${__time(HHmmss,)}  092816 //返回时分秒 
${__time(yyyyMMdd-HHmmss,)} 20151214-092816 //全 
random_tt=${__time(,)}_${__threadNum}
进程：
${__threadNum}
随机数：
${__Random(1,100,fun1)}
编码：
${__urlencode(${q})}
可变参数如进程数等，NUM_THREADS为自己起的名字
${__P(NUM_THREADS)}
对于此种参数传参时为：
/da1/dongshiyue/jmeter3.0/bin/jmeter.sh -JNUM_THREADS=$1 -JDURATION=$2 -JFILE=$3 -JDOMAIN=$4 -JPORT=$5 -JPATH=$6  -n -t ../tusoujmx/tusou_stable_search.jmx
实际应用场景：有时为了方便定位问题，会在请求的url中，增加一个唯一的随机参数，格式：randomtt=${__time(,)}_${__threadNum}，参数是由时间戳和进程号组合(如下图)。
 4 、准备测试数据集
a)   压测数据集是性能测试的重中之重，压测数据直接影响测试的价值与可行度
b)   多个参数的各种组合情况是否覆盖【tips：多个参数多个文件引入时，如果是倍数关系，很多组合情况覆盖不到，需要将各种组合情况列在一个文件中，以参数个数的形式引入】
c)   Query类的压测，测试数据集的选用，需要考虑的问题
query 是否需要去重【去重后的query，在一轮测试中，不会命中缓存】
query 使用线上真实的流量，即从线上日志中获取，不进行去重，能够完整的模拟线上流量
特殊字符集【特殊字符可能会导致服务挂掉，影响稳定性，常见的一些特殊字符：空格，特殊字符，半角全角符号，其他语言文字等】
网络攻击字符集【主要是一些js注入，SQL注入，XSS攻击的语句】
d) 涉及用户状态或等级等功能，准备的cookie数据要涉及不同情况，用户等级的比例也要通过cookie数据的个数进行控制。
5、进行尝试，确定压测脚本和数据集
a)   1-4步完成后，开启日志设置中的responseData等参数，压测一轮。检查返回的数据是否符合预期。【可以检查参数是否正确，cookie是否生效等】
b)   通过尝试，确定并发数
c)   修改日志设置，关闭responseData，开始压力测试。
其他注意点：
(keep-alive  默认是长链接) 跟开发沟通 是否是长链接
a)   涉及到特殊字符等压测数据，最好将测试数据urlencode之后使用。Jmeter本身的编码功能，对一些特殊字符的支持不是很好，测试会中断。
b)   压测web页面，页面较大时，为了避免，打满带宽，导致压力上不去的情况，要设置header中的Accept-Encode字段，用压缩形式。
c)   Jmeter设置的path中，如果包含一些特殊字符例如：&、>、< 等一定要用html实体字符的形式，例如：& --> & > --> >  < --> <
d)   不熟悉jmx文件的情况下，可以通过windows图形化jmeter界面配置，生成的jmx可直接使用，只需修改路径即可(注意jmeter版本保持一致)。

性能测试重要的是如何发压，在什么样的环境下进行，用什么样的流量进行压力测试。接下来主要介绍一下Web端性能测试各阶段需要注意和考虑的问题：

1.  对测试系统进行分析，明确需要对什么进行压力测试（接口？web页面？）

详细说明：

Ÿ  接口：接口中有哪些参数，各含义，是可选项还是必选项，取值范围，是计算密集型，还是IO密集型，期望性能

Ÿ  Web页面，包含哪些接口，涉及哪些服务，期望性能

2.  明确被测对象后，考虑测试环境

a)   被测服务环境是否独立【一般情况下，被测服务的环境尽量与其他服务分开】

b)   被测对象是否有缓存【要根据实际情况，确定压测过程中是否开启缓存】

详细说明：首先要了解缓存的有效期，真实的环境中命中缓存的比例大概是多少；不带缓存压测，可知晓系统的最差性能。带缓存压测，数据集的选取非常重要。

c)   发压机与被测环境要在同机房【简单的ping命令，查看大概的访问延时】

d)   服务是否有些安全机制【例如：同一ip的访问次数限定，同一用户的操作频率限定】，影响性能测试的因数，在测试前需要关闭。

3.  详细分析被测对象，编写压测脚本

a)   请求是http还是https

b)   服务是否与登录有关【登录用户的操作，需要在请求的header中增加cookie字段，标识用户的状态等信息】

详细说明：

Ÿ  很多页面在登录与不登录的情况下处理方式是不同的；有些页面也只有登录用户才可以访问；页面的逻辑与用户的等级等状态有关。

Ÿ  如何获取cookie，fiddler抓包，拷贝整个消息头部的cookie字段。

Ÿ  涉及cookie字段的，要注意相关参数的有效期，压测前检查是否失效。

（jmeter设置cookie及相关cookie文件，如下图）





（Fiddler抓包，获取cookie信息，如下图）



c)   有些服务，会检查refer，hostname等参数，压测脚本中需要在header中增加这些字段

d)   前端页面，有时不同的User-Agent也会影响实际的业务。此时也需要固定请求header中的UA字段

e)   增加断言【检查业务错误率】

详细说明：

Ÿ  jmeter错误率统计的是请求返回非200的情况，但是对于web端而言，在有异常情况的时候，都会有相关的处理方式（例如：302重定向到其他页面），最终不会返回非200。需要设置断言，判断返回页面是否符合预期。

Ÿ  设置断言，检测返回结果中，是否包含某些参数或值

(jmeter设置断言举例，如下图)



f)   设置日志【设置相关内容的记录与否】

g)   利用jmeter常用函数，提高效率



常用函数介绍：



时间：

${__time(,)}         1450056496991 //无格式化参数，返回当前毫秒时间 

${__time(yyyyMMdd,)} 20151214      //返回年月日 

${__time(HHmmss,)}   092816        //返回时分秒 

${__time(yyyyMMdd-HHmmss,)} 20151214-092816 //全 

进程：

${__threadNum}

随机数：

${__Random(1,100,fun1)}

编码：

${__urlencode(${q})}



        实际应用场景：有时为了方便定位问题，会在请求的url中，增加一个唯一的随机参数，格式：randomtt=${__time(,)}_${__threadNum}，参数是由时间戳和进程号组合（如下图）。




 4.  准备测试数据集

a)   压测数据集是性能测试的重中之重，压测数据直接影响测试的价值与可行度

b)   多个参数的各种组合情况是否覆盖【tips：多个参数多个文件引入时，如果是倍数关系，很多组合情况覆盖不到，需要将各种组合情况列在一个文件中，以参数个数的形式引入】

c)   Query类的压测，测试数据集的选用，需要考虑的问题

Ÿ  query 是否需要去重【去重后的query，在一轮测试中，不会命中缓存】

Ÿ  query 使用线上真实的流量，即从线上日志中获取，不进行去重，能够完整的模拟线上流量

Ÿ  特殊字符集【特殊字符可能会导致服务挂掉，影响稳定性，常见的一些特殊字符：空格，特殊字符，半角全角符号，其他语言文字等】

Ÿ  网络攻击字符集【主要是一些js注入，SQL注入，XSS攻击的语句】

d） 涉及用户状态或等级等功能，准备的cookie数据要涉及不同情况，用户等级的比例也要通过cookie数据的个数进行控制。

5.  进行尝试，确定压测脚本和数据集

a)   1-4步完成后，开启日志设置中的responseData等参数，压测一轮。检查返回的数据是否符合预期。【可以检查参数是否正确，cookie是否生效等】

b)   通过尝试，确定并发数

c)   修改日志设置，关闭responseData，开始压力测试。

其他注意点：

a)   涉及到特殊字符等压测数据，最好将测试数据urlencode之后使用。Jmeter本身的编码功能，对一些特殊字符的支持不是很好，测试会中断。

b)   压测web页面，页面较大时，为了避免，打满带宽，导致压力上不去的情况，要设置header中的Accept-Encode字段，用压缩形式。

c)   Jmeter设置的path中，如果包含一些特殊字符例如：&、>、< 等一定要用html实体字符的形式，例如：'&'--> &amp; '>' --> &gt;  '<' --> &lt;

d)   不熟悉jmx文件的情况下，可以通过windows图形化jmeter界面配置，生成的jmx可直接使用，只需修改路径即可（注意jmeter版本保持一致）。







e)   其他资料：http://ferriswheelgyh.blogspot.com/2016/12/jmeter-rcnon-http-response-code.html

       函数：http://jmeter.apache.org/usermanual/functions.html#__P

       教程：http://www.hissummer.com/loadtesting-jmeter.html



jmeter使用技巧：

1）限定数据跑1遍就停止



2）限定请求个数



3）Post 请求  （传json 数据）





4）固定QPS不生效

什么是性能测试？web性能应该注意些什么？

性能测试，简而言之就是模仿用户对一个系统进行大批量的操作，得出系统各项性能指标和性能瓶颈，并从中发现存在的问题，通过多方协助调优的过程。而web端的性能测试应该注意的指标有：用户操作的响应时间、系统的吞吐量（TPS）、系统的硬件资源情况（CPU、硬盘、磁盘）、网络资源占用情况等。

web性能测试之HTTP请求
关于性能测试中，HTTP请求类的性能指标都需要我们去关注些什么？
响应时间，这里的响应时间一定得是前端+后端的响应时间，我们惯性的思维都是只关注后端服务的响应时间，其实前端的响应时间也是须考虑在内的。

并发测试的相应数据，这部分也得考虑前端数据，这只是一个大概的补充，因为具体的系统需要的数据不一样，其中也不乏包括响应时间。

其中，前端的响应时间都涉及到哪些环节呢？
DNS解析
各种请求的连接
TLS的建立
字节流的发送

另外，后端响应时间涉及的环节：
等待（前端请求）
接收信息流
返回响应数据
这其实就是一个比较完整的web端请求所需要的环节，而响应时间就是指的这个请求的过程所花费的时间。这部分时间就是一个用户在操作的时候所等待的时间，所以用户所能接受的时间范围恰好是性能测试所关注的时间范围。通常用户所能接受的系统响应时间是3-5s，若大于这个时间节点，将会使用户失去耐心，取消对系统的操作。

web性能测试之Jmeter
Jmeter属于一个非常实用的测试工具，在性能测试当中也占有一个非常重要的位置。通常jmeter在性能测试过程中，涉及到的基本是直接对接的后端服务，针对前端的响应基本不会涉及，所以用jmeter来对一个web系统进行性能测试时，很难去捕获到前端的响应数据。但是后端响应数据获取起来非常的便捷，其中就包括：并发数、平均响应时间、错误率、吞吐量等等，如下图：



那么，关于前端的响应数据，我们该用什么方法去获取呢？接下来讲的一种方法，就是利用LR来进行。

web性能测试之Loadrunner
Loadrunner则是属于企业软件，这就奠定了它功能繁多，用途广泛的基础。LR算是一个大型的性能测试工具了，但是平常使用也还是其基本的一些功能。LR在用户界面交互上进行了注重，也就是我们之前提到的前端的响应数据，利用LR能够弥补jmeter无法涉及到的前端响应时间这部分，通过更接近用户对界面的交互，得出前端发起请求到请求发送到后台服务这个过程的响应时间。所以，这前后端两部分的响应时间之和，就是我们基本能够判定一个系统真正响应时间的依据。

web性能测试之响应时间
结合以上提及到的响应时间，它所涉及到的有两个部分，一是前端，二是后端：


关于整体系统压测策略
那提及到系统压测的策略，其实是想提一下怎样去利用单节点和集群这两种方案。通常的压测，都是采用的单节点来进行的，这样“以小见大”的方法不为一个不可采取的方法，但是这其中还是会造成很多的误差。还有就是，单节点的压测容易压低整个系统的性能指标，因为无法充分的利用系统资源。

而集群压测，在环境部署上是一个复杂点，但是能够充分利用系统已有资源，这样得出的数据能够更加真实有效。在有过量的时间时，可以讲单节点和集群的压测数据进行对比，这样就能发现其中存在的差异。

关于性能测试日志
性能测试中，日志是非常能够反应出测试工作中问题所在的一个环节，通过查看日志来定位问题是一个繁杂但是极为可靠的方式。

此类测试中，都会涉及到哪些日志呢？



Jmeter端日志
HTTP端打到Nginx端的日志，这层会涉及到来源IP、请求地址、响应时间等。
Tomcat层日志
Server层日志

关于OS层数据监控
CPU监控，通常的指标是CPU使用率不能超过80%，这样给系统预留一个缓冲的范围。这里提及一点，就是其中涉及到多核CPU的情况，严谨的人会去关注每核CPU的使用情况，因为很多时候多核CPU的利用并不是均衡的，整体的CPU使用情况不能反映出单核的使用情况，容易造成误导。

JVM层监控，这主要是去监控线程，其中包含单线程、多线程，同步线程、异步线程。关于同步线程和异步线程，是一个系统中比较关注的点，假如：一个系统处理事务时，采用的是同步线程，很多事务会等待处理造成阻塞，那么这样的系统处理速度就会受到很大的限制，会被视为一个不合格的系统。

以上算是记录一下从多方面去考虑web性能测试的各个点，从而使测试结果更加真实有效。