【系统分析师之路】第九章 软件工程（下）

【系统分析师之路】第九章 软件工程（下）

3.开发环境与开发工具：包括集成开发环境，开发工具（分析设计工具，编程工具，测试工具等）软件开发的平台比较。
软件开发工具包括：建模工具，分析设计工具，编程工具，测试工具，项目管理工具。目前大多使用集成开发环境。
集成化计算机辅助软件工程：
ICASE最终目标：实现应用软件的全自动开发，即开发人员只要写好软件的需求规格说明书，软件开发环境就自动完成从需求分析开始的所有软件开发工作，自动生成供用户直接使用的软件及有关文档。

工具类型	对工具的说明
建模工具	建模应该具有的特征：全面支持UML，保持源代码和模型同步，强大的文档生成能力，支持团队工作，支持重构，支持设计模式，具有逆向工程能力，与软件工程其他工具进行集成。
设计工具	分类为三类：分面向对象设计工具，结构化设计工具，数据库设计工具。
编码工具	从方法学分为两类：结构化和面向对象编程工具；从功能上分类：编辑工具，编译工具，组装工具和排错工具；从使用方式分：批处理编程工具和可视化编程工具。
测试工具	通常可分为黑盒，白盒，测试管理工具三类。
项目管理工具	有MicrosoftProjectServer，PMOffice，P3E，ArtemisView4

4.应用系统构建：熟练掌握分析与设计方法，并能熟练运用；熟练掌握程序设计方法和程序设计语言，并能熟练运用；掌握测试的方法并能熟练运用；
5.软件测试与审计：包括单元测试，系统测试，集成测试的概念；测试用例的设计；软件需求评审；软件验证评审，功能检查，综合检查和管理评审。
软件测试的概念：是为了发现错误而执行程序的过程，是根据程序开发阶段的规格说明及程序内部结构而精心设计的一批测试用例，并利用这些测试用例去运行程序，以发现程序错误的过程。软件测试应尽可能在实际运行使用的环境下进行测试。测试不再只是编码完成以后做的工作，而是应该包括在整个开发和维护的过程中。
软件测试分为：单元测试，集成测试，确认测试，系统测试，配置项测试和回归测试。

测试术语	术语说明
单元测试	检查每个模块能否正确地实现设计说明中的功能，性能，接口和其他设计约束等条件，发现模块内可能存在的各种差错。又叫模块测试
集成测试	检查模块之间以及模块和已集成软件之间的接口关系。验证已经集成的软件是否符合设计要求。软件集成的过程是一个持续的过程，会形成多个临时版本。在不断的集成过程中，稳定性是真正的挑战。在每个版本提交时都要进行冒烟测试，对程序主要功能进行验证。它又叫组装测试。
确认测试	用于验证软件的功能，性能和其他特征是否和用户需求一致。它包括内部确认测试，阿尔法测试，Beta测试和验收测试
阿尔法测试	由用户开发环境下进行测试。
Beta测试	用户在实际使用环境下进行的测试。
验收测试	指针对SRS，在交付前以用户为主进行测试，其测试对象为完整的集成的计算机系统。
系统测试	在真实系统工作环境下验证完整的软件配置项能否和系统正确连接，并满足系统子系统设计文档和软件开发合同规定的要求。系统测试计划一般在系统分析阶段（需求分析阶段）完成。系统测试包括功能，健壮性，性能，用户界面，安全性，安装与反安装测试。它是在实际运行环境下，对计算机系统进行的一系列集成与确认测试。
配置项测试	测试对象是软件配置项，目的是检测软件配置项和SRS的一致性。
回归测试	目的是测试软件变更之后，变更部分的正确性和对变更需求的符合性。以及软件原有的正确的功能，性能和其他规定的要求的不损害性。
冒烟测试	冒烟测试就是完成一个新版本的开发后，对该版本最基本的功能进行测试，保证基本的功能和流程能走通。如果不通过，则打回开发那边重新开发；优点是节省测试时间，防止build失败。缺点是覆盖率还是比较低。
静态测试	被测试程序不在机器上运行，采用人工检测和计算机辅助静态分析的手段对程序进行检测。它包含两部分，对文档的静态测试和对代码的静态测试。对代码静态测试一般采用的三种方法：桌前检查，代码走查，代码审查。
动态测试	在计算机上实际运行程序进行软件测试。有白盒黑盒灰盒测试三种。
白盒测试	也叫结构测试，主要用在单元测试中。白盒的方法主要有控制流测试，数据流测试，程序变异测试。使用静态测试的方法也可以用来实现白盒。白盒测试中最常用的技术是逻辑覆盖。其他的标准还有语句覆盖，判定覆盖，条件覆盖，条件符合覆盖，修正的条件判定覆盖和路径覆盖等。使用人工检查代码的方法来检查代码的逻辑问题，也属于白盒测试的范畴。
黑盒测试	也叫功能测试。主要用于集成测试，系统测试，确认测试。检查程序功能是否按照SRS的要求正常使用。
灰盒测试	在黑盒测试过程中，使用白盒的测试的手段就是灰盒测试。关注输出对于输入的正确性，介于黑盒和白盒之间，关注内部表现。它结合了外部表现和内部逻辑结构来设计用例。
性能测试	负载和压力测试同属于性能测试。
负载测试	测试当负载逐渐增加时，系统各项性能指标变化情况。
压力测试	通过确定一个系统的瓶颈或不能接受的性能点，来获得系统能提供的最大服务级别的测试。
面向对象测试	与传统模式最主要的区别在于面向对象测试更加关注对象而不是完成输入输出的单一功能。这样的话测试可以在分析与设计阶段就先行介入，使得测试更好地配合软件生产过程。面向对象测试的四个层次：算法层，类层，模版层，系统层。
测试管理	测试应该贯穿开发全过程，要成立专门的测试管理组来管理测试。软件测试管理大致分为四部分：测试团队管理，测试计划管理，缺陷跟踪管理，测试件管理。
测试件	是指测试工作形成的产品，包括测试团队经验，技巧工具，能推广通用的测试脚本程序等。

黑盒测试的方法有：等价类划分，边界值分析，判定表，因果图，状态图，随机测试，猜错法和正交实验法等。

等价类划分	将所有可能的输入数据划分为几类，从每一类中选取具有代表性的数据作为测试用例。
因果图法	利用输入条件的多种组合产生相应多个动作的方式设计测试用例。
边界值法	选取刚好等于，刚刚大于或小于输入范围边界的值，作为测试数据。
错误推测法	根据程序中所有可能出现的错误，和容易发生的错误的特殊情况设计测试用例。
正交实验法	就是利用排列整齐的表 -正交表来对试验进行整体设计、综合比较、统计分析，实现通过少数的实验次数找到较好的生产条件，以达到最高生产工艺效果。
随机测试	主要是根据测试者的经验对软件进行功能和性能抽查。

软件测试管理包括：过程管理，配置管理，审计工作。
测试管理过程包括：制定测试计划和用例，执行测试，发现并报告缺陷，修正缺陷，重新测试。
回归测试的对象包括哪四个方面：
1）未通过单元测试的软件，在变更之后，应对其进行单元测试。
2）未通过配置项测试的软件，在变更之后首先应对变更的软件单元进行测试，然后在进行相关的集成测试和配置项测试。
3）未通过系统测试的软件，在变更之后，首先针对变更单元测试，再进行单元测试，集成测试，配置项测试和系统测试。
4）应对变更的软件进行测试，然后再进行相关的软件测试。
软件测试的七大原则：
1）单元测试以外，软件开发人员应避免测试自己的程序。
2）应该尽早测试，需要重复测试
3）对测试用例的态度，设计测试用例时，不仅要考虑合理的输入条件，更要注意不合理的输入条件。
4）要充分注意软件测试中的集群现象，即28法则。不要以为发现几个错误并且修正好以后就不需要测试了，反而这里是错误集群的地方。对20%的部分要重点测试，以提高测试投资的效率。
5）严格执行测试计划，排除测试的随意性。以免发生疏漏或者重复无效的工作。
6）应当对每个测试结果进行全面检查
7）妥善保存测试用例，测试计划，测试报告和最终分析报告，以备回归测试和维护时使用。
软件调试与测试的区别：
1）测试的目的是找出存在的错误，而调试的目的是定位错误并修改缺陷。
2）调试是测试之后的活动，测试和调试在目标方法和思路上都有所不同。
3）测试从一个已知的条件开始，使用预先定义的过程，有预期的结果。调试从未知的条件开始，结束的过程不可预计。
4）测试过程可以事先设计，进度可以事先确定，调试不能描述过程或持续时间。
自动化测试的优势：提高执行测试的速度，提高运行效率，保证测试结果的准确性，连续24小时运行，模拟现实环境下受约束的情况，节省测试成本和企业长远发展。
自动化测试的局限性：
1）不能代替人完成所有工作
2）只是测试规范化，减少人力资源难（需要培训工具使用，维护测试数据）
3）自动化测试结果需要分析和评估，所以不会降低工作量。
自动化测试的应用场景：产品相对单一，或者是开发周期长的项目，我们更倾向自己开发测试工具。
面向对象测试优点：
1）更早地定义出测试用例
2）可降低成本
3）帮助开发与测试对系统理解的一致
4）面向对象测试更注重软件的实质
审计阶段是审核项目是否符合要求，计划，合同以及规格说明和标准。在软件开发的各个阶段，都要求进行评审，评审管理要求按GB8566进行。

需求分析评审	需求分析是最开始的工作，同时也是最重要的工作。需求分析如果做得不够详细或者是偏离用户需求或者是存在缺陷的话，往往会给项目带来灭绝性的灾难。需求分析的正确、准确性，成了决定软件项目成败的关键因素。
概要设计评审	评审的内容是概要设计说明书。概要设计说明书是否与软件需求说明书的要求一致
详细设计评审	文档是否符合有关标准规定。 接口定义是否明确，详细设计说明书是否与概要设计说明书的要求一致 。
测试评审	针对可靠性和可维护性的测试目标，测试方法，测试用例，测试工具，测试通过标准，测试报告。
管理评审	要对计划的执行情况定期进行管理评审，这些评审必需由独立于被评审单位的机构或授权的第三方主持进行。
阶段评审	分三个阶段评审。第一次评审需求，概要设计，验证与确认方法；第二次评审详细设计，功能测试与演示；第三次是功能检查，物理检查，综合检查。
同级评审	是指一种保证方法，由两个或多个同级程序员互相检查，评估，以确保被检查的内容正确，且与软件的其他部分一致。

检查包括的内容有三项：功能检查，物理检查，综合检查。

1	功能检查	在软件释放前，确认已经满足在软件需求规格说明书中规定的所有需求。
2	物理检查	在验收软件前，要对软件进行物理检查，以验证程序和文档已经一致并做好了交付的准备。
3	综合检查	代码和测试文档的一致性，接口规格说明之间的一致性，设计实现和功能需求的一致性，功能需求和测试描述的一致性。

6.系统运行：包括系统成本管理和用户管理；数据资源管理和网络资源管理；系统转换。
新旧系统分析和比较的目的：
1）评估旧系统可能存在的问题，评估升级的代价
2）在可行性分析和方案设计阶段，寻找旧系统主要问题为新系统作参考。
3）在新系统方案确定后，进行新旧系统比较以便验证新系统的设计是否完备。
4）确定新旧系统转换的技术路线。
新旧系统比较分析的三大原则：比较新旧系统，复查，控制规模。

比较新旧系统	确定新旧系统主要差异。可以对旧系统进行业务建模。
复查	是否存在系统分析师对系统的误解，或存在新方案设计中没有涵盖的潜在问题。
控制规模	对旧系统建模和分析，应控制在较小的开发规模，因为比较的目的是发现比较问题。

新旧系统的转换的三种策略：直接，逐步，并行。

新旧系统转换	特点
直接转换策略	新系统是完全重构的系统，对原有系统只能进行抛弃处理。如果现有的信息系统已经不能满足业务要求，存在安全性能等方面的问题，那么就选用。
逐步转换策略	又称为分段转换，向导转换，试点过渡法。这种策略是部分继承原有系统，部分进行新系统的更新和开发的技术路线，最终采取渐进的方式过渡到新软件平台。优点就是震动小，用户容易接受。缺点就是周期长还要注意需求变化。
并行转换策略	较少使用。因为它会较多增加用户的工作量，难以控制新旧系统中的数据变化。

遗留系统概念：也叫做遗产系统，它是指任何基本上不能进行修改和演化以满足新的变化了的业务需求的信息系统。
遗留系统的演化策略：

演化策略	特点
淘汰策略	技术含量低，商业价值低
继承策略	技术含量低，商业价值高
改造策略	技术含量高，商业价值高。建设时间短，本身还有较大的生命力。基本能够满足企业业务运作和决策支持。
集成策略	技术价值高，商业价值低。系统在各自的局部领域里工作良好。

7.系统维护：包括了解维护的几种手段（包括日常检查，定期维护，预防性维护，事后维护和远程维护；针对系统特点，会熟练运用以上几种维护手段进行系统维护。

标准化GB/T14079-1993:软件维护指南。
系统维护一共有四种类型：纠正性维护，适应性维护，完善性维护，预防性维护。（关键字：就是鱼丸）
共同特征：交付软件产品后进行的修改是他们的共同特征。
软件维护不仅仅是在软件交付之后为保障软件运行而要完成的活动，还包括软件交付前应该完成的活动。软件维护占整个生命周期的60%-80%。
目前广泛用来衡量程序可维护性的因素包括可理解性，可测试性，可修改性。（关键字：可理可测可改）
影响维护工作量的五大因素：系统大小，设计语言，系统年龄，数据库技术的应用，先进的软件开发技术。

维护	特点	说明
纠正性维护	历史遗留问题	更正发现的问题（改Bug）。它主要包括了设计错误，程序错误，文档错误，数据错误。
适应性维护	展望未来与时俱进	保持软件产品能在变化后或变化中的环境中继续使用（系统移植）。
预防性维护	未雨绸缪	软件中潜在的错误成为实际的错误前，检测和更正他们（针对未来，占比最小）。
完善性维护	锦上添花	改进性能和可维护性（增加功能，工作量最大）

占比信息：一半在完善，四分之一在适应，百分之五在预防。（就是鱼丸）
适应性维护主要内容包括：
2.1）影响系统规则或规律的变化
2.2）硬件配置的变化
2.3）数据格式文件结构的改变
2.4）支持环境的改变。如操作系统，编译器或实用程序的变化。
完善性维护包括的内容有：
4.1）为扩充和增强功能而做的修改，如算法优化，扩充解题范围。
4.2）为完善性能而做的修改，提高运行速度，节省存储空间。
4.3）为便于维护而做的修改，如增加注释。