检查传出耦合的关系数据，并将其与代码覆盖相关联，会促进作出更明智的决策。例如，假设一个新的需求传达给开发团队。您可以将与该需求相关的更改精确到图 4 所示的 com.acme.ascp.util 包。而且，在以前几个版本中，依赖于 util 并且具有 0 抽象性的 dao 包具有很多高优先权的缺陷（非常可能是因为对这个包进行的开发人员测试太有限，有意思的是，最大的可能是由于代码中的高复杂性值引起的）。
在这种情况下，您的优势是了解 com.acme.ascp.util 和 com.acme.ascp.dao 之间的关系。知道 dao 包依赖于 util 这一事实告诉您，为支持新需求而在 util 中进行的任何修改可能会对易出故障的 dao 包产生负面的影响！
看到这个链接将帮助进行风险评估，甚至帮助进行工作级别的分析。如果未注意到这个链接，您可能已经猜到将需要快速编码工作来支持新需求。如果已经看到这个链接，就可以分配适当的时间和资源来降低 dao 包中的间接损害。
正像连续地监视传入耦合可以揭示架构设计中的熵一样，监视传出耦合也有助于发现不必要的依赖性。例如，在图 5 中，似乎在一些地方有人决定 com.acme.ascp.web 包要为 com.acme.ascp.user 提供内容。在 user 包中的某处，一个或多个对象正在实际从 web 包导入一个对象。
图 5. user 包中的传出耦合
很明显，这并非架构设计最初意图。但是，由于您一直针对传出耦合而监视系统，所以可以轻松地重构并改正这些不一致。或许，web 包中有用的实用工具对象应该移动到实用工具包，以便其他包可以利用它而不会引起不必要的依赖性。
文章来源于领测软件测试网 https://www.ltesting.net/
