接上篇:https://testerhome.com/topics/21438
其它参考博客:https://www.cnblogs.com/clockq/p/10539974.html
上篇简单介绍了如何创建一个 Gatling 工程,并写了一个简单的例子。但是实际应用过程中,需要动态配置接口请求并发量、请求时间等等。那么下面我们来改造一下:
(1)工程目录如图
(2)测试脚本
package test.scala
import java.lang.Double.parseDouble
import java.lang.Integer.getInteger
import io.gatling.core.Predef._
import io.gatling.http.Predef._
import io.gatling.core.structure.PopulationBuilder
class BaiduSimulation extends Simulation {
val userCount = System.getProperty("userCount").toDouble
val duringTime = System.getProperty("duringTime").toInt
val startUserCount = System.getProperty("startUserCount").toDouble
val rampDuringTime = System.getProperty("rampDuringTime").toInt
val httpConf = System.getProperty("url")
// 初始化协议
val url = http.baseUrl(httpConf).shareConnections
// 测试用例
def scnBaidu = scenario("Baidu")
.exec(
http("Baidu")
.get("/")
.check(status.is(200))
)
var setUpList = List[PopulationBuilder]()
// // 恒定模型:QPS以设定的userCount值进行恒定压力测试,时长during
// setUpList :::= List(
// scnBaidu.inject(constantUsersPerSec(userCount) during(duringTime)).protocols(url)
// )
// // 爬升模式:QPS从指定的startUserCount值开始,在时长rampDuringTime内匀速爬升到QPS值为userCount,即停止测试
// setUpList :::= List(
// scnBaidu.inject(rampUsersPerSec(startUserCount) to (rampDuringTime) during(duringTime)).protocols(url)
// )
// 混合模式:先爬升,再恒定
setUpList :::= List(
scnBaidu.inject(rampUsersPerSec(startUserCount) to (userCount) during(rampDuringTime),
constantUsersPerSec(userCount) during (duringTime)
).protocols(url)
)
// 执行所有case
setUp(setUpList)
// run: mvn gatling:test -DLOG_LEVEL=WARN -DuserCount=10 -DduringTime=100 -DstartUserCount=0 -DrampDuringTime=20 -Durl=https://www.baidu.com -DtestClass=BaiduSimulation
}
(3)命令行执行
mvn gatling:test -DLOG_LEVEL=WARN -DuserCount=10 -DduringTime=100 -DstartUserCount=0 -DrampDuringTime=20 -Durl=https://www.baidu.com -DtestClass=BaiduSimulation
(4)查看测试报告
找到 target/gatling 目录下面的 baidusimulation-2019xxxxxxxx 的测试报告,在浏览器中输入/Users/xiaoxaio/Projects/Testing/TestGatling/target/gatling/baidusimulation-20191230122927532/index.html 即可查看最终的测试报告
(5)报告分析
10 个用户的请求响应基本都落在 t<800ms 内,KO 失败率 0%,95 分位(表示 95% 的请求不大于 31ms)响应时间 31ms,99 分位响应时间 86ms。最慢的请求响应 1010ms,平均响应时间 13ms。