系统架构设计专业技能 · 软件工程之软件测试与维护

系列文章目录

系统架构设计专业技能 · 网络规划与设计（三）【系统架构设计师】
系统架构设计专业技能 · 系统安全分析与设计（四）【系统架构设计师】
系统架构设计高级技能 · 软件架构设计（一）【系统架构设计师】
系统架构设计高级技能 · 系统质量属性与架构评估（二）【系统架构设计师】
系统架构设计高级技能 · 软件可靠性分析与设计（三）【系统架构设计师】

现在的一切都是为将来的梦想编织翅膀，让梦想在现实中展翅高飞。
Now everything is for the future of dream weaving wings, let the dream fly in reality.

一、软件测试

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

1.1 测试类型

1.2 测试阶段

1.3 软件调试

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

调试需要确定错误的准确位置；确定问题的原因并设法改正；改正后要进行回归测试。

调试的方法有：蛮力法、回溯法（从出错的地方开始，向回找）、原因排除法（找出所有可能的原因，逐一进行排除，具体包括演绎法、归纳法、二分法）。

1.4 软件度量

软件的两种属性：外部属性指面向管理者和用户的属性，可直接测量，一般为性能指标。内部属性指软件产品本身的的属性，如可靠性等，只能间接测量。

McCabe度量法：又称为环路复杂度，假设有向图中有向边数为m，节点数为n，则此有向图的环路复杂度为m-n+2。

注意m和n代表的含义不能混淆，可以用一个最简单的环路来做特殊值记忆此公式，另外，针对一个程序流程图，每一个分支边（连线）就是一条有向边，每一条语句（语句框）就是一个顶点。

二、软件维护

2.1、遗留系统演化策略

遗留系统（Legacy System）是指任何基本上不能进行修改和演化以满足新的变化了的业务需求的信息系统。

对遗留系统评价的目的是为了获得对遗留系统的更好的理解，这是遗留系统演化的基础，是任何遗留系统演化项目的起点。主要评价方法包括度量系统技术水准、商业价值和与之关联的企业特征，其结果作为选择处理策略的基础。

• 改造策略，高水平、高价值区，即遗留系统的技术含量较高，本身还有极大的生命力。系统具有较高的业务价值，基本上能够满足企业业务运作和决策支持的需要。这种系统可能建成的时间还很短，称这种遗留系统的演化策略为改造。改造包括系统功能的增强和数据模型的改造两个方面。系统功能的增强是指在原有系统的基础上增加新的应用要求，对遗留系统本身不做改变；数据模型的改造是指将遗留系统的旧的数据模型向新的数据模型的转化。
• 继承策略，低水平、高价值区，即遗留系统的技术含量较低，已经满足企业运作的功能或性能要求，但具有较高的商业价值，目前企业的业务尚紧密依赖该系统。称这种遗留系统的演化策略为继承。在开发新系统时，需要完全兼容遗留系统的功能模型和数据模型。为了保证业务的连续性，新老系统必须并行运行一段时间，再逐渐切换到新系统上运行。
• 集成策略，高水平、低价值区，即遗留系统的技术含量较高，但其业务价值较低，可能只完成某个部门（或子公司）的业务管理。这种系统在各自的局部领域里工作良好，但对于整个企业来说，存在多个这样的系统，不同的系统基于不同的平台、不同的数据模型，形成了一个个信息孤岛，对这种遗留系统的演化策略为集成。
• 淘汰策略，低水平、低价值区，即遗留系统的技术含量较低，且具有较低的业务价值。对这种遗留系统的演化策略为淘汰，即全面重新开发新的系统以代替遗留系统。完全淘汰是一种极端性策略，一般是企业的业务产生了根本变化，遗留系统已经基本上不再适应企业运作的需要；或者是遗留系统的维护人员、维护文档资料都丢失了。经过评价，发现将遗留系统完全淘汰，开发全新的系统比改造旧系统从成本上考虑更合算。

2.2、新旧系统的转换策略

在实施新旧系统转换时，转换的策略通常有三种：

• 直接转换策略，适用于新系统不太复杂或现有系统完全不能使用的场合，新系统在转换之前必须经过详细而严格的测试。
• 并行转换策略，新系统和现有系统并行工作一段时间，经过这段时间的试运行后，再用新系统正式替换下现有系统。
• 分段转换策略，分段转换策略也称为逐步转换策略，这种转换方式是直接转换方式和并行转换方式的结合，采取分期分批逐步转换。一般比较大的系统采用这种方式较为适宜，它能保证平稳运行，费用也不太高；或者现有系统比较稳定，能够适应自身业务发展需要，或新旧系统转换风险很大（例如，在线订票系统、银行的中间业务系统等），也可以采用分段转换策略。分段转换策略的优点是，新旧系统的转换震动比较小，用户容易接受。但由于是采用渐进方式，导致新旧系统的转换周期过长，同时由于需求的变化，给新系统的稳定造成比较大的影响。而且，分段转换策略对系统的设计和实现都有一定的要求，在转换过程中，需要开发新旧系统之间的接口，还需要制订阶段性的转换目标和计划。

2.3、数据转换和迁移

数据迁移的主要方法大致有三种，分别是系统切换前通过工具迁移、系统切换前采用手工录入和系统切换后通过新系统生成。

数据迁移的实施可以分为三个阶段，分别是数据迁移前的准备、数据转换与迁移和数据迁移后的校验。其中准备工作要做好以下7个方面的工作：

（1）待迁移数据源的详细说明，包括数据的存放方式、数据量和数据的时间跨度。
（2）建立新旧系统数据库的数据字典，对现有系统的历史数据进行质量分析，以及新旧系统数据结构的差异分析。
（3）新旧系统代码数据的差异分析。
（4）建立新旧系统数据库表的映射关系，对无法映射字段的处理方法。
（5）开发或购买、部署ETL工具。
（6）编写数据转换的测试计划和校验程序。
（7）制定数据转换的应急措施。

在数据迁移完成后，需要对迁移后的数据进行校验。数据迁移后的校验是对迁移质量的检查，同时数据校验的结果也是判断新系统能否正式启用的重要依据。可以通过以下两种方式对迁移后的数据进行校验：
（1）对迁移后的数据进行质量分析。
（2）新旧系统查询数据对比检查。

2.4、影响软件可维护性的因素

• 【可理解性】是指通过阅读源代码和相关文档，了解软件的功能和如何运行的容易程度。
• 【可修改性】是指修改软件的难易程度。
• 【可测试性】是指验证软件程序正确的难易程度。
  可测试性好的软件，通常意味着软件设计简单，复杂性低。因为软件的复杂性越大，测试的难度也就越大。
• 【可靠性】一个软件的可靠性越高，需要维护的概率就会越低。
• 【可移植性】是指将软件从一个环境移植到新的的环境下正确运行的难易程度。
  软件运行环境的变化是软件维护的一种常见情形，可移植性好的软件会降低维护的概率

2.5、软件维护类型

软件的维护并不只是修正错误，为了满足用户提出的增加新功能，修改现有功能以及一般性的改进要求和建议，需要进行完善性维护，他是软件维护的重要组成部分。

• 改正性维护【修BUG】：也称正确性维护，指改正在系统开发阶段已发生而系统测试阶段尚未发现的错误【修正bug、错误】。
• 适应性维护【应变】：指使应用软件适应环境变化【外部环境、数据环境】而进行的修改。
• 完善性维护【新需求】：扩充功能和改善性能而进行的修改。
• 预防性维护【针对未来】：为了适应未来的软硬件环境的变化，应主动增加预防性的新的功能，以使系统适应各类变化而不被淘汰。如将专用报表功能改成通用报表生成功能，以适应将来报表格式的变化。