request_body 做个类型判断，然后分别传入 requests 的.{http_method}(data=,json=)。
操作 dict 总比 split string 的好

说穿了，还是持续维护工作量大且 “价值” 不大的问题。脏活累活谁都不想干，所以不要抱怨环境 XXX 的问题，因为连 “你” 都不想去 “整理”！环境有问题，及时修了就好，修不好 “升级” 让领导们知道 “风险”。

棒棒哒

“现在的问题就是太迷信测试会写代码” 不太理解这句话的意思，能否张开下？

还是自己的舒服啊

不要去抱怨工作以及工作的合作者。想想如何帮助开发提高冒烟成功率，开发的痛点在哪？而不是不断升级 “汇报”，最后谁都不开心。

你原文是啥？

不用想了，赶紧跑路

https://www.jianshu.com/p/82886d77440c

哎～～又是一个关联性的 case 设计。个人建议不要搞这种 case 用 fixture 做 setUp 将前置步骤最短化实现，这样做唯一的坏处就是相关前置步骤修改可能会导致修改量比较大，但 fixture 是能套 fixture 的合理的 “拆封” 是很又必要的。

把代码贴出来

把 param_info 放到 Test_case1 外面看看。

不是信任的问题，是人的记忆力不靠谱。最好的方式还是自动化代码和平时积累的 run log

结果标注，可信度有多高？如何来追溯？

虽然是闲聊式的谈论，但最终还回到了闲聊。。。。。
其实有个点可以突出下 “如何更有效地落地用例”。
思维图，excel 之类但文档，在我看来明显不是有效的落地方式，关键的问题是 “你按照用例做了多少？” “怎么体现你做了多少？” ” 你真做了这么多吗？“

有没有认真看文档？setUp 这个 fixture 没有放到 test_one 的参数里！！！

你时间还短

推荐一个 BasePageObject eeaston/page-objects

大公司成本就低了？就会投入更多的预算？不是抬杠，但这种理想化的思想和 “画大饼” 差不多，还是要脚踏实地，不要去猜想 “别人家的孩子”。

具体情况，具体分析，具体解决。规则是死的

希望对你有帮助 (pytest-xdist)

http://tool.chinaz.com/tools/urlencode.aspx

一个测试理论的问题都没？数据库的问题也没？这么神奇

你还能坚持这么久，耐力可以的。

下次把这些话当面说出来效果会更好。