功能测试用例与回归测试用例的区分及应用疑问

核心逻辑：不是互斥，是角色复用 #

功能测试用例的目标是验证新开发的功能是否完全符合需求，而回归测试用例的目标是确保新增/修改代码不会破坏已上线的现有功能。二者不是完全独立的集合——大部分成熟的功能用例，在功能验证通过后，都会被纳入回归测试套件，成为后续迭代的回归用例。

针对你的场景逐一解答 #

1. Sprint 1的对账功能：回归用例需要加什么？

你在Sprint 1中写的4个对账场景功能用例，本身就是回归用例的核心内容，不需要额外再写新的。

举个具体例子，假设你的4个功能场景是：

• 场景1：两个数据集完全匹配，对账结果显示「无差异」
• 场景2：数据集A多1条数据，对账结果准确标记差异
• 场景3：数据集B某字段值错误，对账结果定位到具体差异
• 场景4：空数据集对账，显示「无数据可对账」

这些用例在Sprint 1完成功能验证后，就会被加入回归测试库。后续任何代码变更（比如Sprint 2加新功能、修复bug），都需要重新运行这些用例，确保对账的核心逻辑没被破坏。

2. Sprint 2加新功能后，为什么还要跑回归？

假设Sprint 2给对账功能新增了「导出对账结果为Excel」的需求，你写了针对导出功能的功能用例（比如验证导出格式、差异标记是否正确）。但开发在实现导出功能时，可能会修改对账模块的核心代码（比如调用了对账结果的生成函数、修改了数据结构），这就有可能意外破坏原来的对账逻辑。

比如开发修改代码后，原本场景2的「A多1条数据」的对账结果，可能变成了「无差异」——这种问题只跑新的功能用例是发现不了的，必须通过回归测试（也就是跑Sprint 1的4个用例）才能验证原有功能是否正常。

3. Sprint 1的功能用例成为Sprint 2的回归用例，这个说法正确吗？

完全正确，但有个补充：不需要把所有功能用例都加入回归套件，只需要选择核心场景、高频使用场景、易受代码变更影响的场景。

比如Sprint 1中如果有一个极端场景（比如数据集包含100万条数据的对账），这种场景测试成本高、发生概率低，就不需要每次回归都跑；但前面提到的4个核心场景，必须纳入回归，确保基础功能稳定。

另外，回归测试用例还会包含之前修复过的bug的验证用例——比如Sprint 1中曾修复过「空数据集对账崩溃」的bug，对应的验证用例也要加入回归套件，避免后续迭代再次出现这个问题。

内容的提问来源于stack exchange，提问作者nayak0765