软件开发: 08 2010存档

我们的API用户已经使用了快一年了，还从没遇到这种情况，多半应该是用户使用上的问题。所以我下楼去看看。

客户的问题很容易重现，但是我写了个一样的例子，却没有这个问题。

“我的例子跟你代码几乎一样啊”我问。

“是啊......不对，有点不一样，你是多进程，我是多线程的，你们的API里用到了read，而且还判断了errno是吧，errno在多线程下岂不是互相影响？”

他这么一说我还真有点怀疑了，虽然API已经被用了一年，但大多数人都是用的多进程（unix的优秀习惯，噢），这可能是大家都没发现这一问题的原因。

我跑去问架构师，说了一下我的怀疑。

“不会吧，linux上系统调用都有可能影响errno，那任何一个多线程程序岂不是都有这个问题？”

“对啊。。。”

我这个人很动摇，两头都在说我就两头都在晃。

架构师查了查errno的man，确实，errno是“thread local”的，一个线程一个errno，不会互相干扰。

干脆回去把我的例子改成多线程的，依然不能重现，这下就不是多线程的问题了。

最后用户突然想起他们有个线程比较特殊，它@X%X%@#￥%……&*，还是API使用上的问题。我松口气。

过去几个月自动化测试跑得都很顺利，太顺利了，每天都没有fail。

写这些用例的人有些离职了。

现在项目有大改动，很多自动case跑fail了，我们知道是哪个case fail，但是，这个case具体是做了些什么才fail的呢？没人知道了，测试人员、包括开发人员，都只能去看自动测试的code来找出原因和重现方法......这样，所谓“自动化测试”，变成了“半自动化测试”??虽然你能告诉我某个case出错了，但你没有告诉我是怎么出错的、怎样重现？

最基本的解决办法是在自动化测试的code里加入足够的用例说明，如果fail了，至少可以很快知道怎么去手工重现。唉，慢慢改吧。