1.查看一下要测试的对象属性 2.…
一.封装方法 1.编程如何越来越快: 首先,需要经验丰富,知识面广. 其次,每一个熟练编程的人员,都会有自己的一个库,解决各种问题.各种通用的方法函数. 同理,自动化脚本也是编程,测试用例则为需求,UI自动化编写虽然容易,但是界面变化快.维护庞大.所以封装通用方法,是最快最容易的途径. 2.哪些方法需要封装: 公共的操作方法 经常使用的步骤:超过两次以上 经常使用的组件:输入框.文本框.列表 经常操作的布局:多个组件组成通用的布局 经常操作的页面:ui页面由一个一个单独Activity组成,就可…
背景 之前写过一篇博客,介绍怎么用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…
背景 因为服务的迁移,Jira版本的更新,很多接口文档的维护变少,导致想要编写部分服务的自动化测试变得尤为麻烦,很多服务,尤其是客户端接口需要通过抓包的方式查询参数来编写自动化用例,但是过程中手工重复操作过多,不利于RF用例的快速覆盖,本文给大家介绍如何通过解析抓包拦截的数据,转化为测试关键字并生成测试用例. 实现 抓包 如何安装抓包工具在本文就不赘述了,抓包,过滤出想要的数据,导出,保存的格式注意选择为har: 数据解析 感兴趣的小伙伴可以直接查看导出的har文件内容,它是一个标准的JSON格…
经过之前的学习铺垫,我们尝试着利用pytest框架编写一条接口自动化测试用例,来厘清接口自动化用例编写的思路. 我们在百度搜索天气查询,会出现如下图所示结果: 接下来,我们以该天气查询接口为例,编写接口测试用例脚本. 一,明确测试对象 针对某个功能做接口测试,首先我们需要确定实现这个功能调用的是哪个接口,这个接口的具体信息(如功能.协议.URL.请求方法.请求参数说明.响应参数说明等等)可以通过查看开发提供的接口文档获取,也可以通过抓包(在没有接口文档的情况下)获取.找到对应的接口也就是测试对象…
前言:最近也思考了一下怎么做接口自动化,以下内容属于自己目前阶段所学习到的内容,也逐渐投入自己实际工作中,把最近的学习新得跟大家分享下,话不多说,切入正题. 对接口自动化测试用例的思考:接口测试大多测试人员都知道,属于黑盒测试范畴,针对拿到的接口地址,接口的参数,请求头格式对各种正常异常的参数输入,检查返回值是否跟预期结果一致,当然设计到接口安全性的问题也需要考虑进去,这里暂时不说明.那么接口自动化是不是我们可以提取系统中重要的接口进行接口用例的维护,然后实现每次版本发布前,执行一遍,看看这次开…
1.  认识TOSCA 安装使用 2.  TOSCA自动化测试工具的优点 1).  可扩展 Tosca Commander™ functionalities can be extended by using AddIns. The AddIns that are part of Tricentis Tosca will be described in the chapters below. 2). 能持续集成 3). 支持API测试 (需要安装REST API Service and Tosca…
需要封装的方法: 公共的操作方法 经常使用的步骤:超过两次以上 经常使用的组件:输入框.文本框.列表 经常操作的布局:多个组件组成通用的布局 经常操作的页面:ui页面由一个一个单独Activity组成,就可以将Activity封装成单独的类 通用的工具函数:文件操作.时间操作之类 初级封装:   通用方法库:将通用的方法封装在一个java文件中,比如登陆.文件操作.时间操作 专用方法库:比如登陆专用的方法:qq登陆.微博登陆等 用例集:通过调用方法库中的方法实现用例,这样看起来简洁清晰. 设计一…
前言 做自动化做久了,经常会思考一个问题,到底别人是怎么做的自动化,跟自己的有啥不一样,看过不少书和资料,都是停留在demo的层面. 真正把自动化做的好的大牛又不屑于分享自己的劳动成果,所以大部分情况就是一群菜鸡在群里互啄,停留在初级入门的demo层面上. 到底自动化要达到什么样的效果呢?这里我把最近的研究成果分享下,有经验的小伙伴也可以一起交流下. 功能用例 我一直认为一切的自动化用例是基于功能测试用例的, 脱离了功能测试用例,你的代码写的再漂亮,那也仅仅是show代码的. 面试的时候经常会遇…
背景 虽然大家都已经使用了统一的关键字,但是在检查了一些测试用例之后,还是发现因为大家对RF的熟悉程度不一导致的测试用例颗粒度差异很大的情况:而且在手动方式转化测试用例过程中,有不少工作是完全重复的且意义不大的,所以我就想了一个使用脚本生成自动化测试用例的方式来解决这个问题. 实现思路 前一篇文章里提到过,我们使用了一个中间的Excel来生成关键字信息,所以我这边的第一想法就是让这个Excel发挥更大的作用 -- 即直接通过Excel生成标准的测试用例. 具体的思路也很简单: 直接转化我们填写在…