是不是不小心洒了点水啊，老哥

喜欢在发现缺陷后，看开发解释自己为啥会出现这个问题

好文章

是不是用例本身就没覆盖全，建议分析一下客户出问题的场景原因在哪里

笑死，不过既然你们头头都这么说了，这个版本就先测试全程投，把 bug 和用例执行情况披露出来，然后以周报形式定期抄送给全部门尤其是你们的研发主管，到时候项目要发了 bug 没解决急得就是他了

看楼主应该 17 年入行，现在还在干，可能他就是测试主管了

这种应该规范一下 bug 提交规范

我还没见过一天之类测试的内容能产出这么多 bug 的开发和发现这么多 bug 的测试，真是开了眼了

项目外包是这样的吧

到时候主管就是问有没有历史能复用或者能参考的，工作量中间先砍一刀

我期望我能干到 40 就知足了

我碰巧有负责过这类模块，我简单说一下我咋测的，先把表单内容进行分类，比如可能不同内容是不同团队负责，按团队维度或者按特性维度，比如订单类型的，执行操作类型的归为不同类，在写用例的时候针对不同类把特性拆细，最好是一个用例测一个数据点做到足够简单，最好是就输入输出这类，把测试设计作为接口自动化的指导，把测试前移，给到开发去实现接口自动化，转测前看接口自动化是否按照我们之前输出的测试设计实现了，用例确保都通过后转测。自己写那种基于用户使用场景的用例，比如客户什么时候什么情况会使用这种大表单，关注哪些内容，按场景去写，不用特意纠结某一个数据的准确性，因为边界值、等价类那些接口测试已经覆盖过了

我也不少了，我想攒着换个衣服

这个为啥加精

先把测试基本功打好，基本的测试设计用例编写要到位，自己测试思维要培养好，至于其他技术我建议你学目前前沿的，一些什么接口自动化、ui 自动化那些都是玩烂的东西了

讲道理这个是工作 1 到 3 个月要掌握的

问题一可以改，但是得人工一个一个看，他又多，我现在使用上更多是把它当做我思维扩展，避免思维腐朽了，看到有什么新奇独特的测试点再摘录进自己的测试设计，这样会节省很多时间，效果也更好，但是又和提升效能的目的违背了，这样往往花的时间更长，不过能发现几个有效测试点，质量也有提高就是

他是有的，但是他项目那里应该是有 bug，手动添加项目了才能看到

我们也有做，这里提几个问题
第一条测试设计这个，我们也有在做但是效果不好，很多冗余的设计以及不能结合版本项目知识来，不好用，第二个这个他有些需要截图的吧，很多问题没有截图不醒目的，而且提问题本身不算一个很高频的行为不接入 AI 问题也不大，暂时认为提效空间有限，第三个还算靠谱，暂时没有特别大的使用问题

这是高手

dify 可以看一下

可以给开发设计转测卡点，转测前要求比如基本功能用例要能跑通且无其他阻塞性问题等，如果未达标为转测质量差导致要被打回，重新进行转测流程，最终上线时间也就跟着顺延了，如果不顺延比如让测试加班解决障碍也可以把压力给到项目经理或者你们的主管

研发直接去给甲方解释吗，我有一个朋友有类似情况，不过人家是做芯片交付工程师的，大头兵的研发我也没见过需要这样的

挺羡慕的，有时间有规范去沉淀，这样不做好质量都难吧

有的，还挺多的