产品的实际可测试性是指一个专门的测试员在给定的环境?中通过特定测试流程进行测试的容易程度。实际的可测试性取决于其他五个“可测试性”：项目相关可测试性、价值相关可测试性、主观可测试性、固有的可测试性以及认知可测试性（俗称“缺口风险”）。正如通常而言的质量一样，可测试性是一个可塑的、多维的宏观概念，并不能用任何具体的单位表达。但总体而言，我们能够通过定义与其相关的问题以及启发来提升产品可测试性。

　　趣味可测试性动态分析
　　产品的改变或质量标准的提高会降低认知可测试性。我们知道的与我们需要知道的之间的差距，是为什么初我们需要测试的原因。如果我们已经足够了解产品的质量或知道其质量标准要求很低，产品将更容易测试，因为没有太多需要测试的项目。这是认知可测试性。因此，如果产品的变化很大，或产品不能有差错自然而然的降低了可测试性。
　　可测试性任何方面的提高都将促进认知可测试性的改善。根据定义，努力改善可测性的任何方面，能够增加填补我们已知和需知之间信息豁口的概率。
　　改善测试策略可能降低主观可测试性，反之亦然。当我们意识到我们现有的测试方法，尽管易于执行，但实际上并不起效时，可能发生这种情况。毕竟，一个更好的测试策略，可能需要更多努力和技能。（祸兮福所倚）要注意的是相反的情况也可能会出现。我们或许会做出改变（例如：增加一个工具）使测试变得看似更容易，实际上却更糟糕。（福兮祸所伏）
　　增加内在可测试性或许会降低项目相关可测性。当设计一个产品让它更容易测试时，可能使得许多新的缺陷出现。发生这种情况或许也因为独立测试员看到它之前，开发员花了更长时间让产品性能稳定。良好的敏捷开发有助于减少这一问题的出现。
　　增加价值相关可测性可能会降低项目可测性。当问题发生在一个项目周期的后期时，同用户和利益相关者更好的接触，完善的预测和必要条件的知识可能导致深层次的重新设计和重新测试重新设计和重新测试。敏捷开发同样有助于解决这个问题。
　　提高实际可测试性还可以提高开发和维护。一个产品如果更容易测试，那它也更容易支持，调试和发展。可观测性和可控性也会跟着水涨船高。
　　测试员必须要求可测性。我们不能期望任何非测试人员能会认真考虑可测试性。他们能的话好，但千万不要太指望。一个的测试员当学习发现可测试性的问题，并同团队一起解决。