并发测试的一点总结【原创】

并发测试一直被认为是一个难点，分析的时候很容易忽视，那我们测试如何去考虑并发的测试点呢，我是先通过和开发了解他们在设计编码过程中是如何去考虑防止并发的问题开始的

通过和开发了解，目前加锁方式去控制并发一般会在程序块里和在数据库级别去做。
1、程序块里的锁一般是针对某个变量（全局变量）的操作的并发。
举例说明，比如很多地方会用到地名（假设有上海、杭州、金华三个地名）的一个下拉列表，而并不是说每次去查询数据库表的方式来取到这个值的，处于性能考虑，程序实现的时候通常会考虑用缓存的方式来做。将数据库表的这些数据先取出来放于一个变量list中（A）作为缓存，然后再做一个更新缓存的功能专门用来更新这个变量的取值，而此时更新缓存的这个动作就会可能出现并发，因为这个更新缓存的类是又一个变量和一个赋值的方法组成的，并且程序加载的时候就做了实例化；当多个用户同时点击更新缓存的时候，就有可能说出现这种情况，前一个更新缓存的请求处理了一半（仅仅将上海赋值给A），后一个更新缓存的请求又起来了，最后更新完之后，变量A中就会分别出现2个上海，2个杭州，2个金华。
对于这种情况要控制并发的话，通常是加synchronize方法来给这个程序块加锁，每次去触发更新缓存的请求的时候就先上这个锁，等第一个线程处理完毕之后再解锁，这个时候第二个线程才可以进入。

2、数据库级别的锁一般是同时去操作同一条数据的时候会用到的，这种情况一般用for update去控制并发。而这个锁肯定是在一个事务里面的(事务起来之后第一件事情就是上锁，然后再后续的动作)，因为是做为这个事务的一部分的，当事务提交或者回滚之后，这个锁会自动失效。（这个你可以联想在pl sql里去for update之后，要进行提交或者回滚那么就不会再锁住记录了）。这种情况一般都会有update记录状态的动作。

3、会一个是并发控制要从源头开始，第二并发控制的意义在于找到一个最佳位置去控制，而这个位置并不一定和相应的业务有直接关系。有时候业务没有相关地方可以锁，会直接选择系统参数表之类的数据库中插入一条数据来锁（就是说你插入一条记录，你要锁的时候就for update这条记录，米有源头制造源头来达到加锁控制并发的目的）

总上所述，我们去分析并发问题首先需要我们测试人员自身对于某个功能点在设计思路上有敏锐的触觉，比如一看到缓存的功能，那么就联想到是否会有全局变量问题存在，然后再和开发去确认他们的设计思路，最终分析出来是否有必要对某个功能点考虑并发的测试。

那么我们该如何去测试并发问题呢？
１、工具，用ＬＲ去创建虚拟用户去模拟并发，这种办法并不能１００％保证能够模拟出并发，这个需要去看日志，看各虚拟用户是否是在一个时间点上去操作的，另外，也需要明确如何去分析操作的结果是否引起并发了。
２、让开发配合做并发测试页面，来模拟启动并发线程，如果要这么做，同时也需要开发配合做一个并发控制器的开关。
３、如果以上办法都不行，那么可以去了解开发的设计思路，如果开发是通过加锁的方式来做的，那么我们需要想办法去验证开发是否加了这个锁，这个我估计只能通过看代码了。（个人认为这种办法应该开发来做的）
４、如果知道开发控制某个并发是通过for update 加锁的方式来做的，那么我们可以提前在数据库里锁住这个记录，然后再去通过功能走，如果功能一直不能往下走直到你解锁才正常进行的话，说明开发是去加这个锁的，因为如果后面一个线程要来做锁的动作的时候发现那条记录已经被锁了，会做等待。