这是一个创建于 948 天前的主题，其中的信息可能已经有所发展或是发生改变。
各位 V 友大佬
按照用例评审后的用例内容进行测试，无 bug 部署后，却出现了用例中的 bug ，这里该如何改善呢？
假设是某前端 or 后端在提测结束后有意无意改动了代码部署上线，这里该如何取证呢？
第 1 条附言 · 2022-05-19 14:37:24 +08:00
ps：
有测试环境->准生产环境->生产环境
有代码版本管理
部署由测试人员部署
问题多是页面样式、偏重前端开发侧的 bug
有测试环境->准生产环境->生产环境
有代码版本管理
部署由测试人员部署
问题多是页面样式、偏重前端开发侧的 bug
 |
1
malusama 2022-05-19 13:18:17 +08:00  1
测试按照提测的 commit id 测试, 测试完了给 commit id 给运维部署
|
 |
2
markgor 2022-05-19 13:18:27 +08:00 1
测试录屏
|
 |
3
ljspython 2022-05-19 13:26:29 +08:00 1
测试环境-》准生产环境-》生成环境
|
 |
4
cxe2v 2022-05-19 13:33:29 +08:00
你们不用代码仓库的吗
|
 |
5
lamCJ 2022-05-19 13:35:09 +08:00 via Android
看发布记录不就知道了
|
 |
6
MagnificentCxx OP @cxe2v 使用的，感觉是前端老油条搞得幺蛾子
|
 |
7
xaplux 2022-05-19 13:38:52 +08:00 1
测试环境由测试人员来部署
|
|
8
cxe2v 2022-05-19 13:41:35 +08:00 1
代码仓库以你开始测试时间前的代码为准啊，看时间记录就容易搞清楚谁动了代码了，你们要是不从代码仓库打包部署，而是开发自己从本地打包，那当我白说
|
 |
9
nothingistrue 2022-05-19 14:01:19 +08:00 2
先别管咋改善的，你们这个 bug 的原因定位到了吗。内部测试无 BUG ，到现场测试出现 BUG ，最可能的原因是环境不同造成的内部漏测，次可能的原因是为了零 BUG 上线故意造成的内部漏测，测试结束以后改个 BUG 出来是最不可能的原因（脑残才会故意弄个 BUG 出来，除非是为了修复之前隐藏的 BUG 的时候除了新 BUG ）。
至于如何改善吗，很简单，你们需要一个软件开发 QA ，真正管过程那种 QA ，不是顶个质量管理员头衔的测试。 |
 |
10
dddd1919 2022-05-19 14:28:59 +08:00
代码没有版本管理工具？
|
 |
11
zoharSoul 2022-05-19 14:31:45 +08:00
不是,
上线的版本和测试的版本都不是一个, 你怎么同意上线的? |
 |
12
lujiaosama 2022-05-19 14:37:25 +08:00 1
如果我是开发想搞事情. 那我完全可以针对不同的环境(开发, 测试, 生产)写不同的逻辑来跑. 就算测试能通过不代表就和生产就没问题, 毕竟环境不同. 所以, 你们需要检查代码里有没有针对不同环境变量写不同的代码逻辑.
|
|
13
MagnificentCxx OP @lujiaosama 前端业务侧的话，这部分的代码都是在哪里比较容易出现呢？ nuxt.js 框架的不知道您是否有了解。
|
 |
14
sadfQED2 2022-05-19 15:06:36 +08:00 1
你知道什么叫偶现 bug 吗？你怎么确定你的 case 真的覆盖到位了？不同环境，不同账号，不同网络等等情况都可能导致 bug 出现。
提测的时候你看看代码 diff ，修完 bug 看一眼代码 diff ，有没有问题一眼不就看出来了 最后，无论如何我是不相信研发会测试的时候给你一个没问题的版本，上线的时候故意改个 bug 出来。 总结，人菜就少点阴谋论，别瞎怀疑别人 |
 |
15
zw1one 2022-05-19 15:14:54 +08:00 2
1 谁的锅：
问题：看你的意思是：开发说测试用例没测导致 bug ；测试说测试完后，开发改了代码导致 bug 解决：叫开发定位 bug 产生原因就行了，代码提交记录里面啥都有，开发真是误改了的话，人品正常都不会说“我没有改，是你们没有测用例”。真扯皮的话就直接确定你们跑用例的时间，回滚代码再测，必要时拉上领导在场。 2 改善： 问题：按照用例评审后的用例内容进行测试，无 bug 部署后，然后开发优化代码 /修改其他 bug ，导致已通过的用例又出现了 bug 。 分析： - 楼上有说测试环境由测试部署，但是在部署解决 bug A 的代码版本时，测试并不会知道其中具体的代码改动，该改动也可能影响了已通过的 bug B ，所以这个方案可以解决开发随意部署测试环境的问题，但不能解决楼主的问题。 - 如果是切换不同环境造成的 bug ，测试没有在不同环境上，将测试用例重新跑一遍，导致没发现不同环境的 bug 问题，那你们的测试流程就是有问题的，锅也是测试的。 解决： - 让开发在修复 bug/优化等代码改动时，给出影响范围，范围内的测试用例需要重新测。可以减少出现这种问题的概率，但是有时候会改动到开发预期外的影响范围，那么给出的影响范围也就不全了。 - 用例测完，bug 修复并验证完成之后，进行一轮回归测试，可以解决预期外的改动范围导致的 bug 。这个看具体各个公司的测试方案，有的出于成本考虑是没有这一轮的，想降低成本的话，也可以考虑自动化测试的方案。 |
|
16
lujiaosama 2022-05-19 15:58:08 +08:00 1
@MagnificentCxx 其实你不用真的去检查代码, 换个环境测试就是了, 一般前端工程环境变量关键字是 NODE_ENV, 分作 dev, test, prod 等. 你们线上环境变量叫做 prod, 就在部署到测试机时换成 NODE_ENV=prod 来测试.基本就可以排除环境变化带来的 bug.测试的至少还是知道这个吧.别的不说, 你去看看 package.json 中的打包命令吧 yarn build 里面具体写的什么吧.
|
 |
17
zhaoyeye 2022-05-20 16:05:38 +08:00 via Android
你们来回扯皮在最后把问题抛给运维解决，我就非常郁闷
|
 |
18
qiyue0726 2022-05-20 19:45:54 +08:00
只求傻测试别下班提 bug 就谢天谢地了
|
Select Language