在正式开始开发功能之前，要先写自动化测试，确保可以验证所开发的功能是否符合需求。这些测试能够帮助团队尽早地发现不符合需求的错误，降低修复成本。这种测试有需求规格说明书的作用。
测试的分类
用户故事（User story）：在软件开发或项目管理中用日常语言或商务用语写成的语句，反应了终端用户或系统用户捕捉到的关于一个用户在其工作职责的范围内做的或需要做的事务。用户故事在敏捷开发方法中用来定义系统需要提供的功能和实现需求管理。
即用户故事就相当于需求用例
验收测试
作用：在敏捷环境中程序如果通过了验收测试，就可以认为用户的需求都被实现了。
Path
- “given-when-then”书写模型：当测试开始时，系统处于一个状态，当用户执行某些动作后，系统有了一个新的状态，称为“Happy Path”
- 实际上，任何用例的初始状态，用户执行的操作，系统执行操作后的新状态都会有所不同，有时会形成不同的用例，这个被称为“ Alternate Path”
- 有时变化会引发一些错误处理，形成“Sad Path”
回归测试
回归测试是自动化测试的全集，通常用来检测修改是否破坏了现有的功能。
自动化测试
一般用来完全覆盖Happy Path的行为，并覆盖一些其他及其 重要 的部分。什么时候应该使用自动化测试，需要分析具体的功能，一般将重复性的手工测试作为自动化测试的实践（该自动化测试应该是不需要很大代价去维护的）。
自动化的验收测试要能正确反应用户故事中从用户视角所定义的业务价值。
实际的项目开发中，从一开始，我们就要做自动化测试。自动化测试能够检测软件质量，所以需要重视该测试的维护，一旦测试出现问题要优先修复。
在开发系统新功能时应该创建有验收条件的用户故事，并将自动化测试作为 该功能实现的标志之一。（实际情况中，自动化测试通常用于高价值的用例）
集成测试
通常用于所开发的应用程序由很多松散耦合的模块组成，模块之间还有复杂的交互操作，或者程序需要通过一系列不同的协议与各种外部系统进行交互的情况。
项目开发中，开发人员与测试人员之间要建立良好的反馈循环，在开发一个用户故事之前，测试人员与开发人员一同参与讨论验收测试，能够让开发人员更好的理解该用户故事，能够明确做到什么程度算是完成了这个用户故事，开发人员完成一个功能时要及时找测试人员检查，即时沟通。
待修复缺陷列表（backlog）
用来存储待修复的系统缺陷，理想状况下不应该有 backlog ，但实际开发中开发人员可能由于测试发现的缺陷过多，来不及修复，或者有的缺陷修复难度大，修复进展缓慢，导致了待修复缺陷列表的产生。
有了backlog，我们首先要做的就是将它可视化，让团队成员能够看到目前存在的缺陷，起到鞭策的作用，让参与人员尽快修复缺陷。
小结
测试是一个软件质量的衡量，做的自动化测试需要投入精力和时间，一般考虑到开发成本，选择高价值的用例，为其编写自动化测试来保证其功能。
