关于第三部分 软件测试过程（内容）

1.单元测试

⭐单元测试也称模块测试，这是针对最小的可测试软件元素-模块进行测试工作。

单元测试目的在于发现各模块内部可能存在的各种差错。

基本概念

“单元”：明确的功能、规格定义，与其他部分明确的接口定义

A.结构化程序设计：函数或子过程

B.面向对象：类或者类的方法

C.一个菜单、屏幕显示界面或对话框等

定义

• 单元测试的依据是详细设计描述
• 单元测试的内容包括单元的内部结构（如逻辑和数据流）以及单元的功能和可观测的行为
• 通常我们用白盒测试方法测试单元的内部结构，用黑盒测试方法测试单元的功能和可观测的行为

⭐单元测试环境

单元测试时，如果模块不是独立的程序，需要辅助测试模块：

• 驱动模块(Driver)：所测模块的主程序：它接收测试数据，把这些数据传递给所测试模块，最后再输出实测结果。当被测试模块能完成一定功能时，也可以不要驱动模块。
• 桩模块(Stub)：用来代替所测模块调用的子模块。

🔺被测试模块、驱动模块和桩模块共同构成一个测试环境

⭐单元测试内容

• 模块接口测试

I/O 参数值的个数、类型、次序、格式是否正确，I/O文件属性、操作是否正确等。

• 边界条件测试

边界条件常包括循环边界，最大最小值、控制流中等于、大于、小于的比较值等。

• 错误处理测试

检查“错误处理程序”本身的错误。

• 局部数据结构测试

数据说明是否正确、一致，变量及其初值定义是否正确等。

• 重要路径测试

重要路径通常是指完成模块功能的主要路径，一般是控制结构。

单元测试用例的设计思路

• 为系统运行设计用例
• 为正向测试设计用例
• 为逆向测试设计用例
• 为满足特殊需求设计用例
• 为代码覆盖设计用例
• 为覆盖率指标完成设计用例

⭐单元测试的过程

2. 集成测试

⭐集成测试又称组装测试，是在单元测试的基础上，将所有模块按照设计要求组装成子系统或系统进行的测试活动。选择集成测试数据是为了确保系统的组件或子系统正确地协同工作。测试用例将探索组件之间的不同交互，并确保产生正确的结果

集成测试内容

确保各单元组合在一起后能够按既定意图协作运行，并确保增量的行为正确，所测试的内容包括单元间的接口以及集成后的功能。

集成测试优点

• 单元测试具有不彻底性，对于模块间接口信息内容的正确性、相互调用关系是否符合设计无能为力。只能靠集成测试来进行保障。
• 同系统测试相比，由于集成测试用例是从程序结构出发的，目的性、针对性更强，测试项发现问题的效率更高，定位问题的效率也较高。
• 能够较容易地测试到系统测试用例难以模拟的特殊异常流程，从纯理论的角度来讲，集成测试能够模拟所有实际情况；
• 定位问题较快，由于集成测试具有可重复强、对测试人员透明的特点，发现问题后容易定位，所以能够有效地加快进度，减少隐患。

⭐集成测试层次

• 模块内集成测试
• 子系统内集成测试：先测试子系统内的功能模块，然后将各个功能模块组合起来确认子系统的功能是否达到预期要求。
• 子系统间集成测试：子系统间集成测试：测试的单元是子系统之间的接口。子系统是可单独运行的程序或进程。

集成测试方法

• 静态测试技术：针对概要设计的测试
• 动态测试技术：灰盒测试

🍉灰盒测试优点：

• 能够进行基于需求的测试和基于路径的覆盖测试。
• 可深入被测对象的内部，便于错误的识别分析和解决。
• 能够保证设计的黑盒测试用例的完整性，防止功能或功能组合的遗漏
• 能够减小需求或设计不详细或不完整性对测试有效性造成影响。

Drivers and Stubs

Drivers and Stubs是临时软件组件
§Drivers调用被测软件，将测试数据作为输入传递
在手动测试中，如果系统接口尚未完成，则在其位置使用test Driver来提供测试用户和被测软件之间的接口
Drivers
§Drivers 的复杂程度各不相同。
§可以对其进行硬编码，以运行一系列固定的输入值，从准备好的文件中读取数据，包含合适的随机数生成器等。集成测试-驱动程序
Stubs
§stub是被测试软件正常运行所需的临时或伪软件。
§这是一个一次性版本，允许进行测试。
§它将提供一组固定或有限的值，以传递给测试中的软件

⭐集成策略（基于分解的集成）

指在测试对象分析基础上，描述软件模块集成的方式、方法。

• 非增量式集成策略——一步到位**（Big Bang Integration）**

所有模块进行个别的单元测试后，按照程序结构图将各模块连接起来，把连接后的程序当作一个整体进行测试。又叫大爆炸集成。

优点：

①方法简单
②允许多测试人员同时并行工作，人力物力资源利用率较高

缺点：

①必须为每个模块准备相应的驱动模块和桩模块，测试成本较高
②一旦集成后包含多种错误，难以纠正

• 增量式集成策略——逐步实现

逐次将未曾集成测试的模块和已经集成测试的模块（或子系统）结合成程序包，再将这些模块集成为较大系统，在集成的过程中边连接边测试，以发现连接过程中产生的问题。

A.自顶向下增量式测试 Top-down integration

①主控模块作为测试驱动器test drivers。
②根据集成的方式（深度或广度），下层的桩模块一次一次地被替换为真正的模块。
③在每个模块被集成时，都必须进行单元测试。重复第2步，直到整个系统被测试完成。

优点：

①较早地验证了主要控制和判断点；
②按深度优先可以首先实现和验证一个完整的软件功能；
③功能较早证实，带来信心；
④只需一个驱动，减少driver开发的费用；
⑤支持故障隔离。

缺点：

①桩的开发量大；
②底层验证被推迟；
③底层组件测试不充分。

适用范围：

①产品控制结构比较清晰和稳定；
②高层接口变化较小；
③底层接口未定义或经常可能被修改；
④产口控制组件具有较大的技术风险，需要尽早被验证；
⑤希望尽早能看到产品的系统功能行为。

B.自底向上增量式测试 Bottom-up integration

从具有最小依赖性的底层组件开始，按照依赖关系树的结构，逐层向上集成，以检验系统的稳定性。最常用的集成策略。

步骤：

①起始于模块依赖关系树的底层叶子模块，也可以把两个或多个叶子模块合并到一起进行测试
②使用驱动模块对步骤１选定的模块（或模块组）进行测试
③用实际模块代替驱动模块，与它已测试的直属子模块组装成一个更大的模块进行测试
④重复上面的行为，直到系统最顶层模块被加入到已测系统中

优点：

①对底层组件行为较早验证；
②工作最初可以并行集成，比自顶向下效率高；
③减少了桩的工作量；
④能较好锁定软件故障所在位置。

缺点：

①驱动的开发工作量大；
②对高层的验证被推迟，设计上的错误不能被及时发现。

适用范围：

①适应于底层接口比较稳定；
②高层接口变化比较频繁；
③底层组件较早被完成。

C.三明治增量式测试（混合增量式测试）Sandwich integration

把系统划分成三层，中间一层为目标层，目标层之上采用自顶向下（stub）集成，之下采用自底向上（driver）集成

优点：

合了自顶向下和自底向上两种策略的优点
顶层和底层可以并行完成
所需的存根和驱动程序较少
难以隔离问题

缺点：

中间层测试不充分
测试收敛到中间、集成会话的数量可能不同

适用范围：

适应于大部分软件开发项目

测试生命周期

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QBPBR0EP-1685610313898)(https://github.com/Pangxiaox/2019-FinalExam-Notes/blob/master/软件测试图片/pic7.PNG)]

3. 单元测试框架

JUnit

• Junit框架让我们继承TestCase类，用java来编写自动执行、自动验证的测试。这些测试在Junit中称作“测试用例”。

• JUnit提供一个机制能够把相关测试用例组合到一起，称之为“测试套件“（test suite）

• JUnit还提供了一个“运行器”来执行一个测试套件。

①如果有测试失败了，这个测试运行器就报告出来
②如果没有失败，就会显示“OK”

使用JUnit的好处：

• 提高开发速度：测试是以自动化方式执行的，提升了测试代码的执行效率。
• 提高软件代码质量：它从使用小版本发布至整个系统集成，便于实现人员排除错误。同时引入重构概念，让代码更干净和富有弹性。
• 提升系统的可信赖度：它是回归测试的一种。支持修复或更正后的“再测试”，可确保代码的正确性。

使用JUnit：

注意JUnit对于测试用例的命名法是“test”+ TestCaseName测试用例的名字

例如：testDivideByZero() ：public、void、无方法参数

测试置具

常常有这样的情况，会我们写的几个测试都用到同一个或同一组对象。

①如果在每个测试里各自写这样的对象，将造成代码冗余，不利于维护。
②把这样的代码分离出来单独写，让所有的测试都可以利用这些对象代码。
③在JUnit框架里，把这些对象称为“测试置具”（test fixture）。

⭐JUnit框架小结

4. 系统测试

⭐系统测试是将经过集成测试的软件，作为计算机系统的一个部分，与系统中其他部分结合起来，在实际运行环境下对计算机系统进行的一系列严格有效地测试，以发现软件潜在的BUG，保证系统的正常运行。

系统测试的对象不仅仅包括需要测试的产品系统的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。因此，必须将系统中的软件与各种依赖的资源结合起来，在系统实际运行环境下进行测试。

系统测试的内容

• 性能测试

1.评估系统的能力

2.识别系统中的弱点

3.系统调优

• 压力测试

模拟巨大的工作负荷，以查看系统在峰值使用情况下是否可以正常运行。

通过逐步增加系统负载来测试系统性能的变化，并最终确定在什么负载条件下系统性能处于失效状态，以此来获得系统性能提供的最大服务级别的测试。

• 容量测试

采用特定手段，检测系统能够承载处理任务的极限值所进行的测试工作。

目的是使系统承受超额的数据容量来检测它是否能够正确处理，通过测试，分析出反映软件系统应用特征的某项指标的极限值，确定系统在其极限值状态下还能否保持其主要功能正常运行。

• 健壮性测试

用于测试系统抵御错误的能力。测试重点为当出现故障时，系统是否能够自动恢复或忽略故障继续运行。健壮性包括两层含义：一是高可靠性（软件系统的质量）；二是从错误中恢复的能力（软件系统的适应性）。

• 安全性测试

安全测试检查系统对非法侵入的防范能力。目的是为了发现软件系统中是否存在安全漏洞。

安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。例如想方设法截取或破译口令；专门定做软件破坏系统的保护机制；故意导致系统失败，企图趁恢复之机非法进入；试图通过浏览非保密数据，推导所需信息等等。

• 恢复性测试

恢复测试主要检查系统的容错能力。当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。

恢复测试首先要采用各种办法强迫系统失败，然后验证系统是否能尽快恢复。

对于自动恢复需验证重新初始化、检查点、数据恢复和重新启动等机制的正确性；对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。

• 备份测试

恢复性测试的一个补充，目的是验证系统在发生软件或者硬件失败时备份数据的能力。

从以下几个角度来进行设计：备份文件并且比较备份文件与最初文件的区别；存储文件和数据；完善系统备份工作的步骤；备份检查点数据；备份引起系统性能的衰减程度；手工备份的有效性；系统备份“触发器”的检测；备份期间的安全性；备份过程日志。

• 兼容性测试

兼容性测试是指检查软件之间是否能够正确地进行交互和共享信息。

测试软件是否和系统的其它与之交互的元素之间兼容，如：浏览器、操作系统、硬件等。验证测试对象在不同的软件和硬件配置中的运行情况。

• 安装性测试

软件如要实现其功能（除嵌入式软件外），第一步是安装操作。理想情况下，一个软件的安装程序应当可以较好的与已有系统相兼容，并有相应的提示界面供用户参考，安装完毕并实现其功能。若事先没有正确的安装测试，导致软件安装错误或失败，则软件根本就谈不上正确的执行，因此安装测试就显得相当重要。

安装性测试的目的就是要验证系统成功安装的能力，并保证程序安装后能正常运行。因此清晰且简单的安装过程是系统文档中最重要的部分。

• GUI测试

GUI测试是对图形用户界面进行的测试。

• Alpha测试

⭐α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。

⭐α测试的目的是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。尤其注重产品的界面和特色。α测试可以从软件产品编码结束之时开始，或在模块(子系统)测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。

α测试即为非正式验收测试。

• Beta测试

⭐Beta测试由软件的最终用户们在一个或多个客户场所进行。

⭐与Alpha测试不同，开发者通常不在Beta测试的现场，因Beta测试是软件在开发者不能控制的环境中的“真实”应用。用户Beta测试过程中遇到的一切问题（真实在或想像的），并且定期把这些问题报告给开发者。接收到在Beta测试期间报告的问题之后，开发者对软件产品进行必要的修改，并准备向全体客户发布最终的软件产品。

Beta测试优点：

①测试由最终用户实施

②大量的潜在测试资源

③提高客户对参与人员的满意程度

④与正式或非正式验收测试相比，可以发现更多由于主观原因造成的缺陷

• 回归测试

⭐回归测试是在软件发生变动时保证原有功能正常运作的一种测试策略和方法。

①所做的修改达到了预期的目的，例如缺陷得到了修改，新增加的功能得到了实现

②软件的修改没有引入新的缺陷，没有影响原有的功能实现

⭐回归测试不需要进行全面的测试，而是根据修改的情况进行有选择性的测试。

5. 软件测试自动化

手工测试与自动测试的对比

手工测试

耗费时间、低可靠性、人力资源有限、不一致性、对于一次性的测试有益

⭐自动测试

• 显著降低重复手工测试的时间
• 建立可靠、重复的测试，减少人为错误
• 增强测试范围和覆盖率

但它不能：

• 完全替代手工测试和手工测试工程师
• 保证100%的测试覆盖率
• 弥补测试实践的不足

自动化测试的优点和缺点：优点：
§支持重复测试用例的执行
§有助于测试大型测试矩阵
§允许并行执行
§鼓励无人值守执行
§提高准确性，从而减少人为错误
§节省时间和金钱
缺点：
§自动化仪器通常很昂贵；
§它在测试应用程序中的用户体验方面是无效的；
§编码知识和经验是必须的

⭐🍉 在系统功能测试、验收测试、适用性测试、涉及物理交互性测试时，多采用黑盒测试的手工测试方法；单元测试、集成测试、系统负载或性能、稳定性、可靠性测试等比较适合采用自动化测试。

测试自动化普遍存在的问题

• 不正确的观念或不现实的期望
• 测试工具本身的问题影响测试的质量
• 没有进行有效的、充分的培训
• 没有考虑到公司的实际情况，盲目引入测试工具
• 没有形成一个良好的使用测试工具的环境
• 其他技术问题和组织问题

功能测试工具(QTP、UFT)

QTP测试过程

定制测试计划 👉创建测试脚本👉增强测试脚本功能👉运行测试👉分析测试结果

QTP测试对象管理机制

• 创建测试：获取被操作对象的属性信息。使用唯一的对象名在对象仓库中记录该对象。将对象的全部属性信息存放在数据仓库中。标识关键属性信息。在脚本中记录对象名称和相应的动作。
• 运行测试：从脚本中获得对象名称。在对象仓库中定位对象，并获取其关键属性。根据关键属性信息在被测应用中定位对象。根据脚本中录入的动作执行相应的操作。

QTP八种检查点

标准检查点、图片检查点、图像检查点、文本/文本区域检查点、网页检查点、表格检查点、数据库检查点、XML检查点

性能（压力）测试工具 (LoadRunner)

解决测试资源的限制

• 利用“Virtual Users"代替实际测试人员
• 运行大量的”Virtual Users“在不同的机器上
• 通过”Controller“管理”Vusers“
• 利用图表工具分析测试结果
• 利用录制的脚本进行回归测试

LoadRunner工作流程

制定压力测试方案👉创建Web Virtual Users👉设计测试场景👉执行场景（额外有系统性能调优）👉分析测试结果

软件测试管理（后四部分）

软件测试环境

软件测试环境包括设计环境，实施环境和管理环境三部分，是指为了完成软件测试工作所必需的硬件、软件、设备、数据的总称。

软件测试环境是软件测试实施的一个重要阶段，软件测试环境适合与否会严重影响测试结果的真实性和正确性。

测试环境的要素

⭐一般来说，配置测试环境应该满足五个基本要素是：硬件、软件、网络环境、数据准备、测试工具。其中硬件、软件是测试环境中的最基本的两个要素，并派生出后三者。

• 硬件环境：软件赖以运行的硬件平台，例如服务器、个人服务器、PC机及配套设备等。测试中所需要的硬件设备的数量，以及对每台设备的硬件配置要求，包括CPU的速度、内存和硬盘的容量、网卡所支持的速度、打印机的型号等。
• 软件环境：指支持待测软件运行的软件系统平台，包括用来保存各种测试工作中生成的文档和数据的服务器所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本。测试工具软件也是软件环境中派生出来的一部分。
• 数据准备：在软件测试中测试的数据源非常重要，应尽可能的取得大量并且真实数据。无法取得真实数据时尽可能的模拟出大量的数据。数据准备包括数据量和真实性两个方面。数据的真实性通常表现在为正确数据和错误数据，在容错性测试中对错误数据的处理和系统恢复是测试的关键。
• 网络环境：网络环境是硬件因素和软件因素的综合。各种路由器，交换机，网线，网卡等是硬件基础，各种代理，网关，协议，防火墙等是软件基础。
• 测试工具：为了提高软件测试的效率，有时测试必须依托测试工具，以便测试过程的自动和半自动执行和测试结果的自动或半自动评审和报告。现在一般测试工具分为：代码分析工具，自动或半自动测试过程管理工具，测试资源管理工具 ，文档编写工具、性能测试工具、缺陷跟踪管理系统等。 包括软件的名称、版本、License数量，以及所要用到的相关补丁的版本。对于性能测试工具，则还应当特别关注所选择的工具是否支持被测应用所使用的协议。

测试环境管理员

每个测试项目或测试小组都应当配备一名专门的测试环境管理员，职责包括：

①测试环境的搭建

②测试环境的备份及恢复

软件测试计划

是软件测试员与产品开发小组交流意图的主要方式。

⭐测试计划目标

①规定测试活动的范围、方法、资源和进度；

②明确正在测试的项目、要测试的特性、要执行的测试任务、每个任务的负责人，以及与计划相关的风险。

③测试计划的最终目标是：交流（而不是记录）软件测试小组的意图、期望，以及对将要执行的测试任务的理解。

测试计划主题

①测试过程中第一个论题是定义测试小组的高级期望。

②测试计划需要明确在项目中工作的人，他干什么，怎样和他联系

③定义，如对软件缺陷的定义等，这些定义要达成一致

④明确团队之间的责任

⑤明确哪些要测试，哪些不用测试

⑥测试的阶段

⑦测试策略

⑧资源需求

⑨测试员的任务分配

⑩测试进度

测试计划制订过程

分析和测试软件需求👉定义测试策略👉定义测试环境👉定义测试管理👉编写和审核测试计划

定义工作进度的过程

确认工作任务👉估算工作量👉编写进度计划

测试策略

• 测试范围

测试过度，则在测试覆盖中存在大量冗余；测试范围过小，则存在遗漏错误的风险。

定义测试范围是一个在测试时间、费用和质量风险之间寻找平衡的过程。

• 测试方法

①需求分析阶段：静态测试

②概要设计与详细设计阶段：静态测试

③编码和单元测试阶段：静态测试和动态测试、白盒测试

④集成测试阶段：动态测试、白盒测试、黑盒测试

⑤系统测试阶段：动态测试、黑盒测试

⑥验收测试阶段：动态测试、黑盒测试

• 测试标准

定义测试标准的目的是设置测试中遵循的规则。

①基于测试用例的规则

②基于”测试期缺陷密度“的规则

③基于”运行期缺陷密度“的规则

需要制订这几种标准：测试入口标准、测试出口标准、测试暂停与继续标准

• 测试工具

选择自动化测试工具

软件缺陷(bug)管理

所谓软件缺陷，即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。

缺陷的主要属性

缺陷标识、缺陷类型、缺陷严重程度、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷根源

如何报告缺陷

①结构:测试过程的结构。
②再现:三次再现缺陷。
③隔离:确定影响再现的变量。
④推广:确定系统其他部分是否可能出现这种错误。
⑤比较:评审运行相似测试的结果。
⑥总结:简短描述客户或用户的质量体验和观察到的特征。
⑦压缩:精简不必要的信息，特别是冗余的测试步骤。
⑧去除歧义:使用清晰的语言。
⑨中立:公正地表达自己的意思，避免夸张、幽默、讽刺。
⑩评审:同行评审。

⭐如何跟踪缺陷

• 使用状态来管理缺陷生命周期

• 强调所有权和责任

• 关键转移

缺陷度量

帮助确定产品缺陷分布的情况、 帮助确定产品缺陷分布的情况“概率”和“风险发生后所带来的损失”来评估风险。

• 测试有效性度量

• 缺陷度量

  • 缺陷数量
  • 产品缺陷

  在产品中或客户发现的缺陷数量。

  • 缺陷消除率（DRE）

  DRE = （测试期间发现的bug数量）/（测试期间发现的bug数量+未发现的bug数量）

  未发现的bug数量=客户发现的bug数量

  • 缺陷潜伏期（Defect Age）

  我们发现bug的时间越晚，这个bug所带来的损害就越大，修复这个bug所耗费的成本就越多。

  • 缺陷损耗

  缺陷损耗 = （缺陷数量*发现的阶段潜伏期）/（缺陷总量）

  损耗的数值越低，说明发现过程越有效。

  • 缺陷密度

  缺陷密度 = （缺陷数量）/（代码行或功能点的数量）

软件配置管理（SCM）

⭐①是软件工程中用来管理软件资产变更的一项规程，包括它所使用的相关工具和应用技术（流程和方法）。

②协调软件开发使得混乱减到最小的技术

⭐③软件配置管理是指通过执行版本控制、变更控制等规程，以及使用合适的配置管理软件，来保证所有配置项的完整性和可跟踪性。配置管理是对工作成果的一种有效保护。

④表示和确定系统中配置项的过程，在系统整个生存期内控制这些配置项的投放和更动，记录并报告配置的状态和更动要求，验证配置项的完整性和正确性。

软件配置管理的基本概念

• 配置项

凡是纳入配置管理范畴的工作成果统称为配置项。配置项主要分两大类：

①属于产品组成部分的工作成果，例如源代码、需求文档、设计文档、测试用例等等。

②在管理过程中产生的文档,例如各种计划、监控报告等等，这些文档虽然不是产品的组成部分，但是值得保存。

• 基线

基线（Baseline）由一组配置项组成，这些配置项构成了一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改。

基线通常对应于开发过程中的里程碑（Milestone），一个产品可以有多个基线，也可以只有一个基线。基线的主要属性有：名称、标识符、版本、日期等。

通常将交付给客户的基线称为一个“Release”，为内部开发用的基线则称为一个“Build”

• 配置管理员

为了提高配置管理的效率和安全性，项目应当设有配置管理员这个角色。配置管理员的主要工作是为项目制定配置管理计划，创建和维护配置库等。

⭐SCM的三个应用层次（从低到高）

• 版本控制

版本控制主要应用于个人独立开发或小组开发，它可以控制任何文件的版本、实现分支和归并功能、进行文本比较、标记注释和版本报告信息。

版本控制就是通过对软件开发进程中的文档及源码的版本（每一次改动）进行控制(记录、追踪、比较、合并等)。

• 以开发者为中心

以开发者为中心主要应用于部门级开发，它可用于软件维护、不断增加的开发任务、并行开发、QA及测试，它面向大型团队、利于交流、能最大限度地利用人力资源。

• 过程驱动

过程驱动主要使用于企业级开发，着重解决新的工具引入、IT审核、管理报告、复杂的生命周期、应用工具包、集成解决方案、资料库等问题，实现真正规范的团队开发。

软件维护

⭐软件维护的定义

软件维护是指软件系统交付使用以后，为了改正错误或满足新的需要而修改软件的过程。

要求进行维护的原因

• 改正程序中的错误和缺陷
• 改进设计以适应新的软、硬件环境
• 增加新的应用范围

⭐软件维护的类型

• 改正性维护

为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，应当进行的诊断和改正错误的过程就叫做改正性维护。

• 适应性维护

为使软件适应外部环境或数据环境的变化，而去修改软件的过程就叫做适应性维护。

• 完善性维护

为了满足用户提出的新要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。

• 预防性维护

采用先进的软件工程方法对需要维护的软件或软件中的某一部分（重新）进行设计、编制和测试，称为预防性维护。

⭐🍉 各种维护类型和维护工作量的比例

• 完善性维护：50%-66%
• 适应性维护：18%-25%
• 改正性维护：17%-21%
• 其他维护：4%

软件维护特点

• 结构化维护与非结构化维护差别巨大

⭐①非结构化维护

在非结构化维护过程中，开发人员只能通过阅读、理解和分析源程序来了解系统功能、软件结构、数据结构、系统接口和设计约束等，这样做是十分困难的，也容易产生误解。

在没有文档的情况下，也不可能进行回归测试，很难保证程序的正确性。

风险极大！

⭐②结构化维护

在结构化维护的过程中，所开发的软件具有各个阶段的文档，它对于理解和掌握软件的功能、性能、体系结构、数据结构、系统接口和设计约束等有很大的作用。

这种维护有利于减少工作量和降低成本，大大提高软件的维护效率。

• 软件维护代价高昂

$$M=P+K\ast e^{(c-d)}$$

M是维护的总工作量，P是生产性工作量，K是经验常数，c是复杂程度，d是维护人员对软件的熟悉程度.

• 维护问题多

影响软件维护工作量的因素

• 系统的大小
• 程序设计语言
• 系统年龄
• 数据库技术的应用
• 先进的软件开发技术
• 其它一些因素

软件维护的过程

软件维护过程由一系列变更请求触发。变更请求可能来自系统用户、管理层或者客户。对变更请求经过成本和影响分析评估，一旦变更请求获得批准，就要对系统规划一个新版本，然后实现这个变更。

软件维护工作在维护申请提出之前就开始了，它包括：
①建立维护组织，强制报告和评估的过程；
②为每个维护申请确定标准化的事件序列；
③制定保存维护活动记录的制度和有关复审及评估的标准。

软件维护的副作用

软件维护的副作用指，由于维护或在维护过程中其他一些不期望的行为引入的错误。

分为三类：

• 代码副作用
• 数据副作用
• 文档副作用

软件可维护性

⭐软件可维护性是指纠正软件系统出现的错误和缺陷，以及为满足新的要求进行修改、扩充或压缩的容易程度。

可维护性、可使用性、可靠性是衡量软件质量的主要质量特性，也是用户十分关心的几个方面。

🔺目前广泛使用的是如下七个特性来衡量程序的可维护性

• 可理解性
• 可测试性
• 可修改性
• 可靠性
• 可使用性
• 可移植性
• 效率

可维护性的度量

常用的度量一个可维护性的程序的七种特性的方法，就是：

• 质量检查表
• 质量测试
• 质量标准

⭐提高可维护性的方法

• 建立明确的软件质量目标和优先级
• 使用提高软件质量的技术和工具
• 进行明确的质量保证审查
• 选择可维护的程序设计语言
• 改进程序的文档