对移动应用后端API进行性能测试，不是简单模拟HTTP请求。要求测试工具能模拟移动网络的不稳定性、移动设备的资源限制以及真实用户的行为模式。
一，移动应用后端
和传统Web后端不同，移动后端面临：
网络环境多变：需要在Wi-Fi、4G/5G、弱网（高延迟、低带宽）间无缝切换，并处理频繁的断线重连。
用户行为：用户会话通常更短、更频繁（碎片化使用），并伴随特定的操作序列（如启动App->刷新内容->点赞->退出）。
API设计：大量使用短连接、推送通知、分页、数据同步和二进制协议（如Protocol Buffers）。
设备和系统碎片化：需处理海量设备标识、操作系统版本和推送Token。
二、 使用Gatling精准模拟移动网络特性
这是和桌面测试本质的区别。Gatling的throttling机制和连接管理是关键。
import scala.concurrent.duration._ import io.gatling.core.Predef._ import io.gatling.http.Predef._ class MobileAPIPerformanceTest extends Simulation { val httpProtocol = http .baseUrl("https://api.zmtests.com") // 1. 模拟移动网络连接池特性：连接数少，生命周期短 .disableCaching // 移动App通常自主控制缓存 .maxConnectionsPerHost(10) // 模拟移动设备有限的并行连接数 .shareConnections // 更真实地复用连接 // 2. 设置全局超时，模拟移动用户耐心 .requestTimeout(5.seconds) .connectTimeout(3.seconds) val scn = scenario("模拟移动用户典型会话") .exec( http("启动App - 获取配置") .get("/api/v1/config") .header("User-Agent", "YourApp/1.0 (iPhone; iOS 15.4)") .header("Device-ID", "${deviceId}") // 动态设备ID ) .pause(2.seconds) // 模拟用户阅读时间 .exec( http("刷新信息流") .get("/api/v1/feed?page=1") .header("Authorization", "Bearer ${authToken}") .check(jsonPath("$.nextCursor").saveAs("nextCursor")) // 处理分页 ) // 3. 注入网络节流：模拟特定网络类型 .during(5.minutes) { // 模拟不稳定的4G网络：下载100 Mbps，上传20 Mbps，高延迟 throttle( reachRps(50).in(10.seconds), // 4G下请求速率可达50 RPS holdFor(4.minutes), jumpToRps(5), // 突然降至弱网状态 holdFor(50.seconds) ).exec( http("弱网下提交操作") .post("/api/v1/action") .body(StringBody("""{"action": "like", "id": "${itemId}"}""")) .expectation( // 弱网下用户容忍更长的响应时间 responseTimeInMillis.percentile4.lt(3000) // P95响应时间<3秒 ) ) } setUp( scn.inject( // 4. 模拟移动用户的启动潮汐：例如，早晨高峰 rampUsersPerSec(1).to(50).during(30.minutes), constantUsersPerSec(50).during(2.hours), rampUsersPerSec(50).to(1).during(30.minutes) ) ).protocols(httpProtocol) // 5. 应用全局网络节流 .throttle( // 模拟全球用户混合网络状况 reachRps(1000).in(1.minute), // 峰值吞吐 holdFor(3.hours), jumpToRps(100), // 进入夜间低峰 holdFor(4.hours) ) // 6. 定义断言：移动API性能标准通常更宽松但必须稳定 .assertions( global.failedRequests.percent.lt(0.1), // 错误率<0.1% global.responseTime.percentile4.lt(2000), // P95响应时间<2秒 details("弱网下提交操作").responseTime.percentile4.lt(3000) ) }三、模拟真实移动用户行为
移动用户行为具有场景化特征，需用更精细的场景设计来模拟。
// 定义不同行为模式的用户群体 val regularUser = scenario("活跃用户") .exec(Login.flow) .exec( // 模拟“下拉刷新->浏览->互动”的短周期循环 repeat(15) { exec(Feed.refresh) // 刷新内容 .pause(1.second, 5.seconds) // 随机浏览时间 .randomSwitch( 60.0 -> exec(Interaction.like), // 60%概率点赞 20.0 -> exec(Interaction.comment), // 20%概率评论 20.0 -> exec(Interaction.share) // 20%概率分享 ) } ) val backgroundUser = scenario("后台用户") .exec(Login.flow) .exec( // 模拟后台静默同步：低频、定时的数据拉取 forever() { exec(DataSync.sync) .pause(5.minutes, 10.minutes) // 每5-10分钟同步一次 } ) // 在setUp中混合不同用户群体，模拟真实用户构成 setUp( regularUser.inject(rampUsers(5000).during(30.minutes)), // 70%为活跃用户 backgroundUser.inject(rampUsers(2000).during(30.minutes)) // 30%为后台用户 )四、 测试移动API机制
移动API包含诸多特有机制，测试中必须包含。
// 1. 测试Token认证和刷新机制 val authScenario = scenario("认证流程测试") .exec( http("初始登录") .post("/auth/login") .body(ElFileBody("bodies/login.json")) .check( jsonPath("$.access_token").saveAs("accessToken"), jsonPath("$.refresh_token").saveAs("refreshToken"), jsonPath("$.expires_in").saveAs("tokenExpiresIn") ) ) .pause("${tokenExpiresIn}") // 模拟token自然过期 .exec( http("自动刷新Token") .post("/auth/refresh") .body(StringBody("""{"refresh_token": "${refreshToken}"}""")) .check(jsonPath("$.access_token").saveAs("accessToken")) ) // 2. 模拟推送通知接收和点击（通过API调用模拟） val pushScenario = scenario("推送互动测试") .exec( http("模拟接收推送") .post("/api/v1/push/report-receipt") .header("Authorization", "Bearer ${accessToken}") .body(StringBody("""{"push_id": "${pushId}", "action": "received"}""")) ) .pause(2.seconds, 30.seconds) // 用户看到推送后可能的延迟 .exec( http("模拟点击推送") .post("/api/v1/push/report-action") .body(StringBody("""{"push_id": "${pushId}", "action": "clicked"}""")) ) // 3. 测试数据同步和冲突解决 val syncScenario = scenario("数据同步测试") .exec( http("增量同步") .get("/api/v1/sync/updates?last_sync=${lastSyncTime}") .check( jsonPath("$.updates").saveAs("updates"), jsonPath("$.full_sync_required").saveAs("needsFullSync") ) ) .doIf("${needsFullSync}") { exec(http("全量同步").get("/api/v1/sync/full")) }五、 专项测试建议
后端和客户端指标关联：在测试中注入唯一的trace_id，便于在分布式追踪系统（如Jaeger）中关联客户端请求和后端全链路处理。
文章来源：卓码软件测评
精彩推荐：点击蓝字即可
▲软件负载测试▲API自动化测试▲软件测试▲第三方软件测试▲软件性能测试▲软件测试机构
重点注意弱网和边缘情况：
高延迟测试：使用Gatling的throttling模拟高达1000ms的RTT。
丢包测试：虽然Gatling无法直接模拟丢包，但可结合TC（Traffic Control）等网络工具在测试机层面实现。
频繁重连测试：在场景中设计repeat循环，模拟App从后台唤醒后重新建立连接的行为。
设备资源模拟：
通过限制并发连接数、请求队列来模拟设备资源限制。
测试后端在客户端频繁崩溃重启（表现为连接突然断开）后的容错能力。
六、 通过标准
移动API的性能标准应结合业务实际制定：
成功率：关键API（如登录、支付）必须在99.9%以上。
端到端延迟：主要操作（如 feed 刷新）的P95响应时间，在良好网络下应<1秒，在弱网下应<3秒。
网络效率：关注单个请求的数据传输量，特别是在蜂窝网络下，避免不必要的冗余数据。
电池影响模拟：通过分析请求的频率和模式，评估后端API设计是否有利于省电（如使用批量操作、减少轮询）。
