软考笔记（十）高级系统架构师/分析师：系统测试 维护 稳定性

目录

软考官网 报名通道

软考架构师笔记（一）：计算机系统基础

软考架构师笔记（二）：计算机网络基础与信息安全

软考架构师笔记（三）：操作系统基础

软考架构师笔记（四）：企业信息化与系统规划

软考架构师笔记（五）：系统需求工程 需求分析

软考架构师笔记（六）：数据库

软考架构师笔记（七）：系统分析 系统设计

软考架构师笔记（八）：系统架构

软考架构师笔记（九）：软件工程与项目管理

软考架构师笔记（十）：系统测试 维护 稳定性

软件测试

软件测试可分为单元测试、集成测试、配置项测试、系统测试、验收测试和回归测试等类别。

单元测试：
也称为模块测试，测试的对象是可独立编译或汇编的程序模块、软件构件或面向对象软件中的类（统称为模块），
其目的是检查每个模块能否正确地实现设计说明中的功能、性能、接囗和其他设计约束等条件，发现模块内可能存在的各种差错。
单元测试的技术依据是软件详细设计说明书。

测试一个模块时，可能需要为该模块编写一个驱动模块和若干个桩模块。
驱动模块用来调用被测模块，它接收测试者提供的测试数据，并把这些数据传送给被测模块，然后从被测模块接收测试结果，并以某种可见的方式将测试结果返回给测试人员；
桩模块用来模拟被测模块所调用的子模块，它接受被测模块的调用，检验调用参数，并以尽可能简单的操作模拟被调用的子程序模块功能，把结果送回被测模块。
顶层模块测试时不需要驱动模块，底层模块测试时不要桩模块。
单元测试策略主要包括自顶向下的单元测试、自底向上的单元测试、孤立测试和综合测试策略。
①自顶向下的单元测试 先测试上层模块，再测试下层模块。测试下层模块时由于它的上层模块已测试过，所以不必另外编写驱动模块。
②自底向上的单元测试。自底向上的单元测试先测试下层模块，再测试上层模块。测试上层模块由于它的下层模块已经测试过，所以不必另外编写桩模块。
③孤立测试不需要考虑每个模块与其他模块之间的关系，逐一完成所有模块的测试。由于各模块之间不存在依赖性，单元测试可以并行进行，但因为需要为每个模块单独设计驱动模块和桩模块，增加了额外的测试成本。
④综合测试。上述三种单元测试策略各有利弊，实际测试时可以根据软件特点和进度安排情况，将几种测试方法混合使用，

集成测试：
目的是检查模块之间，以及模块和已集成的软件之间的接口关系，并验证已集成的软件是否符合设计要求。集成测试的技术依据是软件概要设计文档。
集成测试可以分为一次性组装和增量式组装，增量式组装测试效果更好。集成测试计划一般在概要设计阶段

系统测试：
的对象是完整的、集成的计算机系统，系统测试的目的是在真实系统工作环境下，验证完整的软件配置项能否和系统正确连接，并满足系统/子系统设计文档和软件开发合同规定的要求。
系统测试的技术依据是用户需求或开发合同。配置项测试的对象是软件配置项，配置项测试的目的是检验软件配置项与软件需求规格说明的一致性。

确认测试：
主要验证软件的功能、性能和其他特性是否与用户需求一致。验收测试是指针对软件需求规格说明，在交付前以用户为主进行的测试。

回归测试：
目的是测试软件变更之后，变更部分的正确性和对变更需求的复合型，以及软件原有的、正确的功能、性能和其他规定的要求的不损害性。

 

验收确认测试

软件确认测试一种针对需求的测试，是用户参与的测试。它主要验证软件功能、性能及其它特性是否与用户需求一致。
软件确认测试包括：内部确认测试、Alpha、Beta和验收测试。
 

α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。
α测试的目的：评价软件产品的FLURPS(即功能、局域化、可用性、可靠性、性能和支持)。尤其注重产品的界面和特色。
α测试可以从软件产品编码结束之时开始，或在模块(子系统)测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。α测试即为非正式验收测试。

Beta一种验收测试。所谓验收测试是软件产品完成了功能测试和系统测试之后，在产品发布之前所进行的软件测试活动，它是技术测试的最后一个阶段，通过了验收测试，产品就会进入发布阶段。验收测试一般根据产品规格说明书严格检查产品，逐行逐字地对照说明书上对软件产品所做出的各方面要求， 确保所开发的软件产品符合用户的各项要求。 通过综合测试之后，软件已完全组装起来，接口方面的错误也已排除，软件测试的最后一步——验收测试即可开始。验收测试应检查软件能否按合同要求进行工作，即是否满足软件需求说明书中的确认标准。

测试的分类

动态测试

黑盒测试  透明的，不可见细节

• 等价类划分
• 边界值分析
• 错误推测
• 因果图

白盒测试

• 基本路径测试
• 循环覆盖测试
• 逻辑覆盖测试

灰盒测试

静态测试

• 桌前检查
• 代码审查
• 代码走查

测试特点

尽早、不断的进行测试
程序员避免测试自己设计的程序
既要选择有效、合理的数据，也要选择无效、不合理的数据修改后应进行回归测试
尚未发现的错误数量与该程序已发现错误数成正比

测试与调试的区别

测试的目的是找出存在的错误，而调试的目的是定位错误并修改程序以修正错误调试是测试之后的活动，测试和调试在目标、方法和思路上都有所不同测试从一个已知的条件开始，使用预先定义的过程，有预知的结果；
调试从一个未知的条件开始，结束的过程不可预计
测试过程可以事先设计，进度可以事先确定；调试不能描述过程或持续时间

 

---

系统转换

遗留系统演化

如上图，把对遗留系统的评价结果分列
在坐标的四个象限内。对处在不同象限的遗留系统采取不同的演化策略。
1.淘汰策略
第三象限为低水平、低价值区，即遗留系统的技术含量较低，且具有较低的业务价值。对这种遗留系统的演化策略为淘汰，即全面重新开发新的系统以代替遗留系统。完全淘汰是一种极端性策略，一般是企业的业务产生了根本变化，遗留系统已经基本上不再适应企业运作的需要；或者是遗留系统的维护人员、维护文档资料都丢失了。经过评价，发现将遗留系统完全淘汰，开发全新的系统比改造旧系统从成本上更合算。对遗留系统的完全淘汰是企业资源的根本浪费，系统分析师应该通过对遗留系统功能的理解和借鉴，可以帮助新系统的设计，降低新系统开发的风险。

2.继承策略
第二象限为低水平、高价值区，即遗留系统的技术含量较低，已经满足企业运作的功能或性能要求，但具有较高的商业价值，目前企业的业务尚紧密依赖该系统。对这种遗留系统的演化策略为继承。在开发新系统时，需要完全兼容遗留系统的功能模型和数据模型。为了保证业务的连续性，新老系统必须并行运行一段时间，再逐渐切换到新系统上运行。

3.改造策略
第一象限为高水平、高价值区，即遗留系统的技术含量较高，本身还有极大的生命力。系统具有较高的业务价值，基本上能够满足企业业务运作和决策支持的需要。这种系统可能建成的时间还很短，对这种遗留系统的演化策略为改造。改造包括系统功能的增强和数据模型的改造两个方面。系统功能的增强是指在原有系统的基础上增加新的应用要求，对遗留系统本身不做改变；数据模型的改造是指将遗留系统的旧的数据模型向新的数据模型的转化。

4.集成策略
第四象限为高水平、低价值区，即遗留系统的技术含量较高，但其业务价值较低，可能只完成某个部门（或子公司）的业务管理。这种系统在各自的局部领域里工作良好，但对于整个企业来说，存在多个这样的系统，不同的系统基于不同的平台、不同的数据模型，形成了一个个信息孤岛，对这种遗留系统的演化策略为集成。

 

系统维护

软件维护是生命周期的一个完整部分。
可以将软件维护定义为需要提供软件支持的全部活动这些活动包括在交付前完成的活动，以及交付后完成的活动。
交付前完成的活动包括交付后运行的计划和维护计划等；交付后的活动包括软件修改、培训、帮助资料等。

系统的可维护性分为：

• 易分析性
• 易改变性
• 稳定性
• 易测试性

系统的维护类型分为：

正确性（改正）维护：指改正在系统开发阶段已发生而系统测试阶段尚未发现的错误；为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，应当进行的诊断和改正错误的过程称为改正性维护。

适应性维护：指使应用软件适应信息技术变化和管理需求变化而进行的修改；外部环境（新的硬、软件配置）、数据环境（数据库、数据格式、数据输入/输出方法、数据存储介质）可能发生变化。为使软件适应这种变化而修改软件的过程称为适用性维护。

预防性维护：为了改进应用软件的可靠性和可维护性，为了适应未来的软硬件环境的变化，应主动增加预防性的新的功能，以使用系统适应各类变化而不被淘汰。

完善性维护：扩充功能和改善性能而进行的修改。对已有的软件系统增加一些在系统分析和设计阶段中没有规定的功能与性能特征。
在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。这种情况下进行的维护活动成为完善性维护。

 

负载均衡

分布式：

集中式：

与分布式负载均衡方式相比，集中式负载均衡实现简单

缺点：（1）系统的可扩展性不强，均衡器需要记录所有计算机的负载信息。
           （2）安全性较差，如果均衡器所在的计算机瘫痪，则会导致整个集群系统的瘫痪。
           （3）实现不够灵活，负载均衡器很难根据不同脚手架的特性配置不同的均衡策略。