评价蛋糕是否熟了没，每个人都有自己不同的测试方法与标准，有人尝一下，有人用牙签插入蛋糕拔出来是否牙签干净。
提供故事是否完成的标准。
在写代码之前测试：
提前写测试有助于帮助程序员开发系统。
在什么时候编写测试：
1.开发人员和客户讨论故事记录明确细节的时候。
2.在迭代开始时，在写代码前作为一项专门的任务。
3.在开发中之后的任何时候发现新的测试时。
客户在写故事测试的时候：
1.关于这个故事，程序员还需要知道什么？
2.对于这个故事，我们的想法是什么？
3.有没有一些特殊情况会使这个故事有不一样的行为？
4.这个故事在什么情况下出错。
客户定义测试：
既然软件是用来实现用户的愿景，验收测试当然应该由客户来定义。
测试试过程的一部分：
1.测试人员根据程序员的描述去测试软件这是错的，应该站在用户的角度。让开发者测试是不可取的。
2.测试是开发过程的一部分，而不是在编码完成后做的事情，这点使用用户故事尤为关键。
多少测试才算多？
1.只要觉得测试还在为故事增加价值和使它更清晰，客户就应该写测试。
集成测试框架
测试类型
1.用户交互测试，确保所有用户交互组建如期工作。
2.可用性测试，确保程序好用。
3.性能测试，测试应用程序在各种负荷下的工作情况。
4.压力测试，使应用程序在用户和事务的极限值情况下或其他任何让应用程序在压力下的情况运行。
小结：
1.验收测试可以用来记录客户和开发人员讨论的很多细节。
2.验收测试可能记录了有关故事的一些假设，这些假设可能还没有和开发人员讨论过。
3.验收测试提供了检查故事是否被完整实现的基本标准。
4.验收测试应由客户来写而不是开发人员。
5.验收测试应在程序员写代码之前就写好。
6.如果新的测试对阐明故事的细节或意图没有帮助，就不需要写。
7.FIT和FitNesse是写验收测试的优秀工具，他们用的是我们熟悉的表格或电子表格。
开发人员职责：
1.若团队觉得需要，则负责实现自动化验收测试。 ？？？
2.开始开发一个新的故事时，负责考虑更多的验收测试。
3.负责为代码做单元测试，使验收测试就不必顾及故事的那些细节。
客户职责：
1.负责编写验收测试。
2.负责执行验收测试。