如果您在构建网页时遇到问题，那么您可以做的最有帮助的事情就是开始构建一个简化的测试用例。“问题”可以是任何事情：CSS 没有按您预期的方式工作，JavaScript 行为不正常，存在跨浏览器问题等。在创建简化测试用例的过程中，您将：
- 发现这是一个您犯的错误，帮助您隔离并修复它（或者为 寻求帮助 提供一个很好的测试页面）
- 发现一个真正的错误，并为您提供一个完美的演示，以便向相关人员展示。
那么，什么是简化测试用例呢？ 简化测试用例是您创建的一个演示/示例页面，它以尽可能少的代码重现您遇到的问题。**仅**包含显示问题内容所需的 HTML。**仅**包含与该简化 HTML 相关的 CSS。**仅**包含与当前问题功能相关的 JavaScript。
简化测试用例是解决错误的绝对、毫无疑问的、首要方法。 事实上，有些人仅仅通过将错误报告转换为简化测试用例，供更有经验的开发人员探索，从而为开源项目做出贡献。以下是如何从您的问题开始创建测试用例的步骤…
1. 使其静态
如果是前端问题，请将页面设为静态，而不是从服务器动态构建（例如，如果您使用的是某种 CMS）。也就是说，查看问题页面的源代码，将其复制粘贴到新文档中，然后从那里开始您的简化测试用例。将该文档放在一个仅用于测试用例的新目录中。
2. 使其隔离
然后获取 HTML 所需的所有资源文件（CSS、图像、JavaScript 等），并将它们也放在该目录中。现在，您拥有了一个专门用于此目的的封闭式小环境。现在，您可以编辑这些资源文件和标记，而无需担心会影响任何实时内容。如果需要将测试用例传递给其他人，这也使其具有可移植性。
3. 简化，简化，再简化！
现在开始删除一些内容，定期测试以确保您的问题仍然存在。首先删除 HTML，以便页面上显示的内容减少到所需的最小程度。然后删除现在不需要的任何 CSS。然后删除与问题无关的任何 JavaScript。如果不是 JavaScript 问题，请删除所有 JavaScript（除非您认为它可能干扰问题的真正原因）。
4. 记录它
如果代码中有一些您怀疑可能是问题的部分，请在代码中添加注释。每种 Web 语言都有某种方法可以插入不影响代码的注释。
5. 将其发布到网上
如果您在本地工作，请将简化测试用例发布到网上的某个位置。我见过有人使用免费的 Dropbox 来托管一个快速示例。这将使您更容易与可能能够提供帮助的其他人共享问题。
但是我不知道问题出在哪里！他们需要看到所有内容！
您确实知道问题出在哪里。无论问题是什么，它就是它。向某人展示“所有内容”通常会让他们不知所措，并使他们难以理解。至少我个人是这样认为的。如果有人请求帮助，他们在论坛中粘贴了 1000 行 CSS 代码，我的眼睛通常会变得模糊，然后我就跳过它。但是，简化测试用例通常很有趣，并让人想要查看。
其他资源
- WebKit 关于测试用例简化的内容
- CodePen 是一个创建简化测试用例的好应用。
您是否知道关于此主题的其他好的讨论？请告诉我，我会将它们链接起来。
我同意。
虽然我通常在提交错误报告时没有处理网页，但我几乎总是会提供一段代码，用尽可能少的额外信息来重现错误。这意味着如果可能，甚至要降低与错误相关的文档的复杂性。对于基于网页的错误报告，我所做的也是一样的事情。
我还应该指出，由于使用了这种策略，我通常会收到非常有帮助的回复，而且这些回复来得很快。
绝对的。RTC 的理念超越了 Web，肯定适用于任何可能出错的事情。
绝对同意。当我在 CMS 构建中已经处于数据驱动阶段但随后遇到前端问题时，我经常这样做。如果我可以制作一个静态的示例，则更容易调试。对于 CSS 位置/尺寸问题，我喜欢在元素上使用荒谬的背景颜色，例如红色、青柠色、紫红色等。背景颜色使元素易于查看，并且不像边框那样增加其大小。如果是 JS，则 console.log() 和 alert() 是关键。
绝对同意。当我在 CMS 构建中已经处于数据驱动阶段但随后遇到前端问题时，我经常这样做。如果我可以制作一个静态的示例，则更容易调试。对于 CSS 位置/尺寸问题，我喜欢在元素上使用荒谬的背景颜色，例如红色、青柠色、紫红色等。背景颜色使元素易于查看，并且不像边框那样增加其大小。如果是 JS，则 console.log() 和 alert() 是关键。
+1
在我关注的一些论坛上，人们发布长代码示例非常普遍，但正如 WC 指出的那样，他们很少得到帮助。检查所有代码需要花费太多时间。
通常是初学者发布长代码段（甚至整个页面）。不能责怪他们，因为这可能是 DreamWeaver 生成的，他们不知道任何代码的含义。
对于初学者来说，最好这样做——通过将他们提供的代码简化为他们认为有问题的部分，他们通常会排除问题。
或者，他们会“假设”问题，以至于您甚至无法弄清楚他们的问题是什么。
如果我要帮助他们，我宁愿浏览他们的整个代码并自己找到问题。否则，这只是一个盲目的猜测。
感谢您提供的信息。几天前我遇到了一个麻烦的问题，这将非常有帮助，因为我当时眼睛都花了，试图找到问题所在！
这是一篇很棒的文章。有时，根据具体情况，如果我有一段我认为可能有点棘手的代码，我会先单独构建它并使其运行，然后再将其集成到我的项目中。根据我的经验，这有助于减少故障排除的工作量。
非常好的建议。
在遇到 CSS 浏览器问题时，我做了一些类似的事情。我会从最顶层的容器开始，并将其设置为 `display:none`。如果错误消失了，我就知道它包含在该容器中的某个地方。然后，我逐层向下，依次显示 none，直到找到真正导致问题的原因。通常情况下，我可以用 5 分钟或更少的时间来解决这些棘手的错误 :)
是的，CSS 没有按照我预期的那样工作，尤其是在 IE6 中。我使用“float:left”或“clear:both”来解决它。将代码放到 Dropbox 上线确实是一个好方法。但是，中国用户无法直接访问 Dropbox，就像 Blogger、Twitter、Facebook 一样。
很好的观点。我一直在思考如何做到这一点。
当我遇到非常复杂的编码问题时，最终，我会通过花时间将其分解成一个非常简单的 `test.html`、`test.js` 之类的东西来获得巨大的收益……并以一种非常基础、简化的方式深入到确切的问题。
我看到一些新手程序员没有做到这一点。他们迷路了……他们感到困惑。最大的问题是“不要迷失在兔子洞里”。如果你能做到这一点，你就没问题了。
代码真的非常复杂，即使你认为自己是个天才。如果你减少整体认知负荷，它就会运行得快得多。
这是解决问题的最佳方法。我完全同意。
你可以从全新的角度看待问题，甚至可以使其比最初设想的更好。
非常好的建议！我自己也做了很多年，但从未想过要分享这个技巧……
网络上缺少这种类型的建议：如何钓鱼。不要再赠送鱼了！
好建议。在论坛里发布 1000 行 CSS？吓死人了！至少 CSS 很容易。在论坛里发布 1000 行 Perl 代码可能会让我害怕，但任何想要寻求帮助查找一个错误的人都不应该发布这么多内容！
非常棒的技巧，非常感谢。
精彩的文章，感谢分享，干得好。
我也这样做！
我只是复制页面，删除不必要的代码，并给它一个明显的“测试”名称，例如 `index_test.php`，以便我知道之后要删除它。
这是极好的建议。如果有人学习编码却从未使用过这种方法，我会感到惊讶。
但我以前从未给它命名过。解释说存在问题，并且您正在使用简化的测试用例来解决问题，听起来好多了。
感谢您提供术语！
很棒的帖子。非常感谢，伙计。
这通常是许多类型的编码（不仅仅是 Web 编程）的良好建议。
这种方法的一个轻微变体是使用类似于 jsFiddle 的工具。它为您的 JavaScript、CSS 和 HTML 提供了单独的文本框。如果可以在其中重现问题，那么您可以非常轻松地进行更改和更新，并且可以与其他人共享您的 fiddle。
除了 CSS-tricks 论坛之外，还有 Stack Overflow 和 doctype 可以快速获得问题的答案……
非常棒的建议，我很少去论坛寻求帮助，但这是我们在进行后端开发工作时经常使用的一种技术。在一两行代码中发现错误比在 20 行代码中发现错误要容易得多。
感谢您提供清单！
很好，这对我有用，谢谢。