没做过这个行业，要不你到三和市场雇个做日结的大神？一天才一百块好像

自动化测试分两种
一种是也做业务也做自己做的业务的自动化，一条龙跟下来的具有自动化能力的业务测试。这个模式。本质上是业务测试。
另一种是专职做自动化，其他业务测试做用例，他只负责用例自动化的（这种模式比较少用了，因为用例的沟通理解成本高，误解风险大）这个不深入讨论，很罕见。
专职的测开本质是开发跟测试没啥关系（当然很多顶着测开头衔的测试是另外一回事）。

很简单，让开发自测 + 容忍漏测。
腾讯经常搞出十几个开发配一个测试的情况，就是让开发自测 + 容忍漏测。

左移，右移要搞；但是左移势必和开发的工作产生重叠，很多测试左移工作实际上是 “帮助开发完成自测”，所以哪些要左移哪些要让开发做好自测，就要定义清楚。 糟糕的是目前这个没有业界统一标准，甚至同一个公司不同部门也相互差别巨大。

于是会出现一个人，适应 A 部门的分工，但到了 B 部门就适应不了的现象，因为两个部门测试 和 开发 两个角色分工差异较大。

同时也给招聘工作带来巨大麻烦，需要去验证候选人能够适应当前团队的分工，而如果当前团队的分工不合理，往往也会加剧人员流失，造成招聘工作频繁发生，更加剧了招聘工作量。。。。 再加上 测试工作频繁交接带来的风险和低效率。。。
左移，怎样左移，移到什么程度，真是个大问题。

右移反而清晰一些，大多数情况是，测试想找运维要线上数据，运维不给，不配合，基本以运维配合的程度为界限，界限分明一些，比较好做，能做到哪做到哪，大佬想推就往运维那边甩，有大佬压力，运维配合给拷贝数据，导流量就做，而且右移对质量保障和提升效率的效果比左移明显。 如果遇到线上风险大，测试不用说话，运维直接把方案拍死，大佬一般也不会强推毕竟大佬也不想出事故。

这就是一个分工混沌的地方，我觉得纯粹的测开应该就是开发，测试是他开发的系统的使用方而已，开发会计系统的人一定要懂会计吗？ 为啥开发测试工具平台的人一定要懂测试？

我一般喜欢用独立进程，让操作系统来管理多线程多好，非要自己管理多线程多此一举，测试脚本没必要考虑执行效率优化到线上服务级别啊。
至于数据共享，为啥有 redis，mysql 不用？嫌厚重？还有 sqlite 呢。 测试脚本应该多用简单的积木少自己实现功能。

实际遇到我可能就选 C 了

我遇到过一个 bug，必须一直跑 7 天不重起才能发现它，而给我的测试周期没有 7 天（简单的说就是连着跑 7 天以后一大半请求会直接报错），而且还是开发代码夹带，提测需求单里没提这茬，而测试周期的评估是按需求单的。。。。。。。。。。。。。。。。。。就这样我把这个 bug 给漏了，然后 7 天后被运维发现，我就这样稀里糊涂的有了一个现网 bug，还是特别严重的那种。。。。。

开发这样害我，我该怎么办？？？？

Apache Bench（对发压机性能要求低但是不支持复杂测试，只能测试单一接口的单步操作，可以多开几个进程同时测多个接口但不能用前一个接口的响应作为下一个接口请求的一部分）不就是固定 QPS 吗，另外 jmeter 用 Synchronizing Timer 也可以实现，可以做复杂测试（需要发压机性能较好）

测试人员的新姿从 5000 到 50000 分布着，也有低于 5000 和高于 50000 的少数