• 接口测试平台开发之接口开发(项目管理、接口管理、用例管理)


    在浏览器里输入https://www.showdoc.cc/xinghan?page_id=2778492898901704,点击回车看到好多个接口文档,接下来开发项目管理接口,在星瀚项目中点击项目管理,一直显示玩命加载中,检查看这个接口http://127.0.0.1:8000/api/project一直报404,证明这个接口没有开发,首先配一下url,在urls.py里新增path('project', views.ProjectView.as_view()),然后在forms.py里新增如下图:

    项目管理和全局参数接口基本一样,需要增删改查,因此也要继承NbView,ProjectView里的代码如下图:

    然后点击项目管理,页面可以打开,点击添加按钮,录入完必填信息后,点击确定按钮,提示如下图:

    报错了,创建全局参数的时候没有报错,因为全局参数没有和别的表做关联,而项目管理是和user表做关联了,打开F12,点击Application,点击Local Storage,单击http://localhost:63342,可以看到前端缓存信息的位置,如下图:

    也可以看pycharm里的日志,打印出<QueryDict: {'name': ['本机项目'], 'desc': ['本机项目0321'], 'host': ['http://127.0.0.1:8000'], 'user': ['undefined']}>,看到userIdundefined,这是登录接口登录成功时返回的,项目管理拿着userId向后台请求的时候必然会报错,为了解决这个问题,找到views.py文件里的LoginView类,看代码登录成功的时候返回了token和user,于是加上代码user_id=user.id(因为project表里是user_id),如下图:

    然后重启服务,再重新登录,看到userId是2,如下图:

    再次添加,可以添加成功,在页面、数据库里都能看到添加的数据,如下图:

    然后编辑查询删除,都ok,在项目管理这个get请求中返回的user是2,但是接口文档中user返回的是人,如下图:

    于是需要重构代码,重写GetView的get方法,把get方法拷贝到views.py文件下的ProjectView类下,print(instance)打印出来项目管理,是一个数据库对象,代表项目管理这一条记录,于是添加代码model_dict['user'] = instance.user.username,新增代码如下图:

    在Network的Preview里看到user是dsx了,重写成功了,接下来开发接口管理接口,在星瀚项目中点击接口管理,一直显示玩命加载中,检查看这个接口http://127.0.0.1:8000/api/interface一直报404,证明这个接口没有开发,首先配一下url,在urls.py里新增path('interface', views.InterfaceView.as_view()),然后在forms.py里新增如下图:

    接口管理和项目管理接口基本一样,需要增删改查,因此也要继承NbView,InterfaceView里的代码如下图:

    然后点击接口管理,页面可以打开,点击添加按钮,录入完必填信息后,点击确定按钮,可以添加成功,编辑、删除、按照接口名称查询也ok,但是按照归属项目查询实现不了,于是修改一下代码,因为归属项目是下拉框选择,所以filter_field按照project查询,同时增加project_idproject_name,修改如下图:

    所有功能都OK了,唯独缺少一个按照全部项目进行查询,接下来开发用例管理接口,在星瀚项目中点击用例管理,一直显示玩命加载中,检查看这个接口http://127.0.0.1:8000/api/case一直报404,证明这个接口没有开发,首先配一下url,在urls.py里新增path('case', views.CaseView.as_view()),然后在forms.py里新增如下图:

    用例管理和接口管理接口基本一样,需要增删改查,因此也要继承NbView,拷贝InterfaceView类的代码到CaseView中,修改后代码如下图:

    刷新用例管理页面,可以打开,点击添加按钮,输入用例标题,选择所属项目的时候会报错,页面一直转圈,如下图所示:

    在Network里找到标红的URL,发现这个url(/api/get_rely_case)报404,要找到每个归属项目下的所有用例展示到依赖用例这里,于是要根据需求再开发一个get_rely_case接口,get_rely_case要传一个project_id,根据项目id获取项目下的所有用例,在views.py里开发一个RelyCaseView类,在urls.py里新增path('get_rely_case', views.RelyCaseView.as_view()),views.py文件例新增代码如下图:

    用例管理页面,点击添加按钮,选择一个归属项目,添加对话框没有loading,说明get_rely_case接口调用成功了,Network的Preview里看到data的返回值为空,如下图:

    先添加一条用例,添加完点击确定按钮时,报status是必填项,如下图:

    由于models.py文件里case默认为2,只是在数据库里是2,forms.py里的CaseForm会去验证status这个字段,没有传,所以报status是必填项,如果写了null=True、blank=True,CaseForm就不去验证它了,为解决这个问题在forms.py文件里CaseForm类中排除字段添加上statusexclude = ['is_delete', 'status'],排除这个字段不去验证它,再次点击确定按钮,在页面上可以看到添加成功的用例,如下图:

    支持修改删除和按照titleproject查询功能,再次添加一条用例,选择归属项目的时候报错了,添加对话框一直loading中,和开始遇到的情况是一样的,这是因为代码没有写完,按照接口文档的返回是id和title,把.all()改成.values('id', 'title')qs_data = models.Case.objects.filter(project_id=project_id).values('id', 'title'),.values('id', 'title')的意思是只获取id和title,再次添加,这次OK了,没有报错,也把依赖用例列出来了,如下图:

    点击添加成功的test哈哈,发现了bug,依赖用例没有显示出来上次的用例,点击获取接口时把两条用例都带出来,而且test哈哈还能依赖test哈哈,这里有问题,如下图:

    同时在Network下的Preview里出现了一个链接,get_rely_case?project_id=7&case_id=5,可以看出编辑操作时会传case_id,添加时不传case_id,因此要修改代码如下图:

    添加时,选择归属项目,把依赖用例带出来了,勾上依赖用例,添加成功了,如下图:

    编辑时,没有把依赖用例传过来,这是个bug,如下图:

    点击获取接口,弹出依赖的用例,还得依赖一次,如下图:

    但是看接口文档可以发现返回rely_case字段,格式是

    "rely_case": [
                           {
                              "id": 4,
                              "title": "项目请求"
                           }
                        ]
    rely_case默认为空显示,用外键自关联的方式将数据取出来,在sksystem下新建一个目录core,在core下新建一个case_utils.py文件,定义一个方法
    get_premise_case,传一个instance,在views.py里导入from .core.case_utils import get_premise_case,然后在CaseView类里的get方法下新增model_dict['rely_case'] = get_premise_case(instance),接下来再写get_premise_case方法,先print(instance),刷新用例管理页面,在日志里可以看到打印出来的用例标题,证明拿到了用例对象,get_premise_case方法的代码如下图:

    刷新用例管理页面,在日志里可以看到打印出来的用例对象的数据和rely_cases,如下图:

    看case表里注册和test哈哈对应的id是65,而case_premise没有对应的id,所以打印出来是[],在添加时,勾选依赖用例,点击确定的时候没有创建依赖关系,post走的是NbView里PostView下的post方法,所以要重写post方法,把PostView下的post方法拷到get方法的下面,修改后的代码如下图:

    添加成功,查询也能看到依赖的用例,编辑和删除也没有问题

  • 相关阅读:
    json数组解析
    sparkschedule任务类
    elasticsearch的操作类
    删除hbase的region步骤和代码
    zookeeper持有者类
    zookeeper主节点竞争类
    剑指offer(61-66)编程题
    Codeforces Round #190 (Div. 2) B. Ciel and Flowers
    一些傍晚的感想
    Codeforces Round #307 (Div. 2) D. GukiZ and Binary Operations
  • 原文地址:https://www.cnblogs.com/laosun0204/p/12532902.html
Copyright © 2020-2023  润新知