《敏捷软件开发：用户故事实战》—可测试的

可测试的

故事必须是可测试的。成功通过测试可以证明一个故事已经成功地开发完成。如果故事无法被测试的话，开发人员如何知道他们何时已经完成了编码？

不可测试的故事通常出现在非功能需求中，这些需求是关于系统的需求，但不是直接关于功能的。

例如，考虑如下非功能性故事。

l   用户必须感觉软件易于使用。

l   任何界面的出现都不要让用户等太久。

可见，这些故事是不可测试的。只要有可能，测试应该是自动化的。这意味着要努力实现99%的自动化，而不是10%。能自动化的测试几乎总是比你想象的更多。当一个产品被增量地开发时，事情可能会很快发生变化，昨天工作的代码可能在今天就会停止正常工作，这时候你需要自动化测试来尽快发现问题所在。

总有一小部分测试不能实现真正的自动化。例如，一个用户故事说“一个新用户能够在没有培训的情况下完成普通的工作流”，这个可以进行测试，但不能实现自动化。测试这个故事可能需要一个人为因素专家设计一个测试，这个测试包括对一个典型的新手用户的随机样本的观察。这种类型的测试既耗时又昂贵，但这个故事是可测试的，而且可能适合某些产品。

“任何界面的出现都不要让用户等太久。”这样的故事是不可测试的，因为它说“都不要”，而且它没有定义“等待时间”到底是多长时间，证明从未发生的事情是不可能的。一个更简单、更合理的目标，就是证明某些事情很少发生。这个故事本来可以写成，“在95%的情况下，新的界面在2秒钟之内出现。” 甚至可以编写一个自动化测试来验证这一点。