测试case自动化代码框架

这个是我在自动化case编写框架的经验总结，由于作者经验有限，如有错误，欢迎指正

另外我有代码示例，但是不知道怎么上传，好像不支持附件啊，我传到资源里了，找不到的同学也可以留言，我私下发给你

框架背景

在测试项目中，项目的版本会有很多，需要测试人员对每个版本进行尽可能详尽的测试。自动化case能够大大提高测试的效率，减少人为出错的可能，有益于项目质量的保证。随着项目规模的扩大，项目case的增多，测试case的编写困扰着测试人员，这篇文章就是为了解决这个问题。

框架优点

  1. 简单
  2. 重用代码
  3. 层次化
  4. 便于扩展
  5. 让测试人员聚焦于业务逻辑的编写，提高自动化case编写的效率
  6. 方便代码的维护

框架使用

对于框架的使用，从一个小case说起，在作者测试的一个项目中，经常测试网络的连通性case，传统的case，可能需要十几甚至几十行代码，而使用自动化case编写框架，只需简单的3行语句，就能很好的完成这个任务

代码如下

#-*- coding: UTF-8 -*-

__author__ = ‘ligengyong‘

‘‘‘

a sample test for auto case framework

‘‘‘

import CaseBase

class Case(CaseBase.CaseBase):

def __init__(self):

CaseBase.CaseBase.__init__(self, "host ping itself")#case 名字

def caseWork(self):

cmd = "ping -c 3 127.0.0.1"

flag = self.verifySumLocal(cmd, "icmp_seq", 3)

self.organiseOutputDefault(flag)

def work(self):

self.caseWork()

if __name__ == "__main__":

case = Case()

case.start()

查看执行结果：

[[email protected]bb-nsi-uinp09.bb01.baidu.com ligengyong]# python demo.py

/usr/local/lib/python2.7/site-packages/Crypto/Util/number.py:57: PowmInsecureWarning: Not using mpz_powm_sec. You should rebuild using libgmp >= 5 to avoid timing attack vulnerability.

_warn("Not using mpz_powm_sec. You should rebuild using libgmp >= 5 to avoid timing attack vulnerability.", PowmInsecureWarning)

exe cmd at local host: ping -c 3 127.0.0.1  #执行命令

return:

PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data. #返回结果

64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.014 ms

64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.031 ms

64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.018 ms

--- 127.0.0.1 ping statistics ---

3 packets transmitted, 3 received, 0% packet loss, time 1999ms

rtt min/avg/max/mdev = 0.014/0.021/0.031/0.007 ms

#case执行情况

Project: project

Version: 1.0.0

Case: host ping itself

Start_Time: 12:19:56 07/04/2015

End_Time: 12:19:58 07/04/2015

Expectation: success

Result: success

Reason: success

框架介绍

框架类关系图

关于图中几个类介绍一下

  1. case A, B, C表示具体的case类，本文中的demo例子中的case类型和CaseC类似
  2. CaseBase自动化代码基础框架类，继承了threading.thread类，实现了run方法，run调用了三个方法，

    a. 调用work方法，这个方法执行具体的工作，由子类去实现

    b. 调用时间戳函数，当case执行结束后计算更新时间

    c. 调用case运行结果输出函数，统计case执行结果

  3. ProjectBase继承了CaseBase，用来对一些project层面的配置和公用函数的编写，以及规范化case的执行流程

    举个例子，作者测的项目中，经常要在机器a上执行一些命令，CaseBase提供了函数exeRemote(self, cmd, ip, port, name, password, timeout=10)但是我不想每次都要输入host a的ip，密码等信息，这样我就写一个

    exeCmdAtHostA（）方法，在exeCmdAtHostA中按照ProjectBase对于host a的配置信息对exeRemote方法进行进一步的封装，这样所有的子类case都可以简单的调用这个方法就可以了，既简化了代码，又便于理解，同时当host a的配置信息发生了变化或者exeCmdAtHostA方法的功能需要修改的时候，只需要改一处就可以了，这样使得代码便于维护

    另外一种情况，如果对于case要求执行前整理环境，执行任务，之后清理环境，这样就可以再重写work方法，新建子work方法，在work方法中调用整理环境，执行子work方法，清理环境，让子类去重写子work方法

  4. ModuleBase继承了ProjectBase, 它和ProjectBase有着类似的功能，只不过是module层面的信息

通过简单的介绍，不难看出框架具有以下特点

  1. 依赖倒置，使得程序依赖于抽象的类，而非具体的类
  2. 层次化复用代码
  3. 对修改关闭，对拓展开放
  4. 程序的启动由框架来做，用户只负责具体的业务逻辑
  5. 拓展性好，用户可以对框架的执行流程进行拓展或者修改

CaseBase介绍

在上一小节，已经看到CaseBase继承了threading.Thread类，下面对CaseBase的其他方法做一下介绍，由于作者的水平有限以及参与的测试的项目，可能不能对所有测试的基础方法都封装进来，后续如果有其他的需求，可以再加进来

首先介绍一下公共方法：

  1. closeProcessLike(processName) 根据process的名字，在本地找到，并kill掉
  2. closeProcessLikeRemote(processName, ip, port, name, password, timeout=10)根据process的名字，在目标主机找到，并kill掉，如果失败，会抛出异常

其次介绍一下CaseBase的类方法

  1. __init__(self, name)类初始化方法，name为case的名字
  2. initParameter(self)初始化变量
  3. setProjectAndVersion(self, name="project", version="1.0.0")设置项目的名字和版本，这个一般在ProjectBase进行覆盖
  4. def work(self)具体的执行方法，需要子类覆盖
  5. setOutputFile(self, name)设置输出文件，如果没有设置，会输出到标准输出
  6. puts(self, line)自定义的输出方法，如果子类需要打印一些东西，可以调用这个方法
  7. touch(self, TIME)用来更新时间戳
  8. done(self)用来在case执行结束后输出case的执行情况
  9. run(self)覆盖threading.Thread的run方法
  10. getResultString(self)生成执行结果string
  11. verifyHasLocal(self, cmd, target)在本机执行cmd，并查看返回结果是否含有Target，如果有返回True，如果没有返回False
  12. sleep(self, timeout)自定义sleep方法
  13. verifySumLocal(self, cmd, target, sum)在本机执行cmd，并查看返回结果含有target的个数是否为sum，如果是返回True，如果不是返回False
  14. exeLocal(self, cmd)在本地执行命令cmd
  15. exeRemote(self, cmd, ip, port, name, password, timeout=10)在远程执行命令cmd
  16. getRetFromExeRemote(self, cmd, ip, port, name, password, timeout=10)在远程执行命令cmd，并将执行结果返回，用来为用户自定义判断提供接口
  17. transportFile(self, file, remoteFile, ip, name, password, sshPort=22)往远端发送文件
  18. verifyHasRemote(self, cmd, target, ip, port, name, password, timeout=1)和verifyHasLocal类似，只不过是在远端执行的
  19. verifySumRemote(self, cmd, target, sum, ip, port, name, password, timeout=10)和verifySumLocal功能类似，只不过是在远端执行的
  20. organiseOutputDefault(self, flag)默认组织case执行结果的输出，flag为执行的标识，True为成功，False为失败

TestException自定义的异常类

其他事项：

  1. 如果一个case需要两个不同线程，需要将一个线程的done方法重写，并且不做任何处理，这样避免同时有两个线程同时输出case执行结

    def done(self):

    pass

2. 如果一个case需要两个相同的线程的话，需要调用一下，setOutputFlag(False)即可

时间： 2024-11-01 20:59:16

测试case自动化代码框架的相关文章

logging模块和ATP(自动化简单框架)

1.自动化 自动化三种:数据驱动,代码驱动,关键字驱动. 框架其实就是工具的集合. 数据驱动 :根据数据来去测试的.比如case是存在excel中的数据 代码驱动: 测试用例都是写代码来测试的.业务case是代码实现 关键字驱动   主要用于ui自动化  有集成包比如 点击  -->  .click() 下一步 提交  --> .submit() 根据字典中存放的对应的方法,直接只需了解关键字就可以(适合对对吗不了解) { '点击':click() '提交':submit() } 2.日志模块

接口自动化简单框架

接口自动化简单框架 一.自动化测试分类: 1.数据驱动:根据数据(读取EXCEL数据)来测试 2.代码驱动:测试用例都是代码,通过读取代码测试 3.关键字驱动:UI自动化,根据封装好的工具,输入关键字测试,有点傻瓜式测试 点击 --> .click() 下一步 提交 --> .submit() { '点击':click() '提交':submit() } 二.自动化框架 自动化框架:可以理解为工具的集合.在日常工作中根据需要实现某些功能,封装起来.或结合其他自动化工具. 三.搭建数据驱动自动化

接口测试自动化生成框架

接口测试这个词语,相信大家都不陌生了吧.目前我个人的理解,接口测试应该属于白盒测试的范畴,也是很多测试工程师很想从事和向往的一个测试手段.大家都觉得白盒测试深不可测,但实际上是怎么样的呢. 接口测试的实施优先级 对于Web应用来说,接口测试就是对某一个接口进行测试代码的编写和执行.一般情况下,实施接口测试的优先级是:对暴露在外面的接口(该接口会给第三方调用)进行接口测试:内部的核心功能接口也会做接口测试:内部非核心功能接口的接口测试(很多时候就是单元测试).当然这个实施的具体细节,还需要根据项目

jekins测试环境自动化

最近搭建测试环境自动化,之前都是用机器猫.机器猫的流程大概是这样,开发打包上传到svn,给测试一个svn地址,测试到机器猫上传文件,然后再运行启动. 为了减去开发打包这个环节,所以专用jenkins. 实现需求如下: 1.自动拉取git代码,自动打包 2.备份远程机的jar包 3.上传至远程机,并启动项目 4.提供回滚功能 cat /data/jekins_shell/autoshell #参数 $1项目 $2方法 $roll_bak参数 app=meng if [ -n "$1" ]

艾伦 Visual Studio 批量自动化代码操作工具-VS插件发布

艾伦 Visual Studio 批量自动化代码操作工具 以下简称--艾伦工具箱. 艾伦工具箱是一个多文件批量处理插件,目的是为了广大开发者提高开发效率,减少项目代码规范化审计,缩短开发者的项目开发周期. 名称:艾伦 Visual Studio 批量自动化代码操作工具. 亮点:批量操作. 功能:1,代码格式化:2,移除与重排Using. 可选:1,针对整个解决方案进行自动化操作:2,针对选中的当前项目进行自动化操作:3,针对指定的后缀名代码文件进行操作: 注意事项:默认支持*.cs.*.vb,可

静态分析——自动化代码扫描如何预防缺陷和加速交付？

一.什么是静态代码分析? 静态代码分析(简称静态分析)是一种必要的开发测试行为,通过扫描代码模式和结构以及分析逻辑关系,查找潜在缺陷代码,最终将报告呈现给用户以便修复代码缺陷.当高风险代码被侦测到后,静态分析扫描工具就会报告相应违规,指引用户修复代码漏洞.静态分析方法一般有如下一些类型: 模式匹配静态分析 模式匹配静态分析方法是静态分析的一种最简单形式,即根据预先配置的规则库去自动化进行代码扫描,如果发现规则库中匹配的模式代码即报告违规.例如,工程师们有时候不小心使用了字符串""进行字

新书《编写可测试的JavaScript代码 》出版，感谢支持

本书介绍 JavaScript专业开发人员必须具备的一个技能是能够编写可测试的代码.不管是创建新应用程序,还是重写遗留代码,本书都将向你展示如何为客户端和服务器编写和维护可测试的JavaScript代码. 从减少代码复杂性的方法,到单元测试.代码覆盖率.调试.以及自动化,您将全面学到如何编写让你和你同事能够轻松修复和维护的JavaScript代码.测试JavaScript代码是一个复杂的过程.本书将在很大程度上帮你简化该过程. 目标读者 本书主要目标受众是那些想成为JavaScript专业开发人

用于解答算法题目的Python3代码框架

前言 最近在实习,任务并不是很重,就利用闲暇时间使用Python3在PAT网站上刷题,并致力于使用Python3的特性和函数式编程的理念,其中大部分题目都有着类似的输入输出格式,例如一行读入若干个数字,字符串,每行输出多少个字符串等等,所以产生了很多重复的代码. Python代码 于是我就利用VS Code的代码片段功能编写了一个用于处理这些输入输出的代码框架,并加入了测试功能(写函数前先写测试时正确的事情).代码如下 """Simple Console Program Wi

使用docker实现半自动化代码自动部署与回滚

最近开发docker的caas平台,目前已经开发完成,在优化性能与套模板.对于docker最近是很好,很多人把docker做为vm来使用,当然作为测试来说是没问题,但我感觉docker本身在做沙箱.自动化部署与回滚方面更适合,下面介绍一下我这里是如何通过docker实现代码半自动化部署. 目前我这里已经实现能结合svn或者git代码库,对node.php.java代码进行半自动化部署,先给大家截图看效果,感觉满意在继续细看. 总界面如下 点击左上角的"新增开放项目"就可以新建立测试,下