最近遭遇了一个问题,问题不大不小,想半天没想明白是哪里有问题,今天终于解决了 用python读取了excel用例中,body json字符串内容,然后requests去请求内容,结果一直报错,一直不明白是为什么, 使用excel获取到的数据,加上json.dumps 就报500错误 不加上json.dumps就报UnicodeEncodeError错误   直接复制json到代码中又是好的,加上json.dumps报系统500错误   后面突然想到,一直怀疑因为他们不是同一类型字段导致,果然去调

前言:最近也思考了一下怎么做接口自动化,以下内容属于自己目前阶段所学习到的内容,也逐渐投入自己实际工作中,把最近的学习新得跟大家分享下,话不多说,切入正题. 对接口自动化测试用例的思考:接口测试大多测试人员都知道,属于黑盒测试范畴,针对拿到的接口地址,接口的参数,请求头格式对各种正常异常的参数输入,检查返回值是否跟预期结果一致,当然设计到接口安全性的问题也需要考虑进去,这里暂时不说明.那么接口自动化是不是我们可以提取系统中重要的接口进行接口用例的维护,然后实现每次版本发布前,执行一遍,看看这次开

查看完整文章点击原文链接:纯python自研接口自动化脚本更新版本,让小白也能实现0到1万+的接口自动化用例 你是否还在用postman\jmeter做接口自动化吗?用python的开源框架[unittest\pytest]一个一个接口码代码搬运吗?网上调查无论是刚入门的还是进阶阶段的测试者,大部分人以及培训机构的课程还是这样做的接口自动化! 本号推出以一顶三的python自研接口自动化框架,当然也是利用从Excel读取做为驱动和存储测试数据完成接口自动化,请仔细看完这篇文章你就知道脚本的魅力所

背景 之前写过一篇博客,介绍怎么用Python通过解析抓包数据,完成自动化用例的编写.最近这段时间在使用go test,所以就在想能不能也使用代码来生成自动化用例,快速提升测试用例覆盖率.说干就干. 框架 首先介绍一下我们使用的测框架: 项 信息 安装 备注 GO版本 go1.12.9 darwin/amd64 略 测试框架 ginkgo go get -u github.com/onsi/ginkgo/ginkgo 断言库 testify/assert go get github.com/st

Jmeter怎么使用的文章多如牛毛,但怎么组织好测试用例,则几乎很难看到.在本文,我将把Jmeter下怎么组织测试用例的几点心得分享给大家,希望能给你一些帮助或启示. 1.善用“逻辑控制器”中的“简单控制器”.可以把简单控制器像文件夹一样使用,通过它来对用例进行分类归档,方便后续用例的调试和执行. 2.同编写测试用例一样,这里的接口测试用例应该进行唯一性编号,这样在运行整个用例计划出现用例失败时,能快速的定位到问题用例.如,上图中的GW-01-C1:GW取模块前两个汉子拼音的大写首字母,01为子

一.前言:前面一段时间封装的接口自动化测试框架用了一段时间发现还是有很多弊端的,目前又改良了一下,可以说整体思路全都推翻了,功能比之前强大许多,有兴趣的可以私信我单独交流,希望共同学习进步! 二.项目目录 case目录:存放测试执行文件 config目录:存放配置文件(数据库连接信息.token信息等).临时存储的文件(需要提取接口的字段用到) data目录:存放测试用例数据文件 files目录:存放附件(上传接口需要) log目录:存放生成的日志文件 logs目录:封装的日志 report目录

经过之前的学习铺垫,我们尝试着利用pytest框架编写一条接口自动化测试用例,来厘清接口自动化用例编写的思路. 我们在百度搜索天气查询,会出现如下图所示结果: 接下来,我们以该天气查询接口为例,编写接口测试用例脚本. 一,明确测试对象 针对某个功能做接口测试,首先我们需要确定实现这个功能调用的是哪个接口,这个接口的具体信息(如功能.协议.URL.请求方法.请求参数说明.响应参数说明等等)可以通过查看开发提供的接口文档获取,也可以通过抓包(在没有接口文档的情况下)获取.找到对应的接口也就是测试对象

背景 因为服务的迁移,Jira版本的更新,很多接口文档的维护变少,导致想要编写部分服务的自动化测试变得尤为麻烦,很多服务,尤其是客户端接口需要通过抓包的方式查询参数来编写自动化用例,但是过程中手工重复操作过多,不利于RF用例的快速覆盖,本文给大家介绍如何通过解析抓包拦截的数据,转化为测试关键字并生成测试用例. 实现 抓包 如何安装抓包工具在本文就不赘述了,抓包,过滤出想要的数据,导出,保存的格式注意选择为har: 数据解析 感兴趣的小伙伴可以直接查看导出的har文件内容,它是一个标准的JSON格

前言 做自动化做久了,经常会思考一个问题,到底别人是怎么做的自动化,跟自己的有啥不一样,看过不少书和资料,都是停留在demo的层面. 真正把自动化做的好的大牛又不屑于分享自己的劳动成果,所以大部分情况就是一群菜鸡在群里互啄,停留在初级入门的demo层面上. 到底自动化要达到什么样的效果呢?这里我把最近的研究成果分享下,有经验的小伙伴也可以一起交流下. 功能用例 我一直认为一切的自动化用例是基于功能测试用例的, 脱离了功能测试用例,你的代码写的再漂亮,那也仅仅是show代码的. 面试的时候经常会遇

一.封装方法 1.编程如何越来越快: 首先,需要经验丰富,知识面广. 其次,每一个熟练编程的人员,都会有自己的一个库,解决各种问题.各种通用的方法函数. 同理,自动化脚本也是编程,测试用例则为需求,UI自动化编写虽然容易,但是界面变化快.维护庞大.所以封装通用方法,是最快最容易的途径. 2.哪些方法需要封装: 公共的操作方法 经常使用的步骤:超过两次以上 经常使用的组件:输入框.文本框.列表 经常操作的布局:多个组件组成通用的布局 经常操作的页面:ui页面由一个一个单独Activity组成,就可

背景 虽然大家都已经使用了统一的关键字,但是在检查了一些测试用例之后,还是发现因为大家对RF的熟悉程度不一导致的测试用例颗粒度差异很大的情况:而且在手动方式转化测试用例过程中,有不少工作是完全重复的且意义不大的,所以我就想了一个使用脚本生成自动化测试用例的方式来解决这个问题. 实现思路 前一篇文章里提到过,我们使用了一个中间的Excel来生成关键字信息,所以我这边的第一想法就是让这个Excel发挥更大的作用 -- 即直接通过Excel生成标准的测试用例. 具体的思路也很简单: 直接转化我们填写在

本文目录 1.运行所有的测试用例 2.运行单个测试类或某个TestSuite 3.运行某个测试类里面的某个测试方法 4.运行两个不同的测试类或类中的方法 命令行运行Android Robotium自动化用例或单元测试用例 1.运行所有的测试用例 举个栗子:运行测试工程下的所有用例 1 adb shell am instrument -w com.taobao.taobao.test/android.test.InstrumentationTestRunner 2.运行单个测试类或某个TestSu

需要封装的方法: 公共的操作方法 经常使用的步骤:超过两次以上 经常使用的组件:输入框.文本框.列表 经常操作的布局:多个组件组成通用的布局 经常操作的页面:ui页面由一个一个单独Activity组成,就可以将Activity封装成单独的类 通用的工具函数:文件操作.时间操作之类 初级封装:   通用方法库:将通用的方法封装在一个java文件中,比如登陆.文件操作.时间操作 专用方法库:比如登陆专用的方法:qq登陆.微博登陆等 用例集:通过调用方法库中的方法实现用例,这样看起来简洁清晰. 设计一

1  背景 接口用例已经在项目中的yml文件中编写,但是yml文件不能做为交付文档用,本文对工作中从接口输出日志中提取用例信息,并导入到excel文件中做了总些 2  工具 idea,notepad++,excel 3  提取用例 总体思路是代码中将要提取的数据打印到日志中,对日志信息进行处理,然后以文本导入向导的方式导入到excel中 3.1 日志输出 为了便于从日志中提取用例所需要的信息(用例名称,入参,出参),所以代码中要将这几个全部打印到日志中,并加入部分分隔符方便后续处理,如: Mer

在开始自动化时,您可能会遇到各种可能包含在自动化代码中的方法,技术,框架和工具.有时,与提供更好的灵活性或解决问题的更好方法相比,这种多功能性导致代码更加复杂.在编写自动化代码时,重要的是我们能够清楚地描述自动化测试的目标以及我们如何实现它.话虽如此,编写“干净的代码”以提供更好的可维护性和可读性很重要.编写干净的代码也不是一件容易的事,您需要牢记许多最佳实践.以下主题突出显示了编写更好的自动化代码应获得的8条银线. 1.命名约定 当我们从手动转向自动化或实际上以任何编程语言编写代码时,这确实是

我们在前面几篇文章中学习怎么发送数据请求,怎么处理解析接口返回的结果,接下来我们一起来学习怎么进行测试用例管理,今天我们介绍的是使用yml文件进行用例管理,所以首先我们一起来了解一下YAML和它的简单用法. YAML YAML(Yet Another Markup Language),可能大家在工作中或多或少已经接触过这个文件格式.它是一种基于Unicode用来表达资料序列的编程语言,有易阅读.易与脚本语言交互的特点.在博主所在项目接入了k8s之后,基本上所有的配置都使用的yml. 我觉得yml

1.查看一下要测试的对象属性 2.

阿里QA导读:为什么要度量测试有效性?这么多的CASE,花了大量时间和资源去运行,真能发现bug吗?CI做到90%的行覆盖率了,能发现问题吗?测试用例越来越多,删一些,会不会就发现不了问题了?怎么找出那些为了覆盖而覆盖,发现不了真正问题的测试用例?本文带您探索其中的奥秘. 什么是测试用例的有效性? 我们的测试用例有两个比较关键的部分: 1)调用被测代码:例如下面的RuleService.getLastRuleByClientId(ClientId) 2)进行结果Check:例如下面的Assert

http://blog.sina.com.cn/s/blog_68f262210102vx8o.html 第七章 测试用例接入jenkins自动运行 ------Web自动化测试之Webdriver+TestNG--从零到熟练(系列) 自动化测试用例的最终目的就是无人值守的自动化回归测试,不管是用什么语言,什么框架编写的测试用例,如果想达到这个效果,都需要借助于Jenkins或是Hudson.根据业界的习惯,我们还是使用Jenkins.在本人的各个自动化测试教程中,已经多次介绍到了Jenkins

目录结构搭建 Test_framework |--config(配置文件) |--data(数据文件) |--drivers(驱动) |--log(日志) |--report(测试报告) |--test(程序代码) |--case(测试用例) |--common(抽象通用代码) |--page(页面类代码) |--suit(测试套) |--utils(公共方法) |--ReadMe.md(加个说明性的文件,告诉团队成员框架需要的环境以及用法) 1.config层,放配置文件,把所有的项目相关的配

一.基本逻辑 1.自动填写用户名和密码登录成功后跳转到相应页面 2.验证相应页面的url与给定的url是否一致,如果一致则测试通过,如果不一致则不通过 二.以jenkins登陆界面为例,代码如下 from selenium import webdriver import unittest from selenium.webdriver.support.wait import WebDriverWait class TestLogin(unittest.TestCase): # 指定浏览器 def