我也一直是第二种理解。
本质工作做好以后，左移右移只会是加分项呀。

是的。
request 是 pytest 内置的 fixture。
The request fixture is a special fixture providing information of the requesting test function.
request.param，没有后缀 s，是 request 的属性，用来引用参数的。
has an optional param attribute in case the fixture is parametrized indirectly.

谢谢

降低上手难度吧，如果像后端那么封装，可能有些测试就不一定看得懂了

1.追溯代码提交记录，合并主分支时候，少了一行代码。
这个可以用 git 比对的。和开发商量写个自动化脚本吧。

软件测试的艺术第三版，增加了移动端测试内容。

哈哈没事 能解决问题就好 我用的时候也有这样的需求 只统计数量，但是找不到人 只有自己啃文档，能在平台上交流，挺好的

pytest --collect-only 简写 pytest --co
就可以了

测试用例的问题？
测试执行的问题？

排版优化了一下，方便查阅。
有问题欢迎交流呀。

jenkins 没有配置环境变量

测试平台的一个意义，就是更方便的共享成果，不仅是测试之间，还包括测试和开发之间。

我试试

谢谢
我简单说下我做了哪些事
使用 poetry 包管理器添加了胶水代码，把 pytest、requests、allure、faker、jmespath、loguru、deepdiff、pymysql、sqlalchemy、texttable、pandas、numpy 等统一管理，上传到了 pypi，直接就可以安装和更新，方便团队内维护。
基本没怎么封装，就像前面同学说的那样。只是为了个性化定义，用装饰器加了点日志，方便调试。
提供了使用 pytest 组织用例目录的参考，也就是 scaffold。
使用 poetry 结合 pytest hook，写了个 plugin 或者说 hook，自定义了参数--tep-reports，一是加上后可以在本地生成测试报告（用 jenkins 的话就不需要），主要也是本地调试用，跑批量用例看效果。二是 allure trend 默认是没有数据的（jenkins 会自动填充），本地这里也弄了一下，能把每次批量跑的数据 trend 显示出来。
funcs 写了利己的一些公共函数。
dao 用 sqlalchemy 写了 pandas 会用到的 engine，目前只弄了 mysql，访问 db 返回的 dataframe，取数还是挺方便的。texttable 可以在 console 输出表格，方便查数据。
其实没做什么特别意外的事，就是把常用的东西整合整合，方便共享，也是技术积累。哈哈。有点类似工具包吧。很多技术都是跟着 httprunner 学的。
团队测试都想写纯 python，这是我们这样做的最重要原因！
我只是个渣渣

嗯，本来不打算发出来的，每个公司都有自己合适的技术实现。
看来后面还是只在这里发硬干货，不然容易口水战

哈哈
1 淡定
2 之前还不知道 requests 可以直接获取耗时，又可以优化下代码了
3 没怎么造轮子呀 就是借鉴 httprunner 思路简单组装而已
4 我们本来就是直接写 python

谢谢大佬

都学，都会一点，是肯定的。
只是作为第一生产力语言的选择 。

@jacksboy @geons 多谢提醒，已经重新上传图片了。

这种情况要做自动化，就需要把前端页面字段，跟后端返回数据，之间的对应关系整理出来。
关系整理出来了，再考虑如何自动化。
可以从契约测试入手。