03-第2章软件过程模型.ppt

定义质量 (Define Quality)：这应该是软件测试人员的基本职责。敏捷方法鼓励测试人员在计划的时候直接与客户交流，从自己的经验出发，共同为产品功能制定质量要求。 交流缺陷（Communication）：敏捷过程强调团队中的交流。开发人员经常会专注于重要而新奇的功能，测试人员应该抓住细节，寻找设计中的“missing door”；另外，开发人员使用单元测试来保证产品的基本质量，测试人员可以使用验收测试（Acceptance Test）来鉴定客户需求与实际成果之间的不一致性。 及时反馈 (Feedback): 敏捷过程强调简单而高效。测试人员需要及时反馈产品目前的质量问题。这样一来，团队才可以立刻着手解决。如果传统的流程是一周汇总一次状态的话，敏捷流程要求每天汇总质量问题。在我们的项目中，内部的测试报告会以网页的形式显示在内部站点上。每个团队成员能够随时获取。另外，我们的测试框架提供自助测试 (Self-assistant Test)：通过点击测试用例列表中的某个具体用例，开发人员不需要中断测试人员的工作就可以重现缺陷。 极权编程的核心思想 从长远看，早期发现错误以及降低复杂度可以节约成本。极限编程强调我们将任务/系统细分为可以在较短周期解决一个个子任务/模块，并且强调测试、代码质量和早期发现问题。 用户故事设计和发布计划阶段 由于敏捷开发的流程是不断迭代的过程，所以很多复杂的功能可能会在未来的 Sprint 周期中被优化。对测试人员而言，一个有效的方法是尽量将一些验证基本功能的测试用例作为基本验证测试用例（Basic Verification Test Case）在第一时间实现自动化；而对一些复杂的功能测试用例，可以先采用手工的方法测试，直到在未来 Sprint 周期中该功能达到稳定时候再考虑自动化。此外，对测试中出现的缺陷可以设计回归测试用例（Regression Test Case），为其编写自动测试代码，使得此类问题在发布周期（Release Sprint）时可以顺利而高效得进行验证。 用户故事设计和发布计划阶段 动作 数据 期待的结果 登录 用户名：（空）密码：（空） “用户名和密码无效” 动作 数据 期待的结果 登录 正确的用户名和密码 进入系统：请输入搜索条件并点击“搜索”按钮 搜索 错误的类型 提示正确的类型 搜索 使用正确的类型 商户列表 项目实例： 基本验证测试用例： 功能测试用例： 用户故事设计和发布计划阶段 3.3.4 编写验收测试用例 敏捷开发不提倡撰写太多的文档，提倡直接编写测试用例。此外，测试人员和客户应取得良好的沟通，将这些需求总结下来，转化成验收测试用例。如果资源充足，最好对验收测试用例建立版本控制机制。 考虑到需求在每一轮 Sprint 周期中会不断得变化，测试团队要控制测试的自动化率，正确估计未来功能的增减。自动化率过高会导致后期大量测试代码需要重构，反而增加很多工作量。 用户故事设计和发布计划阶段 3.4 Sprint 结束和下一个 Sprint 开始 在一个 Sprint 周期结束时，团队要举行一个回顾会议（Retrospective Meeting）。团队成员可以在会议上畅所欲言，指出在过去一个 Sprint 周期中可行的，不可行的和有待改进的地方。待改进之处将在项目经理监督下于未来的 Sprint 周期中实现。 由于敏捷开发倡导增量开发，当新的 Sprint 开始时，测试团队需要根据新 Sprint 周期的开发进度及时重构验收测试。如果新 Sprint 周期没有具体的新功能开发，测试团队可以将精力集中在执行验收测试和寻找缺陷上。 如果下一个 Sprint 周期是发布周期，那么测试人员需要准备执行回归测试。下面我们来详细了解每个测试活动。 用户故事设计和发布计划阶段 3.4.1 重构验收测试 正如上文所提及，敏捷开发是以迭代方式进行的，功能在每次迭代中推陈出新。于是，验收测试用例经常需要修改或者添加，相应的验收测试代码也需要删减。这部分工作如果时间花销很大，最好在估算的时候一并提出。 项目实例： 在下一个 Sprint 周期中，我们需要实现之前没有实现的“模糊查找”功能。测试人员要在新的 Sprint 周期中更新原来的验收测试用例，在测试“搜索”模块中添加模糊查找测试。重新估算的测试任务参加下表： 用户故事设计和发布计划阶段 任务 估计时间 设计测试用例，准备测试数据（模糊搜索数据集） 2 加载数据集 1 编写自动测试代码 3 执行测试和汇报结果 2 总结 8 用户故事设计和发布计划阶段 3.4.2 执行验收测试 验收测试可以分为两大类，基本验证测试和功能测试。如果是基本验证测试，推荐开发人员在运行完单元测试和提交代码前直接运行自动测试脚本。如果是功能测试，可以在每个 Sp