目录
简单的背后不一定是简单,也有可能是复杂。看你遇到的场景,和你思考的维度。
常规接口压测里面参数提取及组装这一步,我相信大家都不陌生,为什么还要再写这篇文章呢,大概是因为最近回归历史遇到的场景,觉得有一定的代表可写性,能形成一个完整的思路闭环。
日常压测的接口,一般情况下单接口参数值都不会特别大,基本不会一个参数值就要达到 50-60kb这样的大小,但是很多时候也有很多例外场景,比如参数值是图片经过 base64 加码的,这个大小可就不好说了。这里先卖个关子,读者可以先思考下,过程中可能遇到什么问题呢?
为了方便大家对参数大小有一个体感,这里给出样例数据如下:
32,767 字节 ÷ 1024 ≈ 31.96 KB ≈ 32KB; 这是excel单元格可显示的上限内容大小32,767个字符,按照 1 字节来算,大小在 32KB;
64,993 字节 ÷ 1024 ≈ 63.43KB ≈ 63KB; 这是一张人像采集图 base64 加码后的长度,单位字符,按照 1 字节来算,大小在 63KB
ps. 这里我们不深究接口为什么要这样设计,总有一些场景是需要的。
好了,准备就绪,现在切入正题,给你一个这样的接口,你会怎么去分析判断提取组装参数呢?
第一式:判断接口的性质
是全新接口,还是历史业务接口的改写版本。这里的改写可能是接口能力下沉,也可能是内部实现有变动,又或者依赖的三方资源有调整等。
全新接口:意味着需要根据业务的预期自主根据业务特征完成参数组装去测验
历史接口:常见处理办法:一种是直接利用历史接口的真线场景数据;另一种是按照场景边界情况去摸底
第二式:根据接口性质定参数来源
来源基本逃不开三大类:数据库、日志、按照规则随机生成。根据是否需要二次加工,又可分为:拿来即用、自主采集 两大类。
拿来即用:不管是数据库,还是日志提取,一条 sql 语句就可把目标数据按照目标格式提取出来,就可使用了,不需要再做额外的清理工作。
自主采集:常见有 3 种处理办法:第一种是工程能力支撑,直接利用spring的切面能力,工程增加开关动态提取日志参数信息并存储到对应的参数文件上,直接拿来用;另一种办法是直接从日志里面提取参数信息,再做二次加工;最后一种是根据业务特征数据做正交,按照业务比例输出对应的参数样本信息。
第三式:根据参数内容,定文件格式
虽然jmeter 支持多样的参数化方式,比如用户自定义变量、用户变量、CSV Data Set Config元件、JDBC Connection Configuration 和 JDBC Request 元件或者其他第三方插件等,但是涉及到压测,参数样本不少,最常用的还数CSV Data Set Config元件,此元件可直接读取的文件类型有 2 种:csv 或者 txt,但是他们也有自身的适用场景及局限性,所以需要按需选择文件格式类型。
| 类型 | 查找替换 | 数据加工[1] | 可读性 | 大字段值 |
|---|---|---|---|---|
| csv | ✓ | 支持 | 一般 | 存在失真情况[2] |
| txt | ✓ | x | 良 | 可完整显示 |
第四式:参数准备
这里重点讲下从日志里面提取参数信息的情况,这种也是属于比较常遇见的场景,主要存在以下 4 种情况。以阿里云日志为例,分别如下:
-
简单数据&无需数据处理的情况,可直接通过编写提取日志脚本,把结果下载下来即可使用
// aliyun日志内容为对象数组,接口入参也为对象数组,无需更改,提取即用
xxxMethodName | select 参数值列
-
简单数据&需要数据处理的情况,因为一般日志输出是按照一定的日志格式输出的,不能直接映射成接口需要的格式,此时需要把结果做一定的处理才行,sql 能解决的,直接在源头处理,sql 解决不了的,常见的处理工具:excel 里面的数据-分列工具来实现,在不行,就需要程序介入,定制化解析了
// aliyun日志内容为对象数组,接口入参为对象,这个主要是去掉日志参数里面最外层的[]
xxxMethodName | select substr(参数值列, 2, length(参数值列)-2)
-
简单数据&存在大字段值的情况,比如excel的单元格已经显示不下了,这种情况下如果手误重新保存以下excel,可能就会导致单元格的内容变掉了呢
// aliyun日志内容为对象数组,接口入参为对象,这个主要是去掉日志参数里面最外层的[]
xxxMethodName | select substr(参数值列, 2, length(参数值列)-2)
导出为 csv后查看单元格内容,发现显示不全,此时可通过 mac 三件套里面的 numbers 工具
绕排文本的功能确认值的完整性,或者更改导出文件类型为json,在把json文件转成txt文档
-
简单数据&大字段&数据处理的情况,这种目前只能借助编码通过操作文件读取来实现了
public class FileDemo {
public static void readAndWrite() {
// 源文件 json 格式
String jsonFilePath = "/Users/xxx/Downloads/xxxApi.json";
ObjectMapper objectMapper = new ObjectMapper();
objectMapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false);
List<A> list = Lists.newLinkedList();
BufferedReader reader = null;
FileWriter writer = null;
try {
reader = new BufferedReader(new FileReader(jsonFilePath));
String line;
// 行读取
while ((line = reader.readLine()) != null) {
if (!line.trim().isEmpty()) {
A data = objectMapper.readValue(line, A.class);
list.add(data);
}
}
// 目标文件 txt 格式
writer = new FileWriter("xxxApi-t1.txt");
for (A key : list) {
String valueForKey = key.getMessage();
// 内容格式处理
String value = valueForKey.split("args")[1];
String targetValue = value.substring(2, value.length()-2);
// 追加新的元素
String newValue = targetValue.concat(",\"idType\":0}");
// 内容输出
writer.write(newValue);
// 换行符
writer.write(System.lineSeparator());
}
} catch (IOException e) {
throw new RuntimeException(e);
} finally {
try {
reader.close();
writer.close();
} catch (IOException e) {
throw new RuntimeException(e);
}
}
}
}
--- A class
class A implements Serializable {
String message;
// String otherField;// 其他补充字段
public String getMessage() {
return message;
}
public void setMessage(String message) {
this.message = message;
}
}
写在最后
一个参数值都这么大了,那么整个接口参数化文件肯定不会小。此时大家有没有想过当一个参数化文件大小过大时,对到压测的影响又会是怎样的呢?
参考资料
[1] 什么是数据加工: 是指通过excel内置函数工具或者数据分列功能等进行数据二次整合。
[2] 什么是数据失真: 在Excel中,单个单元格可以容纳的最大字符数取决于使用的Excel版本和工作簿中的内容类型。一般来说,对于Excel2007及以后的版本,单元格可以容纳32,767个字符。然而,这个数字可能会受到一些因素的限制,比如格式、单元格内公式的复杂程度等。超过这个数字,Excel的单元格看不到完整值,而Mac版本的numbers工具里面单元格有一个绕排文本的功能,这个可以完整查看base64加码后的完整内容。

2607

被折叠的 条评论
为什么被折叠?



