自动化测试或性能测试能力_可测试性设计如何提高测试自动化能力

自动化测试或性能测试能力

介绍

可测试性是指测试某些东西的能力 。 当这是IT解决方案时，最合适的方法是Automation 。 但是总是有可能自动化测试吗？ 若否，原因为何？ 以及如何改善可测性？

测试类别

通常，软件是由消费者使用的，可以是一个人，另一个软件或物理设备。 在决定自动化测试时，首先要确定的是SUT （ 被测 系统 ）。 该决定决定了自动化的范围以及必须使用自动化测试框架进行仿真的观点。 可以有几种选择，以下是一些最常用的选择：

• 单元测试 ：这里我们要测试代码的最小部分，即方法。 因此，该框架通常是另一个使用SUT相同语言编写的软件程序，该程序能够与每种方法交互，并在其周围创建所有必要的上下文，从而能够执行逻辑并验证预期结果。 此逻辑与其他逻辑结合得越多，代码的可测试性就越差 。
• 集成测试 ：在这里我们要测试两个独立的软件组件是否能够正确对话。 因此，该框架类似于单元测试框架，只是SUT较大，导致涉及更多逻辑和独立组件。 在这类测试中，有趣的是测试例如边界情况以及不同组件之间的数据交换。 至于单元测试，我们必须能够隔离我们要测试的组件， 实际上过多的依赖关系会挖掘测试的有效性 。
• 功能测试 ：这里我们要测试程序使用者所感知的组件行为。 因此，该框架通常是另一个软件程序，该程序能够再现程序使用者的所有交互并在内部或外部检查SUT的结果或状态。 这些程序可以由脚本语言驱动，也可以是单元测试所用框架的扩展（后一种情况在Rich Client Platform解决方案中很常见，例如在NetBeans平台中 ，Jemmy / Jelly Tools扩展了JUnit以自动执行功能测试） 。 对于这类测试，通常必须提供复杂的上下文信息才能执行，因此对基础架构技术的强大依赖性可能使模拟执行测试所需的所有必要条件变得困难 。
• 非回归测试 ：这里我们要测试在两个不同版本的软件之间实现的逻辑的正确性。 该框架通常是一个软件程序，作为用于单元测试的程序，具有访问SUT的输入，功能和输出的功能。 在这里，可测试性问题较少涉及，导致与基础架构的依赖性以及其他软件程序无法避免，因为必须完整地再现系统的操作行为。

可测试性的限制

到目前为止，哪些因素可以挖掘可测试性？ 我会说糟糕的依赖关系或强耦合是主要原因。 有几种类型的依赖关系最好避免：

• 对资源的逻辑 ：当逻辑与特定资源紧密耦合时，就会发生这种形式的依赖关系，这意味着更改此资源将直接影响逻辑（资源可能是技术基础架构，文件系统，旧版软件）。 在这种情况下，逻辑无法与这些资源分离，因此，如果您需要自动化测试，则还必须将所有相关资源也带进去。 如果我们谈论的是数据库，并结合了逻辑，则意味着对于每个测试，您可能需要一个特定的数据库。 这将带来严重的性能和测试套件治理方面的问题。
• 逻辑到逻辑 ：当未应用松散耦合时，会发生这种形式的依赖性。 这意味着没有允许解耦两个交互软件部分的接口。 想象一下，一个10行的方法A正在使用静态对象的方法B来执行其功能。 好十行应该不难测试，但是对方法B的调用隐藏了什么？ 这种强大的耦合意味着方法B所做的任何逻辑都将包含在方法A的测试中，并且如果方法B需要在测试环境中不容易重现的资源或技术，则很可能您会拒绝使方法A自动化。
• UI的逻辑 ：当源代码没有在不同的层中正确组织时，会发生这种形式的依赖性。 因此，必须将逻辑分类为纯粹的应用程序逻辑，充当表示逻辑，为用户显示弹出窗口并等待输入。 但是，特别是对于单元测试，不可能重现用户交互，因此在这种特定情况下，不可能使单元测试自动化（但是非回归和集成自动化也会变得困难）。

如何提高测试自动化能力

可测试性是一个问题，从一开始就设计可测试性是授予良好水平的测试自动化功能的唯一方法。 为确保不可能在所有项目中都做到这一点，有时我们必须处理遗留代码，在这种情况下，代码审查和重构是唯一可能的解决方案。 我认为提高可测试性的一些好处是：

• 将您的源代码分为几层 ：这将允许您根据代码的范围对代码进行清晰的分类，并避免不良的依存关系（例如，您可以实现我先前文章中所讨论的多层体系结构 ）。
• 应用松散耦合 ：始终创建用于访问功能的接口，并使用允许物理上将合同与逻辑脱钩的技术环境。 应用此原理后，您可以用在测试范围内简单完成的任何其他实现来代替。 当应用于逻辑到逻辑的耦合时，这意味着您可以创建“ 测试双 精度”对象（ 伪对象，模拟，存根 ），该对象将仅专注于您要测试的代码行，并应用于逻辑与资源的耦合时将允许替换在测试环境中不容易设置的资源。 例如，数据库可以完全替换为内存中的较轻版本或某些脚本语言来模拟某些上下文。
• 考虑模块化 ：模块化您的体系结构，很好地定义和定义每个模块的范围，并仅公开其他模块必须使用的内容。 这将减少您可以创建的依赖项数量，从而避免了有用性。

结论

在进行新设计时，值得将可测试性作为主要考虑因素。 启动测试自动化露营之后，您将轻松获得成果。 相反，如果您要处理旧代码，则将描述许多重构模式，这些模式可以帮助提高可测试性。 可以肯定的是，即使不是针对可测试性进行设计，自动化测试的总体功能也会很快成为问题。

参考： 可 重构性博客上的JCG合作伙伴 Marco Di Stefano提供了可测试性设计如何提高测试自动化能力的信息。

翻译自: https://www.javacodegeeks.com/2013/06/how-design-for-testability-can-improve-test-automation-capability.html

自动化测试或性能测试能力