敏捷实践 大家有什么好的办法确定回归范围

aaaa微裂 · 2022年05月24日 · 最后由 ghost 回复于 2022年05月30日 · 4093 次阅读

大家有什么好的办法确定回归范围,目前自己比较常用的是看开发的文档,每次迭代都会修改接口,db,开发设计文档,会根据修改的内容,把相应的关联部分功能做回归测试
有没有其他好办法

共收到 6 条回复 时间 点赞

我们以前一般会根据自己的经验罗列一个影响范围,再找开发要一个影响范围,结合这个拉出一批测试用例。(当然这个范围是要项目组同学共同认可的,后面有其他歧义的时候再做查缺补漏)
如果要再细的话,就做代码版本 diff,但一般来讲没有这个必要,这个阶段进度就比较靠后了。

比较常规的如一楼所说,测试先划定一个,再找研发评估对齐。
引入其他依据的话,可以是基于代码调用链上下游各 N 层来评估测试范围,这个评估步骤可以是人来做,也可以做成自动化。

每次迭代都会修改 DB?
这系统设计不咋滴啊~

Thirty-Thirty 回复

有的迭代会改

如果是黑盒测试,回归范围是不能确定的。

同意一楼的回复,
我们这边把回归范围包含两部分,本身修改部分 + 受影响部分。

黑盒测试,确实只能通过需求文档和设计文档评估范围,但这个不太准确,时不时会有遗漏。

目前精准测试还在构建中,调用链路分析没搞定之前,貌似也起不了啥作用。

如果人为去 code diff 代码行,除了对测试人员代码能力要求较高以外,花费的时间估计也不少。
可能折中一下会好一些,还是以黑盒评估为主。在代码提交以后,git diff 获取修改代码的文件,根据文件判断大致涉及功能,然后反馈黑盒,确认是否有测试范围遗漏。 不过这个方法还没实践过,楼主可以参考下

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册