系统一级测试驱动发展的3个小贴士

近年来,我看到了嵌入式开发人员在使用单元测试和测试驱动开发(TDD)方面的兴趣显著提高。测试驱动开发有可能降低时间到市场和成本,同时提高整体产品质量。使用TDD的开发人员通常编写测试,使其失败,然后只编写生产代码使测试通过。失败的测试驱动代码开发。

嵌入式开发人员通常在应用程序级别上采用TDS。单元测试用于驱动特性开发和构建可以用于回归测试的测试,以确保没有问题。你有没有想过为什么我们把TDD限制在单元测试上?为什么团队不从系统层面开始他们的TDD之旅?

我怀疑原因是嵌入式开发人员通常从硬件上思考。它们从驱动程序、中间件和应用程序代码开始。在那一点上,他们编写所有的系统测试(是的,我经常看到集成测试被完全跳过!)。现代嵌入式系统有一个复杂的层次,需要从上到下的思考,从应用到硬件。人们常说,系统的数据提供了价值,而不是收集数据的硬件。如果是这样的话,我会认为我们在嵌入式系统中对TDD的方法是有缺陷的。这是自下而上的,不是自上而下的!

如果你想开发一个能够利用现代技术如敏捷、开发等的产品,你可以考虑采用一个系统级的TDD方法。从最关键的用户特性入手,编写系统测试,使其失败,然后编写代码,使系统级测试通过。在这个过程中,您将编写需要单元和集成测试的组件。您编写的系统级测试将记录您的需求,并编写到能够驱动开发,并可用于系统级回归测试。

系统级TDD可能对您没有吸引力,但如果是,这里有三个提示可以考虑启动。

提示1-拥抱模拟和仿真

在系统级TDD流程之后,嵌入式开发人员可以接受模拟和仿真。在大多数嵌入式的情况下,软件团队在项目启动时无法访问硬件;如果是,项目已经落后于计划了。因此,开发人员可以通过使用模拟器、模拟器或主机环境编写满足所需行为的系统级测试和应用程序代码来拥抱TDD。

模拟器可以帮助开发人员证明应用程序的业务逻辑是正确的,即使它还没有与硬件挂钩。这有几个好处:

· 系统级测试可以在硬件可用之前编写并执行

· 用户可以与模拟器进行互动,以确保系统能更早地满足他们的需求。

· 该应用程序可以开发、测试和证明独立于硬件

模拟可以为开发人员提供一个灵活的架构,使应用程序能够在具有不同组件的多个环境中执行。一般而言,你会发现所产生的软件和体系结构更具有可伸缩性、灵活性和更高的质量。在某些情况下,我甚至将较低的硬件级别与网络协议联系起来,然后通过这些协议来驱动Guis来可视化系统正在做什么。如果使用得当,具有系统级TDD的模拟可以成为嵌入式产品团队的有力工具。

提示2-使用自动测试框架

有很多很棒的测试工具,开发人员可以用来编写嵌入式软件的单元测试。然而,在系统层面,开发人员必须超越其单元测试工具,转向自动化测试框架。

自动化测试框架是一套工具,它提供了创建、执行和管理自动化测试的结构化方法。该框架可包括编写和一致进行测试的指南、标准和程序。此外,开发人员通常可以使用这个框架来开发报告和收集测试覆盖度指标。

有几个系统级自动测试框架,您可以考虑。例如,CMAR构建系统包括CTET,允许团队运行系统级测试,包括测试发现、执行和测试结果报告。近三分之二的软件行业已经在使用C制造,这使它成为一个令人兴奋的选择。另一个选择是PYTET,这是一个基于金字塔的测试框架。

存在其他自动化测试框架,但您必须评估和选择最适合您的开发需求的框架。例如,您可以使用自动测试框架编写测试用例、收集遥测、强制故障条件等。

提示#3-您仍然可以使用TDD周期

在他的书中,肯特·贝克以例子为例,将TDD周期定义如下:

· 再加一个测试

· 做完所有的测试

· 改变一下

· 做测试并成功

· 还原器删除重复

这个过程可以在一个带有一点警告的系统级别上使用;一个系统级别的测试可能会产生一系列的单元和集成测试。TDD背后的想法是,您正在进行小的增量测试,以构建您的软件。在系统层面,像发送命令和接收响应这样的小测试可能需要大量的底层基础设施。然而,开发人员仍然可以从小规模的测试开始,并"在被迫做之前将其伪造"。当它被强迫,即。开发人员将使用单元测试来创建支持应用程序模块和集成测试来测试这些模块。

一开始,系统级的TDD可能会感到有点尴尬,因为你从高水平开始,向下工作到最低水平的硬件。实际上,这是很尴尬的,因为你有可能在不同的测试工具和工具之间切换,以成功完成测试。然而,这种方法可以帮助您专注于首先实现客户和产品最关键的特性。为了使系统级测试通过,您可以使用仿真和模拟,这将帮助您更快地推进应用程序,即使在没有硬件的情况下。

结论

测试驱动开发彻底改变了我编写嵌入式软件的方式。TDD帮助提高了软件质量,并帮助我更快地编写代码。在系统级别应用TDD可以在系统级别上提供同样多的价值(如果不是更多的话)。系统级测试可以根据用户的基本特性记录需求和驱动软件开发。通常,嵌入式开发人员首先关注的是他们最感兴趣的软件部件。这些可能是也可能不是在关键路径上,也可能是价值的一部分。

当一个新项目开始时,编写Gpio驱动程序是否是用户或客户最需要的增值产品?我想没有。系统级别的TDD可以帮助团队根据客户需求和交互设定优先级。此外,系统级测试可以从一开始就集成到CI/CD管道中,确保新代码不会破坏用户正在与之交互的内容。一个系统级的TDD方法还可以帮助嵌入式开发人员思考自上而下的问题,并利用模拟和仿真来代替依赖硬件。

我希望这篇文章对你关于嵌入式系统开发的一些想法提出了质疑。我们已经研究了一些将TDD提升到下一个层次的想法。因此,好好想想,想象一下,一个系统级的TDD方法可以为您和您的客户做什么。