软件性能测试（连载4）

1.7 性能测试的判断标准

对于功能测试，判断测试用例是否测试通过，往往是比较容易的，只要不发生错误并且满足用户的需求即可。而对于性能测试该如何来评判性能测试是否通过呢？可以考虑以下三个方面。

•根据用户需求来判断。

如果用户对性能有明确的需求，比如登录操作，不得小于3秒，那么测试工程师就可以就这个需求来进行测试。另外系统运行过程不发生内存溢出、死锁等故障也应该属于隐性的性能需求。

•根据业内标准来判断。

比如第1.4-1节提到的2/5/10法则，前端响应时间不得超过全部响应时间的30%等都是业内不成文的性能标准。

•根据基准测试结果来判断。

一般而言，本次测试的度量指标不得小于上次版本的95%以下。

1.8性能测试的场景

一般根据性能测试的类型及各个类型的组合来设计性能场景，常见的性能测试场景如下。

•普通测试场景。

•并发测试场景。

•容量测试场景。

•疲劳测试场景。

•强度测试场景。

•配置测试场景。

•并发+疲劳场景。

一般采用65%-75%的并发峰值，持续测试48小时。

•容量+疲劳场景。

一般采用65%-75%的容量峰值，持续测试48小时。

•容量+并发+疲劳场景

65%的并发峰值，65%的容量峰值，持续测试48小时。

•多业务测试场景。

有多个业务组合形成的测试场景，一般将前面的性能场景测试完毕以后再进行，否则发生问题难于定位。

1.9 性能测试的干系人

由于各种原因都可能造成性能问题，所以性能测试干系人包括。

•客户代表。

•产品经理。

•销售人员。

•市场人员。

•项目经理。

•研发人员。

包括需求分析师、架构设计师、开发工程师、测试工程师等。

•运维人员。

包括DBA、技术支持工程师等。

1.10 负载测试的二分法找拐点法

负载测试包括并发测试和容量测试，寻找性能拐点往往是这种测试的关键。以往寻找拐点往往采取递进法，即给出一个起点，比如500个并发用户，进行并发测试，如果通过，再加100，变成600个并发用户，进行并发测试。通过这样的方法进行层层递进来寻找拐点。可以想象一下，如果并发拐点为3000，岂不需要测试25次才可找到拐点。这里来介绍二分法找拐点的方法。

二分法找拐点的方法请参看图3-17所示。

图3-17 二分法找拐点的方法

（1）寻找m,n两个值，其中m<n,建议初始的时候m与n之间的差距拉得大一些。

（2）对m进行并发/容量测试。

（3）如果m测试不通过，说明拐点比m小，寻找新的m值a，假设以前测试过的最小值为x（如果没有，令x=0）。那么a=( m + x)/2，返回第（1）步。

（4）如果m测试通过，说明拐点比m大，对n进行并发/容量测试。

（5）如果n测试通过，说明拐点比m大比n小，选择新的n值a，a=(m+n)/2，返回第（1）步。

（6）如果n测试不通过，说明拐点比n大，寻找新的n值b，假设以前测试过的最大值为y（如果没有，令y=∞）。那么a=( n + y)/2，返回第（1）步。

（7）当n-m<=某一固定的值，当前值即为拐点值，递归结束。

案例3-10：负载测试的二分法找拐点法

使用二分法测试寻找并发测试的拐点，如果n-m<50，即为找到拐点。

（1）令m=1000, n=5000，对1000进行并发测试，持续10分钟，没有发现异常，测试通过，说明拐点比1000大。

（2）对5000进行并发测试，持续10分钟，发现异常，测试失败，说明拐点比5000小。此时n-m=5000-1000=4000>50。

（3）选择新的n=(1000+5000)/2=3000，此时n-m=5000-3000=2000>50，对3000进行并发测试，持续10分钟，发现异常，测试失败，说明拐点比1000大但比3000小。

（4）选择新的m=(1000+3000)/2=2000，此时n-m=3000-2000=1000>50，对2000进行并发测试，持续10分钟，没有发现异常，测试通过，说明拐点比2000大但比3000小。

（5）选择新的m=(2000+3000)/2=2500，此时n-m=3000-2500=500>50，对2500进行并发测试，持续10分钟，没有发现异常，测试通过，说明拐点比2500大但比3000小。

（6）选择新的m=(2500+3000)/2=2750，此时n-m=3000-2750=250>50。对2750进行并发测试，持续10分钟，没有发现异常，测试通过，说明拐点比2750大但比3000小。

（7）选择新的m=(2750+3000)/2=2875，此时n-m=3000-2875=125>50。对2875进行并发测试，持续10分钟，没有发现异常，测试通过，说明拐点比2875大但比3000小。

（8）选择新的m=(2875+3000)/2=2938，此时n-m=3000-2938=62>50。对2938进行并发测试，持续10分钟，没有发现异常，测试通过，说明拐点比2938大但比3000小。

（9）选择新的m=(2938+3000)/2=2969，此时n-m=3000-2969=31<50，所以认为并发拐点为2938。

这样仅对8个数值进行了测试就找到了拐点。

另外需要说明的是并发测试的拐点没有容量测试那么明显，所以在找到拐点之后，需要对这个值进行多次验证，确保是真正的拐点。而容量测试的拐点往往表现特别明显，拐点上与拐点下的性能表现得很明显。

1.11 全链路压测

正如第1.2-3节描述，2018年双11，淘宝“退货退款”模块瘫痪。对于“退货退款”模块往往是一个被忽视的性能测试模块，但是自从这个事故发生之后。各大互联网公司对全链路压测试得到了非常重视。京东、淘宝、腾讯等网商企业现在都在双11到来之前至少半年就开始筹划全链路压测了。全链路压测往往在晚上00:00-5:00在线进行测试，但是也要看公司具体而定。由于LoadRunner是通过并发用户的License收费的，并且收费是相当昂贵的。而JMeter是一个基于Java多线程来实现虚拟用户的开源工具，自身就占用很多的系统资源，所以也被排除。而现在作为全链路压测工具基本上选用Gatling。

Gatling是一个开源的基于Scala、Akka、Netty 实现的高性能压测框架，较之其他基于线程实现的压测框架，Gatling 基于AKKA Actor 模型实现，请求由事件驱动，在系统资源消耗上低于其他压测框架（如内存、连接池等），使得单台压测机可以模拟更多的用户。

另外由于全链路压测是在线上进行的，所以要确保测试数据与真实数据分离，在全链路压测完毕，需要把压测数据全部删除。