于是，Z leader继续吃饼干;Y leader继续调试;X一干人等继续“研究”我国风景区的管理问题。而我也终于无聊到了极点，开始“友情赞助”，检查Y的问题代码。代码很少注释，写得也很随意，甚至缩进的格式都显林乱;但好在代码不长，逻辑也不复杂。我重点检查了内存的操作，但没有发现问题。
正在我纳闷同样一段代码，为什么其他数据都可以取得，偏偏这项数据取不到的时候，传来了Y learder的叫声。虽然听起来很像绝望后的惨叫，但我敢肯定，这的确是找到真正问题后的欢呼(和惨叫相似也是情理之中，毕竟都是在身心及其疲惫后发出的)。果然，他发现了：这项取不到的数据的名称写错了，应该是Status，但写成了State。(Y向Z要数据时，要传给Z一个数据的名称，然后Z就从硬件取得，并返回给Y。这些数据的名称是Z定义的)那么，怎么会发生这种低级错误的呢?原来，出错的代码Y的那个程序员从另外一处Copy来的，其他数据项的名称都是相同的，偏偏这项数据的名称不同。
有多少Code可以重来：
Y leader忙着改C文件和H文件，因为这个数据项的名称出现在多处，所以Y leader改得很仔细，也很辛苦;我想他心里一定在臭骂他的这个team member，为什么不定义一个常量或者宏。在Y leader改代码的时候，我也在想，这简直就像Z在故意制造陷阱：这两组数据这么类似，而且其他数据项的名称都相同，为什么偏偏这项数据，一个叫State，另一个叫Status，真是有空，真TMD。
Y leader终于确认改正了所有该改的State。但用他的team member的单元测试程序一测发现还是有老问题。你可以想象到我们当时的感觉，就像吃了一吨广告上那个很夸张的“凉”得透顶的润喉糖。
但是! Y leader大叫：单元测试程序里的State也要改成Status。在无数双眼睛的注视下，Y leader颤抖着replace all，save，F5。终于，当大家看到计算机上的一串字符后，每个人都舒心的笑了。(当然，如果没有刚才的虚惊一场，可能不是每个人都在快工作到午夜的时候还能笑得动的)。我想，此时此刻，此情此景，在Y leader的眼里，一定滚动着些东西，除了眼屎。
现在，又轮到我上场了。Build时发现X的代码中也需要把一些State改成Status。(如果当初他们也检查一下就好了)。X的程序员也没有定义常量或者宏的习惯，所以我Build了多次，他们才把所有要改的State改掉。
一个QA的精彩：
后来发生的事可以用一个“峰回路转”来形容，在无数双眼睛的注视下(我的手没有颤抖，因为人已经麻木了，或者说一切都习惯了)，我启动了我们的软件，连接到B平台上，检查所有的数据，全部OK;连接到C平台上，检查所有的数据，全部OK。搞定了!
文章来源于领测软件测试网 https://www.ltesting.net/