1.软件设计框架

1.1 软件设计框架是什么?

  1. <br /> [软件框架(software framework)的标准定义](https://baike.baidu.com/item/%E8%BD%AF%E4%BB%B6%E6%A1%86%E6%9E%B6/1471931?fr=aladdin#reference-%5B1%5D-10610992-wrap):通常指的是为了实现某个业界标准或完成特定基本任务的软件组件规范,也指为实现某个软件组件规范时,提供规范所要求之基础功能的软件产品
  2. **框架(Framework) 通常指的是一种抽象的形式,它提供了一个具有通用功能的软件或者代码,这些代码或功能可以由使用者自行进行更改,从而开发出一个服务于“特定”应用的软件**。**它是对部分或者整个系统的可重用设计,往往表现为一组抽象构件以及构件实例间交互的方法,框架可以理解为被应用开发者定制的应用骨架。**

框架( Framework )是构成一类特定软件可复用设计的一组相互协作的类。框架规定了你的应用的体系结构。它定义了整体结构,类和对象的分割,各部分的主要责任,类和对象怎么协作,以及控制流程。框架预定义了这些设计参数,以便于应用设计者或实现者能集中精力于应用本身的特定细节

  软件框架本质上是一种通用的、可复用的软件环境(也就是别人写的代码),它提供了特定的功能,用以作为一个更大的软件平台的一部分,以达到促进软件应用、产品和解决方案的开发工作。也就是说,框架本身一般是不完整的,不可以解决特定的问题;框架就是天生为扩展而设计的;框架可以为后序扩展的组件提供很多辅助性、支撑性的方便易用的实用工具(即通常配套有一些帮助解决某类问题的库或工具)。

通俗来说,框架其实就是某种应用的半成品,就是一组组件,供你选用,来完成属于你自己的系统。再简单一点说,就是别人帮你搭建好了一个舞台,你来做表演。一个好的框架往往是十分成熟的,并不断地进行着迭代升级

    就其本质而言,框架是一个软件,而且是一个半成品的软件。所谓半成品,就是还不能完全实现用户需要的功能, 框架 只是实现用户需要的功能的一部分,还需要进一步加工,才能成为一个满足用户需要的、完整的软件。因此框架级的软件,它的主要客户是**开发人员**,而不是最终用户。

    有些朋友会想,既然框架只是个半成品,那何必要去学习和使用框架呢?学习成本也不算小,那就是因为框架能完成一定的功能,也就是这“框架已经完成的一定的功能”在吸引着开发人员,让大家投入去学习和使用框架。基于框架进行开发可以大大提升软件设计效率。

1.2 软件设计框架具体作用

     架构 能完成一定功能,加快应用开发进度,

    由于 框架 完成了一定的功能,而且通常是一些基础的、抽象的,有难度的、通用的功能,这就避免我们在应用开发的时候完全从头开始,而是在框架已有的功能之上继续开发,也就是说会复用框架的功能,从而加快应用的开发进度。

     架构 给我们一个精良的程序架构

    框架定义了应用的整体结构,包括类和对象的分割,各部分的主要责任,类和对象怎么协作,以及控制流程等等。

    业界大多数流行的软件设计框架,大都出自大师手笔,设计都很精良。基于这样的框架来开发,一般会遵循框架已经规划好的结构来进行开发,从而让我们开发的应用程序的结构也相对变得精良了。

1.3 软件设计框架和软件设计模式的区别

       框架与设计模式虽然相似,但却有着根本的不同。设计模式是对在某种环境中反复出现的问题以及解决该  问题的方案的描述,它比框架更抽象;框架可以用代码表示,也能直接执行或复用,而对模式而言只有实例才能  用代码表示;设计模式是比框架更小的元素,一个框架中往往含有一个或多个设计模式,框架总是针对某一特定     应用领域,但同一模式却可适用于各种应用。可以说,框架是软件,而设计模式是软件的知识

     框架 已经是实现出来的软件了,虽然只是个半成品的软件,但毕竟是已经实现出来的了。而 设计模式 的重心还在于解决问题的方案上,也就是还停留在思想的层面。因此设计模式比框架更为抽象。

     设计模式 是比 框架 更小的体系结构元素<br />          如上所述,框架是已经实现出来的软件,并实现了一系列的功能,因此一个框架,通常会包含多个设计模式的应用。<br />         框架 比 设计模式 更加特例化<br />         框架是完成一定功能的半成品软件,也就是说,框架的目的很明确,就是要解决某一个领域的某些问题,那是很具体的功能,不同的领域实现出来的框架是不一样的。<br />         而设计模式还停留在思想的层面,在不同的领域都可以应用,只要相应的问题适合用某个设计模式来解决。因此框架总是针对特定领域的,而设计模式更加注重从思想上,从方法上来解决问题,更加通用化

2. 自动化测试框架

2.1 自动化测试框架是什么


自动化测试框架当然是一种软件框架

                    **在执行测试的过程中,我们可以发现,发现无论执行什么类型的测试,其过程总有相似的地方,一般包括测试用例的收集, 测试执行的初始化, 测试用例执行的管理(执行顺序,重复执行,条件执行),测试数据的收集, 测试结果的判断,测试收尾工作, 测试报告的生成等。 于是我们把这些类似的测试流程进行总结和抽象,通过软件代码实现,这就是我们通常所说的自动化测试框架。**    <br />                    <br />                       因此自动化测试框架是为自动化测试用例或者脚本**提供执行环境而搭建的基础设施**。自动化测试框架有助于有效地开发、执行和报告自动化测试用例,自动化测试框架是为自动化**测试脚本**提供执行环境的平台。  

                  由于我们面对的测试项目类型和特点各不相同, 一般来说我们需要对现有的测试框架进行二次<br />开发,根据项目需求集成需要的插件等。  

2.2 自动化测试脚本是什么

        **测试脚本是通过软件代码来描述一个测试用例的执行过程,还包括对测试结果收集和断言。**

**  Testing script(测试脚本)**,一般指的是一个特定测试的一系列指令,这些指令可以被[自动化测试](https://so.csdn.net/so/search?q=%E8%87%AA%E5%8A%A8%E5%8C%96%E6%B5%8B%E8%AF%95)框架执行。 为了提高测试脚本的可维护性和可复用性,必须在执行测试脚本之前对它们进行构建。或许会发现这样的情况,即有的操作将出现在几个测试过程中。因此,应有目的地确定这些操作的目标,这样就可以复用它们的实施。 测试脚本是自动执行测试过程(或部分测试过程)的计算机可读指令。测试脚本可以被创建(记录)或使用测试自动化工具自动生成,或用编程语言编程来完成,也可综合前三种方法来完成。

测试脚本语言(test scripting language)是脚本语言的一种,准确地讲是脚本语言在测试领域地一个分支,是自动化软件测试设计的基础。要理解测试脚本语言就不能不对脚本语言进行一些了解。
脚本语言(scripting language) 就是在执行时以解释(interpreting) 为主的编程语言,比如常见的perl,python,php,tcl,guile,ruby以及UNIX系统的各种shell都是脚本语言。

目前自动化测试领域,最流行的脚本编程语言就是Python

脚本语言应用到测试领域就可以称之为测试脚本语言,以上提到的脚本语言都可以作为测试脚本语言来使用,特别是tcl语言更是被业界称为事实上的测试脚本语言标准。随着软件测试的发展,各种测试工具也相继推出,为了保护知识产权或者说是保护商业秘密,这些商业化的软件大多使用自己的测试脚本语言,比如MI的TSL语言等

测试用例为实施测试而向被测试系统提供的输入数据、操作或各种环境设置以及期望结果的一个特定的集合。 测试脚本是为了进行自动化测试而编写的脚本。测试脚本的编写必须对应相应的测试用例

2.3 自动化测试框架有哪些优点

代码复用,提高测试效率,更高的测试覆盖率,维护成本低,更早发现和记录bug 。

2.4 好的自动化测试框架有哪些标准?

  • 使自动化测试的实施更容易一个好的自动化测试框架是可以让不那么懂技术的人也可以

写自动化测试脚本

  • 解决自动化测试脚本本身存在的问题:如异常处理和场景恢复。
  • 测试易于维护
  • 可重用性:可以实现一些通用功能,简化脚本开发过程。
  • 测试报告美观易

2.5 自动化测试框架有哪些类别?

                目前流行的各种类型的自动化测试框架。这些框架可能基于对不同关键因素(例如驱动<br />      类型、可重用性、易于维护等)进行自动化的支持而彼此不同,下面我列举几种常见的类别:

2.5.1 基于模块的测试框架 (可应用程度-低)

image.png

这种框架将整个“测试中的应用程序”分为许多逻辑和独立的模块。对每个模块,创建一个独立的测试脚本,这些脚本结合在一起时,会构建成更大的测试脚本,代表多个模块,这些模块被抽象层隔开,这样在应用程序的各个部分所做的更改不会对该模块产生影响。

缺点:在为每个模块实现测试脚本的同时,测试数据已经嵌入到测试脚本中,这导致使用不同的测试数据进行测试时需要在测试脚本中进行操作。

2.5.2 基于库的测试框架 (可应用程度-低)

image.png

库体系结构测试框架是建立在基于模块的测试框架之上,但比后者有一些额外的优势。它没有将测试的应用程序划分为测试脚本,而是划分为函数。因此,为测试中的应用程序创建一个由公共函数组成的公共库,当需要时,可以从测试脚本中调用这些库。

它的基本原理就是确定通用的步骤,并将这些步骤分组到公共库下的函数中,在需要的时候在测试脚本中调用这些函数。

比如,一个登录的步骤,可以把它组合成一个函数,并保存到一个库中,登录时可以直接从库中调用这个函数,而不需要重新再编写代码。

缺点:像基于模块的框架一样,测试数据嵌入测试脚本中,改变数据需要修改脚本;随着越来越多的库的引入,可能会使框架越来越复杂

2.5.3 基于数字驱动测试框架 (可应用程度-高-重要)

image.png

              数据驱动是当前自动化测试中非常重要的思想,绝大多数情况下,**数据和逻辑分离**是我们进行自动化测试框架设计时,是必须要遵循法则。<br />        <br />                  数据驱动测试框架**将测试脚本逻辑和测试数据彼此分离**。**可以把测试数据单独存储起来**,存储数据的可以是 yaml文件、excel文件、文本文件、csv文件、ODBC数据库等。一般都是以 key-value (相当于python 中的字典)格式存储,方便获取使用 。   <br /> <br />                  其中**yaml **是目前最流行的数据储存格式之一。  

2.5.4 基于行为驱动测试框架 (可应用程度-低)

            <br />                  紧贴测试流程的执行过程, 逻辑代码线性化程度高, 行为驱动测试框架可以让开发人员、测试人员等以易于阅读和理解的格式实现功能验证的自动化。 可通过自然语言来描述测试功能,测试场景,测试步骤,测试结果等。 <br />        <br />                 由于数据和逻辑没有分离, 代码可维护程度低。 重复开发工作量大。 不太适合大型企业项目。

2.5.5 基于关键字驱动测试框架 (可应用程度-高-重要)

image.png

  关键字驱动测试框架是对数据驱动测试框架的扩展,从某种意义上说,它不仅将测试数据从脚本中分离出来,它还将数据测试脚本的特定代码集保存到外部数据文件中。这些代码集被称为关键字,每个关键字都一种操作。关键字和测试数据都是独立于该框架。

缺点:
需要懂得关键字的创建机制,从而可以自己开发关键字
随着越来越多的关键字引入,可能会使框架逐渐变得复杂
测试用例变得更长且复杂,从而影响测试用例的可维护性

2.5.6 混合驱动测试框架 (可应用程度-中)

image.png[

](https://blog.csdn.net/m0_37621024/article/details/116463040)
混合测试框架就是上述(模块化,数据驱动和关键字驱动)多中类型框架的组合。就是利用各种类型框架的优点,组合起来的混合型测试框架。

在这种框架中,通过将测试用例结合到模块化测试框架中,从模块化脚本中开发测试用例。每个测试用例都使用一个驱动程序脚本,该脚本使用数据驱动框架中的数据文件和关键字驱动框架中的操作文件。

缺点:会比其他类型的测试框架更为复杂一些,例如阅读、维护等
[

](https://blog.csdn.net/m0_37621024/article/details/116463040)

2.6 自动化测试框架包含哪些基本组件?

image.png

1、需要配置文件管理:
一般需要一个配置文件去控制一些环境信息、开关。配置文件可以是txt/xml/yaml/properties/ini,一般.properties使用较多在JAVA里,Python的话通常会选择ini文件。

2、业务逻辑代码和测试脚本分离
如果代码和脚本在一个类文件,那么就根本没有用到代码重构,复用。代码和用例文件分离后,会更加清晰,可以有更多人开发脚本,方便调试。

3、报告和日志文件输出
执行了多少case,case结果如何,这都需要报告来展示,一般采用第三方插件来实现这个功能。好多报告格式是html,简单,明了的风格。日志输出也很重要,如果发生报错,脚本执行失败,通过日志快速定位发生问题位置。

4、自定义的库的封装
很多功能需要重复调用,可以写成一个公用方法,放到工具包下,每次方便调用,例如浏览器引擎类和basepage.py的封装。

5、管理、执行脚本方式
例如Python中单元测试框架unittest使用率非常高。

6、第三方插件引入
有时候,一些功能需要借助第三方插件,能够更好实现,例如AutoIT(来实现文件上传和下载)。还有利用第三方报告插件生成基于html格式的测试报告。

7、持续集成
git、svn、ant、maven,jenkins,我们会把这整合到jenkins,达到持续集成,一键执行测试脚本。
[

](https://blog.csdn.net/m0_37621024/article/details/116463040)