当自主研发的测试软件 拖慢产品开发时

您的公司是否自行开发硬件测试软件？许多公司都这样做。几乎所有的硬件测试 软件都是这样开发的。这种方法称为“自主研发”测试，因为软件开发是在公司 内部进行的，所使用的是市场上现成的软件工具。 如果您对测试软件有完全的掌控能力和精深的知识，这固然可喜。您能够开发合 适的功能以满足自身特定的测试要求。

但是，如果您的团队跟不上需求，又会如 何？产品测试要求的变化速度超过测试软件的更新速度时，就会出现问题。这很快 就会导致产品开发进度大大拖延。自主研发的软件工具通常无法满足多功能产品的 新需求，也无法与您所在公司的设计和仿真软件集成。

在您的公司里，不同的团队可能开发了不同的测试软件，这阻碍了协作和数据交 换。如果核心工程师离职，自主研发就会陷入绝境。招聘和培训人员来开发和支 持您的自主研发环境，可能会耗费大量研发资源，而这些资源本来可以用于加速 创新。 在本文中，我们将探讨自主研发测试软件遇到的问题，并讨论现代商用测试软件 环境能够带来什么帮助。

自主研发的测试软件 如何拖慢您的速度

• 无法跟上快节奏的产品 开发和测试周期
• 很难与设计和仿真软 件集成
• 软件不利于协作
• 浪费宝贵的软件开发和 支持人才

与快节奏的产品开发和测试周期保持同步

公司正竭尽全力应对竞争压力、满足客户需求，产品的开发周期随之不断加快。现代设计和仿真软件的改进是产品开发加速的主要因素1,2。设计周期的压缩加重了确认和制造测试团队的压力，他们可能很难跟上如此快的开发节奏，并有可能成为拖累整体发布时间的瓶颈。自主研发的测试软件在过去可能能够跟上发展的脚步，但今天的快速设计周期需要更快、更敏捷的方法。

新产品设计通常需要更多测试，但测试截止日期保持不变。设计占用的时间越长，留给测试的时间就越短。自主研发的软件无法满足对更快测试速度的需求。那些不是为了加快测试速度而设计的软件也很难提升速度。在传统系统中优化测试步骤流程和执行速度同样充满挑战。现代测试软件平台提供了包含时序分析仪在内的各种内置诊断工具，可以帮助工程师分析哪些测试耗时最多，优化整体测试执行（图 1）。

与产品设计和仿真软件集成

许多公司正在采用越来越复杂的产品设计和仿真软件来帮助加快开发进度。虽然这些设计工具可以帮助研发团队加快进度，但也加重了确认和测试团队的责任。现代设计和仿真软件可能产生大量数据，而测试团队必须对这些数据进行确认测试。将设计数据与自主研发的测试软件集成，可能是一项十分艰巨的挑战，迫使测试开发人员重复开发设计工具中已有的大部分内容。

另一个挑战是确保设计仿真结果与确认测试结果相符。除非您的仿真和测试软件使用相同的测量算法，否则无法保证获得一致的结果。当结果不一致时，往往会造成设计团队和测试团队之间发生混乱，尤其是当各个团队都努力争取在产品进入制造阶段之前实现一致性时，这样的问题会导致进一步的延迟。

现代测试环境与设计和仿真软件无缝集成，确保物理测试与仿真使用相同的测量技术。任何差异都指向产品本身的实际问题，而不是设计或测试软件或方法中的问题。

跨分布式团队协作

随着产品设计和开发的快速发展和全球化，分布式测试团队必须尽可能高效地工作。如果各个团队都自己开发测试软件，且使用不同的算法和不同的用户界面，协作就是一项挑战。不一致的测试结果会导致团队之间容易产生误解，减慢开发过程。使用电子邮件来回发送结果会导致更多延误。

自主研发的测试软件通常不利于与其他团队（如研发团队）或其他部门所使用的设计软件或测试软件共享信息。无法在产品开发生命周期中共享测试软件和测试结果，会导致成本高企、耗时的重复性工作和项目返工（图 2）。

自主研发的软件一般只能完成整个产品测试工作流程的一小部分，它们通常是为支持某项特定任务或测试而开发的。现代测试软件环境提供了一整套测试自动化、测试项目管理、测试站管理、测试监测和分析工具。借助现代化的体系结构，用户可以从各种站点和位置交换数据，从而增强协作（图 3）。现代工具提供了通用接口、通用数据库和开放 API，可以方便地与现有硬件和软件集成，优化您的测试操作。

什么是 TestOps？

敏捷软件开发为软件开发带来了翻天覆地的变化。在后数字时代，很少有流程创新能够像敏捷开发和 DevOps 这样，给生产力带来如此巨大的提升。敏捷方法、DevOps 团队和 Scrum 工作流程实现了现代化的软件开发，将组织从每年发布一次软件版本重大升级的模式，转型为每天或每周推出多个软件版本的环境。如今，在测试和测量领域中也发生了类似的转变。自主研发的单一功能测试正在被模块化、可重复使用的组件取代，这些组件可以高度并行化以提高测试效率和吞吐量。结合现代协作工作环境，出现了革命性的新方法：TestOps。

优化工程人才资源，支持自主研发的软件

自主研发的工具通常是从现有工具和代码改编而来，但这些工具和代码可能已经过时且很难获得支持。在开发周期中，开发人员会创建内部测试软件，但一经发布，以后的测试改进周期可能变得极其缓慢。满足当今要求的软件可能无法满足明天的需求。内部解决方案和自行开发的工具往往依赖开发人员独特的个人技能。如果这个人离职，就很难找到替代的人。在寻找了解器件测试的软件程序员时尤其如此。

与数据采集工具类似，测试工程团队通常会创造自己的软件工具来分析数据。有时这是通过电子表格或其他标准工具实现的，但有时是在内部开发专有软件系统。这些系统可能足够好，但会占用本可以部署在更重要任务上的资源。创造的大量数据也使得传统工具力不从心。现代测试环境提供综合的数据管理和分析功能，帮助可视化和解读复杂的测试结果，让所有团队成员均可轻松访问（图 4）。

内部开发的测试软件工具可能难以维护，而且管理成本高昂。通常只有一位或几位关键工程师知道如何更新该软件。如果专家离职或调动到其他部门，那么团队的其他成员就不得不花时间重新学习这些工具。很多时候文档是有限制的，并且该工具可能与其他已经升级的系统不一致。额外的工作会耗尽本该用于实际测试而非软件开发的资源。

请下载此文档以了解更多信息。