“让我不要东想西想把测试设计这块拿下，以后往管理岗位转。”
这句话非常有共鸣！在工作这些年，别人对我说过这句话，我也对自己说过这句话，最近有个技术 leader 试图跟我说这句话，被我拒绝了，因为我要转测试开发。我曾经相信了这句话，放弃了技术学习，专搞项目业务测试那一套，等到跳槽时才看到差距。视野内的管理岗很多也都是技术大牛担任的，不搞技术未来发展会越来越窄，这不是说业务不重要，业务是开发和测试共同的基础，只不过测试相对来说技术积累少很多，导致容易迷茫看不到成长，换家公司就没用了。千万不要被别人定性了，也千万不要听所谓过来人，尤其是非测试的项目管理者的言论，有时候他们只需要听话的工具人而已。我也喜欢东想西想，现在除了想还在做，多实践，多写代码，多看看机会，把视线从公司放到整个市场来。
实在不喜欢测试，完全可以转开发，身边就有个妹子，也是被调到做测试，结果实在受不了点点点，转 C++ 了。

从生态来看，Java 无疑是不会后悔的选择。

奥你的问题是，经过参数化后的多个子用例，在分布式执行时，如何按顺序执行？这个貌似没有办法吧，分布式本来就是并行的，并行又要保证先后顺序。
分布式执行用例的设计原则：
用例之间是独立的，用例之间没有依赖关系，用例可以完全独立运行。【独立运行】
用例执行没有顺序，随机顺序都能正常执行。【随机执行】
每个用例都能重复运行，运行结果不会影响其他用例。【不影响其他用例】

.py 文件内部的执行顺序就是从上往下的吧，具体问题能再描述下么？

分布式执行用例的设计原则：
用例之间是独立的，用例之间没有依赖关系，用例可以完全独立运行。【独立运行】
用例执行没有顺序，随机顺序都能正常执行。【随机执行】
每个用例都能重复运行，运行结果不会影响其他用例。【不影响其他用例】

开源估计要等到明年了，哈哈，到时候应该会写个系列文章来从头做个偏学习的版本。

其实现在就是用 Git 管理的，走的 Pull Request，审核后再合并到主干分支，要做成平台是因为每个人的本地环境同步会稍微有点麻烦，开发也有跑用例造数据需求，平台能忽略这些问题，上手就用。还有一个重要原因是公司需要，领导需要，就找了这个折中方案。1 条用例是放在 1 个 test_name.py 文件来写的，就是为了避免多个文件依赖混乱的情况，这一点借鉴了 httprunner 一个 yaml 文件一条用例的做法。如果要改别人的用例，可以先复制用例再修改用例，避免影响别人使用。

好的，我试试，感谢建议，哈哈。

是的，部署没有说，前后端代码是放在 BitBucket 上面的，Drone 是 CI 工具，会轮询 BitBucket 的 Pull Request，自动拉取代码打包成 docker 镜像，通过运维平台配置域名和 Nginx 路由后，部署 image 到 pod，这一套是直接用的公司流程。K8S 这块确实可以优化下。

转成字符串

感谢各位大佬指点。已经和几个负责人沟通了，先解决项目估时问题，把 Story 和 Bug 收敛起来，严格控制发版代码质量，借助 Jira 统计评估是否发版，当收敛到个位数，主流程回归 ok 情况下，出测试报告，澄清测试内容和遗留问题。

再试试这条命令
pip install --default-timeout=6000 -i https://pypi.tuna.tsinghua.edu.cn/simple tep

现在开发想法是测试出报告，线上有问题，报告没写就是测试担责，测试写了就是开发担责。这个做法很慌

是的，初创团队，问题一堆。

每次发版三十个 Bug 没改，十几个 UserStory 没有彻底开发完，你们应该不是这个情况吧
测试报告 测试总结 这是要写 2 份文档

这么夸张 好累

测试数据放 yaml，为什么不直接用 HttpRunner

试试 pip install tep==0.5.3 呢

2021 流行 Java 自动化测试了么

点赞 相同技术栈 正在做 刚好借鉴下

我正在自己写 Vue + Django + DRF

我也没想到被加精了，从读者了解到，文章亮点是给快速搭建自动化项目提供了便利。
tep 只是一款测试工具，不像测试框架逼着你非得这么干，数据代码分离可以通过 fixture 来实现，取决于个人需求和代码习惯。
断言也是一个道理，严谨的话就加上数据库断言呗。

Python 转 Java 方向是什么原因呢

简单易上手，就是 postman 了。

感谢恒温大佬加精！