2015微软解决方案框架.ppt

第 7 章 解决方案的开发 课程概览 本章概览 MSF 开发阶段 测试解决方案 MSF 开发阶段 学习完本节后，你将能够： 讨论如何为开发解决方案做准备 讨论内部发布和每日构造 描述代码评审过程 描述用户体验交付成果和运营文档的开发 描述 MSF 开发阶段中的目标 、里程碑和交付成果 MSF 开发阶段概览 目标：完成功能规格说明书中所描述的功能、组件和其他要素 团队主要工作 编写代码 开发基础架构 创建培训课程和文档 开发市场和销售渠道 MSF 开发阶段的里程碑和交付成果 交付成果 解决方案代码 构造版本 培训材料 文档 部署过程 运营过程 技术支持和疑难解答 营销材料 更新的主项目计划、进度表和风险文档 项目计划的执行 按照计划和进度表进行开发 开始进行并行工作 在整个开发阶段中构造和测试要综合进行 基础架构的开发 开发基础架构包括以下几项任务： 开发解决方案配置 构造部署脚本和过程 自动部署工具和部署检查清单 制定疑难解答和解决问题的指导方针 按照设计文档的要求开发备份/恢复或故障恢复功能 解决方案的验证 创建解决方案基础架构的基准 在模拟的环境中确认解决方案的可行性 不包含对定制开发组件的验证 为持续的开发和构造过程打基础 构造版本 开发人员创建构造版本用来： 在模拟的环境中验证解决方案的可行性 为迭代开发创造基础 构造的内容包括： 代码组件、目录结构、基础架构、文档和自动部署脚本 如果是第一个构造版本，可能只含有少数组件 通过内部发布开发解决方案 使用内部发布的指导方针 设定标准来评估构造版本的质量 使每个内部发布尽可能独立 经常进行构造和测试 经常进行代码评审 使用内部发布的好处 将复杂项目分解为多个可管理的任务 易于实现对计划的变更 提高了解决方案的整体质量 提供了一个相对容易实现的短期目标 每日构造的步骤 每个内部发布周期都包含多个每日构造 一个每日构造有以下三个步骤： 开发——完成内部发布里程碑对应进度表中所规定的功能 测试——按照测试计划进行测试 验证——按照质量标准进行评估 使用每日构造开发内部发布 代码评审 代码评审可能是正式的，也可能是非正式的，或者是由第三方进行评审 评审可为解决方案带来以下好处： 提高代码质量 加快开发速度 清楚的了解开发人员的编码水平 评审使整个项目和团队受益： 提供了培训 降低了解决缺陷的成本 提高了代码的可维护性 改进了开发过程中的做法和标准 代码评审的指导方针 尽早开始代码评审 将代码评审作为一项任务并在项目进度表中分配相应的进度和参与的团队成员 共同分享所获得的经验教训 构造用户体验交付成果 用户体验角色负责用户体验交付成果 与解决方案的其他交付成果同时构造 反复的逐步完善的开发过程 将开发成果与对应的内部发布版本同步 交付成果包括： 用户参考资料（用户手册和帮助文件） 用户界面中的图形元素 最终用户培训 可用性测试场景 构造运营文档 发布管理角色负责运营文档 与解决方案的其他交付成果同时构造 反复的逐步完善的开发过程 将开发成果与对应的内部发布版本同步 交付成果包括： 操作指南、标准的操作流程 用户支持和技术支持的流程 知识库 技术支持人员的培训 本节回顾 开发阶段的交付成果是什么？ 为什么变更控制在开发阶段很重要？ “开发”除了“写代码”之外还包含其他什么意思？ 构造同编译代码相比还增加了什么内容？ 好的代码评审应遵循哪些指导方针？ 说明属于用户体验角色和发布管理角色职责范围的交付成果 测试解决方案 学习完本节后，你将能够： 定义测试 描述测试目标 描述覆盖测试、使用测试、基础架构测试和单元测试 描述怎样管理缺陷 描述开发阶段的成功标准 认识到每日构造在开发过程中的重要性 解释在开发阶段的测试目标、测试过程和测试产生的成果 测试目标 找出所有团队必须解决的缺陷 按照功能规格说明书验证解决方案中的组件 找出设计中的错误 找出由意外的用户行为而产生的错误 测试解决方案中的所有组成部分 测试——评估解决方案的质量 解决方案的测试 测试类型 所有类型的测试都会找出解决方案中的缺陷 测试类型涉及到解决方案绝大部分的特性 根据所需要验证的内容特性来选择测试类型 覆盖测试 覆盖测试 尝试完整地测试解决方案的每个功能 尝试完整地测试解决方案的代码库 主要在开发阶段使用 覆盖测试的类型 单元测试 功能测试 签入测试 构造验证测试 回归测试 使用测试 使用性测试 尝试成功完成用户实际使用场景 尝试在实际使用环境中进行测试 主要在稳定阶段使用 使用测试的类型 配置测试 兼容性测试 压力测试 性能测试 文档和帮助文件测试 可用性测试 缺陷的定义 不是所有的缺陷都是缺点，但所有发现的缺点都是缺陷