QA的工作看起来好像是每天都在等dev的bug fix，等build，等每天的daily build，跑跑smoke，跑跑automation，执行几组测试用例，再或者搞搞探索性测试。

　　有没有想过从某一天build突然就嗝屁了安装不上去了，daily smoke飞掉了，这时我们紧张滴提一个bug，兴冲冲满怀希望dev能给出最快的fix，毕竟这是P0的case啊，按理，不对，按照规定，要在12小时内搞定，可是事情就是这麽不给力，bug看起来似乎很难解，12小时过去了，一天，两天，四个工作日了，这个问题还摆在那里，

　　看起来遥遥无望，按照概率学统计学根本解释不通嘛，难道所有操蛋的事情看来只能依墨菲定律解释？

　　看dev们忙的焦头烂额无比憔悴胡子拉碴，我们却在这里外表光鲜地喝白开水等build，内心却也同样苦逼：日了，C姨喔可是要求20号交付给客户的，这他妈的肯定要delay了！ 这时的QA不仅苦逼，还得担心另一种很坏的可能发生那就是无路如何，军令如山，交付日期不能变。这意味着我们要减少至少5天的测试时间，却还得保证产品质量（待会还会提到这一点），而刚刚的弹出新闻窗口正在播报某某山公司的一位工程师又因操劳过度而离开人间。。

　　如果是你在负责这个产品的测试，面对P0的case迟迟不解你会怎麽做？还要继续等你梦中的白富美嘛？

　　下面就是我的一次历险：

　　第一天：今天build安装不上去，错误信息为某核心组件安装失败。应对：赶紧提bug，notify相关dev——当日无解

　　第二天：仍然是同样的问题，这次我增加了几个测试环境，在几个老的以前是正常环境中发现问题依然存在，看来该问题不是因为新环境新系统的原因导致的，基本可以确定是dev自身checkin代码导致的，dev开始反省最近几天checkin的所有changelist，逐一排查，我不知道这种方法是不是有点笨，但是满怀希望。——当日无解，dev们仍在排查

　　第三天：因为问题还在，dev提了一个work round的版本，可以安装到底，只不过跳过了核心组件出错的地方，这样我们可以把产品的其他部分和需要的文件都装进去，都助于调试问题。dev发现这是一个COM调用的错误，但是为什麽会出错不得而知，而那个COM组件的代码并没有最近的code change，只不过升级了一下.NET版本从2.0到4.0而已，按理说不应该有影响的啊——当日仍然无解，我等得有点急了，我开始push dev manager，why？why？why？wait，wait，wait.

　　第四天：下班前后，问题依旧，有点想骂娘（理解万岁），这麽干等不是个办法，活马当死马医，我决定自个儿下厨，看看啥回事。于是加个班，和dev通力合作，研究错误日志，和相关模块的代码，基本理清了出错的点相关的几个模块的依赖关系：

　　首先是下面这张图，显示了错误日志指向的点，就是安装程序在创建一个COM对象的时候，蹦出错误Class Not Registered.

　　这个错误信息看起来像是说COM组件没有注册成功，通过check注册表信息，我们发现COM的注册信息的确写在注册表里了啦，怎麽会会说没有注册呢，难道是注册的方式不对？这时dev想起来曾经改过注册COM的那一部分脚本，我们的COM是.NET编译的，之前是2.0，现在升级到4.0，而相应的注册COM的regasm也换到了4.0目录下的regAsm,而4.0目录下有两个版本的regasm,一个是for 32,还有一个for 64,dev当时觉得我们的产品环境现在只支持64位，所以就用了64位版本的regasm。那麽，难道真是这个问题导致的？至少在COM组件这一个模块的代码工程里，唯一改动的就是这一个地方了，这至少给了我们一点点救命稻草似的希望。于是我们开始猜测是不是due to 32/64位的问题，这时通过google 搜索那条错误日志信息，发现的确有人因为用32位的程序调用64位的COM而产生同样的错误代码。

　　可是疑惑依然没有解开，排列组合，做了几个环境的实验，我们首先排查出我们安装程序是64位的，然后发现那个COM是注册到LOCAL_MACHINE\CLASS下，也就意味着调用for 64位的regasm的确会把COM注册到正确的位置了，我又试了一下for 32的regasm会把COM注册到wowo64for32node下，应该如此。这也就意味着我们的情况和google到的不一样，我们是64 call 64呀，难道是？

　　这是脑海一丝灵光闪现，莫非是我们的COM是for x86 target编译的？而错误的注册成了64位的COM？检查code，很快这一思路被否定，我们的COM工程是target for any cpu,所以在64位的机器上必然是64位的版本。