当我使测试自动化时，我经常以一些小而有意义的方式使测试出错，然后运行它并期望它会失败。例如：

• 如果系统应该在“生命意义”字段中显示“42”，我将更改测试以断言它显示“43”。
• 如果系统应该仅在当前用户是“Ford Prefect”时显示“42”，我将更改测试以以“Zaphod Beeblebrox”登录。
• 如果系统应该仅在福特访问“宇宙尽头的餐厅”页面后才显示“42”，我将更改测试以省略“访问餐厅...”步骤。

我会一次做其中之一。我会让测试出错，运行它，并注意它是否仍然通过。如果测试现在失败，并且可以将失败解释为我的更改，我会得出结论，原始测试正确地处理了该细节，并将其更改回来。

如果测试仍然通过，说明我修改的细节没有达到我想要的效果，所以我需要做一些调试。

如果测试失败，但失败并不能明确归因于我破坏测试的方式，我需要进行一些调试。

一旦我以这些方式测试了测试，并且一旦系统通过了测试，我就会认为测试是相当可靠的，直到我发现有理由怀疑它（例如测试报告失败，这可能表明存在问题测试或系统；或者当我有理由相信系统或其环境已损坏时，测试报告成功）。

我想你是在问你是否需要元测试（自动或其他）。当然，你怎么知道元测试是正确的？这是大多数开发人员的做法：如果觉得某件事有风险，他们会进行测试；否则他们相信他们的代码是正确的。如果他们信任的东西被证明有错误，他们会尝试重新校准他们的判断。你应该做同样的事情。

就个人而言，我不会费心去模拟 HTML。如果您有一个可以修改的站点，您可以尝试引入错误以查看您的测试是否找到它们。当然，你要引入逼真的 bug，要确定哪些 bug 是现实的可能并不容易。

编辑

我们进行测试是为了降低风险，但过度测试可能是无效的，甚至是破坏性的。如果您选择编写自动化测试，您将受到与开发人员相同的决定。大多数开发人员不会选择测试每一行代码。这是一件好事。每一行自动化测试都需要额外的开发工作和额外的持续维护，并且不一定会发现更多的错误。

对于决定何时测试和何时不测试，没有硬性规定。决定取决于您自己的经验、您作为开发人员的信心、您对主题的熟悉程度、您对所依赖的代码的信心、产品的成熟度以及其他因素。 与其寻找一成不变的规则来教条地遵循，不如尝试一些感觉正确的事情，诚实地关注你的结果，并相应地重新校准。

这是您可以尝试的经验法则。如果测试某些东西需要付出巨大的努力，请质疑您的假设。你可能试图以错误的方式测试它，或者你试图测试的东西可能比它需要的更复杂，或者你甚至可能认为它出错的风险并不能证明测试它的成本是合理的。

• “我可以很容易地测试测试通过的场景”，我的经验恰恰相反。以一个测试为例，其中返回值在开始时被初始化为“通过”（非常糟糕的做法），并且测试代码中的错误在实际测试之前将其发送到测试结束。
• 我们通常会为实用功能等核心服务添加一组单元测试。

您还可以采用突变构建方法：在生成构建时插入错误并查看您的覆盖范围是否找到其中任何一个。数字越高，您的覆盖范围就越好，至少从理论上讲:)。