一个建议：只陈述不评价
一个想法：不去做所谓的统计分析报告，将一个测试周期内的工作日志发出来看，粒度达到半小时，大家一起来看看测试在测试阶段都做了什么、遇到了什么，让观众去自己去思考测试阶段的问题情况吧
留白是种美德，如果他们很蠢，那就留的浅点

楼主说的这种情况，其实还是很常见的。

不过楼主的思维有点陷入了 “为测试慢找阻塞进度的原因” 这样的方向了，这个其实很危险。因为这个方向找下去，会发现找到越来越多其他人的问题（因为别人才会 “卡” 住你，你自己怎么可能卡住你自己呢？），而这些问题其实都是很难解决的，它的处理超出楼主自己管理范围。同时，在领导参加的周会上直接说其他团队没做好影响到测试效率，不知道楼主有没有提前把这些复盘内容提前和兄弟团队的 leader 沟通？如果没有，那相当于背刺兄弟团队，这个很危险。。。

我说下如果是我，可能会怎么做，仅供参考：

1、先了解下从领导的角度，为何会觉得测试慢，领导觉得应该是多久，为什么，然后说明下实际情况和领导想的理想情况差异是什么，针对这个差距自己目前在进行的优化计划是什么，让领导对这个问题有清晰且全面的了解。这时候如果领导能理解认同，就没必要花时间精力搞报告了，因为首要目标是扭转领导的这个印象，避免领导觉得测试单方面拖后腿。

2、如果领导不认可，或者要求需要报告证明，那就出报告。但在给领导前，会私底下先和兄弟团队聊，让兄弟团队了解自己难处，也了解兄弟团队的难处，两边一起合计怎么一起优化这个事情（甚至借汇报机会找领导帮忙解决，比如需求太多人手不足的问题，核心是要让兄弟团队感受到是同一战线的），再写进报告里。这样周会上汇报，兄弟团队也可以立即接上这个问题已经在优化中。

另外，楼主上面说的都是其他团队的问题，不知道有没有总结测试自身的问题？建议先集中精力优化自己掌控范围内的问题，产生成效。比如 “目前只能一个人负责一个需求的测试工作” ，这里其实本身就有问题。需求是有轻重缓急之分的，不能一人一个。关键需求（直白点说就是领导都很关注的需求）就优先集中资源优先完成，非关键需求可以按正常排资源测试，或者风险不大的，让开发演示场景测试结果后直接上线（类似免测）。

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

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

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

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

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

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

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

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

仅供参考：

1. 先摸清领导时间进度的需求，与他达成需求一致，这是大前提。过程包括面谈、会议等。如果达不成不一致，事先摆数据，讲事实说服领导。时间进度一定要把正常测试和遇到问题后的测试分开说。
2. 测试基础设施建设。比如造数平台、自动冒烟测试、自动回归测试等。缩短自身测试周期。
3. 改变项目管理方式。看你回复，应该是用了敏捷，但感觉是假敏捷（如果没有用，可以考虑引进下）~计划会上各方预估的时间没有统一。
4. 如果以上都弄了还是慢，那就是资源限制了。加钱加人。

其实吧，有时候测试的慢，新人太多也是一个原因。。。

哈哈，客气拉。这些其实都是很常见的问题，基本都有经历过，相互交流。

其他的功能测试本身也没什么好的办法优化效率，排除没有发现的摸鱼情况之外，也就只有堆人和加班两条路了

这个不知道你是否有深入去分析过？说实话，要缩短测试周期，从你作为测试团队 leader 的位置来说，最有效的手段还是想办法缩短测试自己花费的耗时，因为只有这个范围内的事情你是有比较强掌控能力的。方式包括我前面提到的优先投入到高优先级需求、分析现在测试排期是否合理有没有优化空间、用到的一些测试方法是否是最高效的等。功能测试提高效率的方法很多，写造数脚本缩短造数时间、根据实际质量要求情况舍弃部分操作成本很高的异常场景用例等，你说的这种不涉及逻辑的调整直接免测也是一种。

其次是控制你的准入，比如前面提到的提测质量，这个关守好，也可以减少很多非常影响测试进度的阻塞类问题。不过这个涉及和开发的协作，相对不如上面说的把控性强。

另外，这些非测试内部引起的阻塞测试进度的问题，实际占据测试周期中多少时间，可以大概统计下。在 15% 内应该都算正常，超出的话看下最慢的是哪类问题，让下面的同学再出现的话多久没解决直接上升给你去推动。

其实是一个 “尽快开始测试” 和 “优先结束测试” 的抉择。但不管是优先结束，还是优先进入，都不会缩短项目整体的周期，只是让测试开始到测试结束看起来变短了。

额，这个倒不是优先进入还是优先结束的问题，而是办事方法的问题。测试资源大部分情况下是稀缺的（相比开发资源），有限的时间内只能做有限的事情，那最好是做优先级高的。领导关注的、对业务影响比较大的，也主要是优先级高的事情，优先级不高的，一般引不起关注（领导的时间精力也很有限），就算产品找过来，说明是由于资源优先给了高优先级需求，一般也说得过去。况且这里面也有一些其实就算出问题也风险不大的，评估改动范围后直接让开发自测 + 产品验收也并不是不可以，这样总工作量也有所减少。

同时产品内部也有竞争，同时进行的关键需求也不在少数

不知道你们现在开发测试比大概多少，但如果测试人员数量真的连关键需求都 cover 不住，那就想办法找领导加人吧。

可以跟组内成员一起聊一下，毕竟他们才是需求的测试者，

搞不太懂，你为啥会遇到这个问题，每个需求都不排期吗？排期了就按排期时间来啊，排不进去的需求那就是排不进去，没时间测试还非要接需求，导致上线质量又差或需求上线延期，那不是自己费力不讨好吗？

提测质量和开发达成一致，不符合就打回，另外排期排合理点，能解释出测试排期具体为撒排这个时长的

领导认为开发需要为质量负责，需要加强开发自测，因此交到测试手上应该是完成度比较高
------领导都这样认为了，那就提高转测要求，开发自测用例充分一点，冒烟测试严格一些，不通过的直接驳回，尽量给测试执行时减少一些阻塞性 bug 产生；

问题归根结底是排期和意识问题，测试本身没有推动能力，下个迭代依然如此
------说明 问题未得到及时解决，逐步往上层反应，直到彻底解决，不然下个迭代依然如此，就还是会反反复复遇到这问题；

开需求会时提出，安排好版本更新内容，临近上线时间点，就延迟更新时间（如果不延迟时间，直接说出事自己不背锅）。要出新功能能，就早点吹研发给自己东西，早点跑，早发现。不然一直拖这不给东西，最后测试时间都没有了