第十一章.软件工程（上）

第十一章.软件工程
- 第一节.软件开发模型
- - 瀑布模型（SDLC）
  - 其他经典模型
  - - 原型模型
    - 演化模型
    - 增量模型
    - 螺旋模型
    - V模型
    - 喷泉模型
    - 快速开发模型（RAD）
    - 构件组装模型（CBSD）
    - 敏捷开发方法
- 第二节.企业信息化战略与实施
- - 信息系统开发方法
  - - 结构化方法
    - 原型法
    - 面向对象方法
    - 面向服务方法
- 第三节.需求工程
- - 需求开发——需求分类与需求获取
- 第四节.系统设计——结构化设计
- - 基本原则
  - 内聚和耦合
  - 系统结构/模块结构
- 第五节.软件测试
- - 测试原则
  - 测试类型
  - 测试用例设计
  - 测试阶段
  - McCabe复杂度(又称圈复杂度)（必考）
- 第六节.系统运行与维护
- 第七节.软件过程改进——CMMI
- - 什么是CMMI/li>
  - CMMI 中阶段式的五个等级
  - 题外话（很有用的哦!）
- 第八节.项目管理基础知识
- - 摘要
  - 时间管理
  - 风险管理
  - - 风险曝光度
  - 配置管理和变更管理

第十一章.软件工程

第一节.软件开发模型

??开发模型是软件工程中指导开发的一种开发思想和开发体系。
??不同的开发模型分成不同的阶段，具有不同的指导思想，做着不同的事情。
??开发模型多种多样，经过几十年的发展，产生了很多开发模型，各种开发模型各有特色。

讲到这里，似乎还没有看出有什么缺陷，做事情先有计划再分步骤进行，每个步骤完成后做评审，这似乎是一种很好的方式，而且改进后的瀑布模型还加了回溯的通道。
这样子看起来似乎还不错，为什么会导致那么严重的问题呢br> 根本性原因是需求阶段难以把控。软件的需求往往是不明确的，往往是在项目的初期阶段。你要在软件需求的项目初期能明确几乎是不可能，这就导致了在需求不明确时就开始做，而我们开始做的时候认为这种需求就是用户所需要的东西，完成开发阶段之后交给客户去验收，很大概率会推翻你的所有工作，为什么呢户会告诉你这里不行，哪里不行，哪里需要改，这个思路跟我们想的不一样等等这些问题，所以需要回到需求分析重新开始。这样子会导致浪费大量的时间，最终导致软件项目的失败，就是因为这个原因使得瀑布模型很难完成项目的开发。

瀑布模型适用于什么样的场合呢br> 需求明确或者是二次开发的情况下。当然我们也可以把瀑布模型用在这种场合下，用其它模型先把需求做明确，再按照瀑布模型完成开发阶段和维护阶段，这也是可以的。

总结
??瀑布模型是一个结构化方法中的模型，一般应用于结构化的开发。
??瀑布模型只适用于需求明确的项目，对于需求不明确的项目千万不要使用瀑布模型做开发。

瀑布模型是比较早的一种模型。在它出现之后，引起人们对模型的疯狂追逐，所以产生了很多其它的一些模型。当然，在产生其它模型的同时人们也注意到瀑布模型巨大的缺陷，所以试图避免瀑布模型的缺陷在其它模型中重新出现，避免重蹈覆辙。

其他经典模型

好处：核心模块比较早的和用户进行了接触，在每一轮交给用户去看相关效果的时候，都相当于对核心模块进行再一次的审视，所以这种项目做下来风险会小很多，这是不会出现最后用户提出来核心功能不行需要修改的情况，要修改的内容在整个流程中就已经改完了。

总结
??这就是原型模型和瀑布模型与其它模型的一些区别和联系。
??原型强调构造一个简易的系统，而且它是针对需求不明确的情况。

螺旋模型

特点①：测试起到了更重要的地位。因为V模式的测试被细化到了单元测试、集成测试、系统测试、验收测试，而不是像瀑布模型中只有一个软件测试。
特点②：阶段画成V字型其实是有他的用意的，其实就是各个阶段的对应关系。如：需求分析跟验收测试和系统测试有着对应关系。
需求分析阶段会去写验收测试和系统测试的测试计划。
为什么要这么早去写测试计划呢是希望提早能够发现问题，因为在瀑布模型中我们把软件测试压到最尾端，这种方式的缺点是当你发现问题时，反过来想要去修正代码就不太好改了，如果你要想要修改的话相当于是从需求分析来写起，消耗的成本过高，如果说我们在需求分析阶段就写验收测试的测试计划，那么写测试计划时候就会从测试的眼光看待问题，那么在这个过程中必然就能够发现一些需求所产生的问题。
概要设计阶段会去写集成测试的测试计划。
因为概要设计主要是进行模块的划分，而集成测试测得就是模块之间的衔接。如果说你在进行模块划分的时候就考虑到了我要去测试这些模块之间的衔接是否正常，也就能够发现一些模块划分的问题。
当然，详细测试阶段会去写单元测试的测试计划。这就是V模型。
V模型是一个强调测试的模型，强调要及早地进行测试，强调测试要贯穿于开发的始终，而不是压到最尾端，否则会出现很多问题。
这就好比我们建设房子，砌墙是基本功，如果说你想把一面墙给砌平砌直有两种方式，一种方式就是先砌然后拉水泥线和铅垂线来从水平维度和垂直维度来分析，看看墙面是否平直；另外一种方式是先拉好线然后卡着线砌上去；毋庸置疑，肯定是是先拉线然后再砌上去比较好，卡着线砌上去是不容易出问题的。而瀑布模型实际上是选择第一种方式，先做然后再进行验证，这其实就是验证能够找出问题来，但是修正成本过高，就好比建了一扇墙，一侧发现不平不直，接下来怎么办呢就头疼了，你需要把墙敲掉再重新来，这样成本就太高了，所以V模型就是通过这样一种手段能够起到这样一种效果。

喷泉模型

最大的特点：该模型是一个面向对象的模型。因为在老一代的这种模型中，瀑布模型、原型模型、V模型、增量模型都是结构化方法底下的，所以喷泉模型提出来的时候是面向对象的，故称为它最大的特点。
因为它是面向对象模型，所以就会有面向对象模型的共性在其中，即它的特点当中具有迭代和无间隙。

构件组装模型（CBSD）

这种模型的基本思路是什么呢br> 把软件开发当中的各个模块考虑成为标准的构件，做成标准构件之后，通过一定的方式进行组装就得到了我们最终需要的软件。

那么这种思路为什么能够得到广泛的认可呢br> 其中一个最重要的原因就是极大的提高了软件开发的复用性，一旦提高了复用性就可以使得软件的总时长极大的减小，可以使软件的成本降低，同时还可以使软件的可靠性增加，缩短时间减少成本。

为什么能够提高可靠性呢br> 因为在CBSD这种开发模型当中会建立一个构件库，这个构件库中的构件如果说在新的系统中用得上，就可以直接提取出来应用它。构件库中有着以前很多的构件，这些构件以前运用到其它系统中的构件，这些构件的可靠性已经经过了很长时间的验证，如果说有问题，在以前的系统中就已经发现并修正了，所以在应用到新的系统中，出错的效率就远远小于新开发的构件，正是因为有着这样的新特色，CBSD也就是有着非常强的竞争力。很多的软件开发模型都应用到了这种思想，如RAD。

敏捷开发并不是一个模型，而是一组模型，像自适应开发、特征驱动开发等等都是属于敏捷开发模型，这些模型有着共同的价值观，有着共同的处置原则，甚至于很多最佳实践都是保持一致的。
基本原则部分分析
短平快的会议：对于大型机构往往会议会比较多而会议又比较耗时，这样其实就消耗了项目组大量的资源。因为对于软件项目开发来说，最重要的就是人力资源，如果你把人力资源都用来开很多无意义的会议上往往会有造成浪费。实现这一原则的做法：首先把不必要的会议砍掉，如：传达某种意见或意思的会议可以通过其它形式替代；把现有的会议缩短甚至是站立式的会议，这样子就形成控制时长和高效快捷的会议。
小型版本发布：因为你做再多的文档最终运行的还是软件产品，得到用户认可的也是软件产品，所以做一些小型的版本让用户在整个开发流程中能够使用这些版本，能够及时发现一些问题并按照用户的需求进行修改。这一点跟原型思路有点接近，原型是构造一个简易的系统。
4大价值观
沟通（对内对外都非常重要）
简单（不要过度设计，能够满足基本需求就可以了）
反馈（随时跟客户反馈相关情况，这样子有问题就能够及时调整）、
勇气（同时强调大家要有勇气去面对变更，因为很多人面对变更是很头痛的。对于开发人员来说变更不是啥好事，但是也不可避免，既然如此迟变不如早变，早变反而有更大的主动性，成本就会更低一些）。
最有代表性几个的最佳实践
计划游戏：强调设计一个游戏可以让用户能够直接参与进来，而非制作原来的一些墨守成规的文档化的一些东西。
隐喻：要善于用比喻的方式跟用户表述一些问题。
测试先行：编写代码前把测试提前想出来。
结对编程：两个人一组，一个人编码另外一个人检查代码，看上去是两个人在做一个人的事情，效率降低了，但事实上两个人都用心在做事情，往往效果不会降低，反而会变得更高。为什么呢为两个人的思考会变得更全面，同时开发不会很耗时，调试会很耗时。两个人进行商量往往更快的找出问题所在，缩短调试的时间。
集体代码所有制：参与开发的人都能够看到这些代码。
正是因为这些开发的思路让国内并不是很认可敏捷开发方法，在国外应用的还是很不错的。

当敏捷模型的基本原则都达到要求时，就进入了下一个轮回，为什么呢br> 这就相当于原来是减，然后减难以控制就变繁，即加了很多的流程规范，流程规范过多就导致走出了正常的尺度，那么咱们就需要回归到轻量级简单级的开发模式。基本就是这种思路，但是这种状态和项目开始比较简单的状态有着本质上的差异，同时敏捷方法也有着很大的局限性，为什么这么讲呢为敏捷方法的思路只使用中小型项目，绝大部分是小型项目，中型项目就有点为难。一般是小型项目，做小型项目一般是比较合适的，因为你砍掉一些文档是没有问题的，核心文档抓住就行了，但如果是大型项目就有点力不从心了。因为IBM做过这种尝试，用极限编程（XP方法）来做一个项目，而且还是作为极限编程的样本工程，结果项目做了不到两年失败了，原因就是规模太大，不适合敏捷开发方法。所以敏捷方法往往是适用于小项目，它强调的是小步快跑的模式去做项目。

如果说让大家写一篇敏捷开发的文章，你可以取几个点来讲，比如：讲一讲敏捷编程的思路，讲一讲每周工作40小时不加班的好处，运作过程中遇到些什么问题等等。从这些思路进行分析进行探讨。

第二节.企业信息化战略与实施

信息系统开发方法

信息系统开发方法主要分成四种方法。

所谓业务需求，其实是从业务的角度有一个比较总态的一个描述。比方说我的企业要开发一套财务管理系统，那这个时候如果说我们有内部团队会是一个什么样场景呢家可以想象一下，如果说我是这一家公司的总经理，那我会把我开发部门的经理叫过来。我告诉他，按现在公司业务发展的需求，我们需要开发一套适合于自身的财务系统。然后把财务的审批、费用的销等等这些东西给系统管理起来。大致讲一下宏观方面，我们对这个系统的一个初步的想法，大的方面的想法。这个时候业务部门的这个经理，开发部门的经理他可能会提出疑问来。那具体来讲咱们哪些职位会用到财务系统，每一个职位，它具体有什么样的要求了作为公司的总经理，我是不会去跟他讲这些东西的，我只会告诉他这套系统反正是内部人员用，大致是会涉及到哪些角色，在讲宏观的业务的需求的时候会提到。

那这个时候你作为开发部门的经理，你就会要去思考一个问题，这套系统为了满足业务的要求，我们应该要涉及到哪些角色，要做哪些事情。有这个初步想法之后了，你应该去找各个角色去进行沟通，由各个角色给你反馈。你比如说会计，比如说出纳，你去跟他聊的时候，你从它的那里去获取到，从这一个角色本身的角度来看，需要一些什么样的功能，需要走什么样的流程，就是这样的一个思路。聊完了之后，把这些各个用户从他们自身角度描述的比较微观的这些需求把它们收集起来，这是用户需求。

用户需求收集到之后，要把它转成系统需求。系统需求就是把用户需求转换成计算机能够指导开发的需求。比如说哪些地方它往往是以窗口的形式表达，哪些地方是以选择的方式是来进行，等等这些东西要考虑进去。具体来讲，系统层次的需求会包括功能需求、性能需求和设计约束。

功能需求即要完成哪些功能。
性能需求也称为非功能需求。比如说我的这一个系统的响应时间要达到什么指标，安全性有什么要求，可靠性有什么要求，这些东西属于了性能需求，更加完整全面地来讲的话是非功能需求。
设计约束书上给它的定义是既非功能需求也非性能需求。这样子讲仍然很抽象。我们举一个例子来进行说明，什么情况是属于设计约束。比方说我们要开发一个系统，经过功能和性能这方面的一些研究之后，我们觉得了要完成它的功能，达到它的性能。选的开发平台既可以是 Java 也可以是 Ginit 都可以达到这样的一个要求。但是客户告诉我们他们的维护团队主要是 Ginit 这一块的，所以他希望用 Ginit 开发，这就属于设计约束。因为它跟功能和性能已然没有关系了。这是这样一个情况。还有有的时候用户会指定说我要用自主研发的数据库，我要用 Oracle 数据库，我要用 MySQL 数据库等等。这是另外的一个情况。

从 QFD 质量展开模型的这一个角度来看的话，需求可以分为基本需求、期望需求和兴奋需求。

基本需求就是用户明确提出来需要完成的一些需求。这部分需求对于我们开发团队而言是必须要去完成。

希望需求是用户没有明确提出来，但是用户觉得这个话根本不用我讲，你就应该要把这个事情做好，他认为理所应当，这个系统要达成这样的一个效果，这一部分需求也是你必须要去做的。有的时候我们为什么会讲需求工作难做，客户没讲，但你要领会到他的意思，把他做出来，否则他也不满意。

兴奋需求就是用户没有提出来要做这个事情，他也没有觉得这个事情是必须要做的，而开发人员给做了。就好比我们开发一套财务系统好财务的有一些指标，可能我们要用一些表的方式整体地总态地体现出来会比较好。客户只要求到这一个程度，结果你的开发人员一看说，直接使用表，看起来似乎有些枯燥。对很多指标我给你既有表也有这一个曲线图，还有饼图之类的，给你把这个整个的一些情况趋势都给展现出来。这种做法对于客户而言，他是开心兴奋的。因为除了做好他要做的希望得到的效果以外，还有额外的东西也给他做好了，超预期了，他是很开心的。但是这种做法我们是不提倡，甚至是要严格控制的。为什么/strong>
如果说你作为开发方的角度来看，这就是一个风险极大的事情。因为你去做这些额外的事情会涉及到成本的增加，本来可能一个月就能够完成的任务，因为你的程序员私自加了这么一些需求给他实现了，所以导致这个项目做到了一个月零几天。那么这几天的成本是不是由项目组来支付啦。所以很有可能一个利润很高的项目就被这么一些小的东西给折腾，一些无关紧要不需要去实现的需求给他消耗掉成本了，导致了项目没什么太多利润，这种情况当然要杜绝了。

所以从 QFD 的角度了，是要我们分清楚哪些事情我们该做这些事了，我们必须得去做哪些事情不该做，那就杜绝他不要去做他，这是这一个分类的问题。

第四节.系统设计——结构化设计

所谓结构化设计，其实就是结构化方法里面的软件设计问题。

基本原则

第五节.软件测试

PS：软件测试是考试当中每次都会考到的一个知识点。软件测试的内容主要是出现在上午题中，偶尔作为小的问题出现在案例分歧当中，同时也有一定的几率的出现在论文当中。当然一般我们对测试有着一些基本的认识，同时按方法去练好论文的技巧。

测试原则

尽早、不断地进行测试
这一点和我们之前所讲到的V模型是非常吻合的。V模型认为咱们做测试工作如果说把测试工作都压在最后面去做，这会有极大的风险。因为当你发现问题的时候，你要去修改会要做非常大的一些调整。所以要尽可能早的去做测试，这样子发现问题可以以代价很低的时候就予以修正。

程序员要避免测试自己设计的程序
因为从人性的角度来看，这段程序是程序员编写的，然后你花了很多时间精力去编写它，希望把它做得尽善尽美。从内心里面来讲，你希望它满是窗怡，而非到处是 BUG。所以说了你在测试的时候，潜意识里会按你自己设计的思路去设计一些了能够通过测试的用例，而不会想着想尽办法找出他的错误了，这是一方面。
另一方面就是因为你带有你设计的思路去做相应的测试，这种测试是不全面的，因为你想到的你就设计进来了，你没有想到的那一部分很可能就有瑕疵，有问题的部分。即你做设计的时候没想到你做测试的时候仍然没有想到，所以不应该由程序员去测自己的写的程序，这样子做就不容易找出问题。

既要选择有效、合理的数据，也要选择无效、不合理的数据
有效合理的意思就是在合法的取值范围之类。你比如说要输入一个年龄，设计输入数据为 1 岁、5岁、10岁、90岁等等，这些都是属于合法的数据，它能够录入到系统并且正常处理。但是你不能够仅仅只选这些数据，除了这些数据你还要选不合理的数据，比如说输入数据为 300岁看看会是什么情况为现在还没有人活到这么高的年龄，和这个年龄相差甚远，最多也就活到 100 多岁，一般输到300，说明了输入的数据很有可能出错了。好像这种不合理的数据要输入还有什么数据呢比如说 101 岁，后面这个 1 了输成了小写字母的 L 看上去和 101 非常像。那这种数据也要输进去测一测为什么为很有可能用户在使用的过程中一不留神 copy 了一个年龄，一看以为是101，结果了后面是 L 那用户用的时候就会发现错了，他不知道是什么原因。所以在测试的时候，这些五花八门的情况都要测进去看。面对这种不合理非法数据的时候，系统是怎么反映的用程序会不会立马崩溃，异常错误之类。所以测试数据要显得全面，既有有合理的，也要有不合理的。

修改之后应进行回归测试
什么叫回归测试了修改成功一些 bug 之后，不要直接就发布并使用该系统，这是不行的。因为你修改一个 bug 之后，很有可能引入其他的 bug，这个时候你需要做回归测试，就是把之前已经测过的这个模块重新再测一测，看会不会发生新的问题。

尚未发现的错误数与该程序已发现的错误数成正比
这句话的意思就是有一个程序 A 我们经过测试发现了它有 30 个 bug。有一个程序 B 经过测试发现了它有 100 个 bug。A 和 B 所有 BUG 全部修正之后，应该重点测哪个模块呢该重点测模块B 因为尚未发现的错误数量与该程序已发现错误数成正比。为什么会有这种情况呢为模块之间它的难度会有很大差异。对于原来写得好的程序，可能测出来整体的 bug 数就会比较少，同时它隐藏的 bug 了也比较少。而对于找到了大量 bug 的，往往是不成熟的团队开发的，可能隐藏了更多的问题。所以要利用到这一点来做一些分析。你像这两个模块把所有的 bug 都修正之后，重点测的还是 B 模块。这就成正比的原因。
另外一个方面就是修正一个 bug 会引入新的 bug，那 100 个 bug 修正引入新 bug 的数量，也会比 30 个引入新 bug 的这个情况会要严重一些。

这是测试的一些基本原则。当然测试的原则肯定不仅仅只有这么五条测试的基本原则，它是一种思想。
既然是一种思想，它可以有很多很多的讲法，只要符合测试的基本观念思想就是 OK 的。所以这五条基本的原则可以引申出很多条。所以在了解这些概念的时候，我们更重要的是注意它如何去推导出来，是什么理念，这样子才能够举一反三。

测试类型

白盒测试法 指的在测试的时候，你能够把这一个软件模块看成一个白盒子。你能够打开盒子，看到里面是怎么样的一个情况，看里面的结构是怎么样的。即知道软件模块的内部结构。

以程序模块为例来说明黑盒和白盒测试。
如果说是黑盒测试，我们只知道这个模块的功能是什么，它要输入什么样的参数，它将输出什么样的结果，测试的时候以什么方式来衡量模块是对还是错。比如：它是一个加法模块，输入 1 和 1，得到的结果观察是不是 2 。如果得到的结果是2，我们认为这一组测试用例得到了正确的结果。再用其他的测试用例来进行测试，查看得到的输出是否为正确的结果。
如果说是白盒测试，我们可以看到程序的内部结构，通过程序内部结构来设计测试用例。比如说我们看到一个分支，那我测试用例设计的时候可能就考虑设计用例不能够设计都走一条路线，应该设计两个真分支和假分支，两个分支分别设计一个测试用例。
所以说相对来讲，从理论上来讲，白盒测试往往会比黑盒测试了能够做得更加全面一些，因为你可以看到它结构，当你看到它结构，把所有结构当中的路径全部都用测试用例覆盖一遍的时候，你的测试是完整的完善的。而黑盒测试了是没有这种先天条件的。但是通过科学合理的方法设计，我们也能够把这种覆盖度达到一定的程度。

黑盒测试的测试方法
等价类划分
首先考虑这一个程序模块它的功能是什么，然后它处理这些数据里面哪些数据可以归为一类，分类之后从每个类中设计测试样例。举个栗子，把成绩分等级进行划分，高于 90 分或者等于 90 分的分数我们认为它是优；大于 70 分的是良；高于 60 分的是及格；低于 60 分的是不及格。划分之后我们设计测试用例，在优的范围内选择 95 分来测，在良的范围内选择 88 分来测，在及格的范围内选择 63 分来测，在不及格的范围内选择 8 分来测。测试完之后，我们会发现，虽然我们没有看程序的内部结构但是你测的时候打开盒子一看，会发现你选的测试用例 95、88、63、8都是走的不同的路径，故这种方法也是非常科学，应用十分的广泛。
这是等价类划分。它会考虑把所有的数据类进行归总，看哪些是具有代表性的并且属于一类。在同一类里面我们选一个出来测就 OK 了。由于做了等价类划分，所以可以使得咱们整个的覆盖面会要更加全面一些。

边界值分析
边界值分析是指测试的时候测的是边界值。我们讲 90 分以上的是优等，这是包含 90 分的。像我们等价类划分举的这一系列例子，是不能够
发现边界值是否满足条件。你测 95 也好，88也好，63也好，都不能够发现边界值问题，那要怎么办呢要测 90 你就会发现问题了，90本来应该分成优的，结果被分成了良，所以出问题了，这就测出来了。90是属于边界值，它是属于边缘性的值，正好在两种不同的这个等价类之间的边界上。所以边界是一个极其容易发生问题的地方。所以边界值分析强调我们要去注重边界值的测试。
相信大家对等价类和边界值有一定了解。而我们平常应用的过程中，绝大部分时候会把两种结合起来，即划分等价类测试也侧边界值。举个例子，年龄的取值范围是 0 到150，那我们要做边界值分析的测试应该测哪些点呢求测试年龄的值是整数值。像这种区间问题，往往边界值只有四个，-1、0、150、151。这四个点分别是正好在两个端点上面的，略小于端点的、略大于端点的。

错误推导
错误推导，没什么章法可言，他强调的是一种经验。其实我们平常也经常遇到这种情况。比如说你以前做开发，现在了做项目经理或者说做技术总监，你会发现底下的人写出的代码，他们也经过了自己的一些检查测试，但是有些问题难以发现。而到了你手上，你一看随便一测就发现问题了。原因是什么呢因就是你有丰富的经验，你知道哪些地方容易产生问题，所以你一测就测出了问题。错误推测法就是这种意思，我们会去推测哪些地方有可能产生问题，就去测这些地方，而不是非常严整的思路去走。这种方式实际上应用也非常多。像微软的庞大的测试团队里面就有一类了，非常另类的人为什么讲他们另类呢们有非科班出身，也没有接受过专业的训练，甚至于有些人家庭妇女，没有专业技术找他们来做测试。但是很奇怪的一点，就是往往这类人能够发现一些用其他方法所找不到的问题，就是灵光一闪，觉得哪里有可能有问题，一测果然有问题。这就是错误推测法，往往强调的是一种经验灵感之类的。

因果图
因果图就是由果分析原因的这种方式。即有了一个结果或者一个问题，我们反推分析出它的原因。

白盒测试的测试方法
白盒测试有基本路径测试、循环覆盖测试和逻辑覆盖测试三种测试方法。其中我们主要要了解的是一系列的逻辑覆盖。

语句覆盖就是程序当中所有的语句都要被执行一遍，你测试设计若干个测试用例，能够确保程序当中所有语句都通过你的用例过了一遍，看起来覆盖比较全面。实际上不是这样的，语句覆盖是所有的覆盖里面层次最低的，因为在整个的程序中可能会有非常多条的路径，如：dfs算法、bfs算法它们不仅仅只有语句一条路，因为它们画出递归搜索树可以清晰的看到存在多条路径。
判定覆盖就是将所有判定真假分支都要覆盖一遍。
条件覆盖就是把判定拆分开，判定的多条分支都会覆盖掉。因为这一个判定可能是两个条件拼起来的，如分成和两个真假条件。那这个条件的真假分支都要被覆盖。条件覆盖比判定覆盖又要高一层。
条件判定覆盖就是组合形式的覆盖。后面还有几种的都是类似的一个情况，这里不详细说了。一般了解语句覆盖、判定覆盖、条件覆盖和路径覆盖就可以。
路径覆盖就是把已经达到了所有可行的路径全部覆盖了一遍，这时就达到了最高级别的一个覆盖。

测试阶段

软件测试阶段主要分单元测试、集成测试、确认测试和系统测试。

声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！