【新版】系统架构设计师 - 系统测试与维护

个人总结，仅供参考，欢迎加好友一起讨论

架构 - 系统测试与维护

考点摘要

• 软件测试概念（★★）
• 测试方法及阶段（★★★★）
• 软件开发环境与工具（★）
• 可维护性因素（★★）
• 维护类型（★★）

第二版架构新教材里，将测试的部分内容放到了对应第5.4节，内容也筛减了不少内容（测试用例方面的内容和维护阶段的内容都筛减了），但是个人觉得还是把这块内容列出一篇进行单独梳理，也许论文会出现测试和维护的方向论文题目。

软件测试

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

软件测试 - 测试类型

这里个人认为只需要关注什么类型和具体分类即可，详细细节无需掌握

软件测试 - 静态测试

桌前检查	由程序员检查自己编写的程序。程序员在程序通过编译之后，进行单元测试设计之前，对源程序代码进行分析和检验，并补充相关的文档，目的是发现程序中的错误。检查项目包括检查变量的交叉引用表；检查标号的交叉引用表；检查子程序、宏、函数；等值性检查；常量检查；标准检查；风格检查；比较控制流；选择、激活路径；对照程序的规格说明，详细阅读源代码；补充文档。由于程序员熟悉自己的程序和自身的程序设计风格，这种桌前检查可以节省很多检查时间，但应避免主观片面性。
代码审查	代码审查是由若干程序员和测试人员组成一个会审小组，通过阅读、讨论和争议，对程序进行静态分析的过程。
代码走查	代码走查与代码审查基本相同，但开会的程序与代码会审不同，不是简单地读程序和对照错误检查单进行检查，而是让与会者“充当”计算机。即首先由测试组成员为被测程序准备一批有代表性的测试用例，提交给走查小组。走查小组开会，集体扮演计算机角色，让测试用例沿程序的逻辑运行一遍，随时记录程序的踪迹，供分析和讨论使用。

软件测试 - 动态测试

白盒测试

白盒测试也称为结构测试，主要用于软件单元测试阶段。它的主要思想是，将程序看作是一个透明的白盒，测试人员完全清楚程序的结构和处理算法，按照程序内部逻辑结构设计测试用例，检测程序中的主要执行通路是否都能按预定要求正确工作。白盒测试方法主要有控制流测试、数据流测试和程序变异测试等。

控制流测试	控制流测试根据程序的内部逻辑结构设计测试用例，常用的技术是逻辑覆盖，即使用测试数据运行被测程序，考察对程序逻辑的覆盖程度。主要的覆盖标准有语句覆盖、判定覆盖、条件覆盖、条件/判定覆盖、条件组合覆盖、修正的条件/判定覆盖和路径覆盖等。 ① 语句覆盖。语句覆盖是指选择足够多的测试用例，使得运行这些测试用例时，被测程序的每个语句至少执行一次。很显然，语句覆盖是一种很弱的覆盖标准。 ② 判定覆盖。判定覆盖也称为分支覆盖，它是指不仅每个语句至少执行一次，而且每个判定的每种可能的结果（分支）都至少执行一次。判定覆盖比语句覆盖强，但对程序逻辑的覆盖程度仍然不高。 ③ 条件覆盖。条件覆盖是指不仅每个语句至少执行一次，而且使判定表达式中的每个条件都取得各种可能的结果。条件覆盖不一定包含判定覆盖，判定覆盖也不一定包含条件覆盖。 判定覆盖只关心判定表达式的值（真/假），而条件覆盖涉及到判定表达式的每个条件的值（真/假）。 ④ 条件/判定覆盖。同时满足判定覆盖和条件覆盖的逻辑覆盖称为判定/条件覆盖。它的含义是，选取足够的测试用例，使得判定表达式中每个条件的所有可能结果至少出现一次，而且每个判定本身的所有可能结果也至少出现一次。 ⑤ 条件组合覆盖。条件组合覆盖是指选取足够的测试用例，使得每个判定表达式中条件结果的所有可能组合至少出现一次。显然，满足条件组合覆盖的测试用例，也一定满足判定/条件覆盖。因此，条件组合覆盖是上述5种覆盖标准中最强的一种。然而，条件组合覆盖还不能保证程序中所有可能的路径都至少遍历一次。 ⑥ 修正的条件/判定覆盖。修正的条件/判定覆盖需要足够的测试用例来确定各个条件能够影响到包含的判定结果。首先，每个程序模块的入口和出口点都要考虑至少要被调用一次，每个程序的判定到所有可能的结果值至少需要转换一次；其次，程序的判定被分解为通过逻辑操作符（and和or）连接的布尔条件，每个条件对于判定的结果值是独立的。 ⑦ 路径覆盖。路径覆盖是指选取足够的测试用例，使得程序的每条可能执行到的路径都至少经过一次（如果程序中有环路，则要求每条环路路径至少经过一次）。路径覆盖实际上考虑了程序中各种判定结果的所有可能组合，因此是一种较强的覆盖标准。但路径覆盖并未考虑判定中的条件结果的组合，并不能代替条件覆盖和条件组合覆盖。
数据流测试	数据流测试使用控制流程图对变量的定义和引用进行分析，可以发现的错误包括引用未定义的变量、未曾使用的定义、对未使用变量再次赋值、数组越界或条件判断中的条件错误、不正常的程序执行路径、不可执行的代码等。 进行数据流测试，通常首先将程序流程图转换成控制流图，在每个链路上标注对有关变量的数据操作的操作符号或符号序列；然后，选定数据流测试策略，根据测试策略得到测试路径；最后，根据测试路径确定测试用例。
程序变异测试	程序变异测试是一种错误驱动测试，是针对某类特定程序错误的测试。经过多年的测试理论研究和软件测试的实践，人们逐渐发现要想找出程序中所有的错误几乎是不可能的。比较现实的解决办法是将错误的搜索范围尽可能地缩小，以利于专门测试某类错误是否存在。错误驱动测试主要有两种，即程序强变异和程序弱变异。 程序变异测试方法有排错能力强和自动化程度高等优点，但它也存在两大弱点。一是要运行所有的变异体，从而成倍地提高了测试的成本，开销大；二是决定程序与其变异体是否等价是一个不可判定的命题。

黑盒测试

黑盒测试也称为功能测试，主要用于集成测试、确认测试和系统测试阶段。黑盒测试将软件看作是一个不透明的黑盒，完全不考虑（或不了解）程序的内部结构和处理算法，而只检查软件功能是否能按照SRS的要求正常使用，软件是否能适当地接收输入数据并产生正确的输出信息，软件运行过程中能否保持外部信息（例如，文件和数据库等）的完整性等。

黑盒测试根据SRS（需求规格说明书）所规定的功能来设计测试用例，一般包括功能分解、等价类划分、边界值分析、判定表、因果图、状态图、随机测试、错误推测和正交试验法等。

功能分解	功能分解是将SRS中的每个功能加以分解，确保各个功能被全面测试。首先使用程序设计中的功能抽象方法把程序分解为功能单元，然后使用数据抽象方法产生测试每个功能单元的数据。 功能抽象是将程序看成一种抽象的功能层次，每个层次可标识被测试的功能，层次结构中的某一功能由下一层功能定义。按照功能层次进行分解，可以得到众多的最低层次的子功能，并以这些子功能为对象设计测试用例；在数据抽象中，数据结构可以由抽象数据类型的层次图来描述，每个抽象数据类型有其取值集合。程序的每个输入和输出的取值集合用数据抽象来描述。
等价类划分	在设计测试用例时，等价类划分是用得最多的一种黑盒测试方法。所谓等价类就是某个输入域的集合，对于一个等价类中的输入值来说，它们揭示程序错误的作用是等效的。也就是说，如果等价类中的一个输入数据能检测出一个错误，那么等价类中的其他输入数据也能检测出同一个错误；反之，如果等价类中的一个输入数据不能检测出某个错误，那么等价类中的其他输入数据也不能检测出这一错误（除非这个等价类的某个子集还属于另一个等价类）。
边界值分析	经验表明，软件在处理边界情况时最容易出错。设计一些测试用例，使软件恰好运行在边界附近，暴露出软件错误的可能性会更大一些。通常，每一个等价类的边界，都应该着重测试，选取的测试数据应该恰好等于、稍小于或稍大于边界值。例如，对于条件“10 < x < 30”的测试，可以选取x的值为9，10，30和31作为测试数据。 在实际测试工作中，将等价类划分法和边界值分析法结合使用，能更有效地发现软件中的错误。
判定表	判定表最适合描述在多个逻辑条件取值的组合所构成的复杂情况下，分别要执行哪些不同的动作。 某商店业务处理系统中，基本加工“检查订货单”的描述为:若订货单金额大于 5000 元， 且欠款时间超过 60 天，则不予批准；若订货单金额大于 5000 元,且欠款时间不超过 60 天， 则发出批准书和发货单；若订货单金额小于或等于 5000 元，则发出批准书和发货单，若欠款时间超过 60 天，则还要发催款通知书。
因果图	因果图法根据输入条件与输出结果之间的因果关系来设计测试用例，它首先检查输入条件的各种组合情况，并找出输出结果对输入条件的依赖关系，然后，为每种输出条件的组合设计测试用例。
状态图	一个程序的功能说明通常由静态说明和动态说明组成。前者描述输入条件与输出条件之间的对应关系，后者描述输入数据的次序或迁移的次序。逻辑功能模型适合于描述静态说明，该模型中输出数据仅由输入数据决定。但对于较复杂的程序，由于存在大量的组合情况，仅根据静态的逻辑功能模型设计测试用例往往是不够的。在状态图中，由输入数据和当前状态共同决定输出数据和后续状态。根据状态图设计测试用例可以弥补静态逻辑功能模型的不足。
随机测试	随机测试是指测试输入数据是在所有可能输入值中随机选取的，测试人员只需规定输入变量的取值区间，在需要时提供必要的变换机制，使产生的随机数服从预期的概率分布。该方法获得预期输出比较困难，多用于可靠性测试和系统强度测试中。
错误推测	使用等价类划分和边界值分析技术，有助于设计出具有代表性的、容易暴露软件错误的测试方案。但是，不同类型的软件通常有一些特殊的容易出错的地方。错误推测法主要依靠测试人员的经验和直觉，从各种可能的测试用例中选出一些最可能引起程序出错的用例。
正交实验法	正交实验法是从大量的实验点中挑出适量的、有代表性的点，应用正交表，合理地安排实验的一种设计方法。利用正交实验法设计测试用例时，首先要根据被测软件的SRS，找出影响功能实现的操作对象和外部因素，并将其当作因子，而把各个因子的取值当作状态，生成二元的因素分析表。然后，利用正交表进行各因子的状态组合，构造有效的测试输入数据集，并由此建立因果图。这样，得出的测试用例数目将大大减少。

灰盒测试

灰盒测试是一种介于白盒测试与黑盒测试之间的测试，它关注输出对于输入的正确性。同时也关注内部表现，但这种关注不像白盒测试那样详细且完整，而只是通过一些表征性的现象、事件及标志来判断程序内部的运行状态。灰盒测试结合了白盒测试和黑盒测试的要素，考虑了用户端、特定的系统知识和操作环境，在系统组件的协同性环境中评价应用软件的设计。

软件测试 - 测试阶段

• 单元测试：模块测试，模块功能、性能、接口等。
• 集成测试：模块间的接口。
• 系统测试：真实环境下，验证完整的软件配置项能否和系统正确连接。
• 确认测试：验证软件与需求的一致性。内部确认测试、Alpha测试、Beta测试，验收测试。
• 回归测试：测试软件变更之后,变更部分的正确性对变更需求的符合性。

软件测试 - 测试阶段 - 单元测试

单元测试又称为模块测试，是针对软件设计的最小单位（程序模块）进行正确性检验的测试工作。其目的在于检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求，发现各模块内部可能存在的各种错误。单元测试需要从程序的内部结构出发设计测试用例，多个模块可以平行地独立进行单元测试。

单元测试根据详细设计说明书，包括模块接口测试、局部数据结构测试、路径测试、错误处理测试和边界测试，单元测试通常由开发人员自己负责。而由于通常程序模块不是单独存在的，因此常常要借助驱动模块（相当于用于测试模拟的主程序）和桩模块（子模块）完成。单元测试的计划通常是在软件详细设计阶段完成的。

另外，单元测试策略主要包括自顶向下的单元测试（需要桩模块）、自底向上的单元测试（需要驱动模块）、孤立测试和综合测试策略（都需要）。测试一个模块时，可能需要为该模块编写一个驱动模块和若干个桩（Stub）模块。顶层模块测试时不需要驱动模块，底层模块测试时不需要桩模块。

软件测试 - 测试阶段 - 集成测试

集成测试的目的是检查模块之间，以及模块和已集成的软件之间的接口关系，并验证已集成的软件是否符合设计要求。集成测试的技术依据是软件概要设计文档，集成测试计划通常在软件概要设计阶段完成。除应满足一般的测试准入条件外，进行集成测试前还应确认待测试的模块均已通过单元测试。

集成策略可分为非渐增式和渐增式两种。非渐增式集成测试也称大突击测试或一次性集成测试，是先测试所有的模块，然后一次性把所有模块集成到一起，将程序作为一个整体来测试。这种测试方法的出发点是可以“一步到位”，但测试人员面对众多的错误现象，往往难以分清哪些是“真正的”错误，哪些是由其他错误引起的“假性错误”，诊断定位和改正错误也十分困难。

非渐增式（一次性组装）集成只适合于维护型项目（即以前的产品已经很稳定，只有极少数构件被修改），或者软件规模非常小，并经过了充分的单元测试，或者项目采用严格的净室软件工程过程，开发质量与单元测试质量非常高。

渐增式集成测试是将单元测试和集成测试合并到一起，它根据模块结构图，按某种次序选一个尚未测试的模块，把它与已经测试好的模块组合在一起进行测试，每次增加一个模块，直到所有模块被集成在程序中。这种测试方法比较容易定位和改正错误，在业界得到普遍采用。渐增式集成又可分为自顶向下集成和自底向上集成。自顶向下集成先测试上层模块，再测试下层模块；自底向上集成先测试下层模块，再测试上层模块。

这两种集成方法各有利弊，一种方法的优点恰好对应于另一种方法的缺点，在实际测试工作中，可灵活选用最适当的方法，也可将两种方法混合使用。混合的增量式集成也称为三明治集成，测试时将系统划分成三层，先对最上面的一层使用自顶向下的集成，对最下面的一层使用自底向上的集成，最后在中间层会合。

软件测试 - 测试阶段 - 系统测试

系统测试的对象是完整的、集成的计算机系统，系统测试的目的是在真实系统工作环境下，验证完整的软件配置项能否和系统正确连接，并满足系统/子系统设计文档和软件开发合同规定的要求。系统测试的技术依据是用户需求或开发合同，除应满足一般测试的准入条件外，在进行系统测试前，还应确认被测系统的所有配置项已通过测试，对需要固化运行的软件还应提供固件。

系统测试的主要内容包括功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、安装与反安装测试等，其中，最重要的工作是进行功能测试与性能测试。性能测试主要验证软件系统在承担一定负载的情况下所表现出来的特性是否符合客户的需要，主要指标有响应时间、吞吐量、并发用户数和资源利用率等。

软件测试 - 测试阶段 - 配置项测试

配置项测试的对象是软件配置项，配置项测试的目的是检验软件配置项与SRS的一致性。配置项测试的技术依据是SRS（含接口需求规格说明）。除应满足一般测试的准入条件外，在进行配置项测试之前，还应确认被测软件配置项已通过单元测试和集成测试。

软件测试 - 测试阶段 - 确认测试

确认测试主要用于验证软件的功能、性能和其他特性是否与用户需求一致。根据用户的参与程度，通常包括以下4种类型：

1. 内部确认测试。内部确认测试主要由软件开发组织内部按照SRS进行测试。
2. Alpha测试和Beta测试。对于通用产品型的软件开发而言，Alpha测试是指由用户在开发环境下进行测试，通过Alpha测试以后的产品通常称为Alpha版；Beta测试是指由用户在实际使用环境下进行测试，通过Beta测试的产品通常称为Beta版。一般在通过Beta测试后，才能把产品发布或交付给用户。
3. 验收测试。验收测试是指针对SRS，在交付前以用户为主进行的测试。其测试对象为完整的、集成的计算机系统。验收测试的目的是，在真实的用户工作环境下，检验软件系统是否满足开发技术合同或SRS。验收测试的结论是用户确定是否接收该软件的主要依据。除应满足一般测试的准入条件外，在进行验收测试之前，应确认被测软件系统已通过系统测试。

软件测试 - 测试阶段 - 回归测试

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

回归测试的对象主要包括以下4个方面：

1. 未通过软件单元测试的软件，在变更之后，应对其进行单元测试。
2. 未通过配置项测试的软件，在变更之后，首先应对变更的软件单元进行测试，然后再进行相关的集成测试和配置项测试。
3. 未通过系统测试的软件，在变更之后，首先应对变更的软件单元进行测试，然后再进行相关的集成测试、配置项测试和系统测试。
4. 因其他原因进行变更之后的软件单元，也首先应对变更的软件进行单元测试，然后再进行相关的软件测试。

软件测试 - 面向对象的测试

• 算法层（单元测试）：包括等价类划分测试、组合功能测试（基于判定表的测试）、递归函数测试和多态消息测试。
• 类层（模块测试）：包括不变式边界测试、模态类测试和非模态类测试。
• 模板层/类树层（集成测试）：包括多态服务测试和展平测试。
• 系统层（系统测试）

软件测试 - 系统测试步骤

软件调试

软件调试的方法：

• 蛮力法：主要思想是“通计算机找错”，低效，耗时。
• 回溯法：从出错处人工沿控制流程往回追踪，直至发现出错的根源。复杂程序由于回溯路径多，难以实施。
• 原因排除法：主要思想是演绎和归纳，用二分法实现。

软件测试	软件调试
目的是找出存在的错误	目的是定位错误并修改程序以修正错误
从一个已知的条件开始，使用预先定义的过程，有预知结果	从一个未知的条件开始，结束的过程不可预计
测试过程可以事先设计，进度可以事先确定	调试不能描述过程或持续时间

系统转换计划 - 遗留系统演化策略

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

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

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

系统转换计划 - 新旧系统的转换策略

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

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

系统转换计划 - 数据转换和迁移

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

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

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

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

1. 对迁移后的数据进行质量分析。
2. 新旧系统查询数据对比检查。

系统运行与维护

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

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

软件测试不可能揭露旧系统中所有潜在的错误，所以这些程序在使用过程中还可能发生错误，诊断和更正这些错误的过程称为改正性维护。

为了改进软件未来的可维护性或可靠性，或者给未来的改进提供更好的基础而对软件进行修改，这类活动称为预防性维护。

被动调整是适应性维护。

为了更好的适应而进行的主动调整是预防性维护。

增加功能，改进某某功能，改善某某算法就是完善性维护。

重构代码，改善代码通用性是使系统的适应性更强，它属于预防性维护。