我有一个遗留系统来处理每秒都在变化的极其复杂的数据。系统的模块化非常差，因此我无法将业务逻辑拆分为更小的模块以简化功能测试。
实际的测试系统是：“闭上你的眼睛点击并祈祷”，这是完全不可接受的。我想对我们对代码所做的更改充满信心。
有哪些测试良好做法，圣经阅读，操作变更，以增加对此类系统的信心。
问题不在于单元测试，系统不是为此而设计的，它需要花费太多时间来解耦，模拟和存根所有的依赖关系，最重要的是，我们遗憾地没有时间和预算那。我不想就功能测试进行哲学辩论：我想要在现实生活中发挥作用的事实。
答案 0 :(得分：3)
听起来你在试验方面有一个黑盒子。
http://en.wikipedia.org/wiki/Black-box_testing
简单地说，这很糟糕，但如果你不能以任何方式隔离系统，你可以做的就是所有。
您需要将已知数据插入系统并将结果与已知输出进行比较。 你真的需要已知的数据和输出
正常值 - 正常数据 - 你会发现它至少可以做正确的事情
错误的值 - 拼写错误，无效值 - 所以你知道它会告诉你输入是否是垃圾
超出范围 - -1对有符号整数，值大于27亿（假设为32位），依此类推 - 所以你知道它不会因严重错误输入或损坏的数据而崩溃
危险 - 输入会破坏SQL，模拟SQL注入
最后确保所有错误都被小心处理，而不是记录，并且坏/腐败/空值通过系统传递。
您可以隔离并测试这种方式的任何进程都会使调试变得更容易，因为黑盒测试无法告诉您错误发生的位置。这意味着您需要根据发生的事情来诊断错误，更多的是House MD风格而不是正常的调试会话。
如果您拥有上面列出的不同数据类型，则可以使用它们单独测试所有更改，然后在整个系统中测试。随着时间的推移，您最终会触及系统的大部分方面，您将拥有所有区域的测试用例，并能够更轻松地说出最有可能发生故障的位置。
另外：确保将示踪剂放在已知数据中，这样当您测试模块的范围限制时，您不会意外地指示股市崩盘，因此您可以在结束之前将其从结果流中取出在CEO的桌子上。
我希望这是一些帮助
答案 1 :(得分：0)