面对并发的程序测试要高度关注程序的设计

 当程序使用多模块并行处理的时候作为测试一定要跟开发一起讨论设计，对设计也要非常的清楚。

为什么要这么说，因为如果代码的设计存在低概率的漏洞，那么你想通过功能测试测出来概率非常小。除非你知道设计是怎么回事在开发的代码里嵌入测试代码测试。注意此处我也说的是知道设计是怎么回事。举个最近发现的一个问题。

流程大概是这样：每次从一个表拿出一批id（id不一定是唯一的，相同的id可以出现在任意的批次里，但是同一批中相同的id会做uniq），然后从另外一张hbase的表中拿出这些id的数值，其中每个id有个计算完校验值假装叫做md5。将拿出的这批id进行计算，并用计算后的md5和刚刚拿到的md5值进行比较，如果相同则不产生这个结果，如果不同则将计算后的写回hbase那张表。

注意：从一个表中拿出一批id和将这些id做计算写回hbase这两个功能是异步的。也就是只要上批id丢到计算的线程里，不管是否计算完成写回到hbase，另一批id就会开始被丢进来。这里就有问题了，我们进行了异步的并发计算，但是对于不同批的相同id的md5字段要求的却是强一致性，也就是第二批的key必须使用的是第一批对应的key计算好的md5才行。但是这样设计其实是不一定了。如果上一批的id还没计算好写回去，但是第二批的id已经batch get出来了就会造成第二批拿到是老的脏数据。后来，我们把id计算的md5丢到内存map里了，这样当这个id运行到最后计算的插件的时候前一个一定是计算完了写好内存map的了。当然前面是有机制可以保证相同的id分到mapreduce的同一个map中。

反思：

按照第一种的设计只有在数据量非常大写有延时的时候才会出现那种情况，而你功能测试相当于是在走概率事件了，因为本身就是非常低概率发生的事情，抽样的验证非常难发现。所以在面对设计复杂的时候更应该清楚的知道里面的设计认真的思考。其实对已经想出的case要是想漏真是挺难的，但是如果思考不到位没想到的场景你要想靠运气测出来还真也不太可能。

另外最近又冒出一茬说测试消失的人，我是一直认为研发才是公司的核心。但是如果是一个能跟着开发评估设计，case思考设计全面，能够控制风险，有一定代码功底，在讨论设计什么的能给出自己的思路，在程序上提前提醒开发某些地方有陷阱并且认真负责的人充当测试角色，我还真不相信这种人能消失，什么都是取决你做事情做到什么程度。而且就算有那么一天这种人应该也可以顺理成章的转开发。与其争论谁重不要不如多和开发学学知识，多多提高自己来的实在。