阶段三03-SessionCookie机制和优化

2024-02-03 20:50

本文主要是介绍阶段三03-SessionCookie机制和优化,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

在执行单个用例之前我们就可以带上 suite_ctx。在perform_case里处理

 采用方法从下游到上游,还是用之前的方法改一下就能实现套件的参数传递,先给参数传递的方法加两个参数,默认为空。然后通过local_params暴露给用户

def proc_param_expression(val, case_ctx=None, suite_ctx=None, proj_ctx=None):"""处理用例接口参数中的python表达式,将表达式替换为结果:param case_ctx::param suite_ctx::param proj_ctx::param val::return:"""ms = re.findall(r"#\{.+\}", val)if len(ms) == 0:return vallocal_params = {'case_ctx': case_ctx,'suite_ctx': suite_ctx,'proj_ctx': proj_ctx,'re': re,'parse': common.parse_json_like}def new_content(matched):s = matched.group()if re.search(r"__.+__", s):  # __import__.os 等被过滤掉raise Exception(f'python表达式包含非法字符或操作[{s}]')return str(eval(s[2:-1], {}, local_params))return re.sub(r"#\{.+\}", new_content, val)

相应的调用 proc_param_expression函数时也要加传参 get_request_bodies 等3个

接下来把所有用到case_ctx都检查一遍,加上suite_ctx和proj_ctx。

再回到perform_case方法查找用法。

异常处理

图中情况是上一个用例没有给suite_ctx token的值,后一个用例直接去拿 suite_ctx['token']导致的

前置处理和参数预处理没有获取异常,所以或导致系统崩溃。

但是目前以我们的水平可能无法写出可读性很好的异常处理,所有干脆在之前的异常处理前面再try一次。 perform_case 方法里:

 如果 exec_py_script 、 proc_apidef_params 、item.get_query_params等抛出异常的话就会记录堆栈信息到info日志里,用户勾选了失败后终止就break

下面代基本不变。

 只是捕获异常后判断,如果是RespCheckException异常直接返回改接口的校验是吧;如果是其他异常则记录堆栈信息到日志。并且最后通过判断接口是否执行成功(89行)

参数的重复使用

完成异常处理后我们完善好用例,我们想到的是在登陆用例里把token放到case_ctx 和 suite_ctx.

那么就出现了另一个问题了,exec_py_script现在只支持单条  #{},我们要改成支持多条

def exec_py_script(input_, result, case_ctx=None, suite_ctx=None, proj_ctx=None):if not input_:return# m = re.match(r"#\{.+\}", input_)# if not m:#     raise Exception(f'内容格式不支持,请使用#{{}}包含[{input_}]')# exp = m.group()ms = re.findall(r"#\{.+}", input_)if len(ms) == 0:raise Exception(f'内容格式不支持,请使用#{{}}包含[{input_}]')if re.search(r"__.+__", input_):  # __import__.os 等被过滤掉raise Exception(f'输入了python表达式不允许操作{input_}')if re.search(r"import[ \s]\w]", input_):  # 也不允许直接importraise Exception(f'非法导入{input_}')# 约定可提供的数据 resultlocal_params = {'result': result,'re': re,'parse': common.parse_json_like,'case_ctx': case_ctx,'suite_ctx': suite_ctx,'proj_ctx': proj_ctx,}for exp in ms:exec(exp[2:-1], {}, local_params)  # eval执行后会返回一个布尔值,[2:-1]做个切片去掉用户输入的#{}

之后在去执行多用例,OK了,然而事情没有那么顺利,re会这样匹配.导致 前后两个都用不了

我们希望不用户不换行写也行,就需要再改下re的匹配,让它不那么贪婪。改成

ms = re.findall(r"#\{.+?\}", input_)  就行了

Session

目前项目所有的接口、用例都混在一起,没有通过项目隔离。我们想要实现只展示此账号所在项目的接口、用例。就要用到  django的Session机制

 Session放在我们创建的mysql表里

用测试平台举例:在登录时创建一个Session id,退出时销毁

 一般框架都是一个账户只能有一个Session id。新id产生时删掉旧id

按缺省项目过滤数据

我们之前没有使用过滤,接口里面展示的是所有的。现在我们希望按照所选的项目来展示接口

设计实现方法,先在项目里设置默认项目

    def select_pj(self, request, queryset):proj = queryset.first()  # queryset.first取到的就是 Model的对象logger = logging.getLogger('test_plt')# 缺省项目存到django的 request.session里,用字典格式维护request.session['default_project_id'] = proj.id# pj默认调用__str__self.message_user(request, f'默认项目为【{proj}】,后续操作基于此项目。您可以随时重新切换', level=messages.WARNING)select_pj.short_description = '设为默认项目'

在接口定义的model里

    def get_queryset(self, request):"""重写获取queryset方法,调用session里的default_project_id;实现选择默认项目后【接口定义】中展示该项目的所有接口:param request::return:"""qs: QuerySet = super().get_queryset(request)proj_id = request.session.get('default_project_id', default=None)return qs.filter(pj__id=proj_id) if proj_id else qs

其他有需要过滤的模块,上面代码可以复用。唯一需要确定的是 使用的model中有无pj__id的外键

完成其他模块优化

首先是我们选择了默认项目以后,希望进入新建接口时只能选择我们之前给定的默认

在ApiDefAdmin的get_form方法里引入sesstion,默认为空。如果用户之前选了默认项目,则测试项目里只能选择该项目。环境只能选择该项目的环境

 192行,通过get_form方法的obj。如果obj为空则填入用户选择的默认项目

接下来是用例套件中的用例只展示默认项目

在CaseSuiteAdmin里新建一个方法

def formfield_for_manytomany(self, db_field, request, **kwargs):proj_id = request.session.get('default_project_id', default=None)if proj_id and db_field.name == 'cases':kwargs['queryset'] = Case.objects.filter(pj_id=proj_id)return super().formfield_for_manytomany(db_field, request, **kwargs)

重写formfield_for_manytomany方法,需要注意的是这个方法是匹配该modles所有多对多方法。所以我们加个db_field == 'cases'的限制。

方法地址:Django 管理站点 | Django 文档 | Django

用例接口的过滤

此时新建用例时选择的接口还没过滤,显示的是所有项目的接口

我们期望仅展示选择的默认项目里的接口,又因为这个是内联的表格。所以我们找到admin中的CaseApiDefInline,新建一个过滤方法使用formfield_for_foreignkey,和上面代码基本一样。

只需要

if proj_id and db_field.name == 'api':
kwargs['queryset'] = ApiDef.objects.filter(pj_id=proj_id)

最后完成 部署环境、测试成员的新建时的默认值就行了。使用上面form.base_fields['字段名'].initial

总结,缺省值过滤实践中

对于列表页:get_queryset

对于inline(在内联表里):formfield_for_foreignkey 之 kwargs['queryset']

对于普通表单:get_form 之 form.base_fields['pj'].queryset

对于manytomany(多对多表):formfield_for_manytomany 之 kwargs['queryset']

 

这篇关于阶段三03-SessionCookie机制和优化的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/675369

相关文章

Oracle查询优化之高效实现仅查询前10条记录的方法与实践

《Oracle查询优化之高效实现仅查询前10条记录的方法与实践》:本文主要介绍Oracle查询优化之高效实现仅查询前10条记录的相关资料,包括使用ROWNUM、ROW_NUMBER()函数、FET... 目录1. 使用 ROWNUM 查询2. 使用 ROW_NUMBER() 函数3. 使用 FETCH FI

C#使用HttpClient进行Post请求出现超时问题的解决及优化

《C#使用HttpClient进行Post请求出现超时问题的解决及优化》最近我的控制台程序发现有时候总是出现请求超时等问题,通常好几分钟最多只有3-4个请求,在使用apipost发现并发10个5分钟也... 目录优化结论单例HttpClient连接池耗尽和并发并发异步最终优化后优化结论我直接上优化结论吧,

Java内存泄漏问题的排查、优化与最佳实践

《Java内存泄漏问题的排查、优化与最佳实践》在Java开发中,内存泄漏是一个常见且令人头疼的问题,内存泄漏指的是程序在运行过程中,已经不再使用的对象没有被及时释放,从而导致内存占用不断增加,最终... 目录引言1. 什么是内存泄漏?常见的内存泄漏情况2. 如何排查 Java 中的内存泄漏?2.1 使用 J

一文带你理解Python中import机制与importlib的妙用

《一文带你理解Python中import机制与importlib的妙用》在Python编程的世界里,import语句是开发者最常用的工具之一,它就像一把钥匙,打开了通往各种功能和库的大门,下面就跟随小... 目录一、python import机制概述1.1 import语句的基本用法1.2 模块缓存机制1.

Redis主从/哨兵机制原理分析

《Redis主从/哨兵机制原理分析》本文介绍了Redis的主从复制和哨兵机制,主从复制实现了数据的热备份和负载均衡,而哨兵机制可以监控Redis集群,实现自动故障转移,哨兵机制通过监控、下线、选举和故... 目录一、主从复制1.1 什么是主从复制1.2 主从复制的作用1.3 主从复制原理1.3.1 全量复制

Redis缓存问题与缓存更新机制详解

《Redis缓存问题与缓存更新机制详解》本文主要介绍了缓存问题及其解决方案,包括缓存穿透、缓存击穿、缓存雪崩等问题的成因以及相应的预防和解决方法,同时,还详细探讨了缓存更新机制,包括不同情况下的缓存更... 目录一、缓存问题1.1 缓存穿透1.1.1 问题来源1.1.2 解决方案1.2 缓存击穿1.2.1

Java如何通过反射机制获取数据类对象的属性及方法

《Java如何通过反射机制获取数据类对象的属性及方法》文章介绍了如何使用Java反射机制获取类对象的所有属性及其对应的get、set方法,以及如何通过反射机制实现类对象的实例化,感兴趣的朋友跟随小编一... 目录一、通过反射机制获取类对象的所有属性以及相应的get、set方法1.遍历类对象的所有属性2.获取

MySQL中的锁和MVCC机制解读

《MySQL中的锁和MVCC机制解读》MySQL事务、锁和MVCC机制是确保数据库操作原子性、一致性和隔离性的关键,事务必须遵循ACID原则,锁的类型包括表级锁、行级锁和意向锁,MVCC通过非锁定读和... 目录mysql的锁和MVCC机制事务的概念与ACID特性锁的类型及其工作机制锁的粒度与性能影响多版本

MySQL不使用子查询的原因及优化案例

《MySQL不使用子查询的原因及优化案例》对于mysql,不推荐使用子查询,效率太差,执行子查询时,MYSQL需要创建临时表,查询完毕后再删除这些临时表,所以,子查询的速度会受到一定的影响,本文给大家... 目录不推荐使用子查询和JOIN的原因解决方案优化案例案例1:查询所有有库存的商品信息案例2:使用EX

MySQL中my.ini文件的基础配置和优化配置方式

《MySQL中my.ini文件的基础配置和优化配置方式》文章讨论了数据库异步同步的优化思路,包括三个主要方面:幂等性、时序和延迟,作者还分享了MySQL配置文件的优化经验,并鼓励读者提供支持... 目录mysql my.ini文件的配置和优化配置优化思路MySQL配置文件优化总结MySQL my.ini文件