LoadRunner中遭遇交互数据加密的处理方案

最新推荐文章于 2021-09-30 17:49:16 发布

xreztento

最新推荐文章于 2021-09-30 17:49:16 发布

阅读量3.8k

点赞数 3

文章标签：性能

本文链接：https://blog.csdn.net/xreztento/article/details/90411837

版权

本文探讨了在LoadRunner中遇到加密交互数据时的处理方案。建议避免使用Java或C#.Net脚本以保持性能，并提出了四个策略，包括使用C语言实现加解密、调用外部Java接口、参数化和使用Java脚本。文中还分享了一个实际案例，展示了如何在C语言脚本中实现特定加密计算需求。

摘要由CSDN通过智能技术生成

在使用LoadRunner时，当你录制完脚本后可能会发现在交互的数据中会存在密文，或者当拿到接口文档时就已经明确的描述出了交互数据的加解密方法，你该怎么办？

事实上这样的遭遇如今已经成为了一种常态，发送数据或接收到的数据中很难避免不出现密文，有些加密算法是自定义的方法，有些则是标准的对称或非对称加密算法。

很多时候对于像JMeter这样原生的Java程序测试工具来说，在高级语言特性、丰富的加解密算法库条件下，你可能一个简单的BeanShell处理器或自定义函数就可以轻松解决这些问题，但对于LoadRunner这种原生是C语言脚本的测试工具来说，为了能够发挥其自身在性能上巨大的优势，可能处理起来就没有那么轻松。

你将采取的方案

首先你要清楚选择LoadRunner作为性能测试工具的主要目的是什么？在JMeter、nGrinder等开源工具不断发展壮大，并且各自特点鲜明，不断蚕食着LoadRunner的优势地位，大有后来居上的情况下，你仍然甘愿花费重金或冒着侵权风险的条件下使用LoadRunner时，你必须清楚LoadRunner能够为你带来什么。

LoadRunner能成为行业标杆的前提是其优越的自身性能和丰富的协议支持。因此，你在使用它时也有必要将这两方面发挥到极致。一些建议是尽量避免使用LoadRunner的Java或C#.Net脚本，这样做会严重影响工具自身的性能，导致LoadRunner失去其巨大的性能优势，这也意味着在很大程度上就失去了使用它的价值。

下面我们按解决问题方案的优先级进行罗列：

方案一是使用C语言实现加解密过程，唯一麻烦的是LR在内存控制方面可能有一些小问题需要自己调试一下；
方案二是用Java这样可以支持long类型的语言编写一个外部的接口实现计算，可以在需要计算时使用一个HTTP请求这个接口；
方案三是使用参数，本地代码计算与用户对应形成加密数据的参数列表；
方案四才是使用Java脚本；
当然最后方案五是找开发改逻辑。

案例

曾经在群里就遇到了这样一个发送端数据加密传输的需求：
9位数字，比如987654321，前缀123，后缀456，组合成一个13位的数字123987654321456，之后乘以数字30，再进行base64编码计算。

方案一实现

这个需求对于Java语言来说简直小儿科，只需要引入org.apache.commons.codec参考以下代码：

long number = 987654321L;
number = Long.valueOf("123" + String.valueOf(number) + "456") * 30;
String token = new String(Base64.encodeBase64(String.valueOf(number).getBytes()));  
System.out.println(token);

但对于LoadRunner下的C语言脚本，就需要稍微转动一下脑筋来实现这样的需求：

const char * base64char = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/";


Action()
{
   
	char *a = "123987654321456";
    char base64[4096];
	char bigint[16];
    bigint_muti(a, 30, bigint);
	base64_encode(bigint, base64, sizeof(char) * 16);
	lr_output_message("%s", base64);
	return 0;
}



char *
get_bigint(const int high_bit, const int low_bit){
   
	//内存区域分配大于8，否则high和low的内存会连在一起导致无法补0
	char high[16];
	char low[16];

	char bigint[16];
	int i = 8;

	sprintf(high, "%d\0", high_bit);
	sprintf(low, "%d\0", low_bit)