正常来说，主流程不通就打回的，但是实际情况比较复杂，还有就是要预告风险，那就是测试不通过，告知有延期上线的风险，并且，如果讲究流程的话，那就是在你这里是测试不通过的。不支持发布

如果总是改一半的话，不如把这个问题甩给产品，就是直接群里艾特开发和产品，告知开发目前改成这个样子能不能接受，不能接受就艾特开发继续改，能接受就不改了你也省心省事，把开发的问题暴露出来，光测试可能改变不了什么了，看能不能凭借产品给开发压力，让开发提高提测质量

开发没什么感受，无非就是太忙了，或者是没理解透需求导致改 bug 的思路完全不正确。作为测试而言就是很心累了。跟开发强调一下，有个自测流程会好一点

再干几个月就过年了，期待着元旦，望着过年，也不远了。坚持就是胜利

还好吧，半年时间不算很短，比起你的工作时间更关注你的技能和项目经历以及在面试中表现的可成长性，简单来说，你是刚毕业没多久的新人，更关注你在工作的中的综合能力的表现以及是否可以培养，对刚入职的新人的能力要求相对来说会放低一些。

首先，经济上没压力，然后，心理上做好休息半年的准备，怎么说呢，现在离职，大概率年后再工作了。其次，如果公司有年终奖的话，那还是等发了年终后再离职会比较好。不要跟钱过不去

不是贬义，但是有时候，bug 的质比量更重要。其次，保证的是上线后的功能，用户反馈的线上 bug 少，那就是很好的测试了。

挺好的，很强了。

按照我自己的面试和被面试的经历，就是测试的基本功，用例可以多重视一点，其次就是业务了，如果现在人员不多的情况下，尽量去接触代码，最好能在开发的代码阶段就能提前发现问题，积累经验，会 CR 代码的测试，其实还是蛮受欢迎的。其他的感觉有点虚，性能方面，开发能做的更好，自动化成本太大了，目前很少能用到。简单来说，用例设计上，多思考多积累，代码能力提升一下，业务理解更深更底层一些。

我面试的时候，也是先主要考察业务逻辑和测试用例的基本功，如果基本功不过关，我就直接 pass 了。其他的都是加分项，有更好，没有也没啥。