参数化数据驱动 数据驱动测试也称


pytest测试框架-数据驱动 yaml/excel/csv/json
测试驱动在自动化测试中的应用场景:
【参数化数据驱动 数据驱动测试也称】 实现读yaml文件,先创建env.yml文件配置测试数据
结果示例:
常用的读取方式有:xlrd、xlwings、pandas、openpyxl
黑盒测试与白盒测试的区别?
虽然下面说的这么多,但只要能说出自己最理解的几点就可以了! 白盒测试:依据:LLD(详细设计)目的:利用不同的逻辑率到达某种程度的代码覆盖率(考虑全部程度的代码覆盖率会增加本) 步骤:静态分析和动态分析优点:迫使测试人员去了解软件的实现 检测代码中的每条路径和分支 揭示隐藏在代码中的错误 对代码的测试进行比较彻底缺点:白盒测试投入较大,成本较高 白盒测试不验证规格的正确性 无法检查代码中遗漏的路径和数据敏感性错误黑盒测试:依据:SRS(Software requriement specification软件需求说明书)目的:从质量特性的不同方面,对软件进行测试,检测该软件是否实现了SRS中所有显示和隐式的需求步骤:构造输入和预期输出,通过一定的操作步骤来测试软件 。优点:对较大的代码单元来说,黑盒测试比白盒测试的效率高 测试人员不需要了解实现得细节,包括特定的编程语言 测试人员和编程人员是相互独立的 从用户的角度进行测试,很容易被接受和理解 有助于暴露任何与闺阁不一致或者歧异的地方 测试用例可以在规格完成后马上进行缺点:不能测试程序内部特定部位 如果程序未执行的代码无法发现 没有清晰的和简明的规格,测试用例很难被设计
参数化数据驱动
在自动化测试中,经常会遇到如下场景:
这里只是随意找了两个典型的例子,相信大家都有遇到过很多类似的场景 。总结下来,就是在我们的自动化测试脚本中存在参数,并且我们需要采用不同的参数去运行 。
经过概括,参数基本上分为两种类型:
然后,对于参数而言,我们可能具有一个参数列表,在脚本运行时需要按照不同的规则去取值,例如顺序取值、随机取值、循环取值等等 。
这就是典型的参数化和数据驱动 。
如需对某测试用例(testcase)实现参数化数据驱动,需要使用Parameters函数,定义参数名称并指定数据源取值方式 。
参数名称的定义分为两种情况:
数据源指定支持三种方式:
三种方式可根据实际项目需求进行灵活选择,同时支持多种方式的组合使用 。假如测试用例中定义了多个参数,那么测试用例在运行时会对参数进行笛卡尔积组合,覆盖所有参数组合情况 。
使用方式概览如下:
将参数名称定义和数据源指定方式进行组合,共有 6 种形式 。现分别针对每一类情况进行详细说明 。
对于参数列表比较小的情况,最简单的方式是直接在 pytest 中指定参数列表内容 。
例如,对于独立参数 password,参数列表为 ['aA123456','A123456',''],那么就可以按照如下方式进行配置:
进行该配置后,测试用例在运行时就会对 password 实现数据驱动,即分别使用 ['aA123456','A123456',''] 三个值运行测试用例 。运行日志如下所示:
可以看出,测试用例总共运行了 3 次,并且每次运行时都是采用的不同 password 。
对于已有参数列表,并且数据量比较大的情况,比较适合的方式是将参数列表值存储在 CSV 数据文件中 。
对于 CSV 数据文件,需要遵循如下几项约定的规则:
例如,password 的参数取值为"aA123456","A123456","" ,那么我们就可以创建 password.csv,并且在文件中按照如下形式进行描述 。
然后在 pytest 测试用例文件中,就可以通过内置的 Parameterize(可简写为 P)函数引用 CSV 文件 。
假设项目的根目录下有 data 文件夹,password.csv 位于其中,那么 password.csv 的引用描述如下:
即 Parameters 函数的参数(CSV 文件路径)是相对于项目根目录的相对路径 。当然,这里也可以使用 CSV 文件在系统中的绝对路径,不过这样的话在项目路径变动时就会出现问题,因此推荐使用相对路径的形式 。
对于没有现成参数列表,或者需要更灵活的方式动态生成参数的情况,可以通过在 debugtalk.py 中自定义函数生成参数列表,并在 pytest 引用自定义函数的方式 。
例如,若需对 password 进行参数化数据驱动,那么就可以在 debugtalk.py 中定义一个函数,返回参数列表 。
然后,在 pytest 的 Parameters 中就可以通过调用自定义函数的形式来指定数据源 。
另外,通过函数的传参机制,还可以实现更灵活的参数生成功能,在调用函数时指定需要生成的参数个数 。
对于具有关联性的多个参数,例如 username 和 password,那么就可以按照如下方式进行配置:
进行该配置后,测试用例在运行时就会对 password 和 error_code 实现数据驱动,即分别使用
{"error_code": "0", "password": "aA123456"}、
{"error_code": "3007", "password": "A123456"}、
{"error_code": "3001", "password": ""}
运行 3 次测试,并且保证参数值总是成对使用 。
对于具有关联性的多个参数,例如 username 和 password,那么就可以创建 username_password_errorCode.csv,并在文件中按照如下形式进行描述 。
然后在 pytest 测试用例文件中,就可以通过内置的 parameterize(可简写为 P)函数引用 CSV 文件 。
假设项目的根目录下有 data 文件夹,username_password_errorCode.csv 位于其中,那么 username_password_errorCode.csv 的引用描述如下:
对于具有关联性的多个参数,实现方式也类似 。
例如,在 debugtalk.py 中定义函数 get_account,生成指定数量的账号密码参数列表 。
那么在 pytest 的 Parameters 函数中就可以调用自定义函数生成指定数量的参数列表 。
完成以上参数定义和数据源准备工作之后,参数化运行与普通测试用例的运行完全一致 。
采用 hrun 命令运行自动化测试:
采用 locusts 命令运行性能测试:
区别在于,自动化测试时遍历一遍后会终止执行,性能测试时每个并发用户都会循环遍历所有参数 。
自动化测试中,数据驱动是什么?
 数据驱动的自动化测试框架是这样的一个框架,从某个数据文件(例如ODBC源文件、Excel文件、Csv文件、ADO对象文件等)中读取输入、输出的测试数据,然后通过变量传入事先录制好的或手工编写的测试脚本中 。其中,这些变量被用作传递(输入/输出)用来验证应用程序的测试数据 。在这个过程中,数据文件的读取、测试状态和所有测试信息都被编写进测试脚本里;测试数据只包含在数据文件中,而不是脚本里,测试脚本只是一个“驱动”,或者说是一个传送数据的机制 。
数据驱动测试的介绍
数据驱动测试,即黑盒测试(Black-box Testing),又称为功能测试,是把测试对象看作一个黑盒子 。利用黑盒测试法进行动态测试时,需要测试软件产品的功能,不需测试软件产品的内部结构和处理过程 。数据驱动测试注重于测试软件的功能性需求,也即数据驱动测试使软件工程师派生出执行程序所有功能需求的输入条件 。数据驱动测试并不是白盒测试的替代品,而是用于辅助白盒测试发现其他类型的错误 。

请问软件测试中的黑盒、白盒测试指的是什么呢?
 白盒测试:
也称结构测试或逻辑驱动测试,它是知道产品内部工作过程,可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行,按照程序内部的结构测试程序,检验程序中的每条通路是否都有能按预定要求正确工作,而不顾它的功能 。
 白盒测试常用方法
基本覆盖标准:逻辑驱动、循环、基路测试等,主要用于软件验证 。
“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试 。
“白盒”法是穷举路径测试 。在使用这一方案时,测试者必须检查程序的内部结构,从检查程序的逻辑着手,得出测试数据 。贯穿程序的独立路径数是天文数字 。但即使每条路径都测试了仍然可能有错误 。
黑盒测试:
也称功能测试、数据驱动测试,它将被测软件看作一个打不开的黑盒,主要根据功能需求设计测试用例,进行测试 。
概念:黑盒测试是从一种从软件外部对软件实施的测试,也称功能测试或基于规格说明的测试 。其基本观点是:任何程序都可以看作是从输入定义域到输出值域的映射,这种观点将被测程序看作一个打不开的黑盒,黑盒里面的内容(实现)是完全不知道的,只知道软件要做什么 。因无法看到盒子中的内容,所以不知道软件是如何实现的,也不关心黑盒里面的结构,只关心软件的输入数据和输出结果 。
检测软件功能能否按照需求规格说明书的规定正常工作,是否有功能遗漏;
检测是否有人机交互错误,是否有数据结构和外部数据库访问错误,是否能恰当地接收数据并保持外部信息(如数据库或文件)等的完整性;
检测行为、性能等特性是否满足要求等; 检测程序初始化和终止方面的错误等 。
关于数据驱动测试和数据驱动测试也称的内容就分享到这儿!更多实用知识经验,尽在 www.hubeilong.com