可测试性设计：SAFe 中系统架构师角色的一个重要方面

可测试性设计：SAFe 中系统架构师角色的一个重要方面

作者：Alex Yakyma

注意：本文是社区贡献系列的一部分，该系列根据 SAFe 扩展专家社区的经验和意见提供了更多观点和指导。

系统越大，开发和维护就越困难，测试就越困难。不容易测试的系统不能轻易改变。无法更改的系统无法以敏捷方式开发和交付。此外，在处理遗留系统时，添加单元或功能测试可能非常困难，因为系统在设计时没有考虑到可测试性。在本文中，我们建议 SAFe 系统架构师可以在帮助敏捷团队设计可测试性方面发挥关键作用，我们将考虑系统设计如何影响可测试性以及如何开始改进它的许多方面。

背景

可测试性设计 （DFT） 并不是一个新概念。它已与电子硬件设计一起使用超过 50 年。原因很简单：如果你想在设计阶段和以后的生产阶段都能测试集成电路，你必须设计它以便可以测试它。当你设计它时，你必须把钩子“放进去。你不能简单地在以后添加可测试性，因为电路已经在硅中了;你现在无法更改它。DFT 是一个关键的非功能性要求，影响着电子硬件设计的方方面面。同样，复杂的敏捷软件系统在设计和生产过程中都需要测试，并且适用相同的原则。你必须设计你的软件的可测试性，否则你将无法在完成后对其进行测试。

DFT的经济价值

敏捷测试涵盖了两个特定的业务角度：一方面，它提供了对产品进行批评的能力，从而最大限度地减少了缺陷对用户的影响。另一方面，它通过在持续集成过程中提供快速反馈来支持迭代开发。如果系统不允许进行简单的系统/组件/单元级测试，则这些因素都无法发挥作用。这意味着敏捷程序，通过每个设计决策来维持可测试性，将使企业能够实现更短的业务和架构史诗跑道。

DFT 有助于减少大型系统范围的影响，并为敏捷团队提供更易于管理的东西。这就是为什么系统架构师的角色在大规模敏捷中如此重要，但它也反映了一个不同的动机：敏捷架构师不是定义一个大设计前期（BDUF），而是通过确保开发的资产是高质量的，不需要重新审视，来帮助建立和维持有效的产品开发流程。这降低了开发延迟的成本，因为在为可测试性而设计的系统中，所有作业都需要更少的时间。

对系统架构的影响

经验告诉我们，当我们设计可测试性时，我们最终会实现更好的设计。事实上，DFT 通常推动关注点、分层架构或面向服务、代码中实体的高度内聚性等的明确分离。我们的测试的行为非常类似于系统“客户端”——单元测试模仿调用目标类方法的相应客户端类的行为;组件测试模仿客户端组件的行为;功能测试模仿最终用户，即整个系统的“客户端”。如果我们在所有这些层面上设计可测试性，我们还在类、组件、服务之间以及最终的用户界面和系统的其余部分之间提供清晰易懂的接口。

文化影响

可测试性设计不能仅仅被视为系统架构师的责任。所有敏捷团队都必须进行 DFT，这是一个支持开发人员、测试人员和系统架构师之间产品开发工作的持续旅程。它创造了一种对产品开发流程负有共同责任的文化，所有人都积极为系统设计和可测试性做出贡献。

系统架构师角色和 DFT

在可测试性设计方面，系统架构师可以在 DFT 中发挥主要作用：

表 1.系统架构师在促进系统可测试性方面的作用。

从哪里开始？

上表旨在提供一组初始想法，这些想法可能会为 DFT 生成一些新的架构史诗。当然，渐进式方法始终是最好的，因为团队可以继续专注于新功能和故事的价值交付，同时增加可测试性。此外，DFT的文化方面最好通过实施渐进式步骤来实现，这些步骤向团队表明，在每一个小小的设计计划之后，在不同的抽象级别上编写新的测试更容易，从而提高团队速度。

让团队获取一些当前的用户故事，并确定最少的重新设计工作量，让他们在以前无法编写的领域编写一些单元测试。然后，他们可以与他人分享研究结果和实际方法（例如，在最近的设计工作委员会会议上）。在表 1 中，您可以看到上述哪些方面可能会受到这些发现的影响——是否为所有团队提供了新的设计指南或对系统配置进行了更改等？

我们建议在系统级别使用类似的方法：让系统团队或功能团队尝试自动执行系统级测试，他们以前会失败，但让他们在当前的一两个功能的上下文中这样做。DFT是一项艰巨的工作。但就像其他所有事情一样，我们可以逐步接近它。

当我们谈论敏捷测试以及立即开始自动化测试的重要性时，我们必须考虑到当前的软件系统通常是不利于测试的。一方面，这是该行业的一个可悲事实;另一方面，通过“为可测试性而设计”，敏捷企业有了超越竞争对手的新机会，因为公司增强了其能力，能够为用户提供更多价值，并且做得更快。