让测试敏打捷起来.pptVIP

让测试敏捷起来 敏捷测试与传统测试的区别： 传统的测试模式基于如下的一些理念： 测试是质量的最后保护者； 严格的变更管理； 预先的计划和细节的准备； 重量级文档； 严格的各阶段测试入口和出口标准； 回归测试阶段重量级的自动化测试； 企图流程改善和执行； 测试团队和开发团队是可分割的。 让测试敏捷起来 敏捷测试与传统测试的区别： 那么对照传统的测试模型，敏捷测试颠覆了以上观念： 测试是质量的最后保护者---开发和测试人员是紧密合作，大家都有责任对软件负责; 严格的变更管理---变更是可接受的，拥抱变更; 预先的计划和细节的准备---计划随时进展时常调整; 重量级文档---只需要绝对必要的文档; 严格的各阶段测试入口和出口标准---各迭代之间已经没有明显的入口和出口标准; 回归测试阶段重量级的自动化测试---所有阶段都需要自动测试，每个人都需要做，是项目集成的一部分; 企图流程改善和执行---流程不再需要严格执行; 测试团队和开发团队是可分割的---团队合作是无缝隙合作; 　 让测试敏捷起来 自组织团队与客户紧密协作，通过高度迭代式、增量式的软件开发过程响应变化，并在每次迭代结束时交付经过编码与测试的有价值的软件。 与客户确定合同后在初期制定并遵循基于活动的完整计划，在重型过程和工具指导下，通过完成大量文档进行知识传递，最后交付需求。 敏捷测试 传统测试 胜于 让测试敏捷起来 敏捷测试概述 1 敏捷测试与传统测试的区别 2 敏捷测试中测试人员的价值与挑战 3 科创敏捷测试思路与探讨 4 让测试敏捷起来 敏捷测试中测试人员的价值 1 敏捷测试中测试人员的挑战 2 敏捷测试成功的关键要素 3 让测试敏捷起来 敏捷测试中测试人员的价值 敏捷测试中测试人员扮演的角色： 　测试是项目的“车头灯”，它告诉大家现在到哪了，正在往哪个方向走。 　测试为项目组提供信息，使得项目组基于可靠的信息作出正确的决定。 　“BUG”是让用户感觉烦恼的东西，测试人员不作出发布的决定。 　测试员不保证质量，整个项目组对质量负责。 　测试不是抓虫子的游戏，它的目的不是纠缠在错误中，而是帮助找到目标。 让测试敏捷起来 敏捷测试中测试人员的价值 在需求和功能设计讨论上，测试人员可以站在客户角度来阐述自己的观点，扮演“用户代表”角色，强调用户体验，真正体现测试人员和开发人员的互补作用。 测试人员不仅扮演“用户代表”角色，而且通过需求讨论、代码复审等各种活动及时地提供质量反馈，包括代码质量、接口一致性等，保证在产品构造的整个过程中质量受到足够的关注，以提高质量改进的持续性和可视性。 测试人员应积极参与单元测试，即使不参加单元测试，也应督促开发人员进行单元测试，确保单元测试达到80% 以上覆盖率，确保开发出具有良好可测试性的代码。 在敏捷方法中，往往将一个大的系统开发分解成多个小的子系统（模块或组件），集成测试和端到端（End-to-End）测试显得更为重要，测试人员在这些测试上能发挥更大的作用。 产品发布前，验收测试和回归测试依然不可缺少，这更是测试人员的用武之地。 一个迭代周期结束后，对缺陷根本原因进行分析、总结规律，帮助开发人员建立良好的习惯，预防缺陷，从根本上提高产品质量。 让测试敏捷起来 敏捷测试中测试人员的价值 1 敏捷测试中测试人员的挑战 2 敏捷测试成功的关键要素 3 让测试敏捷起来 敏捷测试中测试人员的挑战 为什么以前的开发模式不再适用？ 以前的开发模式要求有详细的测试计划，但是缺乏足够的时间来写，而且测试计划受很多因素的影响经常改变。 以前的开发过程会专门留出一个阶段来测试，但是你不能定义进入和退出的标准，测试阶段会随之而过。 以前的开发模式强调变更控制，但是现在的软件需求变更非常频繁，变更成了家常便饭。 以前的开发模式要求测试要对软件做出权威的判断，但是测试很难做出权威的关于软件正确性的判断。 测试的作用 有价值的东西有么提供产品，要么提供服务。那么测试提供什么产品或服务呢？有人认为测试提供调试通过的、经过测试的软件。 这是错误的回答。测试不提供产品，测试提供信息，关于开发过程中的软件的状态的信息，以便基于这些信息做出决定。 让测试敏捷起来 敏捷测试中测试人员的挑战 敏捷测试中，测试人员面临七大挑战： 测试员是否不再需要了？ 测试不完整的软件 可接受性测试是否过于简单了？ 把测试员作为项目组的一部分 测试什么时候完成？ 我们还需要bug跟踪系统吗？ 用什么质量标准来度量敏捷项目？ 回归测试和回归测试工具 让测试敏捷起来 敏捷测试中测试人员的挑战 敏捷测试的挑战之一：测试员