最近领导很关心一个问题，由于觉得目前的需求从提出到实际上线，需要经历的时间有点长，因为对效率比较关心。
又因为测试人力不太够，目前只能一个人负责一个需求的测试工作；项目节奏不好，经常会出现需求扎堆提测的情况，有需求会排不上测试。

为了回答这个问题，根据以往经验，我不完全总结了几点如下：

1. 由于行业原因，领导认为开发需要为质量负责，需要加强开发自测，因此交到测试手上应该是完成度比较高 —— 认为测试只需要做验收工作
2. 由于排期原因，开发经常在手头需求还没做完之前就接到了下一个任务，做不到充分自测，尤其不会进行基于场景的自测 —— 提测质量达到验收标准
3. 由于上述两个原因，测试其实承担了领导预期之外的工作：给开发找 BUG。修改 BUG 需要时间，还有需求增补，改动等。还有测试尾声时产品、UI 会接入验收，也算占用的测试时间。其实测试阶段并不是只有测试在工作 —— 测试时长也不完全是由测试决定
4. 测试过程中环境问题较多 —— 阻塞测试进度
5. 有些功能开发为了赶时间点提测，会选择部分提测。虽然加快了研发的效率，但是基于场景的测试需要构造数据多次，本来一次造数能测完的几个功能点，现在要重复造数很多次去测 —— 拖慢测试进度
6. 测试本身的工作，还包括分析需求，重现缺陷，初步定位问题，提单，回归验收，提出优化，参与讨论等 —— 本身并不是只需要点点点那么简单
7. 会议比较多，但又有参加的必要。在工作过程中，会有新的需求评审 —— 打乱测试节奏

口空无凭。为了能体现上述问题，向领导展示测试的工作内容，回答测试为什么测的这么慢的问题，以及发现每个迭代的问题想办法优化。
我为每个迭代出具测试报告，内容大概有：

1. 基于 tapd，统计基于 BUG 数量的各种维度的数据
2. 记录测试过程中遇到的额外情况：出现的环境问题，需求变动，打乱测试节奏的关键点等
3. 基于每个需求，写测试复盘，讲述测试难点
4. 列出具有代表性的 BUG 单

并在领导的支持下在周会上进行复盘

但是目前依然存在的问题是：

1. 由于测试报告写了本迭代出现的卡点，有指责其他环节的嫌疑，因此收到了与会开发和产品的抱怨。
2. 指出了本迭代的问题，指出了建议优化的点，但是很多问题归根结底是排期和意识问题，测试本身没有推动能力，下个迭代依然如此。并没有达到优化效率的目的
3. 测试本身的周期并没有缩短，从结果导向来看，还是测试人员做的不到位，没有快速完成测试

也就是说，这份测试报告，除了发出去得罪各方人士，并没有达到预期的效果
说了这么多，想听下各位大佬们遇到这种情况会怎么做，有没有什么好的建议