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