8年测试总结，自动化测试必要注意点+自动化测试框架（汇总）

admin • 2024-03-18 21:55 • 研发管理

目录：导读

前言

1、开始自动化测试，必须知道的点

1）为什么自动化测试?

在测试时，你进行了新的部署、bug修复，这是你如何保证新bug没有被引入老功能？你需要测试之前的功能。

因而，每当有bug修复，或新功能添加时，你都要手工测试所有功能？考虑到花费、资源、时间等等因素，你这么测试不是高效的。

因而自动化有了需求：
当你有太多回归测试工作要做时，请自动化你的测试工作

当你正在测试一款web应用时，与此同时，这个应用可能有数千用户正在使用。

你将如何测试这样的web应用？你将如何使用手工方式，同时模拟这些多的用户呢？这是一件十分困难的手工操作。

模拟众多虚拟用户，来测试应用的负载容量时，请将你的负载测试自动化

你正在测试一款代码被频繁修改的应用，虽然GUI几乎一样，但功能变动越多，需要的测试“维修”就越多。

当你的GUI几乎不变，功能频繁发生变化时，请将你的测试工作自动化。

2）关于自动化测试，有哪些风险?

在一些不同的情况下，你可以考虑自动化测试工作。这里我介绍自动化测试的一些风险。如果你已经下定决心要做自动化或者想要更早地采取措施，那么请先考虑以下问题。

1.你能找到有经验的人力吗?
想要自动化，你需要有一些编程经验的人员。

考虑一下你的人力资源。他们有足够的自动化测试经验吗？如果没有，他们有技术

能力或编程背景来轻松应对新技术吗？你打算投资建立一个好的自动化团队吗？如果你的答案是肯定的，那么考虑自动化你的工作吧。

2.自动化的初始成本非常高
我赞同这个观点：由于要雇用熟练的手动测试人员，因而手动测试的相关成本很高。但如果你正在考虑将自动化作为方案，请三思而后行。

自动化的初始新建成本太高，例如：自动化工具的购买，测试脚本的培训和维护。

很多自动化工具用户都会后悔做自动化。如果你花费了很高的成本，却只得到了一些好看的测试工具和一些基本的自动化脚本，那么自动化的用途是什么？

3.如果UI不是一成不变的，不要试图自动化
自动化测试用户界面前务，请必要小心。如果用户界面正在大范围发送变化，那么自动化脚本的维护成本将会非常高。在这种情况下，基本的UI自动化就足够了。

4.你的应用是否足够稳定，可以支持你的自动化测试工作?
在早期的开发周期中自动化测试工作将是一个坏主意（除非它处在一个敏捷的环境）。在这种情况下，脚本的维护成本将非常高。

5.你正在考虑100%自动化?
别异想天开了，你不可能100%将测试工作自动化。当然，有一些领域，如性能测试，回归测试，负载/压力测试，你可以有机会达到接近100％的自动化。但用户界面，文档，安装，兼容性和恢复等领域，必须手动完成测试。

6.不要自动化只执行一次的测试任务
某些识别应用领域和测试用例，可能只需要运行一次，并且不需要包含在回归测试中。避免自动化此类模块或测试用例。

7.你的自动化套件会长期使用吗?
每个自动化脚本套件都应该有足够长的使用寿命，其新建成本应该绝对低于手动执行成本。然而分析每个自动化脚本套件的有效成本有点困难。

对于单独的构建（一般假设，取决于具体的应用程序的复杂性），大约应该使用或运行至少15到20次自动化套件，才能获得良好的ROI。

自动化测试是实现大多数测试目标和有效利用资源和时间的最佳方式。但在选择自动化工具之前，你应该谨慎。在决定自动化测试工作之前，请确保有熟练的人力。否则，您的工具只是一个空架子，无法获得ROI。

将昂贵的自动化工具交给非技术人员会带来失望。在购买自动化工具之前，请确保该工具最适合你的要求。你不太可能拥有与你的要求100％匹配的工具。

你需要找出最符合你要求的工具的局限性，然后使用手动测试来克服这些测试工具的限制性。开源工具也是开始自动化的好选择。

不是100％依赖于手动或自动化，而是要使用手动测试和自动化测试的最佳组合。这是每个项目的最佳解决方案（我认为）。自动化套件不会找到所有的错误，也不能替代真正的测试人员。在许多情况下，随机测试也是必要的。

2、自动化测试框架

1）什么是自动化测试框架？

什么是框架？

特指为解决一个开放性问题而设计的具有一定约束性的支撑结构。在此结构上可以根据具体问题扩展、安插更多的组成部分，从而更迅速和方便地构建完整的解决问题的方案。

框架是整个或部分系统的可重用设计，表现为一组抽象构件及构件实例间交互的方法。也就是说框架本身不解决特定的问题，它是通过扩展的各种组件或者工具来解决问题，并且它可以方便的添加或者修改部分组件的功能。

什么是自动化测试框架？

什么是自动化测试框架，我们拆分来看的话，其实就是三个方面，自动化、测试、框架，什么是框架上面说了，还有就是他能执行测试，而且还是自动化的，所以框架的各个组件的主要功能就是围绕着如何自动化如何执行测试展开的。

这里可以把框架的各个功能称作模块，那我们来看看都需要那些模块，需要一个基础模块，主要是怎么实现脚本编写，管理模块，主要的行为是持续集成，定时执行、case管理，统计模块，主要是发送测试报告，统计分析。

那总结一下自动化测试框架的定义就是：把在自动化测试过程中用到的一些功能或者工具，分装成各个模块，包括如何进行自动化脚本编写以及分层功能的基础模块，进行持续集成、定时任务的管理模块，发送测试报告、进行测试结果统计分析的统计模块等，将这些模块组成一套可重用的骨架

2）自动化测试框架的设计原则

通用性：能够在各种各样的系统和平台都能够使用
易维护性：能够把我们的数据、用例、框架的实现进行独立的维护，能够在实现完善的过程，快速的定义到维护的点，而不对框架的其他功能造成影响

定时处理：能够在指定的时间执行
持续集成：当被测程序和测试代码有更新能够自动执行
调试：可调试行强
测试结果：测试报告、测试数据的统计分析

3）框架的设计思想

可以把自动化测试框架主体分为两部分，一个是内部框架，一个是外部框架，内部框架就是我们自己实现的测试框架代码，外部框架就是抛开我们实现的核心代码，要达到自动化测试框架设计原的一些内容时用到的一些第三方工具。

外部框架：
主要是指以webdriver为核心，辅以外部第三放框架和工具。用以实现持续集成、自动部署、脚本执行、远程调用、报告优化、邮件发送导等功能性框架，实现自动化框架设计原则的一些外围的组件。

内部框架：
也就是分层框架，目的在于更好的优化和管理测试用例，更便捷的进行数据、元素、脚本的维护和更快速的创建新脚本

自动化测试框架设计思路：

通用的外部框架实现逻辑
maven或者tox-自动编译，执行TestNG或junit，集成邮件发送等
TestNG或Junit、pytest，调用webdriver或者发送请求的方法，执行自动化测试用例，规范自动化测试脚本
selenium脚本或者接口用例脚本
reportNG或者allure报告优化模板
main 自动以html邮件通知或者Jenkins发送邮件

内部框架：
层架框架-也就是代码结构优化，根据具体的业务和需求可以大致分为以下几层，有时并不需要下面所有的层次，选取合适自己业务测试的就行。

TestCase层：执行的用例脚本
Task层：公共业务分装，是其他的项目不需要的，只和当前项目相关，比如公共登陆、搜索等业务
-utils层：与业务无关的方法，比如数据驱动-也就进行数据文件的读写、浏览器操作、元素定位方法等进行封装

page层或po层：页面层，页面层主要维护某一个页面的所有元素，对页面的操作、对元素的操作以及和其他页面的交互，业务其实就是一个元素到另一个元素或者一个页面到另一个页面，这就和task层有点重复一般有一个就可以了。
element层：公共元素或者组件的维护，或者自定义组件封装
data层：数据存储
properties层：配置文件、全局变量

下面是我整理的2024年最全的软件测试工程师学习知识架构体系图