添加用户是一个接口，有成功响应以及各种失败响应。
"输入合法用户信息，能够成功添加用户"这是一条用例，执行前得保证构造合法数据，想避免重复用时间戳做后缀是个不错的方法。
“输入已存在用户信息，提示用户重复” 这是另一条用例，执行前得保证该信息一定已在库中。
上面两条用例都是调用添加这个接口。
至于删除相关的用例，应当有一个前置条件，前置条件可以是通过调用添加接口或其他方式来实现。
所谓测试技术还是得围绕基础理论来转啊。

很多人都有强烈的降低自动化测试门槛的欲望，想自己造轮子，让别人别造轮子，包括曾经的我自己
就好比上网经历一样，谁没有不堪回首的过去呢
认为业务不重要的，要么专职做偏运维类的工具开发，当然可能挂的是测试开发的头衔，要么等着被现实毒打。

当初选型看了下，感觉 API FOX 挺方便，把暂时用得上的功能都整合了。
但是不开源，所以最后还是重新改造了一套。
原因有三：
1、对接内部的其他平台，比如我们的 API 得有注册、审核，发布到不同环境。
2、公司层面不愿意把数据放到别人的平台上，私有化部署就意味着成本，老板都是想白嫖，除非真的把握住了痛点。
3、把数据放在外面等于变相地给自己制造痛点...

嗯，想想为什么这些先行者们最终不愿意维护这样的平台了

这题最简单的解法不就是栈吗，正则才是炫技吧
就 25 楼的答案，不上机测试有多少人能看明白结果对还是不对

性能测试跟功能一样，先得有需求吧，再有设计，执行，比对预期结果和实际结果。
光从图上看，几千用户的时候 rps 就到峰值，后面的响应时间都是几十秒，什么业务系统能容忍这么高的响应时间呢？
如果是想把服务器 CPU 压满，那对于瓶颈本来就不在 CPU 的怎么压，再说 RPS 都上不去了追求 CPU 利用率有什么意义。

某知名车企提过的一个需求：
测试人员手工执行时，通过计算机视觉生成自动化用例用于回归测试

看代码风格 4 楼就赢了

服务器的带宽够，那测试机的够吗？

看着像是 celery 与 python 的版本冲突，网上有相关的详细说明，解决的话 python 降级或者 celery 降级。