敏捷软件开发ASD-10-验收测试方法与实践.pptVIP

验收测试方法与实践 尹俊文 国防科学技术大学计算机学院 Agenda 敏捷验收测试 验收测试过程与工具 Fit与验收测试 验收测试的策略 1 敏捷验收测试 1.1 验收测试的传统方法 手工验收测试 用户根据自己的创造力手工练习使用系统 手工验收测试的缺点 开发者不清楚目标，这样的方法不支持TDD 代价高，在系统发生变化时，必须重复这些人工工作 错误容易被忽视，难以确定测试是成功还是失败 通过Capture Replay (e.g. at the GUI level)的验收测试 工具捕捉脚本中(可修改的)的事件 捕捉工具方法的缺点 必须存在一个系统(和GUI)，因此这样的方法还是不支持 TDD ?? 工具是昂贵的 测试是脆弱的，如果系统发生变化，必须重新捕捉 1.2 敏捷验收测试的基本思想 不用等到系统开发完成才能开始验收测试 尽可能快速地编写验收测试 在验收测试基础上构造单元测试 在理解过程的迭代期间运行验收测试 为了验证需要的功能是否构建，在迭代结束时执行验收测试 为什么？ 客户与开发者之间更好地协作，更快速的反馈 Customer / Business / User / Domain Expert 指定需求 以业务语言，关注想定情节、事件流、动态行为 以一种可执行的形式 执行是自动化的 在需求实现之前 验证需求 是否真正需要这个功能？(是否构造了正确的系统？而不是“是否用正确的方式构造了系统?”) 验证一般发生在项目结束期间 (可能太晚了). 单元测试可能不能发现一些目标错误 开发者误解了需求 软件接口不是预期的 模块没有与其他模块集成起来 迭代软件开发 At the start of the iteration, the customer explains the expected functionality to the team. The customer prioritizes for business value and urgency, the team estimates the effort and cost. Then the team brainstorms the necessary tasks to implement the functionality, details the estimation and team members select their tasks. During the iteration, the team holds short status meetings in order to discuss the current tasks, the achievements and the problems. At the end of the iteration, the team demonstrates to the customer the increment of potentially shippable functionality. 1.3 敏捷验收测试的特性 客户所有 客户、开发者和测试者一起编写 关于是什么的测试，而不是怎样实现的测试 使用问题域的语言表达 简练、准确、无歧义 客户所有 验收测试必须为客户所有 客户的主要目的就是为用户故事制定验收标准 客户是清楚阐述这些标准的最佳位置 客户应该是编写验收测试的最佳人选 开发者通常会陷入技术陷阱 验收测试应该是功能规范 而不是技术细节的测试 客户、开发者和测试者一起编写 客户不是编写验收测试的唯一人选 特别是对用户故事和验收测试的新手 客户以及其他团队成员一起编写验收测试有助于团队对用户故事的交流 客户、开发者和测试者几乎覆盖了软件项目的所有领域 开发者独立编写验收测试，必须以已经确认之前存在足够的交流 当然，即使用户故事并不理想也不是世界末日 良好测试与编写者的关注点以及角度紧密联系 关于是什么的测试，而不是怎样实现的测试 “什么”与“怎样” 用户故事关注于说明对客户的价值来源 而不是如何提供价值 这是用户故事适合及早和经常提供价值的原因 验收测试是用户故事的细化 应该保留用户故事中易于理解和交流的本质 验收测试不应该关心实现的细节 关心实现的细节使得验收测试失去了独立性和隔离性 使用问题域的语言表达 这是客户参与验收测试的根本要求 过多使用技术语言容易受到客户的误解 每个客户不可能都可以理解技术词汇，因此可能漏掉一些细节，任务验收测试遗漏了某些环节 使用问题域的语言表达还可以避免测试依赖于实现 测试依赖实现的另一个问题是阻碍了系统重构！ 简练、准确、无歧义 简练、准确、无歧义 每个验收测试总是验证用户故事的一个方面或者一个场景 验收测试应该保持整洁、易于理解、便于翻译为可执行测试 无歧义的验收测试可