移动测试基础 迭代包测试范围应该包括哪些
由于 RD 人员较少，项目周期偏长。在第一轮正式提测前会出 1 或 2 个迭代包，对于迭代包得测试有些疑问：
- 迭代包测试覆盖的用例应该包括哪些？所有还是优先级较高的用例？
- 迭代包一般测多久？
- 迭代包得测试时间要算到最后总的测试时间内么？
- 迭代包产生的 bug 要在正式提测时才验证么？
首先要明白这个迭代包测试主要目的
相当于送测检验，防止在第一轮正式测试时出现主要业务功能没有实现或程序严重崩溃、服务器死机等，进而影响测试过程，甚至造成测试过程中止
1.迭代包测试覆盖的用例应该包括哪些？所有还是优先级较高的用例？
测试用例覆盖根据迭代安排的时间、测试具体对象的特点而定。一般来说，只要覆盖主要功能、主要业务流程即可，在时间范围允许的条件下可以走一遍所有流程。建议在迭代包测试时，加一个随机测试（一般在随机测试过程中会发现很多不合常理的崩溃）
2.迭代包一般测多久？
测试时间不用太长，根据项目工作量大小（如业务功能覆盖）、项目工期安排、测试人员数量等情况，合理安排时间。例如我们完全测试一个 APP 用 2 人 *15 工作日，迭代包测试的时间控制在 2 人 *3 工作日内。
需要指出的是，迭代测试中如发现严重或较严重的 BUG，开发进行修复的时间可能比较长，可能会影响计划的第一轮测试。
3.迭代包得测试时间要算到最后总的测试时间内么？
迭代包测试是整个测试过程的一部分，是要算到总测试时间内的
4.迭代包产生的 bug 要在正式提测时才验证么？
根据迭代测试的目的，建议严重、较严重的 BUG 一定要及时提交反馈给开发，由开发进行修复。修复后再出新的测试版本进行第一轮测试。建议或不太重要的缺陷可以等到正式提测时再提交给开发。
@lifreshman 这个我不太清楚，我们公司较小，没有这样试过。你可以自己先思考思考，有思路了跟项目负责人沟通沟通，看看这样是不是更有效。PS：我不是帅哥啊，是女生。
如果功能模块相对独立，是否可以先出一个包只包括这个模块功能，过一遍这个模块所有用例
这个如果模块真的很独立，并且后续改动不涉及这块逻辑的话，是可以的。但还是要在下一版本提测时进行必要的回归，回归粒度至少覆盖主功能逻辑和用户场景。前提是不打乱现有的项目节奏。
第一轮测试时候根据 rd 合并代码时候的冲突情况，如果冲突较少就简单回归一下
RD 代码合并冲突和修改范围并不是相等的关系，有可能方法有新增（A 状态）、更新（U 状态）但却没有冲突（C 状态）。如果想精确回归范围，可以找 RD 要修改的 diff 列表。根据 diff 范围就可以刨除未经修改的独立的功能，减少回归测试量。
仅供参考