问题描述
任何人都有成功直接在嵌入式硬件自动化测试？
具体来说，我想到的自动化单元测试硬件层模块的电池。我们需要在我们的硬件层code更大的信心。我们的很多项目都使用中断驱动定时器，模数转换器，串行IO，串行SPI设备（闪存）等。
Specifically, I am thinking of automating a battery of unit tests for hardware layer modules. We need to have greater confidence in our hardware layer code. A lot of our projects use interrupt driven timers, ADCs, serial io, serial SPI devices (flash memory) etc..
这甚至值得努力？
我们通常的目标：
处理器：8或16位微控制器（DSP的一些东西）
语言：C（有时是C ++）。
Processor: 8 or 16 bit microcontrollers (some DSP stuff)
Language: C (sometimes c++).
推荐答案
当然。在汽车行业，我们用$ 100,000个定制的测试人员为每一个新产品，以验证的硬件和软件都运行正常。
Sure. In the automotive industry we use $100,000 custom built testers for each new product to verify the hardware and software are operating correctly.
开发商，但是，也建立一个更便宜的（子$ 1,000）测试，其中包括在工作站上输入/输出等，要么使用脚本一堆USB I / O，A / D，PWM，或者特定目的建造HIL / SIL测试软件，如MxVDev。
The developers, however, also build a cheaper (sub $1,000) tester that includes a bunch of USB I/O, A/D, PWM in/out, etc and either use scripting on the workstation, or purpose built HIL/SIL test software such as MxVDev.
硬件在环（HIL）测试可能是你的意思，它只是涉及到I / O连接到设备的I / O部分USB硬件，具有运行针对它的测试计算机上的软件。
Hardware in the Loop (HIL) testing is probably what you mean, and it simply involves some USB hardware I/O connected to the I/O of your device, with software on the computer running tests against it.
是否值得它依赖。
在高可靠性工业（飞机，汽车等），客户指定非常广泛的硬件测试，所以你必须有它只是为了让该项目投标。
In the high reliability industry (airplane, automotive, etc) the customer specifies very extensive hardware testing, so you have to have it just to get the bid.
在消费类行业，与非复杂的项目它通常是不值得的。
In the consumer industry, with non complex projects it's usually not worth it.
对于任何项目中，还有比参与几个程序员的，但是，它的的真正的不错的硬件夜间的回归测试运行 - 这是很难正确地模拟硬件所需要的程度满足自己的软件测试是不够的。
With any project where there's more than a few programmers involved, though, it's really nice to have a nightly regression test run on the hardware - it's hard to correctly simulate the hardware to the degree needed to satisfy yourself that the software testing is enough.
然后测试立即显示问题时已进入构建。
The testing then shows immediately when a problem has entered the build.
通常你同时执行黑盒和白盒测试 - 你有诊断code，可以让你窥探的硬件信号和内存（这可能只是一个调试器，或者可能是$ c中的设备上运行$ C你写的反应，消息总线上，例如）。这将是白箱测试，你可以看到什么内部发生的（甚至造成一些事情发生，比如它不能没有介绍自己的错误进行测试关键的内存错误）。
Generally you perform both black box and white box testing - you have diagnostic code running on the device that allows you to spy on signals and memory in the hardware (which might just be a debugger, or might be code you wrote that reacts to messages on a bus, for instance). This would be white box testing where you can see what's happening internally (and even cause some things to happen, such as critical memory errors which can't be tested without introducing the error yourself).
我们也跑了一堆那里的诊断路径被忽略，只有I / O被刺激黑匣子的测试/读取。
We also run a bunch of 'black box' tests where the diagnostic path is ignored and only the I/O is stimulated/read.
有关便宜得多的设置，你可以用USB和/或以太网（如爱特梅尔UC3系列），它可以连接到您的设备，运行基本测试$ 100个微控制器板。
For a much cheaper setup, you can get $100 microcontroller boards with USB and/or ethernet (such as the Atmel UC3 family) which you can connect to your device and run basic testing.
这对产品的维护特别有用 - 当项目完成后，保存了几个工作板，测试仪，并在CD一套完整的软件。当你需要做出修改或调试问题，可以很容易地将其所有的备份，并与一些知识进行这项工作（测试后），主要的功能并没有受到更改。
It's especially useful for product maintenance - when the project is done, store a few working boards, the tester, and a complete set of software on CD. When you need to make a modification or debug a problem, it's easy to set it all back up and work on it with some knowledge (after testing) that the major functionality was not affected by your changes.
这篇关于测试自动化与嵌入式硬件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！