《自动化测试修炼宝典》-第二章节-测试自动化的前期准备
关键词
可测试性，驱动程序，入侵级别，测试执行工具，测试钩子，测试自动化管理器
学习目标
2.1影响测试自动化的因素
分析被测系统，确定适当的自动化解决方案
2.2工具评估与选择
分析特定项目的测试自动化工具，给出建议
2.3可测性和自动化设计
了解“可测性设计”和“测试自动化设计”
2.1影响测试自动化的因素
?被测系统接口
自动测试用例调用被测系统上的操作。为此，被测系统必须提供可以控制被测系统的接口。
这可以通过UI控件完成，也可以通过较低级别的软件界面完成。
一些测试用例可能能够在通信级别（例如，使用TCP / IP，USB或专有消息接口）进行。
没有可用于测试的用户界面，需要使用软件接口（也称为测试钩子）。
?第三方软件
通常，被测系统不仅有自己的系统，还有第三方提供的软件。
在某些情况下，此第三方软件可能需要测试。
?入侵级别
不同的测试自动化方法（使用不同的工具）具有不同的入侵级别。
对于专门用于自动化测试的被测系统需要进行的更改次数越多，入侵级别越高。
使用专用软件界面需要高水平的入侵，而使用现有的UI元素具有较低的入侵级别。
使用被测系统的硬件元素（如键盘，手动开关，触摸屏，通讯接口）具有更高的入侵水平。
更高级别入侵有虚假警 的风险。
TAS可能会由于测试引起的入侵程度而导致故障，但是当软件系统在真实的现场环境中使用时，这些故障可能不会发生。
测试具有高水平的入侵通常是测试自动化方法的更简单的解决方案。
?不同的被测系统架构
不同的被测系统架构可能需要不同的测试自动化解决方案。
使用COM技术编写的使用C ++编写的被测系统需要一种不同的方法，而不是用Python编写的被测系统。
这些不同架构可能有可能通过相同的测试自动化策略来处理，需要混合使用，达到最佳效果。
?被测系统的大小和复杂性
考虑当前被测系统的规模和复杂性以及未来发展的计划。
对于一个简单而简单的被测系统，可能不需要一个复杂而超灵活的测试自动化方法。
一种简单的方法可能更适合。
相反，对于一个非常大和复杂的被测系统来实现一个小而简单的方法可能不明智。
有时候，即使对于复杂的被测系统来说，开始小而简单也是适当的，但这应该是一种临时方法。
2.2工具评估与选择
?评估组织成熟度和确定测试工具使用方式
?评估测试工具使用需要达成的目标
?识别并收集合适工具
?根据目标和项目约束分析工具信息
?根据坚实的商业案例估算成本效益比
?推荐自动化实施工具
?分析测试工具与被测系统的使用匹配度
功能测试自动化工具经常无法满足自动化项目遇到的所有期望或情况。以下是一系列这些类型的问题的例子（能力有限，可能不全）：
| 问题 | 案例 | 解决方案 |
| 和其他工具不兼容 | ·测试管理工具已更新，连接界面已更改 | ·在任何更新之前注意发行说明，并在迁移到生产之前进行大型迁移测试 |
| ·来自售前支持的信息是错误的，并不是所有的数据都可以转移到 告工具中 | ·尝试获得使用真实SUT的工具的现场演示 | |
| · 寻求供应商和/或用户 区论坛的支持 | ||
| 和开发测试技术平台不兼容 | · 开发部门已更新到最新版本的Java | ·用于开发/测试环境的同步升级和测试自动化工具 |
| GUI上的对象无法捕获 | · 对象可见，但测试自动化工具无法与之进行交互 | ·只能在开发中仅使用知名技术或对象 |
| ·在购买测试自动化工具之前先做一个试点项目 | ||
| · 有开发人员定义对象的标准 | ||
| 工具很复杂 | · 该工具有一个巨大的功能集，但只有一部分将被使用 | · 尝试找到一种方法来限制功能集从工具栏中删除不需要的功能 |
| · 选择许可证以满足您的需求。 | ||
| · 尝试找到更专注于所需功能的其他工具。 | ||
| 与其他系统冲突· | · 安装其他软件后，测试自动化工具不再工作，反之亦然 | · 安装前请阅读发行说明或技术要求。 |
| · 从供应商获得确认对其他工具没有影响。 | ||
| · 问题用户 区论坛 | ||
| 对SUT的影响 | · 在使用测试自动化工具之前/之后，SUT的反应不同（例如更长的响应时间） | ·使用不需要更改SUT的工具（例如，安装库等） |
| 访问代码 | · 测试自动化工具将更改源代码的一部分 | ·测试自动化工具将更改源代码的一部分·使用不需要更改源代码的工具（例如，安装库等） |
| 有限的资源（主要在嵌入式环境中） | ·测试环境有限的可用资源或资源不足（例如内存） | · 阅读发行说明，并与工具提供商讨论环境，以确认这不会导致问题。 |
| · 问题用户 区论坛 | ||
| 更新 | · 更新不会迁移所有数据或破坏现有的自动测试脚本，数据或配置 | · 在测试环境中测试升级，并从提供商获得迁移工作的确认 |
| ·升级需要不同的（更好）的环境 | · 阅读更新先决条件，并决定更新是否值得努力 | |
| ·从用户 区论坛寻求支持 | ||
| 安全性 | ·测试自动化工具需要测试自动化工程师不可用的信息 | · 测试自动化工程师需要被授予访问权限 |
| 不同环境和平台之间的不兼容性 | 测试自动化在所有环境/平台上都不起作用 | · 实施自动测试以最大限度地提高工具独立性，从而最大限度地降低使用多种工具的成本。 |
2.3可测性和自动化设计
可测性设计包括几个部分：
?可观察性：被测系统需要提供能够深入了解系统的界面。然后，测试用例可以使用这些接口来检查，例如，预期行为是否等于实际行为。
?控制能力：被测系统需要提供可用于在被测系统上执行操作的接口。这可以是UI元件，功能调用，通信元件（例如TCP / IP或USB协议），电子信 （用于物理开关）等。
?明确定义的架构：可测试性设计的第三个重要部分是提供清晰可理解的界面，为所有测试级别提供控制和可见性。
考虑如何测试被测系统，包括自动测试，有效（测试正确的领域和发现关键错误）和高效（不需要太多努力）的方式。
每当需要特定的软件接口时，它们必须由TAE指定并由开发人员实施。
重要的是在项目初期定义可测试性，并在必要时提供额外的软件接口，以便开发工作可以进行计划和预算。
支持测试的软件界面的一些例子包括：
?EXCEL电子表格强大的脚本功能。
?仿真器，替代高成本软件或硬件。
?软件接口（或存根和驱动程序）可用于测试错误状况。
?当没有UI可用时，使用软件接口测试。
设计可测试性对于测试自动化至关重要，也有益于手动测试。
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！