2.pytest用例设计及运行

pytest测试用例可以存在函数级别,也可以存在类级别。只需要按照内部的规则设计用例,它可以自动去发现测试用例,不需要像unittest框架测试类需要继承TestCase;

在运行时可以在命令行窗口运行,也可以在pycharm中直接运行,下面会详解两种运行方式;

1.pytest用例设计规则

  1. 所有的测试脚本存放在python的包中。python的包中带有__init__.py文件
  2. 模块名设计规则:test_*.py 或者 *_test.py
  3. 类名设计规则:   Test* 以Test开头的类
  4. 方法名设计规则:test_* 以test_开头的方法名
  5. 函数名设计规则:test_* 以test_开头的函数

2.脚本命令行运行3中方式

  pytest(推荐使用)  py.test  python -m pytest

3.执行脚本时参数

  -s 详细显示日志信息

  -q 显示简略运行信息

  -x 遇到第一个失败用例停止运行

  --maxfile=2 遇到第二个失败用例停止运行,可以改变停止运行的失败用例数

4.pycharm中运性用例

确定是否是pytest运行器运行

更改运行器:file-->setings

用例运行顺序

1.如果鼠标悬停在其中一个用例右键运行,则只会运行悬停处用例;

2.如果鼠标没有悬停则顺序为先运行函数级别用例,在运行类级别用例;

函数级别用例和类中测试方法的运行顺序根据函数名或方法名的尾部,数字优先,然后字母根据ascll码顺序执行;

example:

def test_add_1():
    assert add(1,2)==3

def test_add_2():
    assert add(2,3)==4

def test_add_a():
    assert add(2,3)==5

class Test_class():

    def test4(self,qianzhi):
        print(‘第四个测试用例‘)

    def test5(self,qianzhi):
        print(‘第五个测试用例‘)

运行顺序为:

原文地址:https://www.cnblogs.com/XhyTechnologyShare/p/12251759.html

时间: 2024-10-10 13:53:32

2.pytest用例设计及运行的相关文章

Spark Streaming架构设计和运行机制总结

本期内容 : Spark Streaming中的架构设计和运行机制 Spark Streaming深度思考 Spark Streaming的本质就是在RDD基础之上加上Time ,由Time不断的运行触发周而复始的接收数据及产生Job处理数据. 一. ReceiverTracker : Receiver数据接收器的启动.接收数据过程中元数据管理,元数据管理是使用内部的RPC. 根据时间的间隔把数据分配给当前的BatchDuration : 通过Dstreams中的StreamID以及这个DStr

软件测试 —— 用例设计3(其他)

错误推测方法: 一.    方法简介 1.         定义:基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法. 2.         错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 1)        例如, 输入数据和输出数据为0的情况:输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况.可选择这些情况下的例子作为测试用例. 2)        例如,前面例子中成绩报告的程序,采用错误推

【小白的java成长系列】——构造方法私有化(单例设计)

有了解过spring框架的童鞋们就知道,spring的bean默认是什么形式呀?---单例形式的. 问:那什么叫做单例?单例其实就是Singleton,顾名思义就是只有单个的实例对象操作. 那为什么要使用单例呢? 至于这个问题,后面再做解释,我们先看代码: package me.javen.oop; public class SingletonDemo { public static void main(String[] args) { Singleton singleton1 = Single

基于需求文档(PRD)的功能用例设计

上一篇我讲了在项目运行过程中,用例是需要动态更新的.接下来我将结合实例(移动app)讲解在不同的阶段如何设计用例. 需求文档(PRD)主要讲述app的某个模块有什么功能,每一项功能的页面展示.页面操作有哪些,不同操作之间的关系是什么.基于PRD的用例设计是使用黑盒测试方法,而我平时主要使用了等价类划分.边界值分析法.状态转换测试.场景测试,操作实践时偏好于将模块分成页面展现.页面操作.接口.异常流,在每一个子项里运用黑盒测试方法进行设计. 以移动app的登录为例,大致需求如下图: 一.验证登录弹

用例设计

1.支付用例: 金额框填写校验:只能是数字/小数点两位/金额为空/边界值校验:大于小于等于负数 支付方式:余额(余额不足)/第三方支付:密码填写错误/未安装第三方支付app→跳转或者提示/转账汇款:填写银行卡,信用卡的校验/支付方式空时提交 其他:部分支付/补缴支付/重复支付(避免:未返回前不能再次点击支付loading) 安全:修改支付金额或者支付方式后(charles),后台和第三方的需要校验并且返回/重要的参数传参时需要加密/取消支付/重复支付/支付时订单已取消 网速:限速测试→订单支付状

Java设计模式中的单例设计

/** * 单例设计模式 * 应用场合:只需要一个对象的 * 作用:保证整个应用程序中某个实例有且只有一个 * 类型有:饿汉模式.懒汉模式 * 下面的例子是一个饿汉模式的例子 */ class SingleDemo { // 1.将构造方法私有化,不允许外部直接创建使用 private SingleDemo() {} // 2.创建类的唯一实例,使用private static修饰 private static SingleDemo instance = new SingleDemo(); //

不得不说--自动化测试元素定位与用例设计

关于自动化测试,经常被问到元素的定位 与 如何设计用例. 很多时间我也帮不了你解决实际的问题,只能从个人脚本谈谈如何看待这些问题. 不得不说之元素定位 虽然,本章写了十几篇文章来讲元素的定位与操作,对于碰到的一些常见功能,如何通过技巧来定位它们,但是在实际的自动化脚本开发中,不管是新手还是具有一定经验的老手,我们面临最多的问题仍然是元素的定位问题. 有时间元素定位非常简单,例如,我们只要知道这个元素有的id和name 就可以轻松的来定位到它:有时间元素的定位却非常的令人非常头疼,尽管我们用尽了所

Delphi 仿QQ皮肤组件设计与运行效果图

设计时效果:NO1 运行时效果:NO1 设计时效果:NO2 运行时效果:NO2 Delphi 仿QQ皮肤组件设计与运行效果图

Spring容器-ApplicationContext的单例设计

Spring容器-ApplicationContext的单例设计 每次通过new创建一个ApplicationContext容器,都会执行refresh方法,看源代码了解到这个refresh方法会重新加载配置文件,并且这个创建的容器对象持有一个所有singleton类型bean的map集合,从而实现单例,而且这个map对象的生命周期和容器对象的生命周期是一样的 如果我们每次都通过new一个容器对象,那么每次都要重新加载配置文件,都要重新生成这个singleton bean的集合,这样所谓的单例就