软件测试理论课程第一章讲(软件工程最佳实践).ppt

软件测试 软件工程最佳实践 4 课程描述 教学周数：18周 总学分：4 理论教学：2学时/周 实 验 课：2学时/周 考核方式：期末考核占总成绩的60%（试卷100分），出勤、作业与实验占40%。 5 章节目标 软件开发过程中的问题 解决软件开发过程中通常问题的六个软件工程实践 软件工程过程为软件工程实践提供的支持 6 软件开发的一般过程 需求分析 概要设计 详细设计 编写源程序代码 测试 部署 7 软件测试的一般过程 测试过程是依相反顺序安排的自底向上，逐步集成的过程。 8 软件工程最佳实践 软件开发过程中的一些通常的问题 解决软件开发过程中通常问题的六个软件工程实践 软件工程过程为软件工程实践提供的支持 9 软件开发问题的症状 用户或者业务需求没有被满足 需求的混杂 系统模块无法集成 系统很难维护 较晚的发现系统的缺陷 Unit 标题 10 软件开发问题的症状 不好的质量或者不好的用户体验 不好的负载性能 非并行的团队工作 构建和发布版本的问题 11 软件开发问题的症状 产生差异的原因： 认识的偏差 商业需要 产生差异的结果： 用户得不到满意的产品 12 从症状追溯到根本原因 需求没有满足 需求混杂 模块难集成 系统很难维护 缺陷发现晚 不好的质量 不好的性能 开发人员协作难 构建和发布问题 不正确的需求 含糊不清的沟通 脆弱的架构 过分的复杂性 未发现的不一致 测试不充分 主观的估计 瀑布型的开发 不可控的变更 缺乏自动化 症状 根本原因 软件工程实践 迭代开发 需求管理 Use 基于组件的架构 Model 可视化建模（UML） 持续的质量验证 管理变更 持续的质量验证 统一管理变更 不好的质量 未发现的不一致 测试不充分 主观的估计 13 软件工程最佳实践 软件开发过程中的一些通常的问题 解决软件开发过程中通常问题的六个软件工程实践 软件工程过程为软件工程实践提供的支持 14 实践 1：迭代开发 迭代开发 管理需求 基于组件的架构 可视化建模 (UML) 持续的质量验证 管理变更 软件工程实践 15 瀑布型开发的特点 推迟关键风险决定的确认 通过估计工作产品的进展测量，不利于时间进度和工作完成情况的预估 推迟和集中的集成与测试 排斥早期的部署 经常导致非计划的项目延伸 瀑布型开发过程 16 迭代开发产生一个可执行的版本 17 风险分析 迭代开发可以在项目早期排除风险. 18 实践 2：管理需求 迭代开发 管理需求 基于组件的架构 可视化建模 (UML) 持续的质量验证 管理变更 软件工程实践 19 管理需求 问题 方案空间 问题空间 需求 特性 软件需求 测试 设计 用户文档 可跟踪性 20 管理需求 － 用例概念 参与者代表一个人或者其他与目标系统交互的系统。 用例定义了一个动作的序列，系统通过这个动作序列为参与者产生有观察价值的结果。 21 实践 3：基于组件的架构 迭代开发 管理需求 基于组件的架构 可视化建模 (UML) 持续的质量验证 管理变更 软件工程实践 22 有弹性的基于组件的架构 弹性 满足当前和未来的需求 改进扩展性 增强重用 封装系统依赖 基于组件 重用或者定制组件 从商业上可得到的组件选择 增量式的进化已存在的软件 23 基于组件的架构的目的 重用的基础 组件重用 架构重用 项目管理的基础 计划 人力资源配置 交付 良好的控制 管理复杂性 维护完整性 24 实践 4：可视化建模 (UML) 迭代开发 管理需求 基于组件的架构 可视化建模 (UML) 持续的质量验证 管理变更 软件工程实践 25 为什么要可视化建模 帮助管理复杂性 捕获结构和行为 显示系统元素如何组合在一起 适当的隐藏或者展示细节 保持设计和实现的一致性 促进沟通 为所有软件从业者提供一种语言 26 使用 UML 图进行可视化建模 正向和逆向工程 目标系统 用例图 类图 协作图 时序图 组件图 状态表图 部署图 27 实践 5：持续的质量验证 迭代开发 管理需求 基于组件的架构 可视化建模 (UML) 持续的质量验证 管理变更 软件工程实践 28 持续的质量验证 － 在每个迭代中 29 持续的质量验证 － 软件模型 各种工作活动产生的模型 … 设计模型 被实现 被验证 被验证 … 每一个模型都要被评估 30 实践 6：管理变更 迭代开发 管理需求 基于组件的架构 可视化建模 (UML) 持续的质量验证 管理变更 软件工程实践 31 你想控制什么？ 工作空间管理 过程集成 并行开发 构建管理 使迭代开发能够进行变更 为每个工作者提供安全的工作空间 并行开发成为可能 自