模拟器陷阱
暑去清凉来，一场大雨让燥热一去不复返了，这让身体舒服了许多。本周四晚有一次产品升级操作，按惯例每次升级前的都会对产品做一次针对性的回归测试，这次也不例外，不过临近下班时测试组爆出一个莫名奇妙的问题。
测试人员在BUG说明中写到：产品在只运行某个流程A的情况是正常的，但是当流程A和流程B一起运行时，就会出XX异常情况。作为开发人员遇到类似的问题第一反映多为：这怎么可能呢？这个产品已经经过N轮测试并且早前已在某个省份上线运行了近两个月，如果有此潜在的BUG应该早就暴露出来了才对。及时找到测试人员沟通，测试人员很轻松的就复现出了该BUG，眼见为实！离升级时间点已经不多了，赶紧解决吧。
使用GDB在我认定的关键代码路径上设置了断点，对测试环境下的某进程进行调试，不过无论如何发消息，代码始终没有走到该断点，这让我疑惑不已。负责维护这段代码的开发人员恰参加培训回来，用她擅长的通过调试方法-“加打印语句”又进行了一次调试，发现一些端倪，消息并未按照我们预期的流程走，问题被缩小到消息包中的一个关键字段上，通过打印发现这一字段的值与预期的值不同。我的第一反映：是否有内存污染问题，如果真有这样的问题那就严重了，一直到此时我的怀疑点也一直在产品本身上。
这时测试人员在屏幕上的抓包结果引起了我们的注意：消息包中这个字段的值与设置的不符。通过进一步在产品中的打印结果也印证了这一点。难道是模拟器的问题？记忆中模拟器已经用了一年多了，这个问题之前怎么没有暴露出来呢。我们立即换了一个其他的模拟器进行了测试，结果：流程正常。看来就是模拟器的问题了。
据测试人员说以前未暴露出该问题很可能是因为之前的测试要么只测试A流程，或要么只测试B流程，很少A和B流程一起并行测试，所以这个模拟器陷阱就没有被发现。模拟器在A和B两个流程的共同作用下出现了内存污染的bug，，将A流程中的协议包中的一个重要字段设置错了，导致产品在处理该流程消息时未得出预期结果。
这次的“模拟器陷阱”问题起码暴露出两个问题：
1、缺少对新实现的模拟器正确性的完备测试；
2、测试人员在用例设计上还有提高的余地，应避免只有单一场景的用例了。
© 2009, bigwhite. 版权所有.
Related posts:
评论