裸板焊接测试流程1、电路板拿到后，要观察电路板线路有无损伤，焊盘有无损坏；2、用万用表测量电源与地、不同电源之间，不同地之间是否有短路；3、焊接的时候先焊电源部分，并将电源调试成功；4、再焊CPU及外围阻容、晶振及复位电路，焊接后重新测试电源与地，避免焊接时候的短路和热击穿；焊接CPU后测试：需要确认晶振可正常起振，能正常复位。
可进行程序的下载以及仿真。
调试的时候应确保能够设置对应的IO口，可直接设置IO口点亮LED灯。
5、焊接SDRAM，并进行调试。
6、焊接串口，并与电脑连接进行串口输入输出调试；7、焊其它的外围器件，与软件结合进行对应的硬件调试。
。
EMC实验：热测试：HASS(Highly accelerated stress screen）高加速应力筛选：HASS应用于产品的生产阶段，以确保所有在HALT中找到的改进措施能够得已实施。
HASS还能够确保不会由于生产工艺和元器件的改动而引入新的缺陷。
HASS包含如下内容◆进行预筛选，剔除可能发展为明显缺陷的隐性缺陷；◆进行探测筛选，找出明显缺陷；◆故障分析；◆改进措施。
一般电子产品测试过程：（1）HASS DevelopmentHASS试验计划必须参考前面HALT试验所得到的结果。
一般是将温度及振动合并应力中的高、低温度的可操作界限缩小20%，而振动条件则以破坏界限G值的50%做为HASS试验计划的初始条件。
然后再依据此条件开始执行温度及振动合并应力测试，并观察被测物是否有故障出现。
如有故障出现，须先判断是因过大的环境应力造成的，还是由被测物本身的质量引起的。
属前者时应再放宽温度及振动应力10%再进行测试，属后者时表示目前测试条件有效。
如无故障情况发生，则须再加严测试环境应力10%再进行测试。
（2）Proof-of-Screen在建立HASS Profile（HASS 程序）时应注意两个原则：首先，须能检测出可能造成设备故障的隐患；其次，经试验后不致造成设备损坏或"内伤"。
为了确保HASS试验计划阶段所得到的结果符合上述两个原则，必须准备3个试验品，并在每个试品上制作一些未依标准工艺制造或组装的缺陷，如零件浮插、空焊及组装不当等。
以HASS试验计划阶段所得到的条件测试各试验品，并观察各试品上的人造缺陷是否能被检测出来，以决定是否加严或放宽测试条件，而能使HASS Profile达到预期效果。
在完成有效性测试后，应再以新的试验品，以调整过的条件测试30～50次，如皆未发生因应力不当而被破坏的现象，此时即可判定HASS Profile通过计划验证阶段测试，并可做为Production HASS之用。
反之则须再检讨，调整测试条件以求获得的组合。
（3）Production HASS任何一个经过Proof-of-Screen考验过的HASS Profile皆被视为快速有效的质量筛选利器，但仍须配合产品经客户使用后所回馈的异常再做适当的调整。
另外，当设计变更时，亦相应修改测试条件。
开发流程经验：图2 硬件开发流程框图2 基本思想是使每一步流程具有严密的逻辑；每一步流程可操作；每一步流程的输入、操作及输出受控。
1、硬件系统需求 硬件系统需求直接来源于对产品需求的分解。
个人觉得产品需求下尽量不要存在产品系统方案或总体方案等文档，再由系统方案分解出硬件、电源、软件、机械等需求。
原因在于： (1) 个人觉得，这样的文档体系过于复杂，维护成本过高； (2) 另一点是在实际工作中的体会，一般这样的文档是需要多个专业组共同维护的，这种公共文档存在极高的出错可能。
一方面，在变更管理中，各个专业组的受影响文档往往仅会到专业组需求级，而“惯性”地遗忘系统方案这一上层文档，造成公共文档处于无人维护状态；另一方面，即使某一专业组在变更管理中对公共文档进行了维护，但由于这份文档牵涉到其它专业组，存在误更改的风险。
，系统方案等上层文档往往是由系统工程师完成的，由于其所处的层次，往往在文档撰写中具有随意性，会将某个专业组的需求放大或加入不相关的需求，从而造成测试的困难。
比如，系统方案对硬件的描述为“具有报警音功能，且音量符合XX标准。
”音量符合XX标准，往往应该是整机需要验证的内容，但现在却加入到了硬件需求中，而硬件可能并不具备相关的标准知识和测试手段去验证它，这就造成了无法封闭的可能性。
在硬件系统需求阶段时，除了归档《硬件系统需求》文档外，还应当归档《硬件系统测试方案》。
这样做的原因在于：在归档技术文件进行测试前，研发人员会对硬件各个版本进行自测，而此时测试方案未归档受控，这就存在“作假”的可能性，比如按照某一条判断标准，某项测试是不能通过的，如果分析认为此项FAIL不会带来影响，便不会从根本上去查找原因并进行更改，反而可能通过修改判断标准让此项测试得以PASS。
另一方面，在需求提出时，测试方案也就应该提出了，测试项与需求项是一一对应的。
在撰写需求和测试需求时，个人认为需要注意以下几点： (1) 对应性。
硬件需求应与产品需求对应，不可多也不可少。
少了则意味着需求没有被完全分解，有遗漏项；多了则意味着有错误的需求或不相关的需求。
同理，测试方案应与需求对应，同样是不可多也不可少。
(2) 准确性。
需求是可验证的。
所谓可验证，简单的方法就是让很多个从未从事过此项测试工作的人，按照撰写的测试需求，可以进行测试操作并且得出的结论一致。
下面这个例子便属于需求不准确所造成的不可验证：某项测试标准为“LED灯发出明亮的红光。
”粗略一看，似乎没有什么问题，但如果实际去测试，就会发现“明亮的”无法验证，或者说不同的人去测试很有可能会得出不同的结论。