软件测试第03-软件生命周期的讨论.pptVIP

* 需求分析阶段 * 设计阶段 设计阶段的主要目的是根据用户的需要制定标准，划分并分配任务 设计GUI标准 设计数据库 设计过程模块 设计编码标准 构建原型 分配任务和监督任务 设计阶段涉及的活动 * 开发阶段 开发阶段 对在原型创建阶段构建的用户界面进行最后的修改 构建数据库 通过添加代码使其具备功能 * 评估/测试阶段 本阶段测试每个单元的功能。 测试阶段涉及的活动 单元测试 数据验证测试 安全性测试 强度测试 集成测试 * 维护阶段 本阶段为客户提供故障诊断支持 网络 电话 上门 本阶段还包括应用程序要求的任何软件升级 版本 补丁 * 软件开发过程 比尔通过类似软件瀑布模型的方式成功了完成自己的建筑项目 * 软件开发过程 这次将完成一栋更加复杂的建筑 因为有了以前的经验，比尔感到很有信心 就像我们的软件开始越来越庞大 由于成绩不错，比尔再次被通知 * 软件开发过程 这次需要更多人，更复杂的分析、设计和建造过程 但在完成之前各种问题开始出现 * 软件开发过程 之前设计时犯下一个比较小的错误，在建造时才被发现，已经变成了一个严重的错误 必须停工回到设计阶段重新设计，重新建造 在已经将房间格局建造得差不多时，用户又突然提出更改某处的要求，导致工程再次从设计开始 虽然很努力工作 但还是 工程超时 房屋不能满足用户需要 * 软件开发过程 工程失败的原因 前期错误往往只有到了项目后期才能够被发现 开始阶段的小错误被逐级放大，可能导致项目最终报废 开发进度往往会被意外发生的问题所打乱，需要进行返工或其他一些额外的开发周期，造成项目延期或费用超支 缺乏灵活性，不能适应用户需求的改变 返回上一级的开发需要十分高昂的代价 以上同样也是采用瀑布模型的软件项目的失败原因 * 软件开发过程 瀑布模型适合开发 规模比较小 需求非常明确且很少更改 瀑布模型是早期软件设计的主要手段，已经不太适合现在的项目 需求不清晰、不稳定的项目如何完成呢？ * 原型模型 * 原型模型 原型模型的优点 快速建模，减少由于需求调研不充分，需求表述不明确带来的开发风险 在需求阶段可以通过多次修改原型，得到明确的客户需求 原型可以作为DEMO，可以理解成为演示模型 原型模型的缺点 不宜利用原型系统作为最终产品。 采用原型模型开发系统，用户和开发者必须达成一致：原型被建造仅仅是用户用来定义需求，之后便部分或全部抛弃，最终的软件是要充分考虑了质量和可维护性等方面之后才被开发。 * 螺旋模型 需求分析 系统设计 开　发 测试和维护 最终产品 风险分析 开　始 * 螺旋模型 每一圈是一个阶段，每个阶段就像一个小的瀑布模型，都要经历需求、分析、设计开发和测试 在每个阶段中添加了风险分析的步骤 每一圈都会产生一个可以发布的结果，作为这个产品最终产品的一个子集 每个发布的结果都会马上反馈给客户，听取客户意见，从而尽早发现避免软件中的风险 * 螺旋模型 螺旋模型的优点 风险分析可使一些极端困难的问题和可能导致费用过高的问题被更改或取消 用户评价为需求的变更带来柔性 螺旋和瀑布的最大的差别就在于风险的暴露时间上 螺旋模型的缺点 需要开发人员具有相当丰富的风险评估经验和专门知识 要求用户参与阶段评价，对用户来说比较困难，不易取得好的效果 * RUP模型 RUP(rational unified process)是有Rational公司开发并维护，与一系列软件开发工具紧密集成，以用例驱动，以体系结构为核心，迭代及增量的软件过程模型。 * RUP模型 * RUP模型 迭代模型的优点 针对大型的复杂的系统，逐步完善，降低了实施复杂度 用户可在开发早期提出变更并进行修复，从而有效控制变更风险和代价 可在早期增强用户的信心 迭代模型的缺点 要有专业的架构是，当模块间耦合度高时不适用 已经确定的功能不允许做变更，不现实 * 敏捷模型 敏捷开发是以人为核心，迭代，循序渐进的开发方法。 在敏捷开发中，软件项目的构建被切分为多个子项目，各子项目的输出都经过测试，具备可集成和可运行的特征。 * 敏捷模型 敏捷模型的五个价值观： 沟通 简单 反馈 勇气 谦逊 * 总结 软件项目组中的人员分工 软件开发过程 可行性研究与计划 需求分析 设计 开发 测试 维护 软件开发模型 * 小试牛刀 案例分析：对程序的描述：一个程序从一个输入对话框中读取三个整数值。这三个整数值代表了三角形三边的长度。程序显示提示信息，指出该三角形的类型 不规则三角形 等腰三角形 等边三角形 按你的理解来测试一下上面的程序，并把具体步骤写下来，保存为word文档命名为“案例分析1-名字”发到我的邮箱。 * 预习作业 1、了解了这么多软件测试方面的知识后