工作中，常常碰到同一个需求来回反复的测试，出了一轮一轮的报告
这里有什么原因呢？
1. 用户反馈这里性能有问题了，项目准备跟进。好的，拉上测试来看看，这个问题有多严重
2.测试开始测试，验证，给出完整的量化数据 （这里会有一轮的测试，根据事件的大小，会耗费1天到1周的人力）
3.开发同学优化，然后搞了一个方案，让测试同学看看，再验证一轮（又会耗费一轮的人力），每一次方案的偿试都要求验证一轮
4. 优化好了以后，最后的汇总报告，再验证一轮
在测试资源无限，不用白不用的情况下，或是啥事都要汇报与量化的情况下的确是要多轮的验证的。 这里有优化的空间么？
今天把这个问题与同事讨论了，同事说，如果测试资源被项目中多个团队争抢的情况下，那就找接口的PM来分配与处理。 但后来细想了下这个方案貌似与接口PM的角色定位有关。这个PM如果只是把这个事排下来的话，就会拉起多方的会议“来吧，你们讨论出一个结论吧”
排个期，其实可以得出一个清晰的结论，就是你们要用测试资源的人，像分配财产一样，你用1，3，5我用2，4，6 。 界限是很清晰。但有一点是模糊的，那就是开发与测试并没有一起来想，如何更高效的做完这个事。反正都排下来了，反正测试就是资源，快快的做完了还有变的事。
有没有一种可能，就是：用户反馈有问题了，是否可以通过一个感受，就可以拍板要不要优化。 直接优化完了以后，快速的通过感官的验证就可以出初步的结论。然后只要一轮的测试验证就成，或是直接外网打点上报验证？ 这种可能不做的原因是？ 老板要看数据？ 是这样么？
貌似也不是这样，我们的报告里说，内存占用多了3%，这样的数据老板看了有感么？ 或许真的没有。那这个时候，要把测试团队卷入进来，测试出一个报告说明优化效果是为了什么？ 是为了责任分担？
或许是这样，测试报告就是用来证明我们的优化效果的
所以，我们要的是一个模糊的结论，来清晰的告诉老板们，这里用户反馈的性能问题解决了
嗯，是这样的，那要怎么做呢？
录一个视频，把同样机型，同样的场景，同样的操作，放在视频里，一个是优化前，一个是优化后
这样的测试不用一周，不用一天，只要1小时。。。
