【请教】怎么权衡测试范围

swart2006

我负责的软件经历了一次小版本更新，涉及到的需求有 ：
A：XXX
B：XXX
C：XXX

版本发布了之后，出现漏测，在没有涉及到变更的需求D上出了bug

而且让人郁闷的是，D相对于变更点A、B、C来说，根本就风马牛不相及，不论状态流还是可能涉及到的代码，D都和A/B/C没有关系

我是真心不知道该怎么办了，各位，做小版本更新的时候，到底怎么来确定测试范围？
PS：环境和条件大家都懂的，缺人缺时间，还很可能和其他项目并行展开测试

到底该不该在小版本中对功能点进行测试范围的划分，那么怎么样才能降低漏测率呢，请各位指教！
小生拜谢了。

qinhaoying

首先，你要做一次确认测试，确认版本升级以后，以前的功能是OK的；第二，做一次上线测试，你们上线变更的部分做一次上线验证。
这是基本的，不能少了；时间充裕可做具体的回归测试。

赵佳乐SMILE

人无完人 漏测正常 我上周测第二版 发现第一版漏测了一大块功能 补测就好 第一版就测了三天 需求说明都没时间 不过我今天补看了需求说明 意义也不大

吼吼哈哈

个人见解：

先做需求变更模块的测试，优先级相对较高。。

其次，将“相邻”模块，此处相邻指功能相邻、代码相邻、业务逻辑相邻，确认测试

第三，版本回归测试。。

优先级 依次降低