今天听了下“段念”在INFOQ上一篇有关敏捷测试的演讲课程，听课笔记如下：

　　敏捷测试核心价值观：（交流、简单、反馈、勇气）

　　敏捷测试的要求：“交付可用产品”而非“发现缺陷”

　　传统：Requirements——>specifications——>code——>Testing——>Relese

　　Agile:Each story is expanded,coded and tested

　　Possible release after each iteration

　　UI测试：API和业务适合自动化测试，已稳定的功能适合也适合使用，但UI新功能测试更建议使用手工测试；

　　敏捷带来的挑战：测试工程师应该做什么？测试工程师能够做什么？

　　敏捷测试核心：共享质量目标（工程师和测试均需要承担责任）

　　                               在产品中内建可测试性（是否适合自动化测试）

　　                               关注产品质量提升而非缺陷

　　测试工程师可以做什么：

　　获取和明确用户的质量期望

　　建立合适的系统测试、用户验收测试质量标准

　　让产品和代码质量反馈持续可见

　　推进单元测试（迫使开发对质量的重视）、开发测试、促进代码质量

　　建立与维护合适的自动化测试以减少测试的时间投入

　　测试工程师面临的挑战：

　　必须依赖于自己的沟通技巧与开发密切合作获取产品信息，制定测试计划而不是依赖文档

　　必须密切介入开发过程，参与设计

　　必须能够自我驱动

　　必须具有足够的自动化测试技能与探索性测试技能（随机测试）

　　解决方案：

　　与开发工程师密切合作

　　转变角色，变为“支持者”和“帮助产品具有更好质量的角色”

　　自我驱动。积极参与敏捷过程，主动工作

　　提升自己的技能，自动化测试、探索性测试、快速学习能力

　　测试团队面临的挑战：

　　考核标准需要变更

　　人员技能要求不同

　　测试过程管理需要转变

　　团队管理方式需要变更（传统：强调过程、文档，Agile：激励团队成员去做一切他们可以做的事情）

　　敏捷测试中，各个环节一般所占比例分配：

　　单元测试（70%） 集成测试（20%） UI测试（10%）

　　目前敏捷确实很火，特别是在互联网行业，敏捷开发，敏捷测试一直在提倡，都在转型，其实对于测试人员是一个比较大的挑战，需要测试人员掌握更多的技能，so 学无止境。

　　敏捷不一定适合每个公司，不能为了敏捷而敏捷，选择适合自己公司的测试流程和方法才是硬道理。