不同附件上传，续传合并，参数化并发性能测试

不同附件上传，续传合并，参数化并发性能测试

1、 上传附件后，点击提交问卷，抓包发现并没有看到附件相关的内容，只看到附件的参数，所以判断在点击附件上传的时候已经把附件传入服务器，提交问卷时只是把服务器返回的参数给提交了。
2、 所以在上传附件的时候抓包：

发现有两个请求和一个js包（附件上传后的参数传给前端，然后提交问卷时使用相关参数提交）。
抓包分析发现，chunk为附件的上传请求（断点续传秒传），merge为合并请求

Chunk：

Merge：

3、同样，先配置上传附件chunk的请求：

4、根据抓包里面的参数进行配置：

5、发起并发请求后发现文件并没有存入数据库，与开发确认才知道附件是依靠identifier的这个ID值进行区分附件是否已经上传过服务器，如果这个ID已存在，则不会再上传一次，实际用户操作中只会提交一个js请求给前端，这样的话达不到并发测试的目的。
（这里存在一个问题，同一个附件内容但不同的附件名字不能存入数据库，因为他们的identifier都是同一个，需要根据需求确认是否为bug）

6、最终确认按照identifier这个值来唯一标识附件，不考虑用户修改附件名再上传的情况（这样对服务器比较友好），所以需要模拟不同附件上传就要通过修改identifier这个ID值（参数化），再触发上传发现可正常发起请求，数据库可成功存入该附件。

到此为止chunk的请求已经配置完成。

7、下面配置merge的请求：
Merge里面同样有identifier这个ID，同样需要参数化。

8、这里有一个问题，每次上传附件chunk和merge的identifier值需要一样并且一一对应，所以两个请求包，我们用同一个参数化数据文件即可：

到此为止merge的请求已经配置完成。

9、Chunk和merge的请求已经完成，已经实现模拟用户上传附件的操作，可以模拟对服务器的并发压力，但考虑到尽可能地模拟用户场景，可以加上提交问卷请求的操作，同样需带上identifier值并参数化，另外用户的唯一标识submitterUuid也做了参数化：

10、最后建一个事务控制器把三个请求放一起：