V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
MagnificentCxx
V2EX  ›  程序员

测试与开发的攻防

  •  
  •   MagnificentCxx · 40 天前 · 2089 次点击
    这是一个创建于 40 天前的主题,其中的信息可能已经有所发展或是发生改变。

    各位 V 友大佬

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

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

    第 1 条附言  ·  40 天前
    ps:
    有测试环境->准生产环境->生产环境
    有代码版本管理
    部署由测试人员部署

    问题多是页面样式、偏重前端开发侧的 bug
    18 条回复    2022-05-20 19:45:54 +08:00
    malusama
        1
    malusama  
       40 天前   ❤️ 1
    测试按照提测的 commit id 测试, 测试完了给 commit id 给运维部署
    markgor
        2
    markgor  
       40 天前   ❤️ 1
    测试录屏
    ljspython
        3
    ljspython  
       40 天前   ❤️ 1
    测试环境-》准生产环境-》生成环境
    cxe2v
        4
    cxe2v  
       40 天前
    你们不用代码仓库的吗
    lamCJ
        5
    lamCJ  
       40 天前 via Android
    看发布记录不就知道了
    MagnificentCxx
        6
    MagnificentCxx  
    OP
       40 天前
    @cxe2v 使用的,感觉是前端老油条搞得幺蛾子
    xaplux
        7
    xaplux  
       40 天前   ❤️ 1
    测试环境由测试人员来部署
    cxe2v
        8
    cxe2v  
       40 天前   ❤️ 1
    代码仓库以你开始测试时间前的代码为准啊,看时间记录就容易搞清楚谁动了代码了,你们要是不从代码仓库打包部署,而是开发自己从本地打包,那当我白说
    nothingistrue
        9
    nothingistrue  
       40 天前   ❤️ 2
    先别管咋改善的,你们这个 bug 的原因定位到了吗。内部测试无 BUG ,到现场测试出现 BUG ,最可能的原因是环境不同造成的内部漏测,次可能的原因是为了零 BUG 上线故意造成的内部漏测,测试结束以后改个 BUG 出来是最不可能的原因(脑残才会故意弄个 BUG 出来,除非是为了修复之前隐藏的 BUG 的时候除了新 BUG )。

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

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


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

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

    2 改善:
    问题:按照用例评审后的用例内容进行测试,无 bug 部署后,然后开发优化代码 /修改其他 bug ,导致已通过的用例又出现了 bug 。
    分析:
    - 楼上有说测试环境由测试部署,但是在部署解决 bug A 的代码版本时,测试并不会知道其中具体的代码改动,该改动也可能影响了已通过的 bug B ,所以这个方案可以解决开发随意部署测试环境的问题,但不能解决楼主的问题。
    - 如果是切换不同环境造成的 bug ,测试没有在不同环境上,将测试用例重新跑一遍,导致没发现不同环境的 bug 问题,那你们的测试流程就是有问题的,锅也是测试的。
    解决:
    - 让开发在修复 bug/优化等代码改动时,给出影响范围,范围内的测试用例需要重新测。可以减少出现这种问题的概率,但是有时候会改动到开发预期外的影响范围,那么给出的影响范围也就不全了。
    - 用例测完,bug 修复并验证完成之后,进行一轮回归测试,可以解决预期外的改动范围导致的 bug 。这个看具体各个公司的测试方案,有的出于成本考虑是没有这一轮的,想降低成本的话,也可以考虑自动化测试的方案。
    lujiaosama
        16
    lujiaosama  
       40 天前   ❤️ 1
    @MagnificentCxx 其实你不用真的去检查代码, 换个环境测试就是了, 一般前端工程环境变量关键字是 NODE_ENV, 分作 dev, test, prod 等. 你们线上环境变量叫做 prod, 就在部署到测试机时换成 NODE_ENV=prod 来测试.基本就可以排除环境变化带来的 bug.测试的至少还是知道这个吧.别的不说, 你去看看 package.json 中的打包命令吧 yarn build 里面具体写的什么吧.
    zhaoyeye
        17
    zhaoyeye  
       39 天前 via Android
    你们来回扯皮在最后把问题抛给运维解决,我就非常郁闷
    qiyue0726
        18
    qiyue0726  
       39 天前
    只求傻测试别下班提 bug 就谢天谢地了
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2745 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 12:16 · PVG 20:16 · LAX 05:16 · JFK 08:16
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.