软件设计师-软件工程
2023-10-27 00:04:16 0 举报AI智能生成
软件设计师考点
作者其他创作
大纲/内容
这种方法采用结构化技术来完成软件开发的各项任务。该方法把软件生命周期的全过程依次划分为若干阶段，然后顺序地完成每个阶段的任务，与瀑布模型有很好的结合度，是与其最相适应的开发方法。
自顶向下，逐步分解
核心思想
数据的输入，存储都涉及不同的数据结构，面向数据结构的基本思想是根据数据结构导出程序结构。
先建立系统的数据结构；接着以数据结构为基础，对应的建立程序结构；列出程序中要用到的各种基本操作，然后将操作分配到适当的模块中去
Jackson 方法
也被称为逻辑构造程序方法（简称LCP）
Warnier图是表示数据层次结构的一种图形工具，它采用树形结构来描绘数据结构，能够指出某一类数据或某一数据元素重复出现的次数，并能指明某一特定数据在某一类数据中是否是有条件的出现。
warnier 方法
典型的面向数据结构的设计方法包括
面向数据结构的设计方法并没有明显地使用软件结构的概念，对于模块独立性原则也重视不足，因此并不适合于复杂的软件系统
面向数据结构的设计
结构化分析与设计
这种方法引入了对象的概念，将数据和方法封装在一起，提高了模块的聚合度，降低了耦合度，更大程度上支持软件复用。面向对象方法是现在最流行和最具有发展前景的软件开发方法
面向对象分析与设计
结构开发方法论
用于发现需求，描述需求，主要包括功能需求、性能需求、环境需求、可靠性需求、安全保密要求、用户界面需求、资源使用需求、软件成本消耗与开发进度需求、预先估计以后系统可能达到的目标
问题识别
对问题进行分析，然后在此基础上整合出解决方案
这个步骤经常是反复进行的，常用的方法有面向数据流的结构化分析方法，面向数据结构的Jackson方法，面向对象的分析方法，以及用于建立动态模型的状态迁移图和Petri网
分析与综合
也就是对已经确定的需求进行文档化描述，该文档通常称为软件需求说明书（需求规格说明书）
编制需求分析的文档
它是需求分析工作的最后一步，主要是对功能的正确性、完整性和清晰性，以及其他需求给予评价
需求分析与评审
工作分成四个方面
必须能够表达和理解问题的信息域和功能域。
必须表示软件的行为（作为外部事件的结果）
必须划分描述信息、功能和行为的模型，从而使得可以以层次的方式揭示细节
分析过程应该从要素信息移向细节实现
必须按自顶向下、逐层分解的方式对问题进行分解和不断细化。
要给出系统的逻辑视图和物理视图
需求分析的原则
是指系统必须完成的那些事，即为了向它的用户提供有用的功能，产品必须执行的动作
功能需求
是指产品必须具备的属性或品质，如可靠性、性能、响应时间、容错性、扩展性等
非功能需求
也称为限制条件、补充规约，这通常是对解决方案的一些约束说明，例如必须采用国有自主知识版权的数据库系统、必须运行在UNIX操作系统之下等等
设计约束
是指反映组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求
业务需求
是指描述用户使用产品必须要完成什么任务、怎么完成的需求，通常是在问题定义的基础上进行用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求
用户需求
是从系统的角度来说明软件的需求，它就包括了用特性说明的功能需求，质量属性以及其他非功能需求，还有设计约束
系统需求
需求的分类
需求开发
需求管理
包含
人们通常总存在急于求成的倾向，甚至在问题被很好地理解前，这经常会导致产生一个解决错误问题的优美软件的诞生
在开始建立分析模型前先理解问题
使得用户能够了解将如何发生人机交互。因为人们一般对软件质量的感觉经常基于对界面\"友好性\"的感觉，因此，强力推荐使用原型方法
开发原型
这是建立回溯到客户的可追踪性的第一步
记录每个需求的起源及原因
建立数据、功能和行为模型，为软件工程师提供三种不同的视图，这将减少忽视某些东西的可能性，并增加识别不一致性的可能性
使用多个需求视图
过短的时限可能使每个软件需求得到实现的可能性减小，如果采用增量模型，必须标识那些将在第一个增量中要交付的需求
给需求赋予优先级
因为大多数需求以自然语言描述，存在含糊性的可能，正式的技术复审是发现并删除含糊性的一种方法
努力删除含糊性
指导原则
需求工程
数据流图从数据传递和加工的角度，以图形的方式描述数据在系统流程中流动和处理的移动变换过程，反映数据的流向、自然的逻辑过程和必要的逻辑数据存储
在圆中注明加工的名字与编号
加工
在箭头边给出数据流的名称与编号，注意不是控制流
数据流
文件名称为名词或名词性短语
数据存储文件
在方框中注明数据源或汇点的名称
数据源点或汇点
基本图形
自外向内，自顶向下，逐层细化，完善求精。
保持父图与子图的平衡
除顶层图外，其余分层数据流图从0开始编号
对任何一层数据流图来说，称它的上层数据流图为父图，在它的下一层的数据流图为子图
顶层数据流图只含有一个加工，表示整个系统；输入数据流和输出数据流为系统的输入数据和输出数据，表明了系统的范围，以及与外部环境的数据交换关系
底层数据流图是指其加工不能再分解的数据流图，其加工称为\"原子加工\".
中间数据流图是对父层数据流图中某个加工进行细化，而它的某个加工也可以再次细化，形成子图。中间层次的多少，一般视系统的复杂程度而定
任何一个数据流子图必须与它上一层父图的某个加工对应，二者的输入数据流和输出数据流必须保持一致，即父图与子图的平衡。父图与子图的平衡是数据流图中的重要性质，保证了数据流图的一致性，便于分析人员阅读和理解
根据层次关系一般将数据流图分为顶层数据流图、中间数据流图和底层数据流图
数据流图设计要略
数据流图
数据字典是关于数据信息的集合，也就是对数据流图中包含的所有元素定义的集合
数据流图和数据字典共同构成系统的逻辑模型
没有数据流图，数据字典难以发挥作用；没有数据字典，数据流图就不严格
只有把数据流图和对数据流图中每个元素的精确定义放在一起，才能共同构成系统的规格说明。
数据项条目给出了某个数据单项的定义，通常为数据项值的类型、允许的取值范围等
数据项条目
数据流条目给出某个数据流的定义，它通常是列出该数据流的各组成数据项
有些数据流的组成比较复杂，可以采用自顶向下分解的方式将它表示成更低层次的组合，一直分解到每个与项目有关的人都清楚其准确含义时为止
数据流条目
文件条目给出某个文件的定义，通常也是列出其记录的组成数据项。此外，还可以指出文件的组织方式，如按单号递增次序排列等
文件条目
加工条目是对数据流图中每一个不能再分解的基本加工的精确说明
说明中应精确描述用户要求某个加工做什么，包括加工的激发条件、加工逻辑、优先级、执行频率和出错处理等
其中加工逻辑是最基本的部分，它描述了输入数据流、输入文件与输出数据流、输出文件之间的逻辑关系
加工条目
数据字典中有4种类型的条目
数据流设计
数据元素字典设计
数据处理字典设计
数据结构字典设计
数据存储设计
数据字典的设计包括
数据对象或控制项、数据存储或外部实体的名字
名称
别名或编号
数据对象？加工？数据流？数据文件？外部实体？控制项（事件/状态）
分类
描述内容或数据结构等
描述
使用该词条（数据或控制项）的加工
何处使用
每一个词条中应包含以下信息
介于自然语言和形式语言之间的一种半形式语言，是在自然语言基础之上加了一些限制，使用有限的词汇和有限的语句来描述加工逻辑
即简单的祈使语句
判断语句
循环语句
结构化语言是受结构化程序设计思想启发而扩展出来的。结构化程序设计只允三种基本结构
祈使句中的动词
数据字典中定义的名词
逻辑表达式中的保留字
结构化语言使用三类词汇
结构化语言
若一个动作的执行不只是依赖一个条件，而是与多个条件有关，那么这项策略的表达就比较复杂
如果用结构化语言的判断语句，就有多重嵌套。层次一多，可读性就下降。用判定树来表示，可以更直观一些
判定树
一些条件较多、在每个条件下取值也较多的判定问题，可以用判定表表示
判定表能清晰地表达复杂的条件组合与应做动作之间的对应关系，判定表的优点是能够简洁，无二义性地描述所有的处理规则
但判定表表示的是静态逻辑，是在某种条件取值组合情况下可能的结果，它不能表达加工的顺序，也不能表达循环结构，因此判定表不能成为一种通用的设计工具
判定表
对加工的描述
数据字典
需求分析
在软件设计阶段，主要考查结构化设计，模块内聚与耦合等概念。
概要设计也称为高层设计，将软件需求转化为数据结构和软件的系统结构。例如：如果采用结构化设计，则将从宏观的角度将软件划分成各个组成模块，并确定模块的功能以及模块之间的调用关系。
概要设计主要是设计软件的结构，确定系统是由哪些模块组成的，以及每个模块之间的关系。它采用的是结构图（包括模块、调用、数据）来描述程序的结构，还可以使用层次图和HIPO（层次图加输入/处理/输出图）
整个过程主要包括：复查基本系统模型，复查并精化数据流图，确定数据流图的信息流类型（包括交换流和事务流），根据流类型分别实施变换分析或事务分析，根据软件设计原则对得到的软件结构图进一步优化。
概要设计
详细设计也称为低层设计，将对结构表示进行细化，得到详细的数据结构与算法。同样的，如果采用结构化设计，则详细设计的任务就是为每个模块进行设计
详细设计确定应该如何具体地实现所要求的系统，得出对目标系统的精确描述。它采用自顶向下、逐步求精的设计方式和单入口单出口的控制结构
经常使用的工具包括程序流程图、盒图、PAD图（问题分析图）、PDL（伪码）
详细设计
制定规范，作为设计的共同标准
完成软件系统结构的总体设计，将复杂系统按功能划分为模块的层次结构，然后确定模块的功能，以及模块间的调用关系、模块间的组成关系
设计处理方式，包括算法、性能、周转时间、响应时间、吞吐量、精度等
设计数据结构
可靠性设计
编写设计文档，包括概要设计说明书、详细设计说明书、数据库设计说明书、用户手册、初步的测试计划等
设计评审，主要是对设计文档进行评审
在整个软件设计过程中，需完成以下工作任务
数据设计是实施软件工程中的4个设计活动的第一个。由于数据结构对程序结构和过程复杂性都有影响，数据结构对软件质量的影响是很深远的
好的数据设计将改善程序结构和模块划分，降低过程复杂性
数据设计将分析时创建的信息域模型变换成实现软件所需的数据结构
在实体-关系图（E-R图）中定义的数据对象和关系以及数据字典中描述的详细数据内容为数据设计活动奠定了基础
数据设计
主要目标是开发一个模块化的程序结构，并表示出模块间的控制关系
体系结构设计将程序结构和数据结构相结合，为数据在程序中的流动定义了接口
体系结构设计
接口设计描述了软件内部、软件和协作系统之间以及软件域人（用户）之间如何通信
一个接口意味着信息流（如数据和/或控制流），因此，数据和控制流图提供了接口设计所需的信息
设计软件模块间的接口
设计模块和其他非人的信息生产者和消费者（比如外部实体）的接口
设计人（用户）和计算机间的接口（通常简称为\"人机接口\"或\"人机界面\"）
接口设计主要包括三个方面
接口设计要实现的内容包括一般交互、信息显示和数据输入
接口设计（界面设计）
过程设计应该在数据设计、体系结构设计和接口设计完成之后进行
所有的程序都可以建立在一组已有的逻辑构成元素上，这一组逻辑构成元素强调了\"对功能域的维护\
过程设计
软件设计活动
过程的抽象
数据抽象
控制抽象
抽象化
自顶向下，逐步细化
信息隐蔽是开发整体程序结构时使用的法则，即将每个程序的成分隐蔽或封装在一个单一的设计模块中，并且尽可能少地暴露其内部的处理
通过信息隐蔽可以提高软件的可修改性、可测试性和可移植性，它也是现代软件设计的一个关键性原则
信息隐蔽
模块独立是指每个模块完成一个相对独立的特定子功能，并且与其他模块之间的联系最简单
保持模块的高度独立性，也是在设计时的一个很重要的原则。通常我们用耦合（模块之间联系的紧密程度）和内聚（模块内部各元素之间联系的紧密程度）两个标准来衡量，我们的目标是高内聚、低耦合。
完成一个单一功能，各个部分协同工作，缺一不可
功能内聚
处理元素相关，而且必须要顺序执行
顺序内聚
所有处理元素集中在一个数据结构的区域上
通信内聚
处理元素相关，并且必须按特定的次序执行
过程内聚
所包含的任务必须在同一时间间隔内执行（如初始模块）
瞬时内聚
完成逻辑上相关的一组任务
逻辑内聚
完成一组没有关系或关系松散的任务
偶然内聚
内聚
没有直接联系，互相不依赖对方
非直接耦合
借助参数表传递简单数据
数据耦合
这个记录是某一数据结构的子结构，而不是简单变量。其实传递的是这个数据结构的地址
一个数据结构的一部分借助于模块接口被传递
标记耦合
如果一个模块通过传送开关，标志，名字等控制信息，明显的控制选择另一个模块的功能，就是控制耦合
模块间传递的信息中包含用于控制模块内部逻辑的信息
控制耦合
一组模块都访问同一全局简单变量而不是同一全局数据结构，而且不是通过参数传递该全局变量的信息，称之为外部耦合
与软件以外的环境有关
外部耦合
若一组模块都访问一个公共数据环境，则他们之间的耦合就是公共耦合
公共的数据环境可以是全局数据结构，共享的通信区，内存的公共覆盖区等
多个模块引用同一个全局数据区
公共耦合
一个模块访问另一个模块的内部数据；一个模块不通过正常入口转到另一个模块的内部；两个模块有一部分程序代码重叠；一个模块有多个入口
内容耦合
耦合
模块独立
设计要素
软件设计
符号名即标识符，包括模块名、变量名、常量名、子程序名、数据区名、缓冲区名等。这些名字应能反映它所代表的实际东西，应有一定实际意义
应当选择精练的意义明确的名字，改善对程序功能的理解。必要时可使用缩写名字，但缩写规则要一致，并且要给每一个名字加注释
在一个程序中，一个变量只应用于一种用途。就是说，在同一个程序中一个变量不能身兼几种工作
符号名的命名
程序的注释
利用空格、空行和移行，提高程序的可视化程度
恰当地利用空格，可以突出运算的优先性，避免发生运算的错误。自然的程序段之间可用空行隔开；对于选择语句和循环语句，把其中的程序段语句向右做阶梯式移行。这样可使程序的逻辑结构更加清晰，层次更加分明
视觉组织
源程序文档化
数据说明的次序应当规范化，使数据属性容易查找。
当多个变量名用一个语句说明时，应当对这些变量按字母的顺序排列。
如果设计了一个复杂的数据结构，应当使用注释来说明在程序实现时这个数据结构的固有特点
数据说明
在一行内只写一条语句，并且采取适当的移行格式，使程序的逻辑和功能变得更加明确
程序编写首先应当考虑清晰性，不要刻意追求技巧性，使程序编写得过于紧凑
程序编写得要简单，写清楚，直截了当地说明程序员的用意
除非对效率有特殊的要求，程序编写要做到清晰第一，效率第二。不要为了追求效率而丧失了清晰性。事实上，程序效率的提高主要应通过选择高效的算法来实现
首先要保证程序正确，然后才要求提高速度。反过来说，在使程序高速运行时，首先要保证它是正确的
让编译程序做简单的优化
尽可能使用库函数
避免使用临时变量而使可读性下降
尽量用公共过程或子程序去代替重复的功能代码段
用调用公共函数去代替重复使用的表达式
使用括号来清晰地表达算术表达式和逻辑表达式的运算顺序
避免不必要的转移。如果能保持程序的可读性，则不必用GOTO语句
尽量只采用三种基本的控制结构来编写程序
用逻辑表达式代替分支嵌套
避免使用空的ELSE语句和IF…THEN IF…的语句
避免使用ELSE GOTO和ELSE RETURN结构。
使与判定相联系的动作尽可能地紧跟着判定。
（18）避免采用过于复杂的条件测试。 （19）尽量减少使用\"否定\"条件的条件语句。不要让读者绕弯子想。 （20）避免过多的循环嵌套和条件嵌套。 （21）不要使GOTO语句相互交叉。 （22）避免循环的多个出口。 （23）使用数组，以避免重复的控制序列。 （24）尽可能用通俗易懂的伪码来描述程序的流程，然后再翻译成必须使用的语言。 （25）数据结构要有利于程序的简化。 （26）要模块化，使模块功能尽可能单一化，模块间的耦合能够清晰可见。 （27）利用信息隐蔽，确保每一个模块的独立性。 （28）从数据出发去构造程序。 （29）不要修补不好的程序，要重新编写。也不要一味地追求代码的复用，要重新组织。 （30）对太大的程序，要分块编写、测试，然后再集成。 （31）对递归定义的数据结构尽量使用递归过程。 （32）注意计算机浮点数运算的特点，例如：浮点数运算 10.0*0.1 通常不等于1.0. （33）不要单独进行浮点数的比较。用它们做比较，其结果常常发生异常情况。 （34）避免不恰当地追求程序效率，在改进效率前，要做出有关效率的定量估计。 （35）在程序中应有出错处理功能，一旦出现故障时不要让机器进行干预，导致停工。
语句结构和输入/输出方法
从编码原则的角度提高程序的可读性，改善程序质量
程序设计风格
程序编写
效率是一个性能要求，应当在需求分析阶段给出。软件效率以需求为准，不应以人力所及为准
好的设计可以提高效率
提高存储效率的关键是程序的简单性
程序的效率与程序的简单性相关
程序效率
软件测试是软件质量保证的主要手段之一，也是在将软件交付给客户之前所必须完成的步骤。目前，软件的正确性证明尚未得到根本的解决，软件测试仍是发现软件错误和缺陷的主要手段
软件测试的目的就是在软件投入生产性运行之前，尽可能多地发现软件产品（主要是指程序）中的错误和缺陷
把被测试对象看成一个黑盒子，测试人员完全不考虑程序的内部结构和处理过程，只在软件的接口处进行测试，依据需求规格说明书，检查程序是否满足功能要求
将所有可能的输入数据，划分为等价的部分，然后从每个部分中选取少数有代表性的数据作为测试用例
即合理、有意义的数据集合
有效等价类
即不合理、无意义的数据集合
无效等价类
而在选取测试用例时，应遵从\"设计一个新的测试用例时，应尽可能多地覆盖尚未覆盖的有效等价类；但每次应仅覆盖一个尚未覆盖的无效等价类\"的原则
等价类划分
它是对等价类划分法的一个补充，即选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。
边值分析
列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。
错误猜测
等价类划分、边界值分析都只考虑了输入条件，未考虑输入条件间的联系，而因果图则用来描述多种条件组合的测试用例，其最终生成的结果是判定表
它首先基于规格说明书分析原因（等价类）和结果（输出条件）；然后找出原因与结果之间的关系，画出因果图
在因果图上加上约束或限制条件；将其转换为判定表；根据判定表得出测试用例
因果图
它是由状态迁移图和逻辑功能模型构建的，状态迁移图用于表示输入数据序列以及相应的输出数据；逻辑功能模型用于表示在状态中输入条件与输出条件之间的对应关系
测试用例则是由测试中经过的一系列状态和在每个状态中必须依靠输入/输出数据满足的一对条件组成的
功能图
设计方法
黑盒测试法
把测试对象看作一个打开的盒子，测试人员须了解程序的内部结构和处理过程，以检查处理过程的细节为基础，对程序中尽可能多的逻辑路径进行测试，检验内部控制结构和数据结构是否有错，实际的运行状态与预期的状态是否一致
由于白盒测试是结构测试，所以被测对象基本上是源程序，以程序的内部逻辑为基础设计测试用例
基本路径测试
循环覆盖测试
语句覆盖是指选择足够多的测试用例，使得运行这些测试用例时，被测程序的每个语句至少执行一次。很显然，语句覆盖是一种很弱的覆盖标准
判定覆盖又称分支覆盖，它的含义是不仅每个语句至少执行一次，而且每个判定的每种可能的结果（分支）都至少执行一次。判定覆盖比语句覆盖强，但对程序逻辑的覆盖程度仍然不高。
条件覆盖的含义是不仅每个语句至少执行一次，而且使判定表达式中的每个条件都取到各种可能的结果。条件覆盖不一定包含判定覆盖，判定覆盖也不一定包含条件覆盖
同时满足判定覆盖和条件覆盖的逻辑覆盖称为判定/条件覆盖。它的含义是选取足够的测试用例，使得判定表达式中每个条件的所有可能结果至少出现一次，而且每个判定本身的所有可能结果也至少出现一次。
条件组合覆盖的含义是选取足够的测试用例，使得每个判定表达式中条件结果的所有可能组合至少出现一次。显然，满足条件组合覆盖的测试用例，也一定满足判定/条件覆盖。因此，条件组合覆盖是上述五种覆盖标准中最强的一种。然而，条件组合覆盖还不能保证程序中所有可能的路径都至少经过一次。
路径覆盖的含义是选取足够的测试用例，使得程序的每条可能执行到的路径都至少经过一次（如果程序中有环路，则要求每条环路径至少经过一次）。路径覆盖实际上考虑了程序中各种判定结果的所有可能组合，因此是一种较强的覆盖标准。但路径覆盖并未考虑判定中的条件结果的组合，并不能代替条件覆盖和条件组合覆盖。
以程序内部逻辑为基础的测试技术，如常用的语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、点覆盖、边覆盖、路径覆盖
逻辑覆盖测试
白盒测试法
灰盒测试是一种介于白盒测试与黑盒测试之间的测试，它关注输出对于输入的正确性。同时也关注内部表现，但这种关注不像白盒测试那样详细且完整，而只是通过一些表征性的现象、事件及标志来判断程序内部的运行状态。
灰盒测试结合了白盒测试和黑盒测试的要素，考虑了用户端、特定的系统知识和操作环境，在系统组件的协同性环境中评价应用软件的设计。
灰盒测试法
动态测试指通过运行程序发现错误
动态测试
静态测试指被测试程序不在机器上运行，而是采用人工检测和计算机辅助静态分析的手段对程序进行检测
由程序员自己检查自己编写的程序。程序员在程序通过编译之后，进行单元测试设计之前，对源程序代码进行分析、检验，并补充相关的文档，目的是发现程序中的错误。这种桌前检查，由于程序员熟悉自己的程序和自身的程序设计风格，可以节省很多的检查时间，但应避免主观片面性。
桌前检查（Desk Checking）
第一步，小组负责人提前把设计规格说明书、控制流程图、程序文本及有关要求、规范等分发给小组成员，作为评审的依据。小组成员在充分阅读这些材料之后，进入审查的第二步。
第二步，召开程序审查会。在会上，首先由程序员逐句讲解程序的逻辑。在此过程中，程序员或其他小组成员可以提出问题，展开讨论，审查错误是否存在。实践表明，程序员在讲解过程中能发现许多原来自己没有发现的错误，而讨论和争议则促进了问题的暴露。
代码审查是由若干程序员和测试员组成一个会审小组，通过阅读、讨论和争议，对程序进行静态分析的过程。代码审查分两步
代码审查
第一步，把材料先发给走查小组每个成员，让他们认真研究程序，然后再开会。
第二步，开会的程序与代码审查不同，不是简单地读程序和对照错误检查表进行检查，而是让与会者\"充当\"计算机。即首先由测试组成员为被测程序准备一批有代表性的测试用例，提交给走查小组。走查小组开会，集体扮演计算机角色，让测试用例沿程序的逻辑运行一遍，随时记录程序的踪迹，供分析和讨论用。
代码走查与代码审查基本相同，其过程也分为两步。
代码走查
方法
使用这种方法能够有效地发现30%~70%的逻辑设计和编码错误
静态测试
单元测试又称为模块测试，是针对软件设计的最小单位（程序模块）进行正确性检验的测试工作。其目的在于检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求，发现各模块内部可能存在的各种错误。单元测试需要从程序的内部结构出发设计测试用例，多个模块可以平行地独立进行单元测试。
单元测试的计划通常是在软件详细设计阶段完成的。
单元测试
集成测试也称为组装测试、联合测试（对于子系统而言，则称为部件测试）。它主要是将已通过单元测试的模块集成在一起，主要测试模块之间的协作性。
集成测试计划通常在软件概要设计阶段完成。
集成测试
确认测试也称为有效性测试，主要验证软件的功能、性能及其他特性是否与用户要求（需求）一致。确认测试计划通常在需求分析阶段完成
主要由软件开发组织内部按软件需求说明书进行测试
内部确认测试
由用户在开发环境下进行测试
a测试（Alpha测试）
由用户在实际使用环境下进行测试
b测试（Beta测试）
针对软件需求说明书，在交付前由用户为主进行的测试
验收测试
根据用户的参与程度，通常包括4种类型
确认测试
如果项目不只包含软件，还有硬件和网络等，则要将软件与外部支持的硬件、外设、支持软件、数据等其他系统元素结合在一起，在实际运行环境下，对计算机系统的一系列集成与确认测试
一般地，系统测试的主要内容包括功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、安装与反安装测试等
系统测试计划通常是在系统分析阶段（需求分析阶段）完成的
系统测试
不管是哪个阶段的测试，一旦测试出问题，就要进行修改。修改之后，为了检查这种修改是否会引起其他错误，还要对这个问题进行测试，这种测试称为回归测试或退化测试
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试
通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况
压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。
负载测试和压力测试都属于性能测试，两者可以结合进行，统称为负载压力测试
性能测试的目的是验证软件系统是否能够达到用户提出的性能指标，同时发现软件系统中存在的性能瓶颈，优化软件，最后起到优化系统的目的
测试中得到的负荷和响应时间数据可以被用于验证所计划的模型的能力，并帮助作出决策
评估系统的能力
受控的负荷可以被增加到一个极端的水平，并突破它，从而修复体系的瓶颈或薄弱的地方
识别体系中的弱点
重复运行测试，验证调整系统的活动得到了预期的结果，从而改进性能
系统调优
长时间的测试执行可导致程序发生由于内存泄露引起的失败，揭示程序中的隐含的问题或冲突
检测软件中的问题
在一个生产负荷下执行测试一定的时间是评估系统稳定性和可靠性是否满足要求的唯一方法
验证稳定性和可靠性
性能测试的目的
负载测试是一种性能测试，指数据在超负荷环境中运行，程序是否能够承担
负载测试
强度测试是一种性能测试，表明在系统资源特别低的情况下软件系统运行情
强度测试
确定系统可处理同时在线的最大用户数
容量测试
性能测试的类型
性能测试
测试的目的
第三方测试指独立于软件开发方和用户方的测试，组织的测试也称为\"独立测试\".软件质量工程强调开展独立验证和确认（IV&V）活动，是由在技术、管理和财务上与开发组织具有规定程序独立的组织执行验证和确认过程
软件第三方测试是相对独立的组织进行的软件测试，一般情况下是在模拟用户真实应用环境下，进行的软件确认测试。
第三方测试
测试类中定义的每个方法，基本上相当于传统软件测试中的单元测试
算法层
测试封装在同一个类中的所有方法与属性之间的相互作用。在面向对象软件中类是基本模块，因此可以认为这是面向对象测试中所特有的模块（单元）测试
类层
也称为主题层，测试一组协同工作的类或对象之间的相互作用。大体上相当于传统软件测试中的子系统测试，但是也有面向对象软件的特点
模板层
把各个子系统组装成完整的面向对象软件系统，在组装过程中同时进行测试
系统层
面向对象测试的主要目标，也是用尽可能低的测试成本和尽可能少的测试方案，发现尽可能多的错误
但是，面向对象程序中特有的封装、继承和多态等机制，也给面向对象测试带来一些新特点，增加了测试和调试的难度
面向对象测试
软件测试
软件经过测试，交付给用户后，在使用和运行过程中可能在软件运行/维护阶段对软件产品进行的修改就是维护。
为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，应当进行的诊断和改正错误的过程就叫做改正性维护
20%
改正性维护
在使用过程中，外部环境（新的硬、软件配置）、数据环境（数据库、数据格式、数据输入/输出方式、数据存储介质）可能发生变化。为使软件适应这种变化，而去修改软件的过程就叫做适应性维护。
25%
适应性维护
在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。这种情况下进行的维护活动叫做完善性维护。
50%
完善性维护
这是为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础
预防性维护
主要类型
软件维护
软件工程
软件设计师
0 条评论
回复 删除
下一页
