感谢写了这么多字回复我哈哈哈

就目前来说，目前的测试报告确实是在找测试环境之所以不能达到领导预期那样顺利的原因。然后就会像你说的这样找到其他人的原因，事实上是一种背刺。因为就现实来讲，测试环境一帆风顺基本不可能达到。所以问题找的次数多了，就相当于是狼来了，解决不了问题，得罪了人，测试报告估计慢慢的也就没人看了。。这是我目前最困扰的问题

然后说集中资源做关键需求，这个我也想过：是否是两个人测一个需求，然后晚提测的需求等一两天，将所有需求的测试周期控制在 5 天之内。
只是目前我们的人力资源做不到，因为同时进行着 app 和 web 的不同需求的迭代，同时产品内部也有竞争，同时进行的关键需求也不在少数
所以让每个需求每天看起来都有进度，没有因为测试排不上人力而卡在待测试，这是我之前优先考虑的事情。这样做的好处在于：让每个需求进入测试阶段，尽早开始测试，能尽快发现问题，尽早解决阻塞性的问题，而不是一个需求提测后等了一两天再进入测试，此时开发已经忙别的去了；
不过有时候想预期这样不如攻坚单个需求，排不上人力的就等着。这样做的好处是避免为了测试有进度而拉长每个需求的周期掩盖测试人力不足的问题。
其实是一个 “尽快开始测试” 和 “优先结束测试” 的抉择。但不管是优先结束，还是优先进入，都不会缩短项目整体的周期，只是让测试开始到测试结束看起来变短了。

跟兄弟团队有过沟通，但可能做的却是不到位，或者测试报告的措辞有问题，或者复盘的形式有问题，让大家有了抵触情绪，统一战线这个事情做得不好。我的本意是找到问题，解决能解决的，优化能优化的，同时让领导看到不能解决的。实际情况是确实有部分已经解决和优化了，但被人当众指出问题可能确实大家有情绪，觉得测试在开批斗大会

测试自身的问题呢，现在确实有些解决方案，比如在领导的支持下，有些样式或文案的，没有功能逻辑的需求免测。其他的功能测试本身也没什么好的办法优化效率，排除没有发现的摸鱼情况之外，也就只有堆人和加班两条路了

你提醒的有道理，其实我之前也有想过，事情的起因是领导觉得测试测的慢，对测试的工作有疑问。那么优先应该解决的是这个问题，我之前的想法是空口无凭，出具测试报告，让数据说话，拿到具体问题后再向领导汇报。但目前看确实不如直接沟通，私下沟通如果能争取到领导的理解，那当然是最好的。

昨天有人私聊我质疑测试报告的客观公正性，所以发帖看大家有没有好的方案，向前辈们取取经
再次感谢你的回复 ^{_^}

之前的报告确实是只陈述的，或者说只找测试自己的问题，将问题局限于我能推动解决的范围。。
我们现在就是写测试日志，将每天的主要工作和卡点写出来，中间难免提到需求变动，环境阻塞等具体问题
但是这样的记录，也会让产品和开发觉得测试小题大做，因为测试环节不稳定基本是所有敏捷迭代都有的问题，即使找出来，也不太可能解决

今天试了一下，好像没办法做到用例和代码分离。
响应模板只能写在代码里，如果写在 DB 里，读出来之后是字符串，执行会报错
甚至不能将字符串转换为字典，，
楼主有什么解决办法么

最近静极思动，持续关注，mark 一个先

受教了，那是不是也可以这么理解，如果在稍有名气的企业，达不到见识、认知、流程、规范的提升，那么大厂的作用也就是在筛选简历的时候稍微加点分，对自己的帮助是很有限的

意思是我现在这个算中厂吗？我试过想让组里的做事习惯改变，更遵循流程，但是困难重重。。并不是每个人都愿意改变做事习惯的

即使是大厂的比较坑的项目组吗，我目前这个组没有测试流程，一切沟通靠口头，想换一家。。。

这样看的话，大厂出来就是向小公司兼容，那小厂投大厂，会有难度的上升吗

自己投希望很小吗