这是我参与「第五届青训营 」伴学笔记创作活动的第10天！
本篇文章主要就软件工程的测试与维护进行课堂笔记知识点的梳理。
一、测试基础
1.1 测试原则
- 应尽早并不断的进行测试;
- 测试工作应该避免由原开发软件的人或小组承担;
- 在设计测试方案时，不仅要确定输入数据，而且要根据系统功能确定预期的输出结果;
- 既包含有效、合理的测试用例，也包含不合理、失效的用例;
- 检验程序是否做了该做的事，且是否做了不该做的事;
- 严格按照测试计划进行;
- 妥善保存测试计划和测试用例;
- 测试用例可以重复使用或追加测试。
1.2 动态测试类型
程序运行时测试，分为——
- 黑盒测试法: 功能性测试，不了解软件代码结构，根据功能设计用例，测试软件功能。
- 白盒测试法: 结构性测试，明确代码流程，根据代码逻辑设计用例，进行用例覆盖。
- 灰盒测试法: 即既有黑盒，也有白盒。
1.3 静态测试:类型
程序静止时，即对代码进行人工审查，分为——
- 桌前检查: 程序员检查自己编写的程序，在程序编译后，单元测试前。
- 代码审查: 由若干个程序员和测试人员组成评审小组，通过召开程序评审会来进行审查。
审查小组的任务是发现任务而不是改正任务。 - 代码走查: 也是采用开会来对代码进行审查，但并非简单的检查代码，而是由测试人员提供测试用例，让程序员扮演计算机的角色，手动运行测试用例，检查代码逻辑。
1.4 测试策略
- 自底向上: 从最底层模块开始测试，需要编写驱动程序，而后开始逐一合并模块，最终完成整个系统的测试。优点是较早的验证了底层模块。
- 自顶向下: 先测试整个系统，需要编写桩程序，而后逐步向下直至最后测试最底层模块。优点是较早的验证了系统的主要控制和判断点。
- 三明治: 既有自底向上也有自顶向下的测试方法，二者都包括。兼有二者的优点，缺点是测试工作量大。
二、测试阶段
-
单元测试: 也称为模块测试，测试的对象是可独立编译或汇编的程序模块、软件构件或 OO 软件中的类(统称为模块)，测试依据是软件详细设计说明书。
-
集成测试: 目的是检查模块之间，以及模块和已集成的软件之间的接口关系，并验证已集成的软件是否符合设计要求。测试依据是软件概要设计文档。
（非）渐增式测试方法, -
确认测试: 主要用于验证软件的功能、性能和其他特性是否与用户需求一致。根据用户的参与程度，通常包括以下类型:
- 内部确认测试: 主要由软件开发组织内部按照 SRS 进行测试。
- Alpha 测试: 用户在开发环境下进行测试。
- Beta 测试: 用户在实际使用环境下进行测试，通过该测试后，产品才能交付用户。
- 验收测试: 针对 SRS ，在交付前以用户为主进行的测试。其测试对象为完整的、集成的计算机系统。
验收测试的目的是，在真实的用户工作环境下，检验软件系统是否满足开发技术合同或 SRS 。验收测试的结论是用户确定是否接收该软件的主要依据。除应满足--般测试的准入条件外，在进行验收测试之前，应确认被测软件系统已通过系统测试。
-
系统测试: 测试对象是完整的、集成的计算机系统;测试的目的是在真实系统工作环境下，验证完成的软件配置项能否和系统正确连接，并满足系统/子系统设计文档和软件开发合同规定的要求。测试依据是用户需求或开发合同。主要内容包括功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、安装与反安装测试等，其中，最重要的工作是进行功能测试与性能测试。
功能测试主要采用黑盒测试方法;性能测试。主要指标有响应时间、吞吐量、并发用户数和资源利用率等。 -
配置项测试: 测试对象是软件配置项，测试目的是检验软件配置项与 SRS 的一致性。测试的依据是 SRS 。在此之间，应确认被测软件配置项已通过单元测试和集成测试。
-
回归测试: 测试目的是测试软件变更之后，变更部分的正确性和对变更需求的符合性，以及软件原有 的、正确的功能、性能和其他规定的要求的不损害性。
三、测试用例设计
3.1 黑盒测试用例
将程序看做一个黑盒子，只知道输入输出，不知道内部代码，由此设计出测试用例，分为下面几类:
- 等价类划分: 把所有的数据按照某种特性进行归类，而后在每类的数据里选取一个即可。
- 等价类测试用例的设计原则: 设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止;计一个新的测试用例，使其仅覆盖一个尚未被盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。
- 边界值划分: 将每类的边界值作为测试用例，边界值一般为范围的两端值以及在此范围之外的与此范围 间隔最小的两个值，如年龄范围为 0-150 ，边界值 0,150 ， -1,151 四个。
- 错误推测: 没有固定的方法，凭经验而言，来推测有可能产生问题的地方，作为测试用例进行测试。
- 因果图: 由一个结果来反推原因的方法，具体结果具体分析，没有固定方法。
3.2 白盒测试用例
知道程序的代码逻辑，按照程序的代码语句，来设计覆盖代码分支的测试用例,覆盖级别从低至高分为下面几种:
- 语句覆盖SC:逻辑代码中的所有语句都要被执行一-遍，覆盖层级最低，因为执行了所有的语句，不代 表执行了所有的条件判断。
- 判定覆盖DC:逻辑代码中的所有判断语句的条件的真假分支都要覆盖一次。
- 条件覆盖CC:针对每一个判断条件内的每—一个独立条件都要执行―-遍真和假。
- 条件判定组合覆盖CDC:同时满足判定覆盖和条件覆盖。
- 路径覆盖:逻辑代码中的所有可行路径都覆盖了，覆盖层级最高。
3.3 调试
测试是发现错误，调试是找出错误的代码和原因。 调试需要确定错误的准确位置;确定问题的原因并设法改正;改正后要进行回归测试。
1. 调试的方法
- 蛮力法: 又称为穷举法或枚举法，穷举出所有可能的方法——尝试。
- 回溯法: 又称为试探法，按选优条件向前搜索，以达到目标，当发现原先选择并不优或达不到目标，就退回一步重新选择，这种走不通就退回再走的技术为回溯法。
- 演绎法: 是由一般到特殊的推理方法，与“归纳法”相反，从一般性的前提出发。得出具体陈述或个别结论的过程。
- 归纳法: 是由特殊到一般的推理方法，从测试所暴露的问题出发,收集所有正确或不正确的数据,分析它们之间的关系，提出假想的错误原因，用这些数据来证明或反驳,从而查出错误所在。
2. 软件的两种属性⭐
- 外部属性: 指面向管理者和用户的属性，可直接测量,一般为性能指标。
- 内部属性: 指软件产品本身的的属性，如可靠性等，只能间接测量。
3. 系统维护概述
系统的可维护性可以定义为维护人员理解、改正、改动和改进这个软件的难易程度，其评价指标如下:
- 易分析性。- 软件产品诊断软件中的缺陷或失效原因或识别待修改部分的能力。
- 易改变性。- 软件产品使指定的修改可以被实现的能力，实现包括编码、设计和文档的更改。
- 稳定性。- 软件产品避免由于软件修改而造成意外结果的能力。
- 易测试性。- 软件产品使已修改软件能被确认的能力。
- 维护性的依从性。- 软件产品遵循与维护性相关的标准或约定的能力。
系统维护包括硬件维护、软件维护和数据维护，其中软件维护类型如下:
- 正确性维护: 发现了 bug 而进行的修改。
- 适应性维护: 由于外部环境发生了改变，被动进行的对软件的修改和升级。
- 完善性维护: 基于用户主动对软件提出更多的需求，修改软件，增加更多的功能，使其比之前的软件功 能、性能更高，更加完善。
- 预防性维护: 对未来可能发生的 bug 进行预防性的修改。
结尾
测试是发现错误,调试是找出错误的代码和原因。测试软件一般采用黑盒和白盒的测试方法。
综上，今天又是学习的一天！😊
