测试与开发的攻防

测试按照提测的 commit id 测试, 测试完了给 commit id 给运维部署

测试录屏

测试环境-》准生产环境-》生成环境

你们不用代码仓库的吗

看发布记录不就知道了

@cxe2v 使用的，感觉是前端老油条搞得幺蛾子

测试环境由测试人员来部署

代码仓库以你开始测试时间前的代码为准啊，看时间记录就容易搞清楚谁动了代码了，你们要是不从代码仓库打包部署，而是开发自己从本地打包，那当我白说

先别管咋改善的，你们这个 bug 的原因定位到了吗。内部测试无 BUG ，到现场测试出现 BUG ，最可能的原因是环境不同造成的内部漏测，次可能的原因是为了零 BUG 上线故意造成的内部漏测，测试结束以后改个 BUG 出来是最不可能的原因（脑残才会故意弄个 BUG 出来，除非是为了修复之前隐藏的 BUG 的时候除了新 BUG ）。

至于如何改善吗，很简单，你们需要一个软件开发 QA ，真正管过程那种 QA ，不是顶个质量管理员头衔的测试。

代码没有版本管理工具？

不是,
上线的版本和测试的版本都不是一个,
你怎么同意上线的?

如果我是开发想搞事情. 那我完全可以针对不同的环境(开发, 测试, 生产)写不同的逻辑来跑. 就算测试能通过不代表就和生产就没问题, 毕竟环境不同. 所以, 你们需要检查代码里有没有针对不同环境变量写不同的代码逻辑.

@lujiaosama 前端业务侧的话这部分的代码都是在哪里比较容易出现呢？ nuxt.js 框架的不知道您是否有了解。

你知道什么叫偶现 bug 吗？你怎么确定你的 case 真的覆盖到位了？不同环境，不同账号，不同网络等等情况都可能导致 bug 出现。

提测的时候你看看代码 diff ，修完 bug 看一眼代码 diff ，有没有问题一眼不就看出来了


最后，无论如何我是不相信研发会测试的时候给你一个没问题的版本，上线的时候故意改个 bug 出来。

总结，人菜就少点阴谋论，别瞎怀疑别人

1 谁的锅：
问题：看你的意思是：开发说测试用例没测导致 bug ；测试说测试完后，开发改了代码导致 bug
解决：叫开发定位 bug 产生原因就行了，代码提交记录里面啥都有，开发真是误改了的话，人品正常都不会说“我没有改，是你们没有测用例”。真扯皮的话就直接确定你们跑用例的时间，回滚代码再测，必要时拉上领导在场。

2 改善：
问题：按照用例评审后的用例内容进行测试，无 bug 部署后，然后开发优化代码 /修改其他 bug ，导致已通过的用例又出现了 bug 。
分析：
- 楼上有说测试环境由测试部署，但是在部署解决 bug A 的代码版本时，测试并不会知道其中具体的代码改动，该改动也可能影响了已通过的 bug B ，所以这个方案可以解决开发随意部署测试环境的问题，但不能解决楼主的问题。
- 如果是切换不同环境造成的 bug ，测试没有在不同环境上，将测试用例重新跑一遍，导致没发现不同环境的 bug 问题，那你们的测试流程就是有问题的，锅也是测试的。
解决：
- 让开发在修复 bug/优化等代码改动时，给出影响范围，范围内的测试用例需要重新测。可以减少出现这种问题的概率，但是有时候会改动到开发预期外的影响范围，那么给出的影响范围也就不全了。
- 用例测完，bug 修复并验证完成之后，进行一轮回归测试，可以解决预期外的改动范围导致的 bug 。这个看具体各个公司的测试方案，有的出于成本考虑是没有这一轮的，想降低成本的话，也可以考虑自动化测试的方案。

@MagnificentCxx 其实你不用真的去检查代码, 换个环境测试就是了, 一般前端工程环境变量关键字是 NODE_ENV, 分作 dev, test, prod 等. 你们线上环境变量叫做 prod, 就在部署到测试机时换成 NODE_ENV=prod 来测试.基本就可以排除环境变化带来的 bug.测试的至少还是知道这个吧.别的不说, 你去看看 package.json 中的打包命令吧 yarn build 里面具体写的什么吧.

你们来回扯皮在最后把问题抛给运维解决，我就非常郁闷

只求傻测试别下班提 bug 就谢天谢地了