经常有人问，性能测试是不是就是并发测试？答案是否，性能测试和并发测试是两个概念，且并发测试不等同于性能测试。
今天我们就来详细讲讲什么是并发测试，以及解析实际的项目中常见的并发问题。
并发测试的定义
并发测试的定义中，最主要的有两点：
· 点层面
同一时间做某件事。例如：周一早上7:30，小学生要统一到操场升国旗。
· 线层面
一个时间段做不同的事。例如：中午11:30-13:00，小学生有的跳皮筋，有的踢足球，但同时对服务器产生压力。
并发测试不等于性能测试
这个问题，我面试的时候，问过多个求职者，大部分求职者的第一反应都是说并发测试就是性能测试。
性能测试中把并发又分为负载和压力测试。虽然并发测试与性能测试有交集，但是，并发测试并不仅仅应用于性能测试，并发测试更多被运用于其他领域。
并发测试的分类
并发测试不仅仅是性能测试，它存在各个测试阶段，并且测试目的各不相同。
功能并发测试
要先进行测试单业务功能场景的并发测试，再进行混合业务功能场景的并发测试。
功能并发测试目的为验证系统功能是否符合需求规格说明书的要求。
性能并发测试
同时满足某些系统性能指标的前提下，让被测对象承担不同的工作量，以评估被测对象的最大处理能力及是否存在缺陷。
性能并发测试的目的为验证系统性能指标是否符合需求规格说明书的要求
稳定性的并发测试
判断测试系统的长期稳定运行的能力。
稳定性并发测试目的为验证系统稳定性是否符合需求规格说明书的要求。
异常性并发测试
模拟系统在较差、异常资源配置下运行，以评估被测对象在资源不足的情况下的工作状态。
异常并发测试的目的为验证系统的异常响应机制是否满足需求规格说明书的要求。
常见并发问题
当下流行一种时尚的软件设计理念，叫"微服务"。把复杂功能组合拆分成若干个独立的服务进行开发，然后有选择性的组合执行各服务。
微服务开发框架有利于并发测试设计，每个服务都是测试的切入口，可以单独执行。换句话说，测试切入口越多，越有利于测试场景的设计，有效执行并发用例。
并发切入口从以下三个方面查找统计：
客户端操作
使用工具捕获提交到服务器的请求，分析链接、参数进行测试。
系统接口
查阅相关的接口文档，开发并模拟其他系统功能进行测试。
定时任务
定时任务是开发框架，可能需要二次开发，以接口形式进行测试。
并发测出的问题，是一种综合症，往往有多种错误交织在一起的，所以不能乱用"药"。解决这类问题，通常分以下5个步骤(比把大象放冰箱多了2步)：
①通过并发测试找到故障点；
②以故障点的现象分析问题原因；
③确定产生原因后讨论解决方案；
④根据解决方案实施修复；
⑤同并发测试验证修复情况。
事务并发的问题
由于事务处理而导致的并发问题，我们需要先了解什么是事务。
事务的定义
是数据库操作的最小单元，是作为单个逻辑工作单元执行的一系列操作，这些操作作为一个整体一起向系统提交，要么执行，要么不执行，事务是一组不可再分割的操作集合(工作逻辑单元)。
系统内部事务控制
事务的控制好坏往往取决于码农们的开发技术、业务理解能力、专注程度，由于这类错误而导致的bug是非常低级别且严重的(必须出示黄牌 进行警告)！
我们举例来说明：使用APP订电影票。首先打开某团，找到某电影，选择位置，并点击"确定选择"，然后进入到支付页面，提交订单，选择支付宝去支付，支付成功收到短信。
在前半段，用手机打开某团，找到想看的电影，选择座位，提交订单到支付页面，"选座"与"提交订单"都是某团内部接口。如果将这两个作为一个事务，有以下四个特性：
原子性：要么都整，要么都不整。
一致性：锁定座位提交订单后必须生成订单号，取消订单则解锁座位。
隔离性：座位被别人选中，没有网络，操作日志记录失败等。
持续性：事务提交后永久存在，不会受到任何故障影响。
而作为测试人员，需要考虑的测试点有：
一个座位被多个账号锁定，生成了订单；
座位锁定成功，但没有生成订单；
取消订单，座位未解锁；
生成重复订单号；
操作日志没有完整记录所有行为。
我们再来分析订电影票场景的下半部分：在支付页面，使用了支付宝进行支付，支付成功后收到平台短信。
"支付成功"是外部接口，对于外部接口的事务控制，需要考虑两个系统的设计。对支付接口进行并发接口测试，要考虑的事务问题：
同一笔订单，不能同时选择多种方式，不能进行多次支付；
重复通知上传支付结果(支付成功，支付超时)，只能处理一次订单；
日志记录完整记录发送、接受的支付信息，与测试用例内容相匹配。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
