20_系统测试与维护

测试基础知识

测试原则

动态测试

静态测试

测试策略

测试阶段

测试用例设计

黑盒测试用例设计

白盒测试用例设计

McCabe度量法

鲁棒性测试

缺陷探测率(Defect Detection Percentage,DDP)

调试

系统维护基础

系统转换

系统维护指标

软件容错技术

嵌入式安全关键系统

项目管理

进度(时间)管理

质量管理

配置管理

风险管理

测试基础知识

测试原则

系统测试原则包括如下几项：

(1)软件测试最根本的目的是发现软件的错误。

(2)应尽早并不断地进行测试。

(3)测试工作应该避免由原开发软件的人或小组承担。

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

(5)既包含有效、合理的测试用例，也包含不合理、失效的用例。

(6)检验程序是否做了该做的事，且是否做了不该做的事。

(7)严格按照测试计划进行。

(8)妥善保存测试计划和测试用例。

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

动态测试

动态测试也称动态分析，主要特征是计算机必须真正运行被测试的程序，通过输入测试用例，对其运行情况进行分析，判断期望结果和实际结果是否一致。动态测试包括功能确认与接口测试、覆盖率分析、性能分析、内存分析等。在动态分析中，通过最大资源条件进行系统的压力测试，以判断系统的实际承受能力，在通信比较复杂的系统中尤为重要。

黑盒测试法：功能性测试，不了解软件代码结构，根据功能设计用例，测试软件功能。

白盒测试法：结构性测试，明确代码流程，根据代码逻辑设计用例，进行用例覆盖。

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

静态测试

静态测试也称静态分析，主要特征是在用计算机测试源程序时，计算机并不真正运行被测试的程序。静态测试包括代码检查、静态结构分析、代码质量度量等。它可以由人工进行，也可以借助软件工具自动进行。

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

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

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

测试策略

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

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

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

测试阶段

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

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

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

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

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

测试用例设计

黑盒测试用例设计

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

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

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

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

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

白盒测试用例设计

知道程序的代码逻辑，按照程序的代码语句来设计覆盖代码分支的测试用例，覆盖级别从低至高分类如下。

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

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

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

MC/DC(判定/条件)覆盖率指在一个程序中每一种输入输出至少应出现一次，在程序中的每一个条件必须产生所有可能的输出结果至少一次，并且每个判定中的每个条件必须能够独立影响一个判定的输出，即在其他条件不变的前提下仅改变这个条件的值，而使判定结果改变。

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

McCabe度量法

McCabe度量法又称为圈复杂度，有以下三种方法计算圈复杂度。

(1)没有流程图的算法。基数为1,碰到以下项加1:

1)分支数(如if、for、while和do while);switch中的case语句数。

2)如果条件是两个复合条件，则加2,否则加1。

(2)给定流程图G的圈复杂度V(G),定义为V(G)=E-N+2,E是流图中边的数量，N是流图中结点的数量。

(3)给定流程图G的圈复杂度V(G),定义为V(G)=P+1,P是流程图G中判定结点的数量。

鲁棒性测试

鲁棒是Robust的音译，也就是健壮或强壮的意思。它是在异常和危险情况下系统生存的关键。比如说，计算机软件在输入错误、磁盘故障、网络过载或有意攻击情况下，不死机、不崩溃，就是该软件的鲁棒性。所谓“鲁棒性”,是指控制系统在一定(结构、大小)的参数摄动下，维持其他某些性能的特性。鲁棒测试是对各个模块的功能和系统进行容错性的测试。

缺陷探测率(Defect Detection Percentage,DDP)

DDP=Bugs(tester)/[Bugs(tester)+Bugs(customer)]

其中，Bugs(tester)为软件开发方测试者发现的Bugs数目；Bugs(customer)为客户方发现并反馈技术支持人员进行修复的Bugs数目。

DDP越高，说明测试者发现的Bugs数目越多，发布后客户发现的Bugs就越少，降低了外部故障不一致成本，达到了节约总成本的目的，可获得较高的测试投资回报率(Return on Investment,ROI)。

调试

测试是发现错误，调试是找出错误的代码和原因。调试需要确定错误的准确位置；确定问题的原因并设法改正；改正后要进行回归测试。

调试的方法如下。

(1)蛮力法：又称为穷举法或枚举法，穷举出所有可能的方法一一尝试。

(2)回溯法：又称为试探法，按选优条件向前搜索，以达到目标，当发现原先选择并不优或达不到目标时，就退回一步重新选择，这种走不通就退回再走的技术为回溯法。

(3)演绎法：是由一般到特殊的推理方法，与“归纳法”相反，从一般性的前提出发。得出具体陈述或个别结论的过程。

(4)归纳法：是由特殊到一般的推理方法，从测试所暴露的问题出发，收集所有正确或不正确的数据，分析它们之间的关系，提出假想的错误原因，用这些数据来证明或反驳，从而查出错误所在。

系统维护基础

系统转换

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

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

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

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

系统维护指标

系统可维护性的评价指标包含以下四种。

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

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

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

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

软件维护类型包含以下四种

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

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

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

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

软件容错技术

容错就是软件遇到错误的处理能力，实现容错的手段主要是冗余，包括下面四种冗余技术。

(1)结构冗余：分为静态、动态、混合冗余三种，当错误发生时对错误进行备份处理。

(2)信息冗余：为检错和纠错在数据中加上一段额外的信息，例如校验码原理。

(3)时间冗余：遇到错误时重复执行，例如回滚，重复执行还有错，则转入错误处理逻辑。

(4)冗余附加技术：冗余附加技术是指为实现结构、信息和时间冗余技术所需的资源和技术，包括程序、指令、数据、存放和调动它们的空间和通道等。在屏蔽硬件错误的容错技术中，冗余附加技术包括关键程序和数据的冗余及调用；检测、表决、切换、重构和复算的实现。在屏蔽软件错误的容错技术中，冗余附加技术包括冗余备份程序的存储及调用；实现错误检测和错误恢复的程序；实现容错软件所需的固化程序。

容错技术可以提高计算机系统的可靠性，利用元件冗余保证在局部故障情况下系统还可工作，其中带有热备份的系统称为双重系统。双重系统中，两个子系统同时同步运行，当联机子系统出错时，由备份子系统接替。

计算机系统容错技术主要研究系统对故障的检测、定位、重构和恢复等。典型的容错结构有两种，即单通道计算机加备份计算机结构和多通道比较监控系统结构。

从硬件余度设计角度出发，系统通常采用相似余度或非相似余度实现系统容错，从软件设计角度出发，实现容错常用的有恢复块技术和N版本技术等。

嵌入式安全关键系统

安全关键系统是指其不正确的功能或失效会导致人员伤亡、财产损失等严重后果的计算机系统。可见，由于嵌入式安全关键系统失效的后果非常严重，所以，安全关键系统有一条原则：任何情况下决不放弃!这要求不仅对符合规范要求的外部状态和输入有正确的处理，而且要求在不符合规范要求的情况，也能适当处理，让系统处于安全的状态。

关于健壮性，是指存在意外的扰动情况下系统保持可接受水平的服务的能力。即，健壮性是关于系统在意外状态下的行为，只有当系统偏离其规范时才可看出它的健壮性或者脆弱性。

项目管理

进度(时间)管理

(1)关键路径-双代号图(PERT图)。类似于前趋图，是有向图，反映活动之间的依赖关系，有向边上标注活动运行的时间，但无法反映活动之间的并行关系。关键路径相关计算概念如下。

1)最早开始时间(ES):取所有前驱活动最早完成时间EF的最大值。

2)最早完成时间(EF):最早开始时间(ES)+活动本身时间(DU)。

3)关键路径(项目总工期):项目中耗时最长的一条线路。

4)最晚完成时间(LF):取后续活动最晚开始时间的最小值。

5)最晚开始时间(LS):最晚完成(LF)-活动本身时间(DU)。

6)松弛时间(总时差):某活动的最晚开始时间-最早开始时间(或最晚完成时间-最早完成时间),也即该活动最多可以晚开始多少天。

7)虚路径：在图中用虚线表示的路径，既不消耗资源也不消耗时间，仅用于表示依赖关系。

例：某软件项目的活动图如图3-6-2所示。图中顶点表示项目里程碑，连接顶点的边表示包含的活动，则里程碑在关键路径上，活动FG的松弛时间为

解析：关键路径就是从起点到终点的最长路径，为S-D-F-H-FI(将开始START简写为S,结束FINISH简写为FI),长度为48;松弛时间为FG的最晚开始时间-最早开始时间；从第0天开始计算，基于网络计划图的前推法，活动FG的最早开始时间为第18,最迟开始时间为第38。因此，活动FG的松弛时间为20。具体表格法计算关键路径的过程如下表所示。

(2)甘特(Gantt)图。又称为横道图，横轴表示时间，纵轴表示活动，以时间顺序表示活动，能反映活动间的并行关系，但无法反映活动之间的依赖关系，因此也难以清晰地确定关键任务和关键路径。

质量管理

质量规划：识别项目及其产品的质量要求和标准，并书面描述项目将如何达到这些要求和标准的过程。

质量保证：一般是每隔一定时间(例如，每个阶段末)进行的，主要通过系统的质量审计(软件评审)和过程分析来保证项目的质量。

质量控制：实时监控项目的具体结果，以判断它们是否符合相关的质量标准，制订有效方案，以消除产生质量问题的原因。

一定时间内质量控制的结果也是质量保证的质量审计对象。质量保证的成果又可以指导下一阶段的质量工作，包括质量控制和质量改进。

配置管理

软件配置管理是贯穿整个软件生存周期的一项技术。它的主要功能是控制软件生存周期中软件的改变，减少各种改变所造成的影响，确保软件产品的质量。

配置管理是指以技术和管理的手段来监督和指导开展如下工作的规程：

(1)识别和记录配置项的物理特性和功能特性。

(2)管理和控制上述特性的变更。

(3)记录和报告变更过程和相应的配置项状态。

(4)验证配置项是否与需求一致。

基线：软件开发过程中特定的点，是项目生存期各开发阶段末尾的特定点，又称为里程碑，反应阶段性成果。配置管理至少应有以下三个基线。

功能基线：是指在系统分析与软件定义阶段结束时，经过正式批准、签字的系统规格说明书、项目任务书、合同书或协议书中所规定的对待开发软件系统的规格说明。

分配基线：是指在需求分析阶段结束时，经过正式评审和批准的需求规格说明。分配基线是最初批准的分配配置标识。

产品基线：是指在综合测试阶段结束时，经过正式评审和批堆的有关所开发的软件产品的全部配置项的规格说明。产品基线是最终批准产品配置标识。

配置项：配置管理的基本单位。软件开发过程中的所有文档、代码、工具都可作为配置项，主要包括六种类型：环境类(系统开发环境)、定义类(需求分析与系统定义阶段)、设计类(设计阶段)、编码类(编码及单元测试阶段)、测试类(系统测试完成后的工作)、维护类(维护阶段)。即产品组成部分的工作成果+项目管理和机构支撑过程域产生的文档。

检查点：指在规定的时间间隔内对项目进行检查，比较实际与计划之间的差异，并根据差异进行调整。

里程碑：里程碑就是在项目过程中管理者或其他利益相关方需要关注的项目状态时间点。完成阶段性工作的标志，不同类型的项目里程碑不同。

软件配置项的版本控制，配置项有三个状态：草稿、正式、修改，如下图所示。

配置项规则如下：

处于草稿状态的配置项的版本号格式为：0.YZ,其中YZ数字范围为01～99。随着草稿的不断完善，YZ的取值应递增。YZ的初值和增幅由开发者自己把握。

处于正式发布状态的配置项的版本号格式为：X.Y。其中X为主版本号，取指范围为1～9;Y为次版本号，取值范围为1～9。配置项第一次正式发布时，版本号为1.0。

如果配置项的版本升级幅度比较小，一般只增大Y值，X值保持不变。只有当配置项版本升级幅度比较大时，才允许增大X值。

处于正在修改状态的配置项的版本号格式为：X.YZ。在修改配置项时，一般只增大Z值，X.Y值保持不变。

配置库：一般软件项目开发过程采取开发库、受控库和产品库的管理方法，且采取三库物理隔离的策略。

开发库存放项目确定的软件配置项集合，以及项目组需要存放的其他文件或过程记录。

受控库存放在软件开发过程中达到相对稳定、可以作为后续开发活动输入的软件工作产品(或称为配置项)。软件工作产品(配置项)通常分为文档和代码两大类，文档纳入受控库的条件通常规定为“通过评审且评审问题已归零或变更验证已通过，已完成文档签署”;代码纳入受控库的条件通常规定为“通过了项目规定的测试或回归测试，或通过了产品用户认可”的代码状态。

产品库存放作为软件产品的受控库中各阶段基线或产品基线对应的文档、源程序和可执行代码。