软件测试不等于程序测试，软件测试应贯穿于软件定义与开发的整个周期；软件测试是我们通常讲的一个更广泛主题是确认与验证。
确认是指保证软件的实现满足用户需求的一系列活动。包括有需求规格的确认和程序的确认。而程序的确认又分为静态确认与动态确认，静态确认一般不是在计算机上执行的程序。（PS：我们是否完成了正确的产品）
验证是保证软件正确实现了某一特定功能的一系列活动。（PS：我们是否正确地建成了产品）
测试各个阶段与软件开发各个阶段的关系
首先根据国际GB8566-88《计算机软件开发规范》的规定，软件的开发与维护分为8个阶段：可行性研究及计划、需求分析、概要设计、详细设计、实现（编码）、集成测试、确认测试、使用维护；其中单元测试是在实现阶段完成。
其中单元测试是对详细设计与实现的测试与验证，集成测试是对概要设计、详细设计的验证，确认测试对需求分析与概要设计的验证。
白盒测试的测试用例设计方法
白盒测试又称为结构测试或逻辑驱动测试。需要掌握测试用例设计的方法与原则，以下将详细罗列各个方法，首先将介绍逻辑覆盖的几种方法，然后单独介绍基本路径测试的方法，其中涵盖有环复杂度的概念。
1.语句覆盖：设计若干测试用例，运行所测程序，使得每一可执行语句至少执行一次。（是最弱的逻辑覆盖准则）
2.判定覆盖：设计若干测试用例，运行所测程序，使得程序中每个判断的取真分支和取假分支至少经历一次。（又称分支覆盖）
3.条件覆盖：设计若干测试用例，运行所测程序，使得程序中每个判断的每个条件的可能取值至少执行一次。
4.判定-条件覆盖：设计若干测试用例，运行所测程序，使得判定中的每个条件可能取值至少执行一次，同时每个判定的所有可能结果至少执行一次。换言之，即是要求各个判断的所有可能条件取值组合至少执行一次。（可以将多重条件的判定分解，形成基本判断条件，这样即可有效的检查所有条件是否正确了）
5.条件组合覆盖：设计若干测试用例，运行所测程序，使得程序中每个判断的所有可能的条件取值组合至少执行一次。
6.路径测试：设计足够的测试用例，覆盖程序中所有可能的路径。
白盒测试之基本路径测试
基本路径测试是在程序控制流图基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例的方法。设计出测试用例要保证在测试中程序每一个可执行语句至少执行一次。
一、实施步骤：
1.以设计或代码为基础，画出相应的流程图。
2.确定结果流程图的环复杂度。
3.确定一个基本的路径集合，根据环复杂度。
4.准备测试案例，执行基本路径集合中的每条路径。
二、环复杂度的方法：
1.流图中区域的数量就是环复杂度。
2.V（G）=E-N+2其中E是流图中的边，N是流图节点。
3.V（G）=P+1其中P是流图中的判定节点数。
4.连接矩阵（图矩阵）法：将流图中的节点横向、纵向组成一个正方形的图形矩阵，其中纵向是节点，横向的连接到的节点。在每一个矩阵框中，用1来表示相互连接的节点。在横向有1的行中，每行1进行累加然后减1.最后将每行的最终结果汇总加1，就是环复杂度了。
黑盒测试的测试用例设计方法
黑盒测试的测试用例方法有等价划分法、边界值发、错误推测法和因果图、功能图。其中前3个基本了解其概念方法即可，后两者需要了解其原理和方法，将会以单独的章节来介绍。
1.等价类划分：该方法是把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数有代表性的数据作为测试用例。具体有有效等价类、无效等价类两种情况。
2.边界值分析：是对等价类划分方法的补充。在所有黑盒测试中，最有效的方法不是因果图法，而是边界值分析法。
3.错误推测法：靠经验和直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的例子。
黑盒测试之因果图
等价类分析、边界值分析都是着重考虑输入条件，未考虑输入条件之间的联系。如果在测试中必须考虑输入条件的各种组合，可能又会产生一些新的情况。这就是应用因果图的原因。
因果图方法最终生成的就是判定表。用它来检查程序输入条件的各种组合情况。而判定表就是横向排列有输入条件、中间结果、最终结果。然后根据最终结果导出测试案例。而纵向是根据输入条件的不同情况。具体应用因果图方法的步骤如下：
1.分析软件规格说明描述中，哪些是原因（输入条件或其等价类），哪些是结果（即输出条件），并给每个原因、结果赋予一个标识符。
2.分析软件规格说明中的语义，找出原因与结果之间，原因与原因之间的关系，根据这些关系画出因果图。
3.由于语法或环境的限制，有些原因与原因之间，原因与结果之间的组合情况不可能出现。为表明这些情况，在因果图上用一些记号标明约束或限制条件。
4.把因果图转换成判定表。
5.把判定表的每一列拿出来作为依据，设计测试用例。
黑盒测试之功能图FD
功能图方法是一种黑盒、白盒混合用例设计方法，是功能图FD形式化地表示程序的功能说明，并机器地生成功能图的测试用例。功能图模型由状态迁移图和逻辑功能模型构成。
状态迁移图用于表示输入数据序列以及相应的输出数据。在状态迁移图中，由输入数据和当前状态决定输出数据和后续状态。
逻辑功能模型用于表示在状态输入条件和输出条件之间的对应关系。逻辑功能模型只适合于描述静态说明，输出数据仅由输入数据决定。测试用例则由测试中的一系列状态和在每个状态中必须依靠输入/输出数据满足的一对条件组成。
（2）测试用例生成方法：从功能图生成测试用例，得到的测试用例数是可以接受的。问题的关键是如何从状态迁移图中选取测试用例。若用节点代替状态，用弧线代替迁移，则状态迁移图就可转化成一个程序的控制流程图形式。问题就转化为程序的路径测试问题了。
（3）测试用例生成规则：为了把状态迁移的测试用例与逻辑模型的测试用例相组合起来，从功能图生成生成实用的测试用例，需定义下面的规则。在一个结构化的迁移（SST）中，定义三种形式的循环：顺序、选择和重复。但分辨一个状态迁移中的所有循环是有困难的。
（4）从功能图生成测试用例的过程。
A、生成局部测试用例：在每个状态中，从因果图生成局部测试用例。局部测试用例由原因值（输入数据）组合与对应的结果值（输出数据或状态）构成。
B、测试路径生成：利用上面的规则（3种）生成从初始状态到最后状态的测试路径。
C、测试用例合成：合成测试路径与功能图中每个状态的局部测试用例。结果是初始状态到最后状态的一个状态序列，以及每个状态中输入数据与对应输出数据的组合。
D、测试用例的合成算法：采用合成构造树。
软件测试策略
驱动模块、桩模块、白盒测试的概念是单元测试阶段的内容。
组装测试（集成测试）中主要提及了一次性组装方式和增殖组装方式。对于后者来说，又区分有自顶而下、自下而上的两大类方式；并且在此基础上，又有了一系列的衍生方式。
确认测试（有效性测试）主要是结合软件需求规格说明来对软件功能、性能进行测试。其中有α测试与β测试。
烟幕测试
烟幕测试可以被刻画为一种滚动的集成策略。每天软件都被重新建造（随着新构件的加入）并测试。主要的好处是：集成风险被最小化、终端产品的质量被改善、错误诊断和修改被简化、进展容易评估。
负载测试、压力测试、性能测试[1]
负载测试（Loadtesting）、压力测试（StressTest，应称为强度测试）和性能测试，这三个概念常常引起混淆，难以区分，从而造成不正确的理解和错误的使用。
负载测试、压力测试和性能测试的测试目的不同，但其手段和方法在一定程度上比较相似，通常会使用相同的测试环境和测试工具，而且都会监控系统所占用资源的情况以及其它相应的性能指标，这也是造成人们容易产生概念混淆的主要原因。
我们知道，软件总是运行在一定的环境下，这种环境包括支撑软件运行的软硬件环境和影响软件运行的外部条件。为了让客户使用软件系统感到满意，必须确保系统运行良好，达到高安全、高可靠和高性能。其中，系统是否具有高性能的运行特征，不仅取决于系统本身的设计和程序算法，而且取决于系统的运行环境。系统的运行环境会依赖于一些关键因素，例如：
系统架构，如分布式服务器集群还是集中式主机系统等。
硬件配置，如服务器的配置，CPU、内存等配置越高，系统的性能会越好。
网络带宽，随着带宽的提高，客户端访问服务器的速度会有较大的改善。
支撑软件的选定，如选定不同的数据库管理系统（Oracle、MySQL等）和web应用服务器（Tomcat、GlassFish、Jboss、WebLogic等），对应用系统的性能都有影响。
外部负载，同时有多少个用户连接、用户上载文件大小、数据库中的记录数等都会对系统的性能有影响。一般来说，系统负载越大，系统的性能会降低。
在了解了这样一个背景之后，就比较容易理解为什么在性能测试中常常要谈负载测试。从测试的目的出发、从用户的需求出发，就比较容易区分性能测试、负载测试和压力测试。性能测试是为了获得系统在某种特定的条件下（包括特定的负载条件下）的性能指标数据，而负载测试、压力测试是为了发现软件系统中所存在的问题，包括性能瓶颈、内存泄漏等。通过负载测试，也是为了获得系统正常工作时所能承受的最大负载，这时负载测试就成为容量测试。通过压力测试，可以知道在什么极限情况下系统会崩溃、系统是否具有自我恢复性等，但更多的是为了确定系统的稳定性。
静态测试、动态测试、回归测试
从使用的工具来看，软件测试的方法又可分为静态测试、动态测试。
①静态测试：指人工评审软件文档或程序，借以发现其中的错误，由于评审的文档或程序不必运行，所以称为静态测试。人工评审的手续虽然比较简单，但事实证明这是一个相当有效的检验手段。由于评审人员的能力有限，静态测试显然不可能发现所有的错误。
②动态测试：指通常的上机测试，这种方法是使程序有控制地运行，并从多种角度观察程序的行为，以发现其中的错误。
在软件维护阶段，当修改软件后，除了对修改部分的软件进行常规的测试外，还应对软件的其他部分进行回归测试，所谓回归测试是指全部或部分地重复已做过的测试，它主要检查软件的修改是否在软件的未修改部分引入了新的错误。
③回归测试：指在发生修改之后重新测试先前的测试以保证修改的正确性。理论上，软件产生新版本，都需要进行回归测试，验证以前发现和修复的错误是否在新软件版本上再次出现。
根据修复好了的缺陷再重新进行测试。回归测试的目的在于验证以前出现过但已经修复好的缺陷不再重新出现。一般指对某已知修正的缺陷再次围绕它原来出现时的步骤重新测试。通常确定所需的再测试的范围时是比较困难的，特别当临近产品发布日期时。因为为了修正某缺陷时必需更改源代码，因而就有可能影响这部分源代码所控制的功能。所以在验证修好的缺陷时不仅要服从缺陷原来出现时的步骤重新测试，而且还要测试有可能受影响的所有功能。因此应当鼓励对所有回归测试用例进行自动化测试。
系统测试
确认测试还只是停留在软件层次上，是对软件需求的一种确认。系统测试是对整个系统的测试，包括软件、硬件以及网络环境等。
2.系统测试有：恢复测试、安全测试、强度测试、性能测试。
调试方法
调试的任务就是根据测试时所发现的错误，找出原因和具体的位置，进行改正。调试工作主要由程序开发人员来进行，谁开发的程序就由谁来进行调试。
目前常用的调试方法有如下几种：
（1）试探法。调试人员分析错误的症状，猜测问题的所在位置，利用在程序中设置输出语句，分析寄存器、存储器的内容等手段来获得错误的线索，一步步地试探和分析错误的所在。这种方法效率很低，适合于结构比较简单的程序。
（2）回溯法。调试人员从发现错误症状的位置开始，人工沿着程序的控制流程往回跟踪程序代码，直到找出错误根源为止。这种方法适合于小型程序，对于大规模程序，由于其需要回溯的路径太多而变得不可操作。
（3）对分查找法。这种方法主要用来缩小错误的范围。如果已经知道程序中的变量在若干位置的正确取值，可以在这些位置上给这些变量以正确值，运行程序观察输出结果，如果没有发现问题，则说明从赋予变量一个正确值开始到输出结果之间的程序没有出错，问题可能在除此之外的程序中，否则错误就在所考察的这部分程序中。对含有错误的程序段再使用这种方法，直到把故障范围缩小到比较容易诊断为止。
（4）归纳法。归纳法就是从测试所暴露的问题出发，收集所有正确或不正确的数据，分析它们之间的关系，提出假想的错误原因，用这些数据来证明或反驳，从而查出错误所在。
（5）演绎法。根据测试结果，列出所有可能的错误原因。分析已有的数据，排除不可能和彼此矛盾的原因。对余下的原因，选择可能性最大的，利用已有的数据完善该假设，使假设更具体。用假设来解释所有的原始测试结果，如果能解释这一切，则假设得以证实，也就找出错误；否则，要么是假设不完备或不成立，要么有多个错误同时存在，需要重新分析，提出新的假设，直到发现错误为止。
●调试的任务就是根据测试时所发现的错误，找出原因和具体的位置，进行改正。调试工作主要由程序开发人员来进行，谁开发的程序就由谁来进行调试。目前常用的调试方法有试探法、回溯法、________、归纳法和演绎法。
A.贪婪法B.二分查找法C.回归测试法D.命题推理法
排错策略
排错是一个相当艰苦的过程，无论采用哪种排错方法，目标只有一个，即发现并排除引起错误的原因，这要求排错人员能把直观想象与系统评估很好的结合起来。
常用的排错策略分为三类：
（2）回溯类（backtracking）。回溯法能成功地用于程序的排错。方法是从出现错误征兆开始，人工地沿控制流程往回追踪，直至发现出错的根源，不幸的是程序变大后，可能的回溯路线显著增加，以致人工进行完全回溯到可望而不可及。
（3）排除类（causeeliminations）。排除法基于归纳和演绎原理，采用“分治”的概念，首先列出与错误出现有关有所有数据，假想一个错误原因，用这些数据证明或反驳它；或者一次性列出所有可能的原因，通过测试一一排除。只要某次测试结果说明某种假设已呈现端倪，则立即精华数据，乘胜追击。
测试排错的方法是：如果经测试发现了错误，就可以从不正确的结果处，沿逻辑路径反向搜索，直到发现程序错误为止。
程序排错是排除经测试发现出错的程序中错误的措施，其中测试排错法发现和排除错误的主要手段是________。
A.跟踪程序执行B.测试用例比较C.实现逻辑推断D.路径反向搜索
软件工程三要素
三要素包括有：方法、工具、过程。其中方法是为软件开发提供“如何做”的技术。工具是为软件工程方法提供自动或半自动的软件支撑环境。过程是将软件工程中的方法和工具综合起来以达到合理、及时地进行计算机软件开发的目的。
瀑布模型
瀑布模型也称为线性顺序模型或传统生存周期模型，提供了软件开发的系统化、顺序的方法。过程是：分析、设计、编码、测试和支持（维护）。
一般在需求被很好的理解或十分清晰明确的前提下，可选择。
原型实现模型
原型实现过程是从需求收集开始，开发者与客户一起定义软件的总体目标，标识出已知的需求，并规划出进一步定义的区域。然后通过“快速设计”，快速设计集中于软件中那些对客户/用户可见的部分。然后根据软件用户与开发者进一步精细待开发的需求。逐步调整原型使其满足客户的要求，而开发者对即将要做的事情也有了一个更好的了解，这个过程是迭代的。
一般主要是在客户有一个合理的需求，但对需求的细节没有任何概念与线索的时候，会采用此模型方式。
此模型方式存在的问题是：1.客户通过原型觉得就是产品，而不知道这个原型的实现是粗糙的；所以重新系统化的开发往往客户不能理解，这样的话如果将原型成为最终的产品，那么此产品软件开发管理就十分放松了。2.开发者常常需要实现上的变相的使原型尽快工作。于是有些不理想的选择就成为系统的组成部分。
所以，在原型被采用时候，关键是客户与开发者要达成一致，原型被建造的目的仅仅是为了定义需求，之后会被抛弃或部分抛弃。
快速原型法的特点如下：
（1）快速原型法最显著的特点是引入了迭代的概念。
（2）快速原型法自始至终强调用户的参与。
（3）快速原型法在用户需求分析、系统功能描述以及系统实现方法等方面允许有较大的灵活性。用户需求可以不十分明确，系统功能描述也可以不完整，对于界面的要求也可以逐步完善。
（4）快速原型法可以用来评价几种不同的设计方案。
（5）快速原型法可以用来建立系统的某个部分。
（6）快速原型法不排斥传统生命周期法中采用的大量行之有效的方法、工具，它是与传统方法互为补充的方法。
由于原型开发需要适当的快速开发工具，需要用户密切配合，所以下列情况不适合使用原型法。
（1）缺乏适用的原型开发工具。
（2）用户不参与、不积极配合开发过程。
（3）用户的数据资源缺乏组织和管理。
（4）用户的软件资源缺乏组织和管理。
RAD模型
快速应用开发（RAD）是一个增量型、基于构件化的方式、基本并行的、是线性顺序模式的一个变种、强调极短的开发周期的开发模式。
主要是应用在需求是清晰很好明细的理解，又约束了项目范围的。
每一个过程都包括有业务建模、数据建模、过程建模、应用生成和测试及反复的过程。
它的缺陷是：
1.在大的项目中，需要足够的。
2.对于不可模块化的系统，难以采用。
3.对于或技术要求高的情况下，不宜采用。
演化模型
以上传统模式中瀑布模型、RAD模型的目的都是最终交付一个完善的产品，原型是为了更好帮助客户设计需求的，并不是交付一个最终产品。而软件的演化特征在这些传统的范围中都是没有考虑的。注意与瀑布、RAD模型比较来理解。
所以，演化模型是迭代的。它的特征是使软件工程师渐进地开发逐步完善的程序版本。
增量模型
增量模型融合了线性顺序模型的基本成分和原型实现的迭代特征。强调每一个增量均发布一个可操作产品。而往往第一个增量是核心产品。
螺旋模型
瀑布模型给出了软件生成周期各阶段的固定顺序，上一阶段完成后才能进入下一阶段。演化模型是在快速开发一个原型的基础上，根据用户在调用原型的过程中提出的反馈意见和建议，对原型进行改进，获得原型的新版本，重复这一过程，直到演化成最终的软件产品。螺旋模型将瀑布模型和演化模型相结合，它综合了两者的优点，并增加了风险分析。它以原型为基础，沿着螺线自内向外旋转，每旋转一圈都要经过制订计划、风险分析、实施工程、客户评价等活动，并开发原型的一个新版本。经过若干次螺旋上升的过程，得到最终的软件。
如下图所示是一个演化软件过程模型，它将原型实现的迭代特征与线性顺序模型中控制的和系统化的方面结合起来。适于面向对象的系统开发。
觉得同增量模型不同的是它是一个演化的模型，即每一次的演化都可对上一次的进行调整与完善。对于一个大型系统及软件开发，这个模型是一个很好的选择。
WINWIN螺旋模型
这个模型同螺旋模型不同之处是不仅强调了早期谈判的重要性，同时还引进了三个过程里程碑。称为“抛锚点”。分别是生存周期目标、生存周期体系结构、初始操作能力。
WINWIN模型融合了螺旋模型的基本成分和原型实现的迭代特征，强调分析和标识。通过早期谈判使客户和开发者之间达成一致协议，它将变成进展到软件和系统定义的关键。WINWIN模型引入了3个里程碑，称为“抛锚点”。它可帮助建立一个生命周期的完全性，并提供在软件项目向前进展前的决策里程碑。
并发开发模型
常常被用于作为客户机/应用的开发范例。
喷泉模型
喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。该模型认为软件开发过程自下而上周期的各阶段是相互重叠和多次反复的，就像水喷上去又可以落下来，类似一个喷泉。各个开发阶段没有特定的次序要求，并且可以交互进行，可以在某个开发阶段中随时补充其他任何开发阶段中遗漏。
智能模型
智能模型也称为“基于知识的软件开发模型”，它把瀑布模型和专家系统结合在一起，利用专家系统来帮助软件开发人员的工作。该模型应用基于规则的系统，采用归纳和推理机制，使维护在系统规格说明一级进行。这种模型在实施过程中以知识为基础的生成规则构成的知识系统与包含应用领域知识规则的专家系统相结合，构成这一应用领域软件的开发系统。
智能模型所要解决的问题是特定领域的复杂问题，涉及大量的专业知识，而开发人员一般不是该领域的专家，他们对特定领域的熟悉需要一个过程，所以软件需求在初始阶段很难定义得很完整。因此，采用原型实现模型需要通过多次迭代来精化软件需求
智能模型以知识作为处理对象，这些知识既有理论知识，也有特定领域的经验。在开发过程中需要将这些知识从书本中和特定领域的知识库中抽取出来（即知识获取），选择适当的方法进行编码（即知识表示）建立知识库。将模型、软件工程知识与特定领域的知识分别存入数据库，在这个过程中需要系统开发人员与领域专家密切合作。
智能模型开发的软件系统强调数据的含义，并试图使用现实世界的语言表达数据的含义。该模型可以勘探现有的数据，从中发现新的事实方法指导用户以专家的水平解决复杂的问题。它以瀑布模型为基本框架，在不同开发阶段引入了原型实现方法和以克服瀑布模型的缺点，适应于特定领域软件和专家决策系统的开发。
软件开发模型是指软件开发的全部过程、活动和任务的结构框架。到如今为止，已涌现出了多种软件开发模型，其中螺旋模型是将瀑布模型和演化模型相结合，它建立在原型的基础上，并增加了__(1)__。喷泉模型描述了__(2)__的开发模型，它体现了这种开发方法创建软件的过程所固有的__(3)__和开发各阶段之间无“间隙”的特征。
供选择的答案
（1）A.构架分析B.风险分析C.进度控制D.设计评审
（2）A.面向应用B.面向数据流C.面向对象D.面向服务
（3）A.递归B.归纳C.推理D.迭代
需求分析基本概念理解
在需求管理中，要收集需求的变更和变更的理由，并且维持对原有需求和产品有构件需求的双向跟踪。
需求分析阶段的工作有以下四个方面的内容：对问题的识别、分析与综合、制定规格说明书、评审。
需求分析任务过程有：获取当前系统的物理模型、抽象出当前系统的逻辑模型、建立目标系统的逻辑模型、实例化目标系统的物理模型。原型法主要是帮助明细需求的一个有效方法。
软件需求是指用户解决问题或达到目标所需的条件或能力。软件需求分析的目标是深入描述软件的功能和性能，确定软件设计的约束和软件同其他系统元素的接口细节，定义软件的其他有效性需求。
需求分析阶段又可分为需求获取、需求分析、编写需求规格说明、需求评审4个步骤。需求分析的方法有面向数据流的结构化分析方法(SA)、面向数据结构的Jackson方法(JSD)、面向数据结构的结构化数据系统开发方法(DSSD)和面向对象的分析方法(OOA)等。
结构化分析方法
结构化分析方法适用于数据处理类型软件的需求分析方法。
1.数据流图：是描述数据处理过程的工具。数据流图从数据传递与加工的角度，以图形的方式刻画数据流从输入到输出的移动变换过程。
2.数据字典：对在数据流图中每一个命名的图形元素给予定义，其内容有图形元素的名字、别名或编号、分类、描述、定义、位置等等。
3.Warnier图：是表示数据层次结构的一种图形工具，以树形结构来描述。还能指出某一类数据或某以数据元素重复出现的次数，并能指明某一个特定数据在某一类数据中是否有条件出现。
4.加工：对于加工用的工具有结构化、判定表和判定树。
结构化分析（StructuredAnalysis，简称为SA）方法最初由DouglasRoss提出，由DeMarco推广，由Ward和Mellor以及后来的Hatley和Pirbhai扩充，形成了今天的结构化分析方法的框架，在20世纪90年代得到了广泛的应用。
SA是一种面向数据流的软件分析方法。适合于开发数据处理类型软件的需求分析。数据流图是需求分析阶段使用的一种主要工具，它以图形的方式表达数据处理系统中信息的变换和传递过程。与流图配合使用的是数据词典，它对数据流图中出现的所有数据元素给出逻辑定义。有了数据词典，使得数据流图上的数据流、加工和文件得到确切的解释。
为了表达数据处理过程的数据加工情况，用一个数据流图是不够的。稍为复杂的实际问题，在数据流图上常常出现十几个甚至几十个加工。这样的数据流图看起来很不清楚。层次结构的数据流图能很好地解决这一问题。按照系统的层次结构进行逐步分解，并以分层的数据流图反映这种结构关系，能清楚地表达和理解整个系统。
图10-6给出分层数据流图的示例。数据处理S包括3个子系统1、2、3。顶层下面的第一层数据流图为DFD/L1。第二层数据流图DFD/L2.1、DFD/L2.2及DFD/L2.3分别是子系统1、2和3的细化。对任何一层数据流图来说，我们称它的上层图为父图，在它下一层的图则称为子图。
画数据流图的基本步骤概括地说，就是“自顶向下逐层分解”。检查和修改的原则为：①数据流图上所有图形符号只限于前述4种基本图形元素。②顶层数据流图必须包括前述4种基本元素，缺一不可。③顶层数据流图上的数据流必须封闭在外部实体之间。④每个加工至少有一个输入数据流和一个输出数据流。⑤在数据流图中，需按层给加工框编号。编号表明该加工处在哪一层，以及上下层的父图与子图的对应关系。⑥规定任何一个数据流子图必须与它上一层的一个加工对应，两者的输入数据流和输出数据流必须一致。此即父图与子图的平衡。⑦可以在数据流图中加入物质流，帮助用户理解数据流图。⑧图上每个元素都必须有名字。⑨数据流图中不可夹带控制流。
系统动态分析与E-R图
系统动态分析有状态迁移图、时序图、Petri网。对于数据库的需求分析有E-R图。
数据流图(DFD)和数据字典
结构化分析方法最初由DouglasRoss提出，由DeMarco推广，由Ward和Mellor以及后来的Hatley和Pirbhai扩充，形成了今天的结构化分析方法的框架，在20世纪90年代得到了广泛的应用。
结构化分析方法是一种面向数据流的软件分析方法。适合于开发数据处理类型软件的需求分析。数据流图是需求分析阶段使用的一种主要工具，它以图形的方式表达数据处理系统中信息的变换和传递过程。与数据流图配合使用的是数据词典，它对数据流图中出现的所有数据元素给出逻辑定义。有了数据词典，使得数据流图上的数据流、加工和文件得到确切的解释。
从理论上来说，数据流图可只有一个也可以有多个。但是，一般情况下，为了表达数据处理过程的数据加工情况，用一个数据流图是不够的。稍为复杂的实际问题，在数据流图上常常出现十几个甚至几十个加工。这样的数据流图看起来很不清楚。层次结构的数据流图能很好地解决这一问题。按照系统的层次结构进行逐步分解，并以分层的数据流图反映这种结构关系，能清楚地表达和容易理解整个系统。
画数据流图的基本步骤概括地说，就是“自顶向下逐层分解”。检查和修改的原则为：
（1）数据流图上所有图形符号只限于前述四种基本图形元素。
（2）顶层数据流图必须包括前述四种基本元素，缺一不可。
（3）顶层数据流图上的数据流必须封闭在外部实体之间。
（4）每个加工至少有一个输入数据流和一个输出数据流。
（5）在数据流图中，需按层给加工框编号。编号表明该加工处在哪一层，以及上下层的父图与子图的对应关系。
（6）规定任何一个数据流子图必须与它上一层的一个加工对应，两者的输入数据流和输出数据流必须一致。些即父图与子图的平衡。
（7）可以在数据流图中加入物质流，帮助用户理解数据流图。
（8）图上每个元素都必须有名字。
（9）数据流图中不可夹带控制流。
（28）是一种最常用的结构化分析工具，它从数据传递和加工的角度，以图形的方式刻画系统内数据的运行情况。通常使用（29）作为该工具的补充说明。
（28）A.数据流图B.数据字典C.E-R图D.判定表
（29）A.数据流图B.数据字典C.E-R图D.判定表
试题（28）、（29）分析
数据流图是一种最常用的结构化分析工具，它从数据传递和加工的角度，以图形的方式刻画系统内数据的运行情况。数据流图是一种能全面描述信息系统逻辑模型的主要工具，它可以用少数集中符号综合地反映出信息在系统中的流动、处理和存储的情况。
通常使用数据字典对数据流图加以补充说明。数据字典是以特定格式记录下来的、对系统的数据流图中各个基本要素的内容和特征所做的完整的定义和说明。
IPO图
IPO图是输入/处理/输出图的简称，描述输入数据、对数据的处理和输出数据之间的关系。
基本形式是在左边的框中列出有关的输入数据，在中间的框内列出主要的处理，在右边的框内列出产生的输出数据。
HIPO图
HIPO图（hierarrchyplusinput-porcess-output）是系统设计的描述工具，是公司于70年代中期在层次结构图的基础上推出的一种描述和模块内部处理功能的工具（技术）。
由以下两部分组成：
1.层次结构图--描述整个系统的设计结以及各类模块之间的关系：
2.IPO图--描述某个特定模块内的处理过程和输入/输出关系。
在结构化设计中，（32）描述了模块的输入输出关系、处理内容、模块的内部数据和模块的调用关系，是系统设计的重要成果，也是系统实施阶段编制程序设计任务书和进行程序设计设计的出发点和依据。
（32）A.系统流程图B.IPO图C.HIOP图D.模块结构图
试题（32）分析
系统流程图是表达系统执行过程的描述工具；IPO图描述了模块的输入输出关系、处理内容、模块的内部数据和模块的调用关系；HIPO图描述了系统自顶向下的模块关系；模块结构图描述了系统的模块结构以及模块间的关系，同时也描述了模块之间的控制关系。
需求变更的内外因素和原则控制
引发需求变更的因素可简单地划分为内部因素和外部因素。
（1）内部因素：项目计划阶段，由于业主表达不清、承建单位理解有误、双方沟通不够，或者由于承建单位的粗心大意等原因，需求分析发生错误或遗漏，未能准确、全面地表达业主的实际需求。项目实施时发现了需求偏差，需要纠偏。
（2）外部因素：项目实施阶段，由于外部环境发生变化（如国家新发布了有关的标准规范）、业主改变业务流程或增加业务范围等原因，业主提出改变或增加系统的功能及非功能需求。由内部因素引发需求变更请求时，表明原来的需求分析文档未能准确、全面地表达业主的实际需求。变更确立的主要原则是：
（1）需求变更目标对于承建合同的可追溯性和一致性。
（2）需求变更目标对于业主单位业务目标、系统建设目标的可追溯性和一致性。
由外部因素引发需求变更请求时，表明业主改变或增加系统需求。变更确立的主要原则包括：
（1）需求变更确实是必要的，而不是可有可无的。
（2）需求变更确实是不可推迟的，而不是可早可晚的。
（3）需求变更的技术方案是可行的。
（4）需求变更所引发的进度变更与投资变更是业主能够接受的。
（5）需求变更的潜在风险是可控的。
需求变更控制一般应遵循以下程序：
（1）建立需求基线、变更控制策略和变更控制系统。
（2）需求变更以规定格式提出。
（3）变更控制委员评估论证需求变更。
（4）需求变更以书面方式获得批准并修改进度成本等项目计划。
（5）定期评估需求变更对项目绩效的影响。
McCall的质量因素
提出了表明软件质量的11个质量特性，它们是A（正确性）、B（可靠性）、C（可用性）、D（完整性）、E（可维护性）、F（灵活性）、G（可移植性）、H（可复用性）、效率、可测试性和互联性。这个11个特性分为3个组。分别隶属于产品修正、产品转移和产品运行3个方面。
软件过程质量控制的理解
重视软件过程的质量是近年来质量管理理论和实践的新发展，但不能把产品质量的控制与过程质量的控制相对立起来。重视软件过程质量的控制其部分原因是相对于产品质量的控制来说，过程质量控制是先期的、主动的、系统的，而产品质量的控制是事后的（产品已经生产出来的）、被动的（发现了不合格产品只能报废或采取其他补救措施）、个别的（逐个检查产品质量）。
软件维护
件维护按照类型有：改正性维护、适应性维护、完善性维护、预防性维护。
在软件维护的实施过程中，为了正确、有效地修改，需要经历3个步骤：分析和理解程序、修改程序和重新验证程序。经过分析，全面、准确、迅速地理解程序是否维护成败与质量好坏的关键。有几种方法：分析程序结构图、数据跟踪、控制跟踪及其他方法。在将修改后的程序提交用户，需要通过静态、计算机确认之前和维护后的验收，保证修改后的程序的正确性。
逆向工程和再工程
逆向工程是分析程序，力图在比源代码更高抽象层次上建立程序表式的过程。逆向工程是设计恢复的过程。逆向工程工具可以从已经存在程序中抽取数据结构、体系结构和程序设计信息。（更加强调恢复、重新的含义）
再工程，也叫做复壮或再生。它不仅能从已经存在的程序中重新获得设计信息，而且还能使用这些信息来改建或重构现有的系统，以改进它的综合质量。一般软件人员利用再工程重新实现已经存在的程序，同时加进去新的功能或改善它的性能（有改善、新增的含义）
软件的逆向工程是一个恢复设计的过程，从现有的程序中抽取数据、体系结构和过程的设计信息。逆向过程的完备性可以用在某一个抽象层次上提供信息的详细程度来描述，在大多数情况下，抽象层次越高，完备性越低。下列可以通过逆向工程恢复的制品中，完备性最低的是（25）。
（25）A.过程的设计模型B.程序和数据结构C.对象模型、数据和控制流D状态图和部署图
试题（25）分析
软件的逆向工程是一个设计恢复的过程，从现有的程序中抽取数据、体系结构和过程的设计信息。逆向工程的完备性是指在某一个抽象层次上提供信息的详细程度，在大多数情况下，抽象层次越高，完备性越低。逆向过程和实现该过程的工具的抽象层次是指可从源代码中抽取出来的设计信息的精密程度。理想情况下，抽象程度应该尽可能高。逆向工程过程应该能够导出过程的设计模型（一种底层的抽象）；程序和数据结构信息（稍高层次的抽象）；对象模型、数据和控制流（相对高层的抽象）；UML状态图和部署图（高层抽象）。随着抽象层次增高，完备性就会降低。因此本题应该选择D。
软件配置管理
软件工程过程的输出有三种信息：计算机程序、描述计算机程序的文档、数据结构。在软件工程过程中产生的所有信息项就构成了软件配置。软件配置是软件具体形态在某一个时刻的瞬时影像。
SCM是一组管理整个软件生存期变更的活动，SCM可以视为一种质量保证活动，它应用于整个软件工程过程的所有阶段。其目的就是：标识变更、控制变更、确保变更的正确实现、向其他有关人员报告。
软件维护和软件配置管理之间的区别是：维护是一组软件工程活动，他们发生于软件已经交付用户并已经投入运行之后；软件配置管理是一组追踪和控制活动，他们开始于软件开发项目开始之时，结束于软件被淘汰之时。
基线是软件生存期中各开发阶段末尾的特定点，又称为里程碑。由正式的技术评审而得到的SCI协议和软件配置的正式文本才能成为基线。它的作用是把各阶段工作的划分更加明细化，使本来连续的工作在这些点上断开，以便于检验和肯定阶段成果。
软件配置管理的过程主要归结按顺序有5个任务：标识、版本管理、变更控制、配置审计和配置报告。（理解这5个任务的含义）
软件配置（softwareconfiguration）是指一个软件产品在软件生存周期各个阶段所产生的各种形式（机器可读或人工可读）和各种版本的文档、程序及其数据的集合。该集合中的每一个元素称为该软件产品软件配置中的一个配置项（configurationitem）。
软件配置管理主要包括配置标识、配置控制、配置状态记录与报告、配置检查与评审4个方面的活动。
1.配置标识
详细说明软件项目的基线（即最初批准的配置标识），并把它们与软件生存周期的特定阶段相联系。
描述本项目所有软件代码和文档的标题、代号、编号，以及分类规程。
2.配置控制
描述在软件生存周期中各个阶段使用的修改批准权限的级别。
定义对已有配置的修改建议进行处理的方法。
对于各个不同层次的配置控制组和其他修改管理机构，要求：
（1）定义其作用，并规定其权限和职责；
（2）如果已组成机构，则指明该机构的领导人员及其成员；
（3）如果还没有组成机构，则指明该机构的领导人员、成员及代理人；
（4）说明开发者和用户与配置控制组的关系。
当要与不属于本软件配置管理计划适用范围的程序和项目进行接口时，说明对其进行配置控制的方法。如果这些软件的修改需要其他机构在配置控制组评审之前或之后进行评审，则描述这些机构的组成、它们与配置控制组的关系，以及它们之间的相互关系。
说明与特殊产品（如非交付的软件、现存软件、用户提供的软件和内部支持软件）有关的配置控制规程。
3.配置状态的记录和报告
（1）指明怎样收集、验证、存储、处理和报告配置项的状态信息；
（2）详细说明要定期提供的报告及其分发办法；
（3）如果有动态查询，要指出所有动态查询的能力；
（4）如果要求记录用户说明的特殊状态时，要描述其实现手段。
4.配置的检查和评审
（1）定义在软件生存周期的特定点上执行的检查和评审中软件配置管理计划的作用；
（2）规定每次检查和评审所包含的配置项；
（3）指出用于标识和解决在检查和评审期间所发现问题的工作规程。
功能基线（functionalbaseline）是指在系统分析与软件定义阶段结束时，经过正式评审和批准的系统设计规格说明书中对待开发系统的规格说明；或是指经过项目委托单位和项目承办单位双方签字同意的协议书或合同中所规定的对待开发软件系统的规格说明；或是由下级申请上级同意或直接由上级下达的项目任务书中所规定的对待开发软件系统的规格说明。功能基线是最初批准的功能配置标识。
指派基线（allocatedbaseline）是指在软件需求分析阶段结束时，经过正式评审和批准的软件需求的规格说明。指派基线是最初批准的指派配置标识。
产品基线（productbaseline）是指在软件组装与系统测试阶段结束时，经过正式评审的批准的有关开发的软件产品的全部配置项的规格说明。产品基线是最初批准的产品配置标识。
软件生存期内全部的软件配置是软件产品的真正代表，必须使其保持精确。软件工程过程中某一阶段的变更，均要引起软件配置的变更，这种变更必须严格加以控制和管理，保持修改信息，并把精确、清晰的信息传递到软件工程过程的下一步骤。
变更控制包括建立控制点和建立报告与审查制度。对于一个大型的软件来说，不加控制的变更很快就会引起混乱。因此变更控制是一项最重要的软件配置任务。
“检出”和“登入”处理实现了两个重要的变更控制要素，即存取控制和同步控制。存取控制管理人们存取或修改一个特定软件配置对象的权限；同步控制可用来确保由不同的人所执行的并变更不会产生混乱。
软件的变更通常有两类不同的情况：
1.为改正小错误需要的变更。通常不需要从管理角度对这类变更进行审查和批准。但如果发生错误的阶段在造成错误的阶段的后面，例如在实现阶段发现了设计错误，则必须遵照标准的变更控制过程，把这个变更正式记入文档，并修改所有受这个变更影响的文档。
2.为了增加或者删掉某些功能、或者为了改变完成某个功能的方法而需要的变更。这类变更必须经过某种正式的变更评价过程，以估计变更需要的成本和它对软件系统其他部分的影响。
应该把所有的变更正式记入文档，并相应地修改所有有关的文档。这种变更报告和审查制度，对变更控制来说起了一个安全保证作用。需要注意的是，必须对每一项变更进行评价并对所有的变更进行跟踪和复审。
在变更控制中，（8）可以用来确保由不同用户所执行的并发变更。
（8）A.异步控制B.存取控制C.不同控制D.基线控制
面向对象基础知识
既存类概念
利用既存类来设计类，有4钟方式：选择，分解，配置和演变。这是的一个重要优点。许多类的设计都是基于既存类的复用。
（1）选择：设计类最简单的方法是从既存构件中简单地选择合乎需要的构件。这就是开发软件库的目的。一个00开发环境应提供常用构件库，大多数语言环境都带有一个原始构件库（如整数、实数和字符），它是基础层。任一基本构件库（如“基本”构件）都应建立在这些原始层上。这些都是些一般的和可复用的类。这个层还包括一组提供其他应用论域服务的一般类，如窗口系统和图形图元。表9-1显示了建立在这些层上面的特定域的库。最底层的论域库包括了应用论域的基础概念并支持广泛的应用开发。特定项目和特定组的库包括一下论域库，它包含为相应层所定义的信息。
（2）分解：最初标识的“类”常常是几个概念的组合。在设计时，可能会发现所标识的操作落在分散的几个概念中，或者会发现，数据属性被分开放到模型中拆散概念形成的几个组内。这样我们必须把一个类分成几个类，希望新标识的类容易实现，或者它们已经存在。
（4）演变：要开发的心类可能与一个既存类非常类似，但不完全相同。此时，不适宜采用“选择”操作，但可以从一个既存类演变成一个新类，可以利用继承机制来表示一般化-特殊化的关系。
一、传统开发方法存在问题
1.软件重用性差
重用性是指同一事物不经修改或稍加修改就可多次重复使用的性质。软件重用性是软件工程追求的目标之一。
2.软件可维护性差
软件工程强调软件的可维护性，强调文档资料的重要性，规定最终的软件产品应该由完整、一致的配置成分组成。在软件开发过程中，始终强调软件的可读性、可修改性和可测试性是软件的重要的质量指标。实践证明，用传统方法开发出来的软件，维护时其费用和成本仍然很高，其原因是可修改性差，维护困难，导致可维护性差。
3.开发出的软件不能满足用户需要
用传统的结构化方法开发大型软件系统涉及各种不同领域的知识，在开发需求模糊或需求动态变化的系统时，所开发出的软件系统往往不能真正满足用户的需要。
用结构化方法开发的软件，其稳定性、可修改性和可重用性都比较差，这是因为结构化方法的本质是功能分解，从代表目标系统整体功能的单个处理着手，自顶向下不断把复杂的处理分解为子处理，这样一层一层的分解下去，直到仅剩下若干个容易实现的子处理功能为止，然后用相应的工具来描述各个最低层的处理。因此，结构化方法是围绕实现处理功能的“过程”来构造系统的。然而，用户需求的变化大部分是针对功能的，因此，这种变化对于基于过程的设计来说是灾难性的。用这种方法设计出来的系统结构常常是不稳定的，用户需求的变化往往造成系统结构的较大变化，从而需要花费很大代价才能实现这种变化。
二、面向对象的基本概念
（1）对象：对象是人们要进行研究的任何事物，从最简单的整数到复杂的飞机等均可看作对象，它不仅能表示具体的事物，还能表示抽象的规则、计划或事件。
（2）对象的状态和行为：对象具有状态，一个对象用数据值来描述它的状态。
对象还有操作，用于改变对象的状态，对象及其操作就是对象的行为。
对象实现了数据和操作的结合，使数据和操作封装于对象的统一体中
（3）类：具有相同或相似性质的对象的抽象就是类。因此，对象的抽象是类，类的具体化就是对象，也可以说类的实例是对象。
类具有属性，它是对象的状态的抽象，用数据结构来描述类的属性。
类具有操作，它是对象的行为的抽象，用操作名和实现该操作的方法来描述。
（4）类的结构：在客观世界中有若干类，这些类之间有一定的结构关系。通常有两种主要的结构关系，即一般--具体结构关系，整体--部分结构关系。
①一般--具体结构称为分类结构，也可以说是“或”关系，或者是“isa”关系。
②整体--部分结构称为组装结构，它们之间的关系是一种“与”关系，或者是“hasa”关系。
（5）消息和方法：对象之间进行通信的结构叫做消息。在对象的操作中，当一个消息发送给某个对象时，消息包含接收对象去执行某种操作的信息。发送一条消息至少要包括说明接受消息的对象名、发送给该对象的消息名（即对象名、方法名）。一般还要对参数加以说明，参数可以是认识该消息的对象所知道的变量名，或者是所有对象都知道的全局变量名。
类中操作的实现过程叫做方法，一个方法有方法名、参数、方法体。
三、面向对象的特征
（1）对象唯一性。
每个对象都有自身唯一的标识，通过这种标识，可找到相应的对象。在对象的整个生命期中，它的标识都不改变，不同的对象不能有相同的标识。
（2）抽象性。
分类性是指将具有一致的数据结构（属性）和行为（操作）的对象抽象成类。一个类就是这样一种抽象，它反映了与应用有关的重要性质，而忽略其他一些无关内容。任何类的划分都是主观的，但必须与具体的应用有关。
（3）继承性。
继承性是子类自动共享父类数据结构和方法的机制，这是类之间的一种关系。在定义和实现一个类的时候，可以在一个已经存在的类的基础之上来进行，把这个已经存在的类所定义的内容作为自己的内容，并加入若干新的内容。
继承性是面向对象程序设计语言不同于其它语言的最重要的特点，是其他语言所没有的。
在类层次中，子类只继承一个父类的数据结构和方法，则称为单重继承。
在类层次中，子类继承了多个父类的数据结构和方法，则称为多重继承。
在软件开发中，类的继承性使所建立的软件具有开放性、可扩充性，这是信息组织与分类的行之有效的方法，它简化了对象、类的创建工作量，增加了代码的可重性。
采用继承性，提供了类的规范的等级结构。通过类的继承关系，使公共的特性能够共享，提高了软件的重用性。
（4）多态性（多形性）
多态性是指相同的操作或函数、过程可作用于多种类型的对象上并获得不同的结果。不同的对象，收到同一消息可以产生不同的结果，这种现象称为多态性。