测试与开发的攻防

2022-05-19 13:08:43 +08:00
 MagnificentCxx

各位 V 友大佬

按照用例评审后的用例内容进行测试,无 bug 部署后,却出现了用例中的 bug ,这里该如何改善呢?

假设是某前端 or 后端在提测结束后有意无意改动了代码部署上线,这里该如何取证呢?

3064 次点击
所在节点    程序员
18 条回复
malusama
2022-05-19 13:18:17 +08:00
测试按照提测的 commit id 测试, 测试完了给 commit id 给运维部署
markgor
2022-05-19 13:18:27 +08:00
测试录屏
ljspython
2022-05-19 13:26:29 +08:00
测试环境-》准生产环境-》生成环境
cxe2v
2022-05-19 13:33:29 +08:00
你们不用代码仓库的吗
lamCJ
2022-05-19 13:35:09 +08:00
看发布记录不就知道了
MagnificentCxx
2022-05-19 13:36:02 +08:00
@cxe2v 使用的,感觉是前端老油条搞得幺蛾子
xaplux
2022-05-19 13:38:52 +08:00
测试环境由测试人员来部署
cxe2v
2022-05-19 13:41:35 +08:00
代码仓库以你开始测试时间前的代码为准啊,看时间记录就容易搞清楚谁动了代码了,你们要是不从代码仓库打包部署,而是开发自己从本地打包,那当我白说
nothingistrue
2022-05-19 14:01:19 +08:00
先别管咋改善的,你们这个 bug 的原因定位到了吗。内部测试无 BUG ,到现场测试出现 BUG ,最可能的原因是环境不同造成的内部漏测,次可能的原因是为了零 BUG 上线故意造成的内部漏测,测试结束以后改个 BUG 出来是最不可能的原因(脑残才会故意弄个 BUG 出来,除非是为了修复之前隐藏的 BUG 的时候除了新 BUG )。

至于如何改善吗,很简单,你们需要一个软件开发 QA ,真正管过程那种 QA ,不是顶个质量管理员头衔的测试。
dddd1919
2022-05-19 14:28:59 +08:00
代码没有版本管理工具?
zoharSoul
2022-05-19 14:31:45 +08:00
不是,
上线的版本和测试的版本都不是一个,
你怎么同意上线的?
lujiaosama
2022-05-19 14:37:25 +08:00
如果我是开发想搞事情. 那我完全可以针对不同的环境(开发, 测试, 生产)写不同的逻辑来跑. 就算测试能通过不代表就和生产就没问题, 毕竟环境不同. 所以, 你们需要检查代码里有没有针对不同环境变量写不同的代码逻辑.
MagnificentCxx
2022-05-19 14:47:42 +08:00
@lujiaosama 前端业务侧的话,这部分的代码都是在哪里比较容易出现呢? nuxt.js 框架的不知道您是否有了解。
sadfQED2
2022-05-19 15:06:36 +08:00
你知道什么叫偶现 bug 吗?你怎么确定你的 case 真的覆盖到位了?不同环境,不同账号,不同网络等等情况都可能导致 bug 出现。

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


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

总结,人菜就少点阴谋论,别瞎怀疑别人
zw1one
2022-05-19 15:14:54 +08:00
1 谁的锅:
问题:看你的意思是:开发说测试用例没测导致 bug ;测试说测试完后,开发改了代码导致 bug
解决:叫开发定位 bug 产生原因就行了,代码提交记录里面啥都有,开发真是误改了的话,人品正常都不会说“我没有改,是你们没有测用例”。真扯皮的话就直接确定你们跑用例的时间,回滚代码再测,必要时拉上领导在场。

2 改善:
问题:按照用例评审后的用例内容进行测试,无 bug 部署后,然后开发优化代码 /修改其他 bug ,导致已通过的用例又出现了 bug 。
分析:
- 楼上有说测试环境由测试部署,但是在部署解决 bug A 的代码版本时,测试并不会知道其中具体的代码改动,该改动也可能影响了已通过的 bug B ,所以这个方案可以解决开发随意部署测试环境的问题,但不能解决楼主的问题。
- 如果是切换不同环境造成的 bug ,测试没有在不同环境上,将测试用例重新跑一遍,导致没发现不同环境的 bug 问题,那你们的测试流程就是有问题的,锅也是测试的。
解决:
- 让开发在修复 bug/优化等代码改动时,给出影响范围,范围内的测试用例需要重新测。可以减少出现这种问题的概率,但是有时候会改动到开发预期外的影响范围,那么给出的影响范围也就不全了。
- 用例测完,bug 修复并验证完成之后,进行一轮回归测试,可以解决预期外的改动范围导致的 bug 。这个看具体各个公司的测试方案,有的出于成本考虑是没有这一轮的,想降低成本的话,也可以考虑自动化测试的方案。
lujiaosama
2022-05-19 15:58:08 +08:00
@MagnificentCxx 其实你不用真的去检查代码, 换个环境测试就是了, 一般前端工程环境变量关键字是 NODE_ENV, 分作 dev, test, prod 等. 你们线上环境变量叫做 prod, 就在部署到测试机时换成 NODE_ENV=prod 来测试.基本就可以排除环境变化带来的 bug.测试的至少还是知道这个吧.别的不说, 你去看看 package.json 中的打包命令吧 yarn build 里面具体写的什么吧.
zhaoyeye
2022-05-20 16:05:38 +08:00
你们来回扯皮在最后把问题抛给运维解决,我就非常郁闷
qiyue0726
2022-05-20 19:45:54 +08:00
只求傻测试别下班提 bug 就谢天谢地了

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/853914

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX