EEPW论坛

这听起来是一个非常简单的问题，但在星期五下午四点多的时候，对某位准备在周末进行自动测试的系统工程师来说，则可能是一个真正的问题，因为他必须解决一些可能与软件或硬件相关的问题。

那么，你会打电话给谁呢？哪个倒霉的家伙会在周五晚上被*扰？软件工程师还是硬件工程师？

硬件工程师设计的观点是：硬件总是能够正确运行的。他们的证据是如何如何执行了参数测试，以及在电路中置入了多少余量，云云。

软件工程师会指出软件(固件)永远没有漏洞，除非你证明它有问题，而不仅仅是怀疑，而且证据最好是可重复的。

其实是系统工程师制造了所有的问题，因为是他试图把硬件和软件放到一起！

最近，我在东海岸一家雷达客户那里遇到一个有趣的问题。我们在午餐时段演示时，一边讨论着一些RF新产品。而在演示过程中，有一名听众似乎老是分神——他一边要专心听讲，一边不断被手机短信打断。在会议结束后，他礼貌地问我们是否有时间带设备去帮他解决一下问题。

他是一位跳频雷达产品的系统工程师，产品正准备进行某项质检测试。在周末时，他的测试人员不断地向他提供环境测试中产品的最新测试进度：参数测试——通过；功能测试——失败。

我们到达现场后，看见一个装备相当不错的实验室，一个产品盖子已经打开了，旁边放着一台混合信号示波器，感觉就像是一台呼吸机在维持着产品的生命。

根据经验，我知道示波器右侧标为“Ext Trig”的第五条通道是干什么用的，当出现问题时，你就需要使用这个东东。如果问题自行确定时(通过隔离关心的事件)，你可以很轻松。但有时需要同时使用两台仪器来处理问题。

在对这台跳频雷达进行参数测试期间，该客户用非跳频测试模式，来测试雷达的参数性能。我们一步步地测试了12条可能的工作通道，结果非常明了：硬件一切正常。

功能测试需要在特定通道计划中使用PN9序列把雷达置于自测模式，在本例中，要跳过12条通道中的8条通道。

通过使用实时频谱分析仪，我们在功能测试过程中很清楚地看到8条通道的所有9条通道。是的，所有9条！在真正随机序列上，你有可能得到类似的统计密度（PN9 – 8条通道中512步 ~12.5%的时间）。我们在8条RF通道中看到类似的统计数据，但只用了大约0.2%的时间，通道0出现了。

通过使用频域触发功能（频率边沿、频率模板或统计密度）触发混合信号示波器，每次在PN9顺序重启时，我们都能捕获发送到位移寄存器的通道0值。它是可以重复的设计漏洞，需要向软件工程师打电话解决问题了。很明显，新的固件负载出现了小漏洞。

解决硬件工程师和软件工程师之间的争论，您又有怎样的测试策略呢？欢迎您参与讨论。