这几天一直在看jackei的测试博客，很受启发。很佩服他这么多年来坚持写自己的博客，把自己的测试人生和大家进行分享，帮助到这么多人。
   今天我也花了一些时间整理了一下自己的博客，从今天开始，我也要在自己的博客中记录自己的点点滴滴，包括想法。
   博客宗旨：分享的是原创，我的栏目里，除了“04 转载文章”以外的所有栏目内容都坚持自己的原创；而04栏目我会放我认为非常经典的文章给大家。

另外，栏目里

00置顶推荐----是我认为来我的博客必看的内容，里面的文章会放一些被51test加精，或者被多个测试网站转载的文章
02 测试随笔----这里记录的是自己随时随地的想法，主要侧重在自己平时冒出来的想法
03 学习笔记----这里记录的主要是测试工具，语言，测试方法方面的学习过程中的笔记、想法和总结。这里侧重点是学习别人的东西之后所转换成自己的东西。同样会在这里制定自己的学习任务，完成它，并将过程进行及时总结分享。
04 转载文章【转】---我会放我认为非常经典的文章给大家。侧重别人的好东西。
05 个人英语时空-----当然是英语学习方面的咯。侧重自我的想法和收获
06 生活随笔---我的生活随笔，非测试滴，哈哈
07 工作总结---对某一个阶段的总体回顾。不让自己白活。哈哈

   我的期望：希望每一个看我博客的朋友，都能给我好的建议，我总结的好的地方请给与支持，不好的地方请大家一定帮我指出来，小女子万分感谢！！！hoho

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

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

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

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

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

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

  在支付宝测试分析的角色和系统分析的角色是对应的，只不过一个是测试类的另外一个是开发类的。系分下面会有相应开发，测分下面会有相应的测试用例编写和执行人员。也就是说测试分析文档是对测试执行人员的一个指导（在我原来的理解方式上，觉得测试分析人员应该是用例编写人员；而在这里测试分析人员是从业务上去分析的，用例是用例执行人员来写并且执行的）。

而通过这次的这次分析觉得自己的测分还存在以下的问题：

1、太关注开发的内部实现逻辑。建议：将开发内部实现逻辑看成一个黑盒子，测试分析要从这个黑盒子的输入和输出上去看开发内部实现逻辑是不是有问题，而不应该先去了解开发的实现逻辑然后按照他们的思路去分析。

2、分析文档写的过于详细，甚至将用例的步骤都写了出来。建议：测试分析要从全局上去看问题，细节的东西即便是知道的，也要留给之后的用例编写人员去了解（就像系分之后的开发需要去写详细设计的道理一样），这样后面的人才会自己主动去想问题。

3、分析文档要考虑维护性问题，不要出现类似比如还款中状态为“R”这种具体的数据内容。因为我的分析是对后续用例编写人员的一个指导性的文档，所以如果侧分这么写很有可能导致用例也照着这么写，其实不管侧分和用例都不应该具体写到R这么细节，否则的话开发稍作变动我们就要相应变动我们的用例

4、没有明确测试目的。review用例的时候，没有提出每个用例需要明确一个测试目的，让别人来看这个用例的时候能明白到底是怎么回事。

总结：

1、以后写测试分析文档，依据仅仅是prd文档，必须抛开开发实现逻辑部分（即不去看系分文档），待测分出来之后，再去看系分文档，互相看看彼此考虑的是否存在遗漏的地方。等到在写用例的时候再让写用例的人和相应的开发去互相明确更细节的东西。

2、写用例我们目前都是仅仅做到对流程上的每个节点去单独分析，细到看输出的时候会关注到数据库表的一个变化。但是除了以上部分，其实还少了对整体流程的关注，需要增加业务流程的各条路径的一个覆盖，在针对路径的用例中不需要关注到数据库表级那么细。

3、在做流程路径覆盖之前应该画一个路径图，这个图的画法考虑各个入口的不同分开画流程图，分别进行路径覆盖。