• 在 UI 自动化过程中开启代理,并对指定 base_url 下的接口进行简单断言,比如:状态码:200;"success":"true"等
    如果您想在 UI 自动化过程中仅对代理请求的接口进行记录并断言,可以使用 mitmproxy 库。mitmproxy 是一个强大的交互式 HTTPS 代理工具,它可以拦截、检查和修改 HTTP 请求和响应。

    以下是一个简单示例,演示如何使用 mitmproxy 对请求进行拦截并进行简单断言:

    首先,安装 mitmproxy:

    pip install mitmproxy
    

    然后,创建一个名为 myaddon.py 的 Python 脚本,包含用于拦截和断言的代码:

    from mitmproxy import http
    
    def request(flow: http.HTTPFlow) -> None:
        # 设置目标 base_url 和要断言的路径
        base_url = "https://api.example.com"
        endpoint = "/some_endpoint"
    
        # 检查请求的 URL 是否匹配指定的 base_url 和 endpoint
        if base_url in flow.request.pretty_url and endpoint in flow.request.pretty_url:
            print(f"Intercepted request to: {flow.request.pretty_url}")
    
            # 断言状态码是否为 200
            assert flow.response.status_code == 200, "Status code is not 200"
    
            # 读取响应内容并转换为 JSON 格式
            data = flow.response.get_text()
            json_data = flow.response.get_text(as_bytes=False)
    
            # 断言返回值中是否包含 "success": true
            assert "success\": true" in json_data, "Success key not found in response"
    

    接下来,在终端中启动 mitmproxy,并加载上面定义的脚本:

    mitmproxy -s myaddon.py
    

    现在,当您运行代理时,它会拦截符合指定 base_url 和 endpoint 的请求,并进行简单的断言。您可以根据需要调整断言逻辑以满足特定需求。

  • 基本上都是外包,拿到简历后也没约面试,公司招聘感觉很少,也没啥面试机会,坐标上海,不知道其他地方情况怎么样

    1. 一方面可能因为个人的学历不太好,导致简历投了石沉大海
    2. 另一方面可能今年确实没那么多需求了,去年大裁员,今年还撑得住估计不会这么快招人吧
  • 跟五楼的意见一致,放在单独的线程组中才可以并发请求
    测试计划中取消勾选独立运行每个线程组

  • 那用例和缺陷不是得关联起来,有点好奇是手动关联的还是关键字匹配的呢
    我理解的:
    手动关联:比如在测试用例增加一列 bugid 之类的
    关键字匹配:通过功能、模块名称分类(禅道里面可以区分,但是我们用的版本没法关联测试用例)

  • 项目的甲方来验收的,也会有第三方的验收公司、监理之类的协助验收,验收不用一条条对,应该只是看个大概,毕竟 word 的测试用例可能得几百页

  • $__{setProperty(,auth_token,${auth_token})}
    $__{setProperty(auth_token,${auth_token},)}
    是不是这个函数入参错了,但是看下面两个是对的
    三个参数:属性名、属性值、是否返回原始值(可忽略)

  • 提供一个思路,可以看下是否能够符合你们的场景:参数随机生成不是很可靠,可以尝试从数据库方面对数据进行分析,了解下参数对应的数据库字段,在数据库里面分析历史的数据长度、类型,不同表的主外键,我们公司的测试数据都是从数据库中获取的,通过关联多张表拿到相关数据,提取到放到参数里面进行请求

  • Grafana 里面加一个服务器的性能监控,我用的 Prometheus 做的,可以一边压测一边看服务器的情况,应该稍微好分析问题

  • 如果接口返回的数据是按照上传顺序排序的,可以考虑下面这个方案是否能够实现
    创建一个线程组,放入上传图片接口,请求后提取返回结果,如果图片上传失败,通过 if 逻辑控制器进入 if 条件,if 条件执行:1)删除上传失败的图片;2)重新上传并再次提取返回结果;不满足的话一直执行,满足就跳出循环,然后整个线程组做一个大的循环,上传多少图片就循环多少次

  • 这是不是意味着在生成百万级数据时,生成的数据放到文件中上传更好一点;如果更大量级的话,文件的读取可能会存在瓶颈,就需要使用其他办法了