@lifreshman 这个我不太清楚，我们公司较小，没有这样试过。你可以自己先思考思考，有思路了跟项目负责人沟通沟通，看看这样是不是更有效。PS：我不是帅哥啊，是女生。

首先要明白这个迭代包测试主要目的

相当于送测检验，防止在第一轮正式测试时出现主要业务功能没有实现或程序严重崩溃、服务器死机等，进而影响测试过程，甚至造成测试过程中止

1.迭代包测试覆盖的用例应该包括哪些？所有还是优先级较高的用例？

测试用例覆盖根据迭代安排的时间、测试具体对象的特点而定。一般来说，只要覆盖主要功能、主要业务流程即可，在时间范围允许的条件下可以走一遍所有流程。建议在迭代包测试时，加一个随机测试（一般在随机测试过程中会发现很多不合常理的崩溃）

2.迭代包一般测多久？

测试时间不用太长，根据项目工作量大小（如业务功能覆盖）、项目工期安排、测试人员数量等情况，合理安排时间。例如我们完全测试一个 APP 用 2 人 *15 工作日，迭代包测试的时间控制在 2 人 *3 工作日内。
需要指出的是，迭代测试中如发现严重或较严重的 BUG，开发进行修复的时间可能比较长，可能会影响计划的第一轮测试。

3.迭代包得测试时间要算到最后总的测试时间内么？

迭代包测试是整个测试过程的一部分，是要算到总测试时间内的

4.迭代包产生的 bug 要在正式提测时才验证么？

根据迭代测试的目的，建议严重、较严重的 BUG 一定要及时提交反馈给开发，由开发进行修复。修复后再出新的测试版本进行第一轮测试。建议或不太重要的缺陷可以等到正式提测时再提交给开发。