• 开题立意:我不赞同楼上的观点,回归可以更全面,但是不能冗余
    首先,我们确定下这个问题的性质:这是一个误操作事件,是开发人员工作失误导致的问题,与我们本次需求更改无任何关联关系 (这点待楼主确定,我只是说个场景)
    然后,我认为此类问题无法拦截、也不该由测试去负责擦屁股,至少职责上是的。()

    楼上的回归测试方法是大部分人在面对此类结果 (非源头) 时的第一反应,可是我认为回归测试不该是如此的。中小系统或者具备自动化回归的情况下,我们可以这么去做,那大型产品呢?较频繁的版本迭代呢?难道我们每次都要 all in 吗?
    回归测试核心是针对需求变更对其需求流程、需求关联功能、流程周边功能,这个范围已经足以达标性的保证本次需求的质量管控范围,如果本次存在范围外的需求外变更,我认为测试是不需要为其进行额外负担的。

    当然我们测试人都是很有责任感的,所以也就有了本帖的存在,也就有了同行们对解决所有问题的热忱,但是如果真的线上出现了此类原因导致的问题,我同样不想各位因此背锅因此自疑。注:楼主的举例问题是否可以监控到 excel 的变更情况,有的化可以在转测时对照需求比对下表格的改动是否有出入,没有监控的化那。。

  • 有了兔子后社区活力十足啊

  • 你这个北方省会让我一激灵啊!莫非是 HT?YD?
    没做过工业,没法给你行业建议。看了你的问题,感觉大部分都是公司内流程问题,或者说无流程控制导致的,而且你基本上是出于一个象征品的角色,无能为力。
    如果你打算跳的话就很简单,回顾自身技能,做好面试准备就行;
    如果不打算跳了,我建议可以尝试先向上反馈下流程问题和带来的影响,然后尽量让自己参与到每次的改动中,做到次次参与,即使开始只是看客,也会逐步加强他们对 “要有测试参与” 的意识,接着可以发起诸如评审等测试环节,最后做好左右对接和转测/发版的管控。这是一个话语权的逐步建立,有了话语权和影响力才能慢慢的推动流程。
    第三条路就是:如果不担心被炒而且线上问题在公司内更重视解决而不做回溯追责,那你可以做好甩锅准备后就开始摸鱼养老啦

  • 539 次阅读却无一回复,楼主可以思考下是为啥
    菜鸡的我来凭空想像,尝试回复下

    更新后黑屏卸载重装后恢复
    

    我猜测问题点在原版本文件处,更新时对原文件的处理不当,导致与现版本冲突进而黑屏。卸载操作将原冲突文件删除,进而解决了冲突问题。
    这种问题应该在日志中可以找到对应报错,比如文件找不到、函数未定义啥啥啥的

  • 正则,也可以取到 cookies 的 value 后再 split('=') 取后面的,方法很多,直接百度!
    org_token=(.*?)'
    去吧,正则世界的所有奥秘我都放在上一行啦

  • 可以啊

  • 如果你只是想弄清楚可不可以,多和所有的性质其实是一样的。
    如果你想问下各位大佬的经验,我这位菜鸟的经验是不会有这种场景。
    所有接口都弄到一个 case 里面是可以实现的,但是后续呢?
    和单接口单 case 的区别在哪?或者说优势意义在哪?
    带来的只有一个结果:一次性用品,都谈不上耦合了

  • 能保证质量达标,没有测试又如何;问题不在有无测试,而在质量如何管控

  • 接贴问各位大佬,简历上精通要不要写,写的话该怎么判断和考量呢

  • 有三条正在紧张审核中,我就不多做回复啦,可以了解下单接口和多接口的测试

  • 你就说能不能分布式办公吧

  • 没看到楼主的分享内容是啥,建议用例子来进行阐述,哪怕有个图呢

  • 熟悉测试流程和计划制定,然后领导想让你做,就可以做,重要的是后面

  • 电子校的那些事儿 - 下篇 at 2022年07月15日

    你好歹分个段!!!这不是折磨人吗

  • 1.平台集成 Jmeter?为什么不直接用 Jmeter,学起来也很简单。
    2.java 调用 python 脚本?有 java 基础可以考虑直接学习 python,很简单
    3.如果你是说接口请求,一般都是用 python 的 requests 库,java 的不清楚

  • 编译器测试该如何测试 at 2022年07月15日

    续楼上:你得懂得编译器的工作原理和处理流程才能真正的去测

  • 为啥我看完后更迷茫啦,你在说啥子、

  • 全值断言、局部断言,拿你要比对的部分就行

  • 如果你只是点点点,那确实没啥前方了;如果你是业务测试,那还是有希望的。

  • 初级 开发 + 运维 + 测试 +ETL 工程师

  • 最近关于测试平台的困惑 at 2022年07月14日
    领导要求使用测试平台称只有通过测试平台统计的接口覆盖率才能作为年底绩效指标
    

    这就是你现在的工作目标,应试考核,问题多就先把 kpi 顶上去再说

  • 测开确实更多是为了高薪和 ppt

  • 业务测试的困局 at 2022年07月14日

    假敏捷是没有办法的事情,假敏捷的普遍现象是:持续集成、转测质量差、开发无自测、团队整体无质量保证思想、质量是测试的事情、测试无话语权、软件只为本次不为未来...
    本现象更多的体现在做项目的公司或团队内,开发思想只为交付不为迭代,凑合能用就行,质量是个什么东西

  • 这个问题绝对不会是决定性问题

  • 一个是重在输入前,一个重在输入后,如题例其实是接口脚本对数据的接收处理,而数据驱动则是在脚本完备后构造多种场景数据参数来对多路径进行验证,分界点是参数化后。个人浅见