自动化测试技术探究,有哪些方法和框架？

1  引子

       测试自动化的重要性不言而喻，随着敏捷编程理念的大行其道，自动化测试也越来越引起众多公司的重视。这篇文章我们来学习和探讨一下测试自动化的话题。

 2  测试自动化

       在软件测试中，测试自动化是指使用与被测软件分离的软件来控制测试的执行，并对实际结果与预测结果进行比较，测试自动化可以在已经形成的正式测试流程中自动完成一些重复但必要的任务，或者执行一些人工难以完成的额外测试。测试自动化对于持续交付和持续测试来说是至关重要的。

 2.1 测试自动化方法

       测试自动化的方法有很多，但下面是广泛使用的一般方法：

 2.1.1 图形用户界面测试

       图形用户界面测试会生成用户界面事件，如按键和鼠标点击等，并观察用户界面的变化，以验证程序的行为是否正确。

       许多测试自动化工具提供了记录和回放功能，允许交互式地记录用户的操作，并对用户的操作进行任意次数的回放，将实际结果与预期结果进行比较。这种方法的优点是它几乎不需要软件开发。这种方法可以应用于任何具有图形用户界面的应用程序。然而，依赖这些功能会带来重大的可靠性和可维护性问题。重新标注一个按钮或将其移动到窗口的另一部分，可能需要重新录制测试案例。记录和回放也可能会增加一些不相关的活动或者错误地记录一些活动。

       这类工具的一个变种是用于网站的测试。这里，"界面 "就是网页。这样的框架通过在渲染HTML时监听DOM事件进行记录，而不是像桌面系统应用那样监听操作系统事件。无头（Headless）浏览器或基于Selenium Web Driver的解决方案通常用于此目的。

       这类工具的另一种变种是移动应用测试。鉴于移动电话上使用不同尺寸、分辨率的屏幕和不同的操作系统，这类工具的使用显得非常有意义。对于这种变体，需要使用一个框架在移动设备上进行实例化操作，并收集操作结果，作为记录再回放测试。

       另一个变种是无脚本测试自动化，它不使用记录和回放机制，而是建立一个应用程序的模型，然后让测试人员通过简单地插入测试参数和条件来创建测试用例，这一部分不需要脚本技能。

2.1.2 API驱动测试

       API驱动测试是利用程序的编程接口来验证被测行为的测试框架。通常情况下，API驱动测试完全绕过了应用程序的用户界面。可以是测试类、模块或库的公共接口，通过各种输入参数来验证返回的结果是否正确。

       API测试被软件测试人员广泛使用，因为它可以验证独立于GUI实现的需求，通常是为了在开发的早期进行测试，并确保测试本身遵守清洁代码原则，特别是单一责任原则。它涉及到直接测试API作为集成测试的一部分，以确定API是否满足功能、可靠性、性能和安全性等方面的期望。

       由于API缺乏GUI，所以API测试是在消息层进行的。当API作为应用逻辑的主要接口时，API测试被认为是至关重要的。

2.1.3 持续测试

       持续测试是作为软件交付管道的一部分执行自动化测试的过程，以获得与软件发布相关的业务风险的即时反馈。对于持续测试来说，测试的范围从验证自下而上的需求或用户故事扩展到评估与总体业务目标相关的系统需求。

2.2 测试自动化决策

       自动生成测试用例的一种方法是基于模型的测试，通过使用系统模型来生成测试用例，但是对各种替代方法的研究还在继续。

       对什么进行自动化，何时自动化，是否真的需要自动化，是测试（或开发）团队必须做出的关键性决策，通过对52位从业者和26位学术界人士的多方文献综述发现，测试自动化决策需要考虑的5个主要因素是：

·     测试中的系统（SUT），

·     测试的类型和数量，

·     测试工具，

·     人和组织话题，

·     交叉因素。

       研究中发现最常见的个别因素是：回归测试的需要、经济因素、SUT的成熟度。

2.3 单元测试

       软件开发中越来越多的趋势是使用单元测试框架，例如xUnit框架（例如JUnit和NUnit），这些框架允许执行单元测试，以确定代码的各个部分在各种情况下是否按照预期的方式运行。测试用例描述了需要在程序上运行的测试，以验证程序是否按预期运行。

       测试自动化，主要使用单元测试，是极端编程和敏捷软件开发的一个重要特征，它被称为测试驱动开发（TDD）或测试优先开发。单元测试可以在代码编写之前，通过编写单元测试来定义功能。然而，这些单元测试会随着编码的进行、问题的发现和代码的重构而不断发展和扩充，只有当所有需求功能的测试全部通过时，代码才被认为是完整的。

       与人工探索测试的代码相比，它所产生的软件更可靠，成本也更低，因为它的代码覆盖面更好，而且是在开发过程中不断地运行，而不是像瀑布式开发那样周期结束时才运行一次。开发者在进行修改时，会立即发现缺陷，这时修复缺陷的成本最低。

       最后，当使用单元测试时，代码重构更安全；当重构后的代码被单元测试覆盖时，将代码转化为更简单的形式，代码重复的情况更少，引入新的缺陷的可能性要小得多。

       一些软件测试任务（如广泛的低级接口回归测试）有时是是费时费力的手工测试。此外，手动方法可能并不总是能有效地发现某些类别的缺陷。测试自动化为有效地执行这些类型的测试提供了一种可能性。

       一旦开发出了自动化测试，就可以快速、反复地运行。很多时候，这可以成为维护寿命较长的软件产品的回归测试的一种经济有效的方法。在应用程序的生命周期内，即使是一些小的补丁也会导致现有的功能被打断，而这些功能之前还是可以工作的。

2.4 自动化测试的特殊要求

       虽然自动化测试的可重用性受到软件开发公司的重视，但这种属性也可以被视为缺点。它导致了所谓的 "Pesticide Paradox"，即重复执行的脚本无法检测超出其框架本身的错误。在这种情况下，手动测试是一个更好的选项。这种模糊性再次导致了一个结论，那就是测试自动化的决定应该根据项目的要求和特殊性来单独做出。

       测试自动化工具可能很昂贵，通常与人工测试结合使用。从长远来看，测试自动化可以使测试自动化具有成本效益，尤其是在回归测试中反复使用时。测试自动化的一个很好的候选者是应用程序的普通流程的测试用例，因为每次在应用程序中进行功能增强时，都需要执行回归测试。测试自动化减少了与手动测试相关的精力。开发和维护自动化检查，以及审查测试结果，都需要人工参与。

       在自动化测试中，测试工程师或软件质量保证人员必须具备软件编码能力，因为测试用例是以源码的形式编写的，当运行时，源码会根据其中的断言产生输出。有些测试自动化工具允许用关键字代替编码来编写测试用例，而不需要编程。

3  自动化框架方法

       测试自动化框架是一个集成的系统，它设定了特定产品的自动化规则。这个系统集成了功能库、测试数据源、测试对象细节和各种可重用的模块。这些组件就像一个个小的积木，需要组装成代表一个业务流程的组件。该框架提供了测试自动化的基础，简化了自动化工作。

       支持自动化软件测试的假设、概念和工具框架的主要优点是维护成本低。如果任何测试用例发生变化，那么只需要更新测试用例文件，其他的如驱动脚本和启动脚本将保持不变。理想情况下，如果应用程序发生变化，不需要更新脚本。

       选择正确的框架/脚本技术有助于保持较低的成本。与测试脚本相关的成本来自于开发和维护工作。测试自动化过程中使用的脚本编写方法对成本会有影响。

       一般会使用框架/脚本技术有：

·     线性（程序性代码，可以是通过使用记录和回放等工具生成的程序性代码）

·     结构化（使用控制结构，通常是 "if-else"、"switch"、"for"、"while "条件/语句）

·     数据驱动（数据被保存在数据库、电子表格或其他机制中的测试之外的数据）

·     关键字驱动

·     混合型（使用上述两种或两种以上的模式）

·     敏捷自动化框架

       测试框架的职责有：

·     确定表达期望的格式

·     创建一个连接到或驱动被测应用的机制

·     执行测试

·     报告结果

3.1 测试自动化接口

       测试自动化接口是一个平台，它提供了一个单一的工作空间，用于整合多种测试工具和框架，用于测试使用的系统或者集成测试。测试自动化接口的目标是简化测试与业务标准的映射过程，而不需要编码来阻碍这个过程。测试自动化接口有望提高维护测试脚本的效率和灵活性。

       测试自动化接口由以下核心模块组成：

3.1.1 接口引擎

       接口引擎是建立在接口环境之上的。接口引擎由一个解析器和一个测试运行器组成。解析器的存在是为了将来自于对象库的对象文件解析成特定的测试脚本语言。测试运行器使用测试线束来执行测试脚本。

3.1.2 界面环境

 用于协调用户操作与接口调用的界面平台环境。

3.1.3 对象存储库

       对象库是测试工具在探索被测应用程序时记录的UI/Application对象数据的集合。

3.2 定义自动化框架和测试工具之间的界限

       工具是专门针对某些特定的测试环境而设计的，如Windows和Web自动化工具等。工具作为一个自动化过程的推动者。然而，自动化框架不是执行特定任务的工具，而是提供解决方案的基础设施，不同的工具可以在这里以统一的方式完成自己的工作, 这也就为自动化工程师提供了一个共同的平台。

       测试框架存在各种类型的，根据使用的自动化组件可分类如下：

·     数据驱动的测试

·     模块化驱动的测试

·     关键字驱动的测试

·     混合测试

·     基于模型的测试

·     编码驱动的测试

·     行为驱动的开发

3.3 测试什么？

       测试工具可以对自动化任务提供帮助，如产品安装、测试数据创建、GUI交互、问题检测、缺陷记录等，而不一定要以端到端的方式实现测试自动化。

       人们在考虑选择测试自动化的时候，常见的需求有：

·     平台和操作系统的独立性

·     数据驱动能力(输入数据、输出数据、元数据)

·     自定义报表（DB数据库访问、水晶报表）

·     便于调试和记录

·     版本控制友好 - 最小化二进制文件

·     可扩展性和定制化（开放的API，以便能够与其他工具进行集成）

·     通用驱动。这使得测试能够与开发人员的工作流程集成

·     支持无人值守的测试运行，以实现与构建过程和批处理运行的集成。

·     电子邮件通知

·     支持分布式执行环境（分布式测试床Test Bed）

·     分布式应用支持（分布式SUT）

3.4 语言级的单元测试支持

       有些编程语言直接支持单元测试。它们的语法允许直接声明单元测试，而不需要导入库（无论是第三方还是标准库）。此外，单元测试的布尔条件可以用与非单元测试代码中使用的布尔表达式相同的语法来表示，比如if和while语句中使用的布尔表达式。

       具有内置单元测试支持的语言包括：

·     Apex

·     Cobra

·     Crystal

·     D

·     Go

·     LabVIEW

·     MATLAB

·     Python

·     Racket

·     Ruby

·     Rust

       对于其他的没有内置单元测试支持的编程语言建议使用基于xUnit的测试框架。

3.5 GUI测试工具

       GUI测试工具的目的是用图形化的用户界面实现软件的自动化测试过程。

       参考列表如下：

4  小结

       我们在本文中对自动化测试的相关知识进行了概要性的学习和探索, 希望可以抛砖引玉，对各位朋友有所裨益。

       欢迎批评指正。