前言：
大家好，我是一菲，今天我们来谈谈敏捷测试的相关内容。
敏捷这个话题似乎热了好多年，随之也就自然地有了敏捷测试这个术语。说到敏捷，大家一定听过不少相关的演讲，看到不少相关的书籍，不过不管有什么新的技术，新的流程，归根结底都是遵循着敏捷宣言并以敏捷原则作为根本。就像Scrum开拓了一套敏捷项目管理的框架，XP指导着敏捷开发中的工程实践一样，敏捷测试也就是一组指引测试工作在敏捷团队中的一些最佳实践。
正文：
首先，敏捷测试非常强调和多方的合作。在瀑布开发模式下，测试人员一般是根据需求文档和设计文档来设计测试用例，然后等功能开发完成，软件交付到测试人员手上才开始正式的测试工作，这样对于测试的所有输入就都是文档。而敏捷测试让测试人员在软件开发的最初就加入团队，为的就是使测试人员更加地靠近产品本身，对于产品经理的需求和开发人员的设计有深入的理解，甚至能和后续的部署和运维团队尽早地接触，了解到产品的全方位。
再次，尽早地使产品可以测试起来，越早越好。测试工作不再是软件开发中的某一个环节，而是时时刻刻贯穿于软件开发中。实现这一点的基础就是软件的可测性，而可测性又包括至少两点
有较为明确的需求指标（这里使用了“较为”两个字是因为有些非功能上的指标前期可能的确不太明了，但是随着产品开发的进行，最终还是会慢慢清晰的），这样才能对测试结果进行判定
有适合测试的接口，这样才能方便的设计和执行测试用例，并能最大规模地发挥测试自动化的优势
之后，使团队一起加入测试。千万不要孤军奋斗，软件测试是一件极其需要团队力量的过程，让策划/开发/运维甚至是产品经理一起加入。
开发需要为自己的代码负责，单元测试是必不可少的
编写用户验收测试用例的时候要邀请策划和产品经理，避免对于需求的理解错误
请运维一起加入产品的部署测试，他们有着更多的生产环境的实际操作经验
当然每个角色对于加入的方式可能会不太相同，但是重要的一点就是把所有的测试环节都对团队成员透明，让他们知道产品会进行哪些测试，已经进行了哪些测试，当前的测试结果怎么样。
在测试可以跑起来之后，尽量频繁地测试。说到这个，测试自动化很自然地被提上了日程。注意，这里用的是“测试自动化”，而不是“自动化测试”。个人认为测试自动化不仅仅是把测试用例通过编写代码脚本化并通过机器运行起来，而是包含了一套对于测试过程的自动化，包括测试环境的自动部署，测试数据的自动生成，测试脚本的自动执行和测试结果的自动报告等等。好了，回到“频繁地测试”这个话题，我们需要多频繁呢？越频繁越好！
每一次的代码（产品代码或是测试代码）提交或是每一次的配置更新都有潜在破坏软件的可能性，都是需要测试的
产品在不同部署环境中的表现往往是不可预料的，尽可能多的对可能的部署环境进行验证
即使部署环境和产品都没有变化，也需要重复测试。这个可能会有些疑问，既然什么都没变，已经跑过通过的测试还有必要重复执行吗？答案是“有必要”·产品在刚启动时和运行了一段时间之后的表现是完全不同的，看似重复执行的测试其实已经是运行在不同状态下的
测试的执行往往是按照一定顺序的，依据“杀虫剂”原理，系统是会有一定“抵抗力”的，这时可以不采取简单的重复测试，而是打乱测试顺序（虽然测试用例的设计在原则上是独立的，但是在实际中对于软件产品的内部状态变化是不可预知的）
上面这些只是敏捷测试个人的一些理解，其中并没有涉及到具体技术层面的东西，更多的是一种思想层面对于软件测试的转变
软件测试是软件开发的一部分
软件测试是团队成员的职责
软件测试需要尽早，自动，频繁的执行
也正是因为有了这些需求，TDD/ATDD/CI才会被团队所接受，慢慢变成了一种标配，我们的项目实行敏捷已经近两年了，关于敏捷我相信大家已经比较熟悉了，我今天就先谈谈在敏捷的项目里如何实行测试的工作。
三.拓展：敏捷的项目对测试的影响
文档少，因此难以只是依赖文档来设计测试。
短迭代，需要更短的时间完成测试的工作。
频繁的变化，需要测试更具有探索性和适应性。
敏捷项目的正确测试观念
项目是以结果为导向的，所以测试同样是结果导向。
不以发现缺陷多少为目标。
以不断提高软件质量为目标。
测试人员的作用是帮助开发人员不断提高软件的质量，是协助性的。
测试人员不是批判性的。
测试人员能够尽可能的做能够做的工作，尽可能的早工作。
“等待”在敏捷开发、敏捷测试范畴里已是一种错误概念。
敏捷测试的管理
敏捷项目的测试没有严格的角色。人人都是测试。
以测试任务为导向。测试任务即可以是开发来做，也可以是测试人员来做。
相同的质量目标。开发和测试有着同一个质量目标，因此也承担着同样的责任。
关注质量的提升，测试周期与开发同步。
要有全局观，不只是专注于发现缺陷。
为回滚做准备，本次迭代发布失败，可安全回滚至旧版本。
分享测试知识。
建立缺陷库，指导开发人员避免再次发生同样缺陷。
敏捷测试的执行
关注和推动单元测试。
持续改进自动化测试（因为软件的变化，已经对产品的深入了解）
短文档（测试用例可以不写，测试计划列测试点，测试类型，质量标准即可）。
对新增的或者引起变化的地方（可询问开发人员协助）采取探索性测试。
对稳定的部分添加自动化测试。
我们的项目之前的测试开发比例是1比5，质量基本达到客户的要求，为什么1比5可以，因为我说过，开发人员是可以做测试的工作的。现在觉得唯一有不足的地方是对稳定的地方进行自动化的回归测试。还有，我希望在自动化的探索性测试上有所进步。
最后，我还说一点是，我看到很多项目靠加班，不会休息的团队是不健康的团队。其实，项目往往不是短期行为，通常一个产品的至少需要半年努力和投入，长
时间的超负荷运转会使得工作效率低，身体透支等严重后果。项目中后期往往强度会比前期更大，这个时候，人员倒下和效率低不是一件好事情。所以，如果你的项目还要长期发展，应该帮助团队认识到轻松的团队氛围，张弛有度的工作安排是项目成功的最好方式。
当然，不加班，不代表上班时间不好好干。我们要求就是8小时以内，每周40小时。
四.写在最后：
无论前行的路怎样艰险，请相信只要咬牙坚持，就能抵达属于你的星辰大海。
来源：oschina
链接：https://my.oschina.net/u/4287100/blog/4941594