我觉得 2 种方案都没问题，如果第一种里面设计的 case 是完善且合理的，那使用哪种方法不重要。（第二种其实就是冒烟 + 测试用例执行，说白了，如果你的冒烟用例选的不好，那这个策略就谈不上好了，她比较依赖测试人员本身的 “鉴赏” 能力），如果第一种方法里面设计的 case 本身不完美，但在执行过程中你又找到了好的测试点，那完全可以补充进来放到第二步里面去执行。还有就是第一步发现的 bug，分析一下影响范围，适当的筛选第二步的 case，节省时间。那如果都做不到，就只能按照你说的第一种方案（再找个高手做用例评审，适当规避问题），一个脚印一个脚印来了。

观点：测试应该更早的介入到项目当中
1.第一种方式在我看来已经不适合目前大多项目迭代的速度
2.第二种方式在我看来用例的维护量是一个不小的常态
建议：
1.根据目前项目迭代速度和团队的大小，量化工作量，制定好测试方案和测试计划
2.设计测试用例时候，提高用例的覆盖率
3.将用例维护成一个高复用的用例库，降低重复用例编写的工作量，根据阶段选择用例进行执行
共勉，期待大佬观点