墨菲定律：两个功能交互，引发的一个Bug！
我经常被问到，“在你的测试生涯中，你遇到的最难忘的bug是什么？”对我来说，下面的事情是在几年前发生的一个错误。我曾领导一个支持谷歌应用引擎
制定测试计划需要考虑哪些方面！
创建测试计划通常是一项复杂的任务。理想的测试计划是通过应用成本效益分析和风险分析的基本原则，以最佳方式平衡这些软件开发因素来实现的： 实施成本
变异测试！
History 我的团队长期以来的传统是每年组织两次黑客大会（ hackathons ）。在黑客大会（ hackathons ）之前的几周，团队会收集和集思广益项目的想法，从改进测试基础设施或现有流
仅验证与其被测行为相关的方法参数!
每个测试只应该验证一个行为，这可以使测试用例更可读，更能适应变化。 下面这段测试代码为 MockUserPrompter 的所有参数指定了精确值。一旦被测试的代码发生更改，这些
测试用例太 DRY 了? 应该让它们 DAMP!
下面的测试用例遵循了 DRY 原则 (“Don’t Repeat Yourself”), 它是鼓励重用，消除重复的一个最佳实践，例如, 通过抽取 helper 函数 或 通过使用循环的方
要测试行为（Behaviors），不要测试方法(Methods）
在编写一个method()之后，只需编写一个测试，就可以轻松地验证方法的所有功能。但是如果你认为，测试用例与 公开方法（public metho
要测试 Public APIs，而不是实现细节
public API 可能被任何调用者所使用，而调用者可能会将从任意组合的参数引入到该方法中。 我们当然希望，所有的可能性都能被测试用例覆盖。 这样的话，我们就会