测试平台系列(17) 用例逻辑设计

简介: 用例逻辑设计

回顾


很久没有更新文章了,此时已经是23:23了,有些愧疚,因为自己最近交接的事情+生活的事情还是比较多的,所以到了晚上就没有力气来更新了。这里就更加佩服WQRF这个神一样的男人

记得上次说到,我们制作了一个简易的支持HTTP请求的页面,实际上我们却没有把它用到用例之中

用例设计


我这个人有个很大的缺点,想到啥就做啥,经常是事先设计一个简版,然后后续进行打磨,其实这样对一个成熟的系统来说太不友好了,很多东西可能在设计的时候就太过于局限了。这里不扯废话了,直接进入主题吧。

关于用例


思考过很多次,目前在公司制作的测试平台有个特点,就是不需要写代码就可以完成接口测试用例的编写,只不过碍于对大家的成长没有太大的提升,所以我这次打算做到兼容,如果你愿意写代码,那么你可以导入代码或者在线编写代码,如果不想看到代码,也可以采用无码模式,并且还要做到随时转换。

用例的生命周期


从设计上来说,用例以链路的形式执行,一个用例会有很多个临时变量,通过它们,我们可以解决数据依赖,完成对整个流程的测试。由于笔者画图能力有限,所以这里就不上图了。一个用例分为几个部分:

  • 前置setUp操作
  • 用例执行
  • 后置tearDown操作

其中每个操作里面都拥有很多个步骤(step),每个step产生的数据都会在主用例的生命周期中保存,达到数据互通的效果。

这里的步骤可以是http请求redis操作sql语句python代码片段等等,每个步骤都可以拥有一个返回值,通过返回值解决数据依赖问题。

举例


如果我们需要获取用户的余额,那么我们的用例将这样去编写:

  1. 先设计一个登录的测试用例:

用例名称: 用户登录

前置条件: 无

用例执行: 发送http请求,获取token

后置条件: 无

断言语句: 校验http状态码等

  1. 编写获取用户余额的测试用例(主用例):

用例名称: 获取用户余额

前置条件:

  • step1: 用户登录
    记录返回值为step1,通过step1.token获取到登录接口中的token数据

用例执行:

把body中的${step1.token}替换为真实的token,发送http请求。

后置条件:无

断言语句: 校验code和msg以及data字段中的信息

初期看不懂不要紧,大概方向是这个样子。主要也没有图片,这是一个流程化的东西。

1.jpg

补充一下图片

公用组件包pity_basic


主要内容有:

  • 存储用例生命周期产生的变量
  • 寻找请求字段中的变量并替换成真实数据
  • redis相关操作
  • sql相关操作
  • http相关操作
  • python代码块相关操作
    上述的代码相关的操作都是为了能将数据和代码进行互相转换,具体的构思还没有完全想好。我喜欢边写边想,不然我想得肯定不全,只有写的时候遇到问题了才能想好要怎么做下一步。
    给我思考的时间有限,我只能走一步算一步了!

其实这里我也觉得自己说的云里雾里,还是等后续成品出来了,回过头来看或者修改这篇文章吧!

2.jpg

目录大致结构

编写变量查找相关方法


这边我们自己内定一套规则,凡是${变量}这种数据,都是需要替换的变量,可能由其他前置或常量产生,需要随时替换。这个规则要求变量尽量简单,不要搞特殊符号。


import re
el_exp = r"\$\{(.+)\}"
pattern = re.compile(el_exp)
def get_el_expression(string: str):
    """
    获取el表达式
    :param string:
    :return:
    """
    return re.findall(pattern, string)
if __name__ == "__main__":
    s = "select * from xxx where name = '${mygod}'"
    print(get_el_expression(s))

3.jpg

验证输出无误,成功找到变量

我们用正则提取变量,这样如果我们的sql语句里面有变量的情况下,可以做到动态sql语句,如上图。不过基于这,我们还需要提供一个变量池,用来存放这个用例的所有临时变量

编写变量池相关方法



"""
pity变量池
变量池的生命周期与用例保持一致
"""
__author__ = "xiaoke"
class VarPool(object):
    def __init__(self, case_id):
        """
        :param case_id: 用来标识变量所处的主生命周期case
        """
        self.cache = dict()
        self.case_id = case_id
    def set(self, key, value):
        self.cache[key] = value
    def get(self, key):
        return self.cache.get(key)
    def get_default(self, key, default_value):
        return self.cache.get(key, default_value)


这里创建了一个变量池类,实际上维护了一个map,当然由于复杂场景下,可能会有变量冲突的情况,所以我们会在web页面层去控制,去保证用户不使用重复的变量


今天的内容就先到这里了,主要还是一个构思的问题。后面慢慢补全这些概念,使它越来越明朗。因为我现在也很懵逼,如果疑惑的话,可以等整个用例流程打通了再来回顾一下。


后续的话pity_basic会作为一个tar包,可在pypi下载,单独抽出这个包的主要原因还是为了支持代码无码模式的切换。




相关文章
|
1月前
|
Kubernetes 测试技术 Perl
混沌测试平台 Chaos Mesh
混沌测试平台 Chaos Mesh
58 1
|
2月前
|
传感器 数据采集 监控
LabVIEW电池管理系统测试平台
LabVIEW电池管理系统测试平台
37 4
|
10天前
|
测试技术
基于LangChain手工测试用例转Web自动化测试生成工具
该方案探索了利用大模型自动生成Web自动化测试用例的方法,替代传统的手动编写或录制方式。通过清晰定义功能测试步骤,结合LangChain的Agent和工具包,实现了从功能测试到自动化测试的转换,极大提升了效率。不仅减少了人工干预,还提高了测试用例的可维护性和实用性。
21 4
|
18天前
|
测试技术 Android开发 iOS开发
Appium 是一个开源的自动化测试框架,它支持多种平台和多种编程语言
Appium是一款开源自动化测试框架,支持iOS和Android多平台及多种编程语言。通过WebDriver协议,开发者可编写自动化测试脚本。在iPhone上实现屏幕点击等操作需安装Appium及其依赖,启动服务器,并设置所需的测试环境参数。利用Python等语言编写测试脚本,模拟用户交互行为,最后运行测试脚本来验证应用功能。对于iPhone测试,需准备真实设备或Xcode模拟器。
51 1
|
23天前
|
人工智能 自然语言处理 测试技术
基于LangChain手工测试用例转接口自动化测试生成工具
本文介绍利用大语言模型自动生成接口自动化测试用例的方法。首先展示传统通过HAR文件生成测试用例的方式及其局限性,随后提出结合自然语言描述的测试需求与HAR文件来生成更全面的测试脚本。通过LangChain框架,设计特定的提示词模板,使模型能够解析测试需求文档和HAR文件中的接口信息,并据此生成Python pytest测试脚本。示例展示了正常请求、非法请求及无效路径三种测试场景的自动化脚本生成过程。最终,整合流程形成完整代码实现,帮助读者理解如何利用大模型提高测试效率和质量。
55 2
|
26天前
|
运维 Kubernetes 监控
|
15天前
|
Java 测试技术 API
SpringBoot单元测试快速写法问题之复杂的业务逻辑设计有效的单元测试如何解决
SpringBoot单元测试快速写法问题之复杂的业务逻辑设计有效的单元测试如何解决
|
2月前
|
测试技术
详解单元测试问题之@InjectMocks注解的执行逻辑如何解决
详解单元测试问题之@InjectMocks注解的执行逻辑如何解决
25 1
|
27天前
|
存储 测试技术 API
apifox实例应用-自动化测试用例for循环的使用
总结来说,通过在Apifox自动化测试用例中结合for循环的使用,我们可以有效地对接口进行批量测试,提升测试效率和覆盖率。同时,通过参数化测试数据的灵活应用,能够确保我们的接口在不同的输入条件下都能保持正确的行为。这种方法能够显著减少手动测试工作量,同时通过标准化的流程确保测试的一致性。
36 0
|
2月前
|
测试技术 Apache
单元测试策略问题之设计有效的单测用例问题如何解决
单元测试策略问题之设计有效的单测用例问题如何解决
下一篇
DDNS