结构化分析

结构化的分析方法SA,自顶向下，逐步分解，是面向数据的，强调分析对象的数据 流，需要建立：功能模型（数据流图）、行为模型（状态转换图）、数据模型(E-R 图)以及数据字典（数据元素、数据结构、数据流、数据存储、加工逻辑、外部实 体)。

数据流图描述数据在系统中如何 被传送或变换，以及如何对数据 流进行变换的功能或子功能，用 于对功能建模，数据流图相关概 念如图：

数据流图

数据流图是可以分层的，从顶层（即上下文无关数据流）到0层、1层等，顶层数据 流图只含有一个加工处理表示整个管理信息系统，描述了系统的输入和输出，以及 和外部实体的数据交互。数据流图示例如下：

数据流图基本设计原则：

(1)数据守恒原则：对任何一个加工来说，其所有输出数据流中的数据必须能从该加 工的输入数据流中直接获得，或者说是通过该加工能产生的数据。

(2)守恒加工原则：对同一个加工来说，输入与输出的名字必须不相同，即使它们的 组成成分相同。

(3)对于每个加工，必须既有输入数据流，又有输出数据流。

(4)外部实体与外部实体之间不存在数据流

(5)外部实体与数据存储之间不存在数据流

(6)数据存储与数据存储之间不存在数据流

(7)父图与子图的平衡原则：子图的输入输出数据流同父图相应加工的输入输出数据 流必须一致，此即父图与子图的平衡。父图与子图之间的平衡原则不存在于单张图。

(8)数据流与加工有关，且必须经过加工。

数据字典

数据字典是用来定义在数据流图中出现的符号或者名称的含义，在数据流图中，每 个存储、加工、实体的含义都必须定义在数据字典中，并且父图和子图之间这些名 称要相同。示例如下：

测试基础知识

系统测试是为了发现错误而执行程序的过程，成功的测试是发现了至今尚未发现的错误的测试。

测试原则：

应尽早并不断的进行测试；

测试工作应该避免由开发软件的人或小组承担；

在设计测试方案时，不仅要确定输入数据，而且要根据系统功能确定预期的输出结果；

既包含有效、合理的测试用例，也包含不合理、失效的用例；

检验程序是否做了该做的事，且是否做了不该做的事；

严格按照测试计划进行；

妥善保存测试计划和测试用例；

测试用例可以重复使用或追加测试。

测试阶段

单元测试：

对单个模块进行测试，由程序员自己测试模块内部的接口、信息、功能， 测试依据是软件详细说明书。在单元测试中，驱动模块（上层）用来调用被测模块， 自顶向下的单元测试中不需要另外编写驱动模块。桩模块（底层）用来模拟被测模 块所调用的子模块。

集成测试：将模块组合起来进行测试，分为一次性组装（简单，节约时间，发现错 误少，只适合于小项目)和增量式组装（能够发现更多错误，耗时长，又可分为： 自顶向下、自底向上、混合式)。

确认测试：对已完成的软件进行功能上的测试，分为内部确认测试（无用户情况）、 Alpha测试（用户在开发环境下进行测试）、Beta测试（用户在实际使用时进行的测 试)、验收测试（用户根据SRS对项目进行验收）

系统测试：对软件进行性能测试，主要测试三个方面，即负载测试（在极限情况下， 系统各项性能指标)、强度测试（系统资源特别低的情况下）、容量测试（并发测 试，系统可以处理的同时在线的最大用户数量)。其他还有可靠性等性能测试，系 统测试采用的是黑盒测试方法。

回归测试：软件修改错误或变更后，进行回归测试以验证之前正确的代码是否引入 了错误。

测试方法

动态测试：程序运行时测试，分为

黑盒测试法：功能性测试，不了解软件代码结构，根据功能设计用例，测试软件功能。 白盒测试法：结构性测试，明确代码流程，根据代码逻辑设计用例，进行用例覆盖

灰盒测试法：即既有黑盒，也有白盒。

静态测试：程序静止时，即对代码进行人工审查，分为

桌前检查：程序员检查自己编写的程序，在程序编译后，单元测试前。

代码审查：由若干个程序员和测试人员组成评审小组，通过召开程序评审会来进行 审查。

代码走查：也是采用开会来对代码进行审查，但并非简单的检查代码，而是由测试 人员提供测试用例，让程序员扮演计算机的角色，手动运行测试用例，检查代码逻辑。

测试策略

自底向上：从最底层模块开始测试，需要编写驱动程序，而后开始逐一合并模块， 最终完成整个系统的测试。优点是较早的验证了底层模块。

自顶向下：先测试整个系统，需要编写桩程序，而后逐步向下直至最后测试最底层 模块。优点是较早的验证了系统的主要控制和判断点。

三明治：既有自底向上也有自顶向下的测试方法，二者都包括。兼有二者的优点， 缺点是测试工作量大。

测试用例设计

黑盒测试用例：将程序看做一个黑盒子，只知道输入输出，不知道内部代码，由此设计出测试用例，分为下面几类：

等价类划分：把所有的数据按照某种特性进行归类，而后在每类的数据里选取一个即可。等价类测试用例的设计原则：设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止；计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。

边界值划分：将每类的边界值作为测试用例，边界值一般为范围的两端值以及在此范围之外的与此范围间隔最小的两个值，如年龄范围为0-150，边界值为0，150，-

1,151四个。

错误推测：没有固定的方法，凭经验而言，来推测有可能产生问题的地方，作为测试用例进行测试。

因果图：由一个结果来反推原因的方法，具体结果具体分析，没有固定方法。

白盒测试用例：知道程序的代码逻辑，按照程序的代码语句，来设计覆盖代码分支 的测试用例，覆盖级别从低至高分为下面六种：

语句覆盖：逻辑代码中的所有语句都要被执行一遍，覆盖层级最低，因为执行了所 有的语句，不代表执行了所有的条件判断。

判定覆盖：逻辑代码中的所有判断语句的条件的真假分支都要覆盖一次。

条件覆盖：对于代码中的一个条件，可能是组合的，如a>o&&b<0,判断覆盖只针 对此组合条件的真假分支做两个测试用例，而条件覆盖是对每个独立的条件都要做 真假分支的测试用例，共可有4个测试用例，层级更高，注意区别，条件覆盖，针对 每个条件都要真假覆盖，判定覆盖，只针对一个条件判断语句。

判定/条件覆盖：使判定中每个条件的所有可能取值（真/假）至少出现一次，并且 每个判定本身的判定结果（真/假）也至少出现一次，即两种覆盖的综合。

条件组合覆盖：每个判定条件中条件的各种可能值的组合都至少出现一次。

路径覆盖：逻辑代码中的所有可行路径都覆盖了，覆盖层级最高。

调试

测试是发现错误，调试是找出错误的代码和原因。

调试需要确定错误的准确位置；确定问题的原因并设法改正；改正后要进行回归测 试。 调试的方法有：蛮力法、回溯法（从出错的地方开始，向回找）、原因排除法（找 出所有可能的原因，逐一进行排除，具体包括演绎法、归纳法、二分法)。

系统转换

系统转换是指新系统开发完毕，投入运行，取代现有系统的过程，需要考虑多方面的问 题，以实现与老系统的交接，有以下三种转换计划：

直接转换：现有系统被新系统直接取代了，风险很大，适用于新系统不复杂，或者现有系统已经不能使用的情况。优点是节省成本。

并行转换：新系统和老系统并行工作一段时间，新系统经过试运行后再取代，若新系统在试运行过程中有问题，也不影响现有系统的运行，风险极小，在试运行过程中还可以比较新老系统的性能，适用于大型系统。缺点是耗费人力和时间资源，难以控制两个系统间的数据转换。

分段转换：分期分批逐步转换，是直接和并行转换的集合，将大型系统分为多个子系统， 依次试运行每个子系统，成熟一个子系统，就转换一个子系统。同样适用于大型项目， 只是更耗时，而且现有系统和新系统间混合使用，需要协调好接口等问题。

数据转换与迁移：将数据从旧数据库迁移到新数据库中。，要在新系统中尽可能的保存旧 系统中食理的数据结构，才能降低迁移的难度。，也有三种方法：系统切换前通过工具迁 移、系统切换前采用手工录入、系统切换后通过新系统生成。

转换的过程称为ETL,有三个步骤：抽取（旧数据库数据）一转换（三种转换方法）一装 载（装入新数据库，并校验数据）

系统维护

软件维护是软件生命周期中的最后一个阶段，不属于系统开发过程。是在软件已经交付 使用之后为了改正错误或满足新的需求而修改软件的过程，即软件在交付使用后对软件 所做的一切改动。

系统的可维护性可以定义为维护人员理解、改正、改动和改进这个软件的难易程度，其 评价指标如下：

易测试性：指为确认经修改软件所需努力有关的软件属性；

易分析性：指为诊断缺陷或失效原因，或为判定待修改的部分所需努力有关的软件属性；

易改变性：指与进行修改、排错或适应环境变换所需努力有关的软件属性；

稳定性：指与修改造成未预料效果的风险有关的软件属性。

系统维护包括硬件维护、软件维护和数据维护，其中软件维护类型如下：

正确性维护：发现了bug而进行的修改。

适应性维护：由于外部环境发生了改变，被动进行的对软件的修改和升级。

完善性维护：基于用户主动对软件提出更多的需求，修改软件，增加更多的功能，使其 比之前的软件功能、性能更高，更加完善。

预防性维护：对未来可能发生的bug进行预防性的修改。

系统评价

系统评价分类

立项评价：系统开发前的预评价，分析是否立项开发，做可行性评价。

中期评价：项目开发中期每个阶段的阶段评审。或者项目在开发中途遇到重大变故， 评价是否还要继续。

结项评价：系统投入正式运行后，了解系统是否达到预期的目的和要求而对系统进 行的综合评价。

系统评价的指标

(1)从信息系统的组成部分出发，信息系统是一个由人机共同组成的系统，所以可以按照 运行效果和用户需求（人）、系统质量和技术条件（机）这两条线索构造指标。

(2)从信息系统的评价对象出发，对于开发方来说，他们所关心的是系统质量和技术水平： 对于用户方而言，关心的是用户需求和运行质量：系统外部环境则主要通过社会效益指标来 反映。

(3)从经济学角度出发，分别按系统成本、系统效益和财务指标3条线索建立指标。