the5fire

这段时间一直在某研究院做集成测试，虽然偶目前只是打个副手（囧），不过作为一个旁观者很是清楚大家的工作效率。

一套系统的两个子系统，通过webservice进行交互，早先定好的标准此时已经改变。因此要测试接口，先要修改接口。其实这也不是问题，写代码的效率要远高于测试效率。

花一个小时写好代码，并简单调试没有bug。然后开始部署，开始漫长的测试之旅。

其实一天测试两个接口，主要问题在于环境上。不过我觉得工作流程也有问题，不过以我的水平，目测不出问题所在。

“改代码，本地调试，部署服务器，调用对方WebService，然后通过WebService接受对方返回来的消息。”

这么一个看似简单的流程，却是步步有危险，处处有磨难。

代码好写，规范难定。

都是大公司，文档自然是重中之重，但即便如此，依然会有零星的错误在里面，这些小bug却是很磨人的，写好代码之后，发现无论如何都不能和对方WebService和谐的交互。查看日志后发现对方要的是A+B，我方发的是A&B。这个东西，规范沟通不及时，需要统一管理才行。但对于两个大公司来讲，没人会让别人牵着鼻子。所以这个只能加强开发人员意识。

Service好写，地址难求。

简单的WebService交互，调试了半天，查看日志，一边是啥也没有输出（表示没有接到请求），一边是请求正常，但是返回结果异常。

一遍一遍的测试流程，一点一点的排除bug，怎么着都找不到问题所在，看起来一切正常，理论上应该可以走的通。

两边的接口规范一一对应，没有出入。问题何在？

在最后大家都表示无奈的情况下，终于发现了问题所在，一个webService的调用地址的微小改变引起了这场bug跟踪大战。

在没有笔和纸的年代，记录是一件很难的事情。但是在如今科技发达的年代，如此容易的可以记录代码边改，需求更改，依然会出现这样的“原始景观”——代码的修改没有任何记录，没有任何目的记录，没有任何需求记录。


其实最磨人心头的是环境问题，偌大一个机房，各种服务器嗡嗡作响，一大群的开发人员频繁而有节奏的商讨。还有让人难受的网络。

早上头脑相当的清醒，在里面呆不到两个小时就会觉得头晕脑胀。不过看大家都还在似睡非睡的工作着，我表示，我还是比较坚强。


一天测试两个接口，其实没有想象的那么容易。

- from the5fire.com