C# 3.0 如何处理这种情况？

在开发软件时，会进行各种类型的测试——单元测试、集成测试、功能测试、手动测试。在我当前的项目（winforms with sql server）中，有遗留代码（无测试），我们确实有很多bug。 我们正在尝试使用手动+测试（主要是集成）的组合来删除它们

但是，仍然有一些虫子可以逃脱

例如（假设情景）-如果客户在过去6个月内购买了价值一定的商品，则应在6个月后购买商品时给予折扣。他的状态应更新为特权

但是，由于某种原因（代码中的错误），系统没有这样做。我们应该如何处理这种情况？我们是否应该在数据库上运行一个脚本来查找所描述的场景？该场景的另一个扩展可能是，客户获得特权后必须发送礼物，但系统无法这样做

---

想法？

您应该有一个自动测试套件。此测试套件将实现规范要求的所有场景。因为人们不能等待六个月来测试折扣是否有效，所以实际的实现被一个实现所取代（示例是java，但相同的原则适用于其他语言），例如“模拟”6个月过去了。可以使用断言自动化测试

一旦您准备好了整个测试套件，如果所有测试都在代码重构/更改之后通过（就像之前一样），那么可以确保没有任何特性因重构而损坏

“我们是否应该在数据库上运行一个脚本来查找所描述的场景？”

---

您的意思是“在数据库中放入脚本以更正问题”，然后否

不，从来没有。在任何情况下。通过添加特殊的特例逻辑来解决bug确实是一个非常糟糕的主意

当这种特殊的特例逻辑有自己的bug时，您已经添加了bug代码来尝试纠正bug代码。净亏损

当您试图增强系统时，您会遇到这种特殊的、毫无意义的特殊情况逻辑

a。如果幸运的话，你修复了它应该解决的bug，它将是多余的。现在怎么办？要删除哪个副本

b。否则，它将与其他代码相矛盾。现在怎么办？哪个是对的

---

如果您的意思是“在数据库中放入一个脚本以帮助查找和调试问题”，那么是的。在短时间内，使用您可以使用的所有工具来查找和修复bug。一旦找到并修复，此脚本将无效，必须删除

如果您的意思是“在数据库中编写脚本来测试应用程序”，那么是的。这就是单元测试脚本的用途。使用它们

---

创建单元测试比创建放入数据库的脚本要好得多单元测试是最好的方法。

“在数据库中放置一个脚本来帮助查找和调试问题”-是的，这就是我的意思。但是，同样，这样的脚本应该没有bug（需要测试！）@junky_用户：不，它不需要没有bug。你使用它一天来发现并修复bug，然后删除它。