今天，当我找到一种方法来破坏我们程序中的某些功能时，我正在为客户做一些事情。
（代码实际上是遗留代码，它已经开发了大约 10 年，而我在这里只工作了大约一年。）
它不会导致错误或导致程序崩溃，但如果用户正在使用该程序并重复该行为，我很确定他们会举起他们的“WTF？” 旗帜。
在我们的程序中，我们命名了可以与文本框链接的字段（文本框）和静态文本（标签）。当文本框未填写时，链接到它们的标签会消失。
我破坏的功能是，当您更改已经有一个或多个标签链接的文本框的名称并保存文件时，无需重新关联与文本框关联的一个或多个标签，以前关联的标签当文本框为空白时出现。
现在我对此事的想法是，一个简单的观察者模式本来可以解决这个问题，但后来我没有编写代码。
我在想，如果我能和我店里的人一起挖掘更多这样的情况，也许我可以说服他们考虑单元测试、解耦、在需要的地方应用模式等等。
因此，出于这个原因，我想知道是否有人有任何提示可以在任何类型的应用程序（基于 Web、桌面等）中找到损坏（但不会导致错误）功能
对于一个应用程序可用性失败，它必须有一组定义的预期行为。
“当按下回车键时，这个文本框是否应该什么都不做？” 也许是，也许不是。我见过一些应用程序，其中测试人员/审阅者报告了他们认为应该以另一种方式工作的东西，而实际上客户特别要求他们不希望在返回键按下时提交表单，而只希望单击提交按钮。
所以基本上你必须先定义正确的行为，然后才能确定不正确的行为。
如果它有一个界面，那么我最喜欢的非常规测试之一就是将 5-10 岁的孩子放在它面前。你会惊讶他们能想出什么（尤其是年轻人）。虽然这听起来像是一个笑话，但事实并非如此——它确实有效，因为孩子们没有只通过“心态”路径的心态。
是的，孩子们是“破坏事物”xP 的专家。
代码检查，即阅读源代码：如果您花时间阅读/检查源代码，寻找“气味”，甚至只是寻找您没有立即理解和同意的行为的代码，您可能一直持有提高你的“WTF？” 旗也。
测试，测试，测试。
做意想不到的事情。开始执行一项任务并切换另一项任务，看看是否有任何问题。不应该使用后退按钮。在两个窗口中打开它。让它超时。
在所有浏览器中测试，尤其是 IE。
您可以发现数据库连接/会话不是由以下人员发布的：
我曾经在一家程序员经常忘记取消分配数据库连接的公司工作。标准答案是将资源减少到最低限度，以查看是否存在泄漏 - 并尝试通过重新启动系统并重复运行不同的场景来确定它在哪里。
代码审查的第一个小时，与第一个审查者一起，将尽最大努力发现质量问题。但事情是这样的：你不需要说服人们相信质量问题。你需要让他们相信修复错误的价值，并且只有在目前的质量绝对证明它是合理的时候才重写。
我曾经处理过一些非常糟糕的代码。但你不能只是重写。在您甚至可以判断重写是否是一种改进之前，您需要一个规范。
有时，您必须从代码中推断出规范，然后在某处与某个人进行检查。但是当你这样做的时候，你已经理解了编写的代码，并且现在准备好修复而不是重写——大多数时候。
修复通过一个小的行为保持修改过程进行，这些修改使代码中的规范更加清晰。然后，当你发现一些看起来不对的东西时，你不只是改变它。您四处询问，直到找到负责该决定的人，然后让他们向您展示规范中的哪个地方说行为 X 是正确的。（这个对话可以有多种形式。）如果你很幸运，他们会告诉你行为 X 实际上是不正确的，然后你就得到了报酬。
这是 Visual Studio IDE 特有的，尽管它可能也适用于其他人：
在测试期间，总是在调试器中运行“抛出异常时中断”打开的某个时间点。
这通常可以帮助暴露错误地被静默捕获并代表错误的异常，否则可能不明显。
代码审查还应始终包括对单元测试代码的审查。
问题是，通过临时测试，不可能知道开发人员测试了他们的代码多少或有多好。因此，您受制于不同开发人员对“完成”一词的定义。
如果您在审查生产代码的同时包含对单元测试代码的审查，您应该对代码是否真正完整有一个很好的了解；在那个“完整”包括“测试”。不只是“嘿，我会把它扔到墙上给测试人员！ ”。
assert() 也是带有覆盖分析的单元测试。