我们项目目前处于功能测试阶段，对于开发改 BUG 后的测试环境构建频率，有两种想法。
一种是：一天三个时段构建三次，每次更新一些开发修复的 BUG。
另一种：测试从头到尾测上一轮（比如完全的执行该模块的用例，如果没有阻塞的话），时间上可能是二至三天，
构建一次。
第一种优点：明显是快速进行 Bug 复测，验 Bug 不墨迹
第一种缺点：经常构建稍微有些耽误测试时间
第二种优点：用例可以从头跑到尾
第二种缺点：整体要执行用例轮数较多，因为每次对于一块功能的测试
总结：两种差不太多，每种都有各自的特点
大家进行功能测试时测试环境的构建频率是怎么样的呢？
我们是开发改好直接就打包
你这两个方式都太极端了，测试应该分成几个阶段来进行：
第一阶段：新项目刚提测阶段，这个阶段应该先测试流程性的功能，严重问题先改，不严重的且不影响流程的先跳过，控制提 bug 的数量，尽快修复；
第二阶段：所有的功能从头到尾测试一遍，这个步骤应该要重复几次，等系统较稳定后进入第三阶段
第三阶段：这个阶段 bug 较少，流程相对稳定，这个时候以修复 bug 为主，可以频繁迭代，甚至可以增量更新，模块化测试。
2 楼的建议不错的，但可能不太适合敏捷开发。实际上构建的频率没有统一标准的。一般 block 流程的 bug，在修复以后肯定是要赶紧部署的。非阻塞流程的 bug（小小的交互问题，UI 问题，精度问题，数值错误），你慢点部署慢点验都是 ok 的。但如果数据本身严重影响到下一步的正确性。那在有 bug 的情况下，测了也是浪费资源的一种行为。综上所述，并没有硬性指标规定部署频率和时间，而是根据测试实际情况做调整的。
看项目大小呗，团队人多的话，就按第二种照流程走；
小团队的话，三五个人这种，提测之后，测一天大概就 20/30 个 bug 了，后面的研发上午改好一版，下午接着改测试上午测的呗；
事无绝对，找到适合团队的节奏就行。