测试工作难点之事无巨细

lsekfe

作为软件测试工程师，相信一定经常遇到很多棘手的问题，而其中很大的一个类型就是，客户方或现场问题的复现。要么是怎么都无法复现前方的问题，要么就是概率性重复且没有任何规律。这些飘忽不定甚至被戏称为“鬼影“的问题，往往让测试工程师大为头疼。

如何对这些问题进行精准定位，提高重现概率甚至100%重现，就成为了所有人关注的焦点。千千万万个测试工程师，殚精竭虑，废寝忘食，几乎从技术到玄学的法子都用到，但都无法完全解决，那么就有必要从根本原因上剖析一下问题和做法。

重现，这是一个和机械还原论非常有纠葛的概念。简单来说，就是将一个相对复杂的场景或系统，可以分解为若干个小部分的组合，并且按照既有顺序合成后，可以实现和原场景或系统的功能。

那么，在软件测试工作中，根据机械还原论，将所有因素条件都复刻回来，理论上是可以重现任何场景问题的。然而事实并非完全如此，那么我们要问一下，到底是哪里出了问题？

在思考这个问题之前，有一则非常有启发意义的案例：福特汽车客服中心曾接到一个车主投诉电话，说他买的福特汽车对香草冰淇淋过敏。因为每次去超市买香草冰淇淋后回到车上就启动不起来，但是买芒果和巧克力冰淇淋就没问题。

客服中心认为这个车主在捣乱，就没理会。但是在车主同样问题第五次投诉后，福特汽车公司开始重视起来。但是这个场景离奇到让人无法下手——车辆打不着火和车主吃什么口味的冰淇淋有什么关系？经过多次讨论分析也没有结论，但拿到修理车也没发现问题。于是技术工程师自告奋勇陪车主去买冰淇淋，并要求重现整个过程。

经过尝试后发现，事实果真如此，为什么呢？经过多次测试后，技术工程师终于发现：这个车确实有故障，动力系统一旦熄火，散热不好，就需要5分钟后才能着车。

但超市的芒果和巧克力冰淇淋很畅销，需要排队5分钟以上才能买到，这个时间足以让车辆完成散热。但是香草冰淇淋不畅销，而且位置就在货架靠外的位置，所以3分钟就买好了，等车主走回来这个时间，不足以让车辆完成散热，所以启动不起来。

测试工程师经常遇到的情况就是，售后或者客户在传递信息时，往往会忽略掉自己认为不重要的因素，而将重点聚焦在和产品本身相关的信息上。根据测试理论，我们知道，软件的失效和测试周境息息相关，也就是说，任何参与到这个项目或者产品使用环境中的因素，都足以诱发软件产品的失效。而客户或者售后人员的信息转达，往往会忽略掉一部分测试周境的信息。

像福特汽车这个例子中，客户的反馈显然缺少了“时间“这个重要因素，那么对整个事件的处理，就产生了一定的误导，导致整个事情的反馈听上去像一个闹剧，然而这却是真实发生的。最后，是通过对用户操作步骤和行为的完全再现，才重现了整个问题，进而为问题的定位和解决打下了基础。

这就提醒所有的测试工程师，在还原现场问题的时候，也需要考虑到其余非技术层面的因素。一般情况下，现场的人员会关注在操作步骤上，测试工程师会更多关心一下软件的版本，以及系统平台是否配套等等问题。有些会忽略软件的选项设置，涉及硬件的，则容易忽略型号配套问题。

除此之外是否还有其他因素需要关注呢？

对于纯软件，需要关注的还有系统软件冲突问题，例如输入法的冲突，同类型功能软件冲突，甚至软件快捷键的冲突，更有甚者，还需要关注现场系统中是否缺失了系统运行库，如.NET Framework, 或编程语言运行库依赖（这大都是软件本身的缺陷）。

如果是浏览器，那么还需要考虑使用调试器，先清空缓存，以及不同浏览器间的兼容问题，例如Chrome和IE以及Edge，这些不同内核的适配就不完全相同，也需要在现场一一甄别。

还有软件的误报误处理问题，就需要考虑软件本身是否有直接读写内存单元的行为，或者有未经UAC机制判断，意图绕开系统进行最高权限操作。

纯软件的项目中，会经常遇到UI检查的时候，会出现各种各样的显示问题，即使是在开发声明修复了问题之后，似乎也会出现“”诈尸“一样的问题。遇到这样的情况，一般是要先清空浏览器缓存，通过浏览器菜单清空有时候都不一定能解决问题，需要进入调试模式，在“应用程序”的“存储”页内，选择清除所有数据，包括“第三方cookie”，这样才能将一些预读入的设置和配置清除干净。同样的，在客户反馈类似的问题时，也要提醒客户清空浏览器缓存，当怀疑客户无法在调试模式进行复杂操作的时候，建议可以使用“Ctrl+F5”强制刷新。

另外，当遇到客户反馈浏览器显示问题时，不但需要询问浏览器型号、版本、64/32位，还需要获知操作系统的版本，这些平时微不足道的细节，往往都是诱发问题的关键点。还需要注意的就是，在类似的项目立项时，浏览器和操作系统兼容性列表，就需要预先确认好支持的范围，这样对于客户反馈的范围外的问题，可以告知不在支持列表内，需要进行调整。

对于涉及硬件，需要考虑的周境因素则会增多，包括但不限于硬件产品型号的配套和支持，现场布线环境的电磁兼容，电压电流标准等等，这里就需要用排除法进行一一验证。甚至一些配件物料设备的兼容性，也会诱发软件失效报错，这也就是为什么我们购买一些硬件产品时，都会有建议的配套硬件列表或原装配件提醒。

涉及硬件的问题中，需要将软件问题和硬件问题分开排查。在硬件方面，电源质量是一个需要关注的点，例如电压、电流的质量，是否存在电压不稳、飘忽，此时需要加装稳压器或更换稳压电源，这些电源本身带有整流功能，所以电流质量也会有所提高。特别是很多涉及集成电路和PCB板卡之类的项目，对于电压是非常敏感的，电压的波动会导致芯片的损坏，从而诱发失效场景。

另外多个硬件设备的组合安装中，是否有接地保护，接地电阻是否符合要求，综合布线是否符合电磁兼容要求，有关EMC的标准是否都达到和满足，EMC方面是涉及硬件方面中非常容易出错误的一个领域。这个就需要在现场安装的时候，提前预见到可能出问题的地方。

多年前，某通信实验室在调试一款信号处理系统时，全向天线接收的波形在某一特定角度解析时，总是会出现一个突出的信号波峰，研究人员认为是软件算法有误，但始终无法定位软件问题，最后发现是放在办公区用来热午饭的微波炉的磁控管发生了泄露，导致了天线接收到的波形异常。这就是一个典型的和系统本身无关，但因为测试周境影响而误判的问题。倘若在测试之前进行EMC的检查，是完全可以避免这个问题的。

总之，软件失效的排查和现场问题复现，是一个日常看上去非常简单的活动，却往往在这里会出现各种各样的问题，这就需要作为测试工程师，要做到对现场信息事无巨细地收集，对事务流的细节要不厌其烦地确认，才能够降低无效复现的概率，尽快将问题定位。