【软件测试公司：如何使用k6做软件性能测试】

    项目的目标是为客户交付一个ToC的APP，其后端是基于RESTful的微服务架构，同时后端还采用了Protobuf协议来提高传输效率。在最终上线之前，我们需要执行性能测试以确定系统在正常和预期峰值负载条件下的表现，在得知需要做性能测试后，我们就开始针对性能测试做了一番调研，在阅读了一些性能测试工具对比的文章后，最终挑选了k6，locust和Gatling做了进一步对比，下面是对比的结果。  对我们来说，k6的优势在于： ·k6支持TypeScript，由于项目上已经有TypeScript使用经验，因此该工具学习成本相对更少； · k6官方支持与多种CI工具，数据可视化系统的集成，开箱即用； · Gatling支持Scala/Java/Kotlin，项目上没有使用相关的技术栈，需要和客户申请，成本高于k6。  有了上面的基础，我们便开始尝试在项目中集成k6，在选了一个简单的API写第一个case的时候，发现有以下一些挑战需要解决： 由于当前项目的API都集成了OAuth，任何操作都要有一个有效的用户和Access Token，因此需要提前生成token和测试数据。这一部分因为项目的不同会有一些差异，需要具体情况具体分析。在此次测试中具体包括以下几项： 用户账号准备，比如生成200个用户，并进行一系列的前置处理，让它们变成可用的正常测试账号，并且需根据项目安全规范，保存到合适地方，比如AWS Secrets Manager或者AWS Parameter Store，这里的账号可以复用。 token生成，运行测试前，生成最新的有效token，执行测试的时候只需要去读取token数据。 token刷新，由于token基本上都具有时效性，如果有效时间短，还需要考虑renew token，这里我们采用refresh token去获取新access token的方式。 需要注意的是测试过程中刷新token会计入请求，对性能测试数据会有些许影响，刷新机制需要纳入考虑范围。 下图简要说明了前后端的架构，Mobile和BFF是以Protobuf格式做数据交换，BFF和Backend是以Json格式做数据交换。  我们的性能测试是针对BFF的，因此需要根据项目中定义的Protobuf格式对请求数据进行编码再发送给BFF，从BFF接受到响应数据时也需要根据Protobuf定义的响应格式进行解码，从而解析出想要的数据。  由于每个API的编解码结构都是一份单独的proto，因此还涉及到代码复用的问题，需要设计合适的方法，让不同的API只需要提供对应的encode和decode schema即可。