好的，所以我知道我们无法测试所有可能的场景，这是不可能的。但我想获得任何想法，以使测试更全面，并让 QA 团队在代码投入生产之前发现问题。
我们有一个相当大且非常可配置的系统，我们正在尝试用它来更新一些主要功能。问题是每次我们尝试投入生产时都会出现问题，我们会按下紧急按钮并从备份中恢复。
我们现在被问到为什么这些问题没有出现在 QA 或我们的单元测试中并且没有任何真正好的答案。
我们目前有：
我们是否只需要处理这样一个事实，即我们无法找到所有可能出错的事情，或者是否有技术使其更有可能在最终用户看到问题之前发现问题？
我会有一个完全复制现场的舞台环境。然后，当您必须回滚错误时，您还可以跟踪它并在暂存环境中修复它。
一旦你有一个完整的错误列表及其原因，你就可以努力寻找趋势并阻止它们再次发生。
当某些用户输入与测试数据不同的数据时会发生错误。
除了边界测试之外的模糊测试可能会有所帮助。实际上，任何类型的随机生成或随机变异的数据（根据您的业务规则）都可以帮助找到这些类型的错误。试图破坏系统并且不只是测试系统是否正常工作的专门测试人员通常也非常擅长发现恶意输入或恶意数据组合。
这主要是一些影响另一个领域并通过测试的变化。
最近，当周围已经有一堆针对业务逻辑的单元测试时，我主要在 UI（使用 WPF）中看到此类错误。有人更改了控件模板，而其他一些事情不再正常工作或看起来不正确。自动化的 UI 测试可以帮助解决这个问题，但创建和维护它们真的很乏味。不过，专门的测试人员可以很快找到这些东西。如果是业务逻辑失败，则创建更多单元测试并瞄准更高的覆盖率。代码契约和对数据库更严格的约束也可能有所帮助。
60% 的代码覆盖率意味着您的单元测试还有很大的改进空间。然而，提出单元测试来处理远离幸福道路的情况可能相当困难。您的单元测试永远不会测试事情在夜间发生的所有方式。
人类可以非常接近。聘请测试员。它们便宜且具有令人难以置信的成本效益。一个好的测试人员会模拟两个关键行为：
让测试人员与正在开发的产品一起工作，您在发布时不会遇到这么多有趣的问题。
“我们可以让几个内部人员在质量检查上花费数小时”
这几个人是专业的 QAers/testers 吗？或者只是有几个小时空闲时间的人？
设计和开发主要功能的更新需要多长时间？也许您需要“天”或“周”而不是“质量保证时间”？
您是否对您看到的任何问题进行了根本原因分析？如果您真的不知道原因，就很难确定解决方案。