由雅各布Engblom

自动化测试是现代软件开发实践的关键部分持续集成,持续部署和敏捷开发。只使用手动测试是一种降低速度、在产品中留下bug并使测试部门在挫折中退出的极好方法。做完全自动化的测试有时比听起来要困难，特别是对于嵌入式系统。经常听到人们讨论持续集成和测试，并承认尽管它可以很好地用于一般计算工作负载，但要让它很好地用于嵌入式系统则要困难得多。运行特定测试所需的硬件往往设置复杂、获取代价昂贵、稀缺或难以通信。因此，测试将受到影响，最终影响软件质量和生产进度。使用虚拟平台来扩展和扩充可用测试平台集使得即使是最棘手的系统也可以进行自动测试。以下是我的解释。

Simics的自动化测试真正意味着什么?Simics不是一个测试生成系统或测试管理系统，而是一个优秀的系统执行测试和收集测试输出。Simics通常与硬件一起集成到现有的测试自动化框架中，使用在硬件上运行的相同测试。这将根据测试设计和测试脚本重用现有资产，并确保所有测试可以在任何地方运行，从而增加了灵活性。

尽管如此，Simics添加了一些独特的能力，使测试更加有效和高效。

与硬件相比，管理SIMICS测试系统更容易。随着Simics的只是软件，它不会因硬件配置错误或总目标软件故障而失控，挂起或没有反应迟钝（参见这篇博客文章是关于虚拟硬件和物理硬件之间的区别)。多亏了Simics中的脚本设置系统在这种情况下，通过寻找电路板、连接电缆和上传软件来配置硬件可能需要数小时甚至数天的时间。用户不需要亲自到实验室去重新配置系统，这一切都可以作为软件流程的一部分来完成。

SIMICS在标准服务器或PC上运行，允许更敏捷的测试系统。相同的物理硬件盒可用于运行各种系统的软件。使用硬件板和系统，每种类型系统的数量都是有限的，限制了在需要时对特定类型的系统进行升级的能力。通过SIMICS，还可以通过借用来自同一公司内的其他组的服务器或其他计算机资源暂时增加测试池，甚至在云计算服务上租用时间。

增加虚拟硬件的可用性和并行运行的能力通常有两个好处。

一个是更多的测试可以更快地完成，这使得运行比硬件更严格的测试循环成为可能。我们已经看到那些受到硬件限制的客户极大地增加了测试覆盖率和频率——如果你能每天而不是每周运行你的回归测试套件，错误将更早地被发现，更少的错误将在现场被发现，降低开发成本并提高产品质量。更多可用的测试资源也减少了从提交测试到执行测试的时间点的等待时间，如果一些测试用例必须为开发人员的分析而重新运行，这是特别重要的。如果分析运行必须等待数天才能运行，那么上下文将长期丢失，开发人员将不得不努力记住它是关于什么的。如果能在数小时内完成，就会有更好的连续性和生产率。

实际上无限的硬件可用性的另一个影响是测试不需要缩小或修改以匹配可用的硬件;相反，可以将硬件设置为与需要执行的测试匹配。与其使用开发板，还不如使用真正的板，从而减少构建变体的数量并提高测试的保真度。

除了方便、配置和可用性之外，使用Simics进行自动化测试提供了许多更智能地工作和节省测试时间的机会。

使用Simics检查点，可以以一种很难在硬件上实现的方式将增量值分散出测试。有趣的中间点可以为测试保存和重用，为多个测试提供稳定的起始点，并在设置阶段节省时间(使用检查点从相同的初始状态触发许多测试用例的一个有趣的例子已经在今年早些时候，我们在博客上采访了hyhymin Cho)。下图显示了一些使用检查点的常见方法。测试A和B直接从已启动的检查点运行，因为它们的设置阶段很短。然而，对于安装Q，进行安装的工作要大得多，我们有多个测试将从这个安装运行。因此，在完成设置后，将保存检查点Q，并从此检查点运行依赖于设置Q的所有测试。

值得指出的是，在为测试配置系统之后，但在测试运行之前保存检查点，有一个优点，即在测试之间重置和清理系统非常容易。在传统的基于硬件的测试设置中，您通常需要应用一些复杂的清理代码，并重新启动硬件，以使系统返回到足够原始的状态，以免影响下一个要运行的测试。在Simics中，你只是取干净初始状态的检查点并从它运行，避免测试之间的污染风险，并经常节省大量重启时间。这确实意味着从测试系统管理的清理阶段和开始阶段需要Simics的特殊情况，但这是测试框架的一部分，可以一次性完成。检查点的使用不需要影响测试用例的表达方式。

检查点提供了一种很好的方法，可以在测试后恢复状态，并将失败的测试通过并返回到开发中。正如我在之前关于与Simics持续集成的博客文章，这个反馈循环可以节省几天的开发时间，同时也避免了使用测试系统来诊断问题的需要。

当涉及到向运行在Simics上的系统提供测试用例时，有许多不同的选项可用。最简单的解决方案是将虚拟平台的网络或串口连接到外部世界，并像驱动物理板那样驱动它们。下面图片中的两个外部测试数据箭头说明了这一点。

然而，正如我们在上图中所看到的，这并不是唯一的选择。例如，目标软件堆栈本身可以是测试数据。一个操作系统的新构建将被加载到Simics上，以测试它是否正确地引导和初始化硬件。带有内置测试数据的测试应用程序将被加载到目标系统上，并在没有外部交互的情况下执行。Simics可以执行错误注入(参见我以前的博客文章故障注入一般情况下具体例子)，而注入特定错误或一系列错误的脚本将被视为健壮性、容错和RAS测试的测试输入。

硬件配置本身可以是一个相关的测试刺激。例如，创建单板的某个配置，a .配置一组不同的板子,一定网络大小，或网络拓扑结构。事实上，早在Simics的早期，我们就做过一些有趣的测试。在一个实例中，一个目标机器被配置为具有2^{^ 64年}字节的RAM。这个数量的内存是不可能以实物形式获得的(整个世界上并没有那么多的内存，一个快速的粗略计算表明，其成本将略高于整个美国的国防预算*)。另一方面，对于《Simics》，它很简单，我们可以检查有关的操作系统是否将内存大小视为负值。在另一种情况下，我们最大限度地设置了自配置网络系统，以容纳自配置应该处理的最大节点数量，以测试它是否确实有效。在实验室中，这种测试是不可能完成的，因为开发人员根本没有足够的200多个可用节点。更像是十分钟。

有关Simics的更多信息，请参见西米奇的产品页面在Windriver.com。

*请注意，今天，在2014年10月，那么多的内存可以只有美国GDP的1%(或几乎完全是新西兰的GDP)。