在制定测试策略时，一个常见的错误是，不从金字塔的底层开始测试。比如跳过单元测试，甚至后台服务测试，就直接创建和执行界面测试。用界面测试去测软件的所有部分（应用程序，中间件，底层架构），这本身是个很酷的点子，但是也要考虑到它的劣势。过分强调界面测试自动化，会带来以下问题：

• 需要很长的时间获得反馈结果，尤其是在解决bug的过程中

• Bug定性会更加困难

• 由于某些单元未被测试覆盖，导致应用程序的整体品质受损

• 于设计无益。测试应当有助于提升软件设计

Note

有时我们要区别‘测试’和‘检查’。Michael Bolton认为‘检查’限于‘观察’，无需智慧和脑力，只要按规矩执行。如果需要脑力工作，那就是‘测试’，而不是‘检查’。（参见http://www.developsense.com/blog/2009/09/elements-of-testing-and-checking/）

另一个常见错误是，只测应用层的代码。界面测试的好处是，可以跨应用层，中间件和底层，调用整个架构的代码。那么应该如何处理单元测试和后台服务测试呢？不要仅仅将思考停留在应用层。

• 验收标准

使用敏捷开发流程（如Scrum）时，对未完成的产品项设定有效的验收标准尤为重要。验收标准定义了Story需要满足何种条件才能标记为‘已完成’状态。有效的验收标准规定了你何时结束。据Ken Schwaber和Jeff Sutherland所言，“The backlog is an ordered list of everything that might be needed in the product and is the single so-urce of requirements for any changes to be made to the product.”关于如何处理待办事项的一般建议，参见Mitch Lacey《The Scrum Field Guide》一书第29章。在本书第10章有更多验收测试的讨论。

测试，是待办事项中关键的一部分。通过定义测试用例以确定story的可测试性，这应当是你经常要去做的。在评估一个User Story时，也应该评估它相应的测试工作量。