为什么要搭建自动化测试框架？如何搭建？_为什么自动化脚本封装成框架执行-CSDN博客

本文链接：https://blog.csdn.net/MXB1220/article/details/129824335

什么是框架？

框架（Framework）是整个或部分系统的可重用设计，表现为一组抽象构件及构件实例间交互的方法;另一种定义认为，框架是可被应用开发者定制的应用骨架。前者是从应用方面而后者是从目的方面给出的定义。可以说，一个框架是一个可复用的设计构件，它规定了应用的体系结构，阐明了整个设计、协作构件之间的依赖关系、责任分配和控制流程，表现为一组抽象类以及其实例之间协作的方法，它为构件复用提供了上下文(Context)关系。因此构件库的大规模重用也需要框架。其实目前为止，框架还没有统一定义，我比较喜欢Ralph Johnson所给出的定义：

一个框架是一个可复用设计，它是由一组抽象类及其实例间协作关系来表达的【Johnson 98】。这个定义是从框架内涵的角度来定义框架的，当然也可以从框架用途的角度来给出框架的定义：一个框架是在一个给定的问题领域内，一个应用程序的一部分设计与实现。

为什么要用框架？

又是一个理所当然的问题。因为软件系统发展到今天已经很复杂了，特别是服务器端软件，涉及到的知识，内容，问题太多。在某些方面使用别人成熟的框架，就相当于让别人帮你完成一些基础工作，你只需要集中精力完成系统的业务逻辑设计。而且框架一般是成熟，稳健的，他可以处理系统很多细节问题，比如，事物处理，安全性，数据流控制等问题。还有框架一般都经过很多人使用，所以结构很好，所以扩展性也很好，而且它是不断升级的，你可以直接享受别人升级代码带来的好处。

为什么要搭建自动化测试框架？

从前我以为，自动化测试最重要的事情是找对象（Find Test Object）。现在我明白了一个道理，没有框架的自动化测试是找不到对象的，即使找到了也不会幸福的。就跟现实中，没有车没有房的人是很难找到对象的一个道理。

自动化测试的开发，通常是由自动化测试的需求决定的。这个需求主要包括：

自动化测试更便于实施。这个说的是，你写测试脚本要方便。一个好的自动化测试框架是可以让不那么懂技术的人也可以写自动化测试脚本的，哼。
解决自动化测试脚本本身存在的问题，如异常处理和场景恢复。
测试易于维护。自动化测试项目，基本都是没有好的管理以及维护，一定是个大坑。我可以很负责地说，自动化测试没有一年半载，你是看不到产出的。所以管理及维护就成了最重要的事情。而好的框架，可以减少你在管理维护中所投入的人力物力精力。
可重用性。框架的意义之一就在于可重用吧。所以在框架里，你可以实现一些通用功能，简化脚本开发过程。
美观易读的测试报告。拿UFT来说，它产出的测试报告只是基于测试脚本的，并没有那种基于测试集的报告，所以如果你要，测试框架里可以实现。

还有很多测试需求，我没办法一一列举出来，多数需求我们都可以在测试框架里去定制。现在可以回答上面那个问题了，record & playback是不会幸福的，你需要自动化测试框架。

请慎重考虑是否需要自动化测试（成本投入高，风险大）

自动化测试是个很傲娇的东西，它很挑项目。首先项目周期要长，但是需求不会频繁变更；其次系统中多数对象要可以被识别，并且不存在大量第三方插件。而且你要清楚，你不能指望自动化测试去帮你发现新的bug，自动化测试本身是不具备想象力的（相对于手工测试）。它的优势在于反复迭代，它的价值产出在于长期的回归测试，以保证被测产品长期稳定地版本更新。

关于自动化测试的切入点，通常要在完整的系统测试之后才算具备引入自动化测试的基本条件。

目前我所做的自动化测试成功案例，无一不具备良好的管理和优良的测试框架。二者缺一，自动化测试必然成为大坑。