性能场景之业务模型在性能执行场景中的具体实现逻辑

目录

• 系统架构
• 业务模型
• 脚本设计
  • 策略一：所有业务接口之间都是独立的，没有任何业务逻辑
  • 策略二：业务接口有上下逻辑关系
    • 策略二之方法一：
    • 策略二之方法二：
• 总结
• 接口代码(fastapi+pydantic)

系统架构

业务模型

业务接口	比例
Ta	20%
Tab	30%
Tabc	20%
Tabcd	30%

这里的比例可以通过access访问日志来统计，也可以参照《性能测试30讲》第十四章和《高楼的性能工程实战课》第六章

这里要说明下

1. 每个接口在调用时，都会在经过的系统中产生一条请求，同时插入一条记录。

2. 接口都是串行调用，比如Tabcd接口就是穿过系统ABCD。

下面完善表格

			系统A		系统B		系统C		系统D
业务接口	比例	访问路径	请求数	DB记录数	请求数	DB记录数	请求数	DB记录数	请求数	DB记录数
Ta	20%	A	1	1
Tab	30%	A-B	1	1	1	1
Tabc	20%	A-B-C	1	1	1	1	1	1
Tabcd	30%	A-B-C-D	1	1	1	1	1	1	1	1

上面的表格是每个业务接口调用一次在各系统中产生的请求数和DB记录数

脚本设计

针对这个业务比例，有两种策略来设计脚本

策略一：所有业务接口之间都是独立的，没有任何业务逻辑

显然，我们把每个接口单独控制比例就行了，jmeter设置如下

针对每个业务接口都放到一个Throughput Controller中，比例设置和上面的表格中一致，如下图所示：

这里，我们运行100次迭代，每个接口会严格按照设置的比例来运行，线程组配置如下：

我用一个线程迭代100次，看执行结果：

显然，各个接口是按照我们设计的比例来执行的。

线程组通过设置运行时间来执行，效果也是一样的：

10个线程，每个线程跑10遍，结果如下：

最终落到上面的表格就是这样

			系统A		系统B		系统C		系统D
业务接口	比例	访问路径	请求数	DB记录数	请求数	DB记录数	请求数	DB记录数	请求数	DB记录数
Ta	20%	A	20	20
Tab	30%	A-B	30	30	30	30
Tabc	20%	A-B-C	20	20	20	20	20	20
Tabcd	30%	A-B-C-D	30	30	30	30	30	30	30	30

或者不限定迭代次数，设置duration，再看下

算一下看看

testa：1398/6985=20.014316%

testab：2096/6985=30.007158%

testabc：1397/6985=20%

testabcd：2094/6985=29.978525%

所以，根据这个策略来设计场景，比例偏差必然小于1%。

策略二：业务接口有上下逻辑关系

比如下单，必须登录才能下单，如果你不想登录，就要构造session，这样的业务场景如果还按策略一来设计脚本场景就会有两个问题：

1. 需要造数据
2. 业务接口的调用逻辑和生产不符

在这个业务背景下，我先假设接口是ta-tab-tabc-tabcd，顺序执行，针对上面的比例关系，我们有两种设计方法。

策略二之方法一：

业务接口	比例	业务脚本1	业务脚本2
Ta	20%	20%
Tab	30%	20%	10%
Tabc	20%	20%
Tabcd	30%	20%	10%

1. 业务脚本1包括Ta/Tab/Tabc/Tabcd四个接口，并且是串行执行的。
2. 业务脚本2只包含Tab/Tabcd两个接口，并且也是串行执行。(注：这里我假设的逻辑，Tab - Tabcd是可以组成完整业务的，不需要依赖Ta,Tabc这两个接口，在方法二中我再说当他们不能单独组成完整业务要怎么做。)

这时的场景配置怎么做？首先脚本结构是这样的。

这里的两个业务脚本，对应Throughput Controller。现在问题来了，业务脚本1的执行比例应该是多少呢？

因为业务脚本1的20%是从30%中来的，所以业务脚本1的执行比例是20%/30%，为66.666666...%，而业务脚本2的比例是10%/30%，为33.33333...%，取整结果如下：

	业务脚本1	业务脚本2
执行比例	67%	33%

所以，Throughput Controller我们这样设置：

Thread Group这样配置：

我还是用一个线程迭代100次，这个场景的执行结果，如果不出所料，是这样的：

因为我总共执行100次，业务脚本1会执行67次，所以每个接口都会执行67次；业务脚本2会执行33次，所以Tab、Tabcd会各执行33次，所以执行次数如下：

业务接口	比例	业务脚本1	业务脚本2	业务接口执行次数
Ta	20%	67		67
Tab	30%	67	33	100
Tabc	20%	67		67
Tabcd	30%	67	33	100

执行下看看实际结果：

嗯，果然不出我所料~~

策略二之方法二：

现在有一个需求是这样的，我的接口必须按顺序执行，单独Tab,Tabcd不能闭环怎么办？

这种情况只能有一个业务脚本啊。这时候的脚本可以这样配置：

这里我在每个接口上面加了一个Loop Controller，设置Loop Count成这样：

注：这里的设置循环次数数值取决于百分比，但是由于这里只支持整数，所以当比例值不是整数时，要扩大倍数使之成为整数之后再设置在这里。

线程组设置如下：

这里我们暂且设置为1个线程迭代10次，来更清晰的呈现比例关系。结果如下：

结果证明满足比例关系！

总结

业务模型对性能场景是灰常重要的。从生产上或者从业务手上拿到业务比例后，如果不能严格地在场景中遵循业务比例来执行场景，那这个性能场景就不符合业务模型，从而导致性能项目做起来毫无意义。

在这里，我描述了两种策略来实现业务模型。策略一对应的是无逻辑关系的混合业务场景；策略二对应的是有逻辑关系的混合业务场景。

接口代码(fastapi+pydantic)

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

# 使用pydantic模型做请求体
class Test(BaseModel):
    code: str
    data: str
    tax: float
    amount: float

@app.get("/test")
def home():
    result = {"code":0, "msg": "这是一个用于性能压测的演示项目"}
    return result

@app.post("/testa/add")
def a():
    results = {"code":0,"msg":"success"}
    return results

@app.post("/testab/add")
def b():
    results = {"code":0,"msg":"success"}
    return results

@app.post("/testabc/add")
def c():
    results = {"code":0,"msg":"success"}
    return results

@app.post("/testabcd/add")
def d(test:Test):
    return test