测试平台系列(46) 用例并发之我全都要

我猜当各位领导听到测试平台要建设并发用例功能时候，内心肯定是：这个功能很简单啊，甚至会想是不是开发偷懒了啊，都叫并发测试了，肯定要写一堆接口啊。没错，想的太简单了。

1. 并发用例的复杂性体现在哪里？
2. 并发用例的实际场景落地在那些方面？
3. 并发用例的功能边界在哪里？

为了搞清楚以上三个核心问题，我们开始从并发用例的需求出发，思考如何让一个平台做到真正的并发用例全覆盖，并且做到极致。

一、并发用例的复杂性

1. 接口并行性复杂度 ：并发用例顾名思义就是并发的执行多个接口，执行接口数量的多少直接体现出平台的并发性能，比如一个平台同时并发执行50个接口和同时并发执行200个接口，难度系数可是成倍的。
2. 数据依赖性复杂度 ：并发用例执行的接口之间存在数据依赖关系，按照数据依赖关系的不同，可分为硬依赖和软依赖，硬依赖即当前接口执行的前提依赖于上一个接口的执行结果，软依赖即当前接口执行不依赖于上一个接口的执行结果。比如登录->获取用户列表->查询用户详情 三个接口，登录和获取用户列表是硬依赖关系，查询用户详情和登录、获取用户列表是软依赖关系。对平台来说，如果要保证并发用例执行的正确性，数据依赖性的复杂度极高。
3. 执行顺序复杂度 ：并发用例执行的接口既可以是并行执行，也可以是顺序执行，执行顺序的不同将导致最终结果的不同。比如下单->支付 ，下单成功后才可以支付，顺序不可颠倒；登录->获取用户列表->查询用户详情 ，获取用户列表和查询用户详情可以并行执行，执行顺序没有要求。因此，平台要根据用例的要求保证接口的执行顺序。
4. 用例组合复杂度 ：并发用例往往不是单一的接口，而是组合多个接口的用例，比如创建订单->支付订单->查询订单详情 ，这个用例组合了创建订单、支付订单、查询订单详情三个接口。平台要实现用例组合功能，需要考虑接口组合的灵活性和可扩展性。

二、并发用例的实际场景落地

并发用例在实际场景中主要应用于以下几个方面：

1. 性能测试 ：并发用例可以用来测试系统在高并发场景下的性能表现，找出系统的瓶颈和性能上限。
2. 稳定性测试 ：并发用例可以用来测试系统在高并发场景下的稳定性，发现系统在高并发场景下可能出现的故障和异常。
3. 冒烟测试 ：并发用例可以用来对系统进行冒烟测试，快速验证系统的基本功能是否正常。
4. 回归测试 ：并发用例可以用来对系统进行回归测试，验证系统在修改后是否仍然正常。

三、并发用例的功能边界

并发用例的功能边界主要包括以下几个方面：

1. 并发执行的接口数量 ：平台支持并发执行的接口数量上限。
2. 数据依赖关系处理 ：平台对并发用例中数据依赖关系的处理方式，比如支持硬依赖和软依赖的处理。
3. 执行顺序控制 ：平台对并发用例中接口执行顺序的控制方式，比如支持并行执行和顺序执行的控制。
4. 用例组合功能 ：平台支持并发用例组合的方式，比如支持灵活的接口组合和用例组合的可扩展性。

四、我全都要的并发用例平台

根据并发用例的复杂性、实际场景落地和功能边界，我们要建设的并发用例平台必须满足以下要求：

1. 支持海量接口并发执行 ：平台要支持同时并发执行数百甚至上千个接口。
2. 完善的数据依赖关系处理机制 ：平台要提供完善的数据依赖关系处理机制，支持硬依赖和软依赖的处理。
3. 灵活的执行顺序控制机制 ：平台要提供灵活的执行顺序控制机制，支持并行执行和顺序执行的控制。
4. 强大的用例组合功能 ：平台要提供强大的用例组合功能，支持灵活的接口组合和用例组合的可扩展性。

只有满足以上要求，才能称得上是一个真正的“我全都要”的并发用例平台。这样的平台不仅可以满足性能测试、稳定性测试、冒烟测试和回归测试等各种测试场景的需求，还能极大地提高测试效率和测试质量。

在这个平台建设的过程中，我们也遇到了很多挑战，比如：

1. 如何高效地处理海量接口并发执行？
2. 如何准确地处理数据依赖关系？
3. 如何灵活地控制接口执行顺序？
4. 如何实现用例组合功能的可扩展性？

针对这些挑战，我们进行了深入的研究和探索，并提出了创新性的解决方案，最终成功地打造了一个满足“我全都要”要求的并发用例平台。