软件设计师备考笔记（十）软件工程（开发模型、结构化设计、软件测试）

目录

• 软件开发模型

• 信息系统开发方法

• 需求分类

• 结构化设计

• 软件测试

软件开发模型

瀑布模型

• 历史

  • 盛极一时，但被淘汰；有重大缺陷，会导致项目失败（延期、超支、做不下去）

• 注意事项：每个阶段（绿框）末尾都有评审工作，评审上一阶段是否做好，产出物是否符合相关要求；

• 优点：强调文档化标准化；结构化方法的具现；

改进版瀑布模型

• 增加回溯，遇到问题回到上阶段解决了再往下；

• 缺点：需求往往是不明确的；

  • 往往设计完了，给用户看来，结果用户推翻很多部分；所有东西都要会需求阶段重新开始；所以导致项目失败；

• 适用范围：需求明确或二次开发时适合使用；

常见经典模型

• 用户往往不知道自己需要一套什么系统，程序员和用户也存在隔阂（知识领域不同，一个技术和一个业务）

原型

• 项目开发初期构建一套简易系统（一套界面，开发完成后长啥样；初步系统，让用户用一用）

• 好处：

  • 用户以前不知道具体啥样，描述了也想想不出来，所以没法提细致需求；只要你把东西做出来，他就能提出很多问题；所以开发前做个简易系统，用户发现啥问题一一调整，多次调整后就能大概知道用户要啥，

  • 用户也有个心里预期；往往只用于需求分析阶段；

• 注意事项：原型强调构建简易系统、需求不明确情况

演化模型

• 把原型通过多次调整成为最终产品

螺旋模型

• 原型+瀑布模型+演化模型

增量模型

• 先把核心做出来（可能只要20%的时间），用的过程发现问题就修改问题；然后再做另一块，用户用完再改；不会出现做完后用户突然说核心功能不行，要改完的现象；

增量模型和螺旋模型

• 螺旋模型：融合多种模型特征；多个模型特点都具备

  • 最显著特征：有风险分析

题目遇到不明确需求就选原型

• 如果有一个需求不明确的项目，选螺旋模型还是原型？原型！

  • 考试时追寻最匹配模型，原型的最大特征就是不明确需求；

其他经典模型

V模型

• 和瀑布模型非常接近；测试更为重要，细化了多个测试；

• V型的用意：

  • 为了提早发现问题；

    • 瀑布模型测试完成发现问题时需要冲需求开始改；

    • 如果再需求分析阶段就写验收测试，就能发现一些问题；

    • 所以各个阶段有对应关系，例如：需求阶段就要写系统测试和验收测试的计划了；

• 概要设计：做集成测试阶段的测试计划，因为概要设计就是设计模块的划分，继承测试就是测试模块间的衔接；

  • 能发现模块划分的问题

• 详细设计：写单元测试的测试计划；

• 瀑布模型和V模型的对比：

  • 瀑布模型相当于：先砌墙然后再看墙是否垂直，而V模型相当于先拉了一根引线，根据引线来砌墙；

喷泉模型

• 面对对象的（之前都是结构化方法的），最大的特点 （继承自面对对象的）迭代、无间隙

RAD（快速开发模型）：

• SDLC（瀑布模型）和CBSD（构建化开发模型）组合而成，

• 当用VB这种可视化的工具开发时已经是RAD了，按照瀑布模型的流程走，但是使用组件化开发，

构建组装模型

• 得到了越来越多的认可和应用

• 基本思想：把各个模块做成标准构件，把构件进行组装就能得到最终软件；

• 优点：极大提高了复用性，提高效率、降低成本、提升可靠性；很多软件开发模型都用了这种思想；

• 流程：

  • 需求分析和定义：和瀑布模型没差别

  • 架构设计：瀑布中没提到；类似建房子搭好基本框架

  • 构件库建立：看有什么构建可以用

    • 有三个标准：CORBA （omg提出的）；第二个（微软家族）、EJBj（ava体系）

统一过程模型

• 目前应用非常广泛的模型，可以用于大型项目；

• 了解特点、阶段及其核心任务；

• 特点：

  • 用例驱动：最开始时通过需求分析设计并实现相关用例，同时用例用来指导测试用例开发的依据；整个开发过程中都是由用例把各个阶段串起来并推动各个阶段的；

  • 以架构为中心：强调把架构设计好，再往里面添加构建完成开发；

  • 迭代和增量：每一个循环完成后增加一些东西；

• 英文缩写由两个:UP和RUP都是它

• 初始

  • 识别关键用例：80%的时间在使用20%的功能；必须把20%的功能做好；

• 细化阶段也叫精化阶段:

  • 完成生命周期结构

• 构建：并开发没有的构件并组装；

• 交付：

β测试：测试版本让用户使用

• 交付完后，有缺陷就再修改，进入下一循环；

敏捷开发模型

• 比较年轻的方法：

  • 最初时没有方法，质量很难控制，发展出软件工程各种开发模型；

  • 开发方法和模型越来越规范，但是按照重量级开发模型，往往得不到好的结果（因为重量级开发模型非常重视流程和文档，程序员负担越来越重，产生的文档不不一定有用）。

  • 为了减负、提出敏捷开发模型，减去不必要的文档、流程；

  • 形成敏捷开发的基本思想（不是一种模型而是一组模型）；

    • 这些模型有共同价值观，处置原则，甚至很多最佳实践都是保持一致的；

• 只能做小型项目：中大型项目力不从心；小步快跑；能满足需求即可；不要做拓展；

• 要求：

  • 勇气：既然变更不可避免，迟变不如早变；

  • 结对编程：一个人编码、另一个人检查编码；因为集体代码所有制，国内不太认可；

软件模型就是一个从无到有，从简到繁，又从繁到简；

信息化系统开发方法

结构化方法

• 以前非常普遍

为什么被取代？

• 一旦开发完成，就固化了。不灵活；

  • 之前是老板管财务，现在增加财务总监，由财务总监管理，系统需要改变的东西就非常多；

原型法

• 主要用在需求阶段，补充结构化开发的短板；做个原型探明需求；

面向对象

• 主流开发都是面向对象方法进行。

• 结构化最大的败笔是现实和系统有差距，那么我开发之前先抽象好现实中涉及的人为类；各个对象的区别用属性区分，现实中的人能干什么我们就设计什么方法，有了更好的复用性

面向服务方法

• 听的少，比较新，不成熟，了解特性即可。

需求分类

• 业务需求：总经理告诉开发部门经理，要做财务审批、费用报销等的管理（宏观），大概哪些人用；

• 用户需求：找各个角色去沟通；会计、出纳，了解到角色本身需要的功能（微观）；

  • 开发经理：涉及哪些角色做什么事？

• 系统需求：计算机化，能够指导开发的需求；

  • 性能需求（非功能需求）：响应时间、安全性、可靠性

  • 功能需求：要完成哪些功能

  • 设计约束：经过功能和性能研究之后，发现可以选择java或者.net都能达到要求；客户告诉我们他们的维护团队事.net这一块的，要用.net开发；（用啥啥啥数据库等）

    • 哪些地方用窗口、哪些地方用选择；

• 基本需求：用户希望完成的

• 期望需求：用户没提出来，但是用户觉得我不说你也懂的需求，也是比做

• 兴奋需求：用户没有提出来、也没有觉得一定要有；

  • 财务系统的指标用报表显示，开发人员觉得太枯燥了，于是设计了曲线图、饼状图等；客户高兴.

  • 但是不提倡，开发方的角度来看，风险极大（时间增加、成本上升）

结构化设计

• 实际上是 结构化方法里面的软件设计问题；

基本原则

• 信息隐蔽：一个函数中的内容不能展示给外界；

  • 两个部门合作，不可能一个部门的主管能指挥另一个部门的人；应使用接口；

内聚和耦合

• 扇入：入度

• 扇出：出度高表示模块职能比较多；

系统结构/模块结构

• 图b要掌握，其他了解即可

软件测试

• 主要在上午题（每次都考）；

  • 小概率下午题案例分析；极小概率论文；

测试原则

• 测试原则：途中蓝色框部分

  • 回归测试：改完bug后，把之前测过的模块再测一次

两种测试类型

• 动态测试：用到计算机

• 静态测试：纯手工

  • 桌前检查：程序员自己检查一边

  • 代码走查：人工走一便

  • 代码审查：代码给别人检查

测试用例设计

• 黑盒测试：软件模块看成黑盒子，看不到里面是啥，只知道输入输出

• 白盒测试：能打开盒子看，里面是啥，怎么运行； 设计用例时，设计多个分支用例；往往更加全面；可以把结构中所有路径都覆盖一遍；

黑盒测试

• 实际中往往既测试等价类也测试边界值；

  • 等价类：同一类型的数据，只测试一次

  • 边界值：端点和略大/小的一个值

• 错误推测：强调经验，写代码的人看半天看不出来，你一看就能找到问题；因为你有经验；完全经验没有套路；

• 因果图：由果分析因；

白盒测试

• 语句覆盖低于路径覆盖：13、24就能语句覆盖、但是路径覆盖有四种

• 判定覆盖：所有判定，真假都要覆盖

• 条件覆盖：一个判定可能由多个条件判定，多个条件的分支都要覆盖

• 路径覆盖是最高级覆盖

测试阶段

• 单元测试

  • 关注某个模块，这个局部的数据结构、接口是否满足之前定好的需求；

• 集成测试

  • 也叫冒烟测试：

    • 维修管道时，维修好后要测试是否维修完成，就放烟进去，看有没哪里冒烟；进行相关维护后看有没有问题产生；

  • 各个模块联合起来测试，测试各个模块衔接是否有问题；

  • 两种组装方式

    • 一次性组装：所有模块一次性连接到一起

    • 增量式组装：逐步增加模块，每增加一次测试一次；（更加稳妥，能暴露更多问题）

• 确认测试

  • alpha测试和beta测试

    • 两种测试都是针对产品（需要投入市场的）而言的，项目式开发一般没有；

  • 验收测试：用户参与进来，看产品是否符合要求，是否接受这个产品

• 系统测试

  • 对于一般软件而言，直到确认测试就截止了；

    • 如果是一个集成项目（涉及软硬件和网络时）就会把系统测试放在确认测试前；

  • 偏重压力、性能方面的测试；

  • 要了解负载、强度、容量测试；

    • 负载：并发100时响应时间？并发2000时响应时间

  • 强度测试：系统异常时（资源突然下降），能否正常运行

  • 压力测试：在极限值（并发1000人）的情况，那么十万人访问时会不会崩掉；