软件工程-软件测试和系统运维

Posted 2021-07-17 小毕超

⭐⭐⭐⭐⭐

一、软件测试概念和目标

概念：为了发现错误而执行程序的过程

目标（《软件测试的艺术》）

是为了发现错误而执行程序的过程

好的测试方案能够发现迄今为止尚未发现的错误

成功的测试将发现至今尚未发现的错误

二、软件测试原则

1. 应尽早并不断地进行测试

2. 程序员避免测试自己设计的程序：测试工作应避免由原开发软件的人或小组来承担（单元测试除外）

3. 不仅要包括合理、有效的输入条件，也要包括不合理、失效的输入条件

4. 不仅要确定输入数据，而且要从系统的功能出发确定输出的结果

5. 不仅要检测程序是否做了该做的事，还要检测是否做了不该做的事

6. 修改后应进行回归测试

7. 尚未发现的错误数量与该程序已发现的错误数成正比。

8. 充分重视测试中的群集现象

9. 所有的测试都应追溯到用户需求

10. 穷举测试是不可能的

11. 严格按照测试计划来进行，避免随意性

12. 妥善保存测试计划、测试用例、作为软件

三、基本测试活动

1. 拟定测试计划，制定系统测试计划

   在拟定测试计划时，要充分考虑整个项目的开发时间和开发进度以及一些人为因素和客观条件等，使得测试计划是可行的。测试计划的内容主要有：测试的内容、进度安排、测试所需的环境和条件（包括设备、被测项目、人员等）、测试培训安排等。

2. 编制测试大纲

   测试大纲是测试的依据。其明确详尽地规定了在测试中针对系统的每一项功能或特性所必须完成的基本测试项目和测试完成的标准。

3. 设计和生成测试用例

   根据测试大纲，设计和生成测试用例。在设计测试用例时，可综合利用前面介绍的测试用例设计技术，产生测试设计说明文档，其内容主要有：被测项目、输入数据、测试过程、预期输出结果等等。

4. 执行系统测试，实施测试

   测试的实施阶段是由一系列的测试周期组成的。在每个测试周期中，测试人员和开发人员将依据预先编制好的测试大纲和准备好的测试用例，对被测软件或设备进行完整的测试。

5. 缺陷管理与改错，生成测试报告

   测试完成后要形成相应的测试报告，主要对测试进行概要说明，列出测试的结论，指出缺陷和错误。

四、测试阶段和分类

1. 单元测试

   概念：又称模块测试，是通过对每个最小的软件模块进行测试，对照模块的功能说明，检查各个程序模块是否正确地实现了规定的功能，确保其能正常工作。测试主体：单元测试由开发人员执行

   测试内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试（模块测试，模块功能、性能、接口等）。

2. 集成测试

   概念：在单元测试的基础上，需要将所有模块按照概要设计说明书和详细设计说明书的要求进行组装。主要目的是验证组成软件系统的各模块的接口和交换作用。（模块间的接口，一般在概要设计阶段完成）

   组装时需要考虑的问题：在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失。

   一个模块的功能是否会对另一个模块的功能产生不利的影响；各个子功能组合起来，能否达到预期要求的父功能；全局数据结构是否有问题；单个模块的误差累积起来，是否会放大，以致达到不能接受的程度。

   模块组装方式

   1. 一次性组装方式：其结果：发现有错误，却茫然找不到原因；查错和改错都会遇到困难。

   （1）自顶向下的增殖方式：优点：在测试过程中较早地验证了主要的控制和判断点；功能可行性较早地得到证实，还能增强开发者和用户成功的信心。缺点：导致过多的回归测试；增加建桩模块的复杂度，导致增加附加测试

   （2）自底向上的增殖方式：优点：可以把容易出问题的部分在早期解决；缺点：对主要的控制直到最后才接触到；可以实施多个模块的并行测试，提高测试效率。

   （3）混合增殖方式，完成的标志：成功地执行了测试计划中规定的所有集成测试；修正了所发现的错误（与用户就剩余错误的修改计划达成一致）；测试结果通过了专门小组的评审。

   2. 增量式组装： 测试效果更好。

3. “冒烟测试”（英文：smoke testing）

   这一术语源自硬件行业。对一个硬件或硬件组件进行更改或修复后，直接给设备加电。如果没有冒烟，则该组件就通过了测试。

4. 确认测试

   概念：又称合格性测试，用来检验软件是否符合用户的需求。一般采用黑盒测试法，通过一系列证明软件功能和要求的测试来实现。确认测试着重考虑软件是否满足合同规定的所有功能和性能、文档资料是否完整。确认人机界面和其他方面（如可移植性、兼容性、错误恢复能力和可维护性等）是否令用户满意确认测试过程的重要环节就是配置审查工作。配置审查的文件资料包括用户手册、操作手册和设计资料。其目的在于确保软件的所有文件资料均已编写齐全，用于支持日后软件的维护工作。（验证软件与需求的一致性。内部确认测试、Alpha 测试、Beta 测试，验收测试）

5. 系统测试

   概念：系统测试真实环境下，验证完整的软件配置项能否和系统正确连接。将软件与整个系统的硬件、外设、支持软件、数据和人员等结合起来，以需求规格说明为依据，在实际运行环境下进行测试。检验其是否有不符合系统说明书的地方。

   系统测试过程分为计划与准备、执行、返工与回归测试 3 个阶段

   内容：系统测试一般要完成恢复测试、安全性测试、压力测试、性能测试、可靠性测试、可用性测试、可维护性测试和安装测试（注意：系统测试中没有路径测试）

6. 验收测试

   概念：在测试组的协调下，由用户代表执行。检验系统说明书的各项功能与性能是否实现和满足要求。验收测试完全采用黑盒测试技术，其主要任务是文档资料的审查验收、软件系统的功能测试、性能测试、强化测试、性能降级执行方式测试、检查系统的余量要求、安装测试以及用户操作测试。

7. 回归测试

   测试软件变更之后，变更部分的正确性对变更需求的符合性。

8. α与β测试

   Alpha 测试：是在开发环境下进行的测试，由用户/内部用户模拟实际操作环境下进行的受控测试。目的是评价软件产品的功能、可使用性、可靠性、性能和支持。尤其要注重产品的界面和特色。

   Beta 测试：是用户在实际使用环境下进行的测试。

9. 白盒测试

   概念：根据内部结构和逻辑来设计测试用例，对程序路径和过程进行测试。

   【方法】

   语句覆盖（SC）：设计足够的测试用例，使得使被测试程序中每条语句至少执行一次。

   判定覆盖（DC）:设计足够的测试用例，使得使程序中的每个判定至少都获得一次“真值”或“假值”。又称分支覆盖：使程序中的每一个取“真”分支和取“假”分支至少经历一次。

   条件覆盖（CC）：设计足够的测试用例，使得使得每一判定语句中每个逻辑条件的可能值至少满足一次。条件判定组合覆盖（CDC）：设计足够的测试用例，使得使得判定中每个条件的所有可能（真/假）至少出现一次，并且每个判定本身的结果（真/假）也至少出现一次。

   多条件覆盖（MCC）：设计足够的测试用例，使得使得每个判定中条件的各种可能组合都至少出现一次。修正判定条件覆盖（MCDC）：设计足够的测试用例，使得每一程序模块的入口和出口点都要考虑至少被调用一次，每个程序的判定到所有可能的结果值要至少转换一次；程序的判定被分解为通过逻辑操作符（and or）连接的 bool 条件，每个条件判定的结果值是独立的。

   路径覆盖：设计足够的测试用例，使得被测试程序中的所有可能路径至少被执行一次。

   组合覆盖：要求设计足够多的测试用例，使得每个判定中条件结果的所有可能组合至少出现一次。

10. 黑盒测试

    概念：黑盒测试基于产品功能规格说明书，从用户角度针对产品特定的功能和特性进行验证活动，确认每个功能是否得到完整实现，用户能否正常使用这些功能。

    黑盒测试在不知道系统或组件内部结构的情况下进行，不考虑内部逻辑结构，着眼于程序外部结构，在软件接口处进行测试。

    试图发现的错误：功能不正确或遗漏；界面错误；数据库访问错误；性能错误；初始化和终止错误等

    方法：

    等价类划分法；边界值分析法；因果图法；判定表驱动法；正交试验设计法；错误推测法 ；功能图法。

    等价类划分法

    原则：在输入条件规定了取值范围或值的个数的情况下，可以确定一个有效等价类和两个无效等价类:在输入条件规定了输入值得集合或者规定了“必须如何”的条件的情况下，可以确立一个有效等价类和一个无效等价类；在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类；在规定了输入数据的一组值（假定 n 个），并且程序要对每一个输入值分别处理的情况下，可确定 n 个有效等价类和一个无效等价类；在规定了输入数据必须遵守的规则的情况下，可确定一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）；在确知已划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为更小的等价类
    过程：根据软件的功能说明，对每一个输入条件确定若干个有效等价类和若干个无效等价类，并为每个有效等价类和无效等价类编号。设计一个测试用例，使其覆盖尽可能多的尚未被覆盖的有效等价类。重复这一步，直至所有的有效等价类均被覆盖。设计一个测试用例，使其覆盖一个尚未被覆盖的无效等价类。重复这一步，直至所有的无效等价类均被覆盖。

    应当特别注意，无效等价类是用来测试非正常的输入数据的，因此每个无效等价类都有可能查出软件中的错误，所以要为每个无效等价类设计一个测试用例。

    边界值分析

    经验表明，软件在处理边界情况时最容易出错。设计一些测试用例，使软件恰好运行在边界附近，暴露出

    软件错误的可能性会更大一些。通常，每一个等价类的边界，都应该着重测试，选取的测试数据应该恰好

    等于、稍小于或稍大于边界值。

11. 静态测试

    从测试的类型来看，可以分为动态测试和静态测试。所谓动态测试就是实际的将软件运行。而静态测试它就不运行软件测试的程序，而是采用人工检测、计算机分析辅助静态分析的手段来对程序进行检测。动态测试可以分为黑盒测试、白盒测试和灰盒测试。白盒测试也称为结构性测试，黑盒测试也称为功能性测试。灰盒测试是二者的结合。静态测试的方法主要有桌前检查、代码走查、代码审查。

    桌前检查：由程序员检查自己编写的程序。程序员在程序通过编译之后，进行单元测试设计之前，对源程序代码进行分析和检验，并补充相关的文档，目的是发现程序中的错误。检查项目包括检查变量的交叉引用表；检查标号的交叉引用表；检查子程序、宏、函数；等值性检查；常量检查；标准检查；风格检查；比较控制流；选择、激活路径；对照程序的规格说明，详细阅读源代码；补充文档。

    代码审查：代码审查是由若干程序员和测试人员组成一个会审小组，通过阅读、讨论和争议，对程序进行静态分析的过程。代码审查的过程可以分为两个步骤：第一步，小组负责人提前把设计规格说明书、控制流程图、程序文本及有关要求、规范等分发给小组成员，作为评审的依据。小组成员在充分阅读这些材料之后，进入审查的第二步。第二步，召开程序审查会。在会上，首先由程序员逐句讲解程序的逻辑。在此过程中，程序员或其他小组成员可以提出问题，展开讨论，审查是否存在错误。实践表明，程序员在讲解过程中能发现许多原来自己没有发现的错误，而讨论和争议则促进了问题的暴露。

    在会前，应当给会审小组每个成员准备一份常见错误的清单（通常称为检查单或检查表），把以往所有可能发生的常见错误罗列出来，供与会者对照检查，以提高会审的效率。检查单把程序中可能发生的各种错误进行分类，对每一类列举出尽可能多的典型错误，然后把它们制成表格，供在会审时使用。

    代码走查：代码走查与代码审查基本相同，其过程也分为两个步骤： 第一步，把材料先发给走查小组每个成员，让他们认真研究程序，然后再开会。第二步，开会的程序与代码会审不同，不是简单地读程序和对照错误检查单进行检查，而是让与会者“充当”计算机。即首先由测试组成员为被测程序准备一批有代表性的测试用例，提交给走查小组。走查小组开会，集体扮演计算机角色，让测试用例沿程序的逻辑运行一遍，随时记录程序的踪迹，供分析和讨论使用。

    静态分析：静态分析通过解析程序文本从而识别出程序语句的各个部分，审查可能的缺陷和异常之处，静态分析包括五个阶段：
    （1）控制流分析阶段 ：找出并突出显示那些带有多重出口或入口的循环以及不可达到的代码段；
    （2）数据使用分析阶段突出程序中变量的使用情况；
    （3）接口分析阶段检查子程序和过程说明及它们使用的一致性；
    （4）信息流分析阶段找出输入变量和输出变量之间的依赖关系；
    （5）路径分析阶段找出程序中所有可能的路径并画在此路径中执行的语句。

12. 狭义性能测试分类

    负载测试：确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。

    压力测试：通过确定一个系统的瓶颈或不能接受的性能点，来获得系统能提供的最大服务级别的测试。

    强度测试：在系统资源特别低的情况下考查软件系统运行情况。

    并发测试：并发测试也称为容量测试，主要用来确定系统可处理的同时在线的最大用户数。

五、面向对象的测试

算法层（单元测试）：包括等价类划分测试、组合功能测试（基于判定表的测试）、递归函数测试和多态消息测试。（方法层次）

类层（模块测试）：包括不变式边界测试、模态类测试和非模态类测试模板层/类树层（集成测试）：包括多态服务测试和展平测试

系统层（系统测试）

六、软件调试 ⭐

1. 软件调试方法

   蛮力法：主要思想是“通过计算机找错”，低效，耗时

   回溯法：从出错处人工沿控制流程往回追踪，直至发现出错的根源。复杂程序由于回溯路径多，难以实施（适合于小型程序）

   原因排除法：主要思想是演绎和归纳，用二分法实现

   试探法：调试人员分析错误的症状，猜测问题的位置所在，利用在程序中设置输出语句，分析寄存器、存储器的内容等手段来获得错误的线索，通过一步步的试探和分析来找到错误所在。效率低、适合于结构较简单的程序

   归纳法：是从测试所暴露的错误出发，收集所有正确或不正确的数据，分析它们之间的关系，提出假想的错误原因，用这些数据来证明或反驳，从而查出错误所在。

   演绎法：根据测试结果，列出所有可能的错误原因。分析已有的数据，排除不可能和彼此矛盾的原因，对余下的原因选择可能性最大的，利用已有的数据完善该假设，使假设更具体。

   对分查找法：这种方法主要用来缩小错误的范围。如果已经知道了程序中的变量在若干位置的预期正确取值，可以在这些位置上用赋值语句或输入语句，给这些变量以正确值，运行程序观察输出结果。如果没有发现问题，则说明从给变量的正确值开始到输出结果之间的程序没有出错。然后对剩下部分的程序再依次进行直到把故障范围缩小到比较容易诊断为止。

2. 软件调试与测试的区别

   测试的目的是找出存在的错误，而调试的目的是定位错误并修改程序以修正错误调试是测试之后的活动，测试和调试在目标、方法和思路上都有所不同

   测试从一个已知的条件开始，使用预先定义的过程，有预知的结果；调试从一个未知的条件开始，结束的过程不可预计

   测试过程可以事先设计，进度可以事先确定；调试不能描述过程或持续时间。

七、系统运行 ⭐⭐⭐

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

淘汰策略：遗留系统的技术含量较低，且具有较低的业务价值。对遗留系统的完全淘汰是企业资源的根本浪费，系统分析师应该善于“变废为宝”，通过对遗留系统功能的理解和借鉴，可以帮助新系统的设计，降低新系统开发的风险。

继承策略：遗留系统的技术含量较低，已经满足企业运作的功能或性能要求，但具有较高的商业价值，目前企业的业务尚紧密依赖该系统。对这种遗留系统的演化策略为继承。在开发新系统时，需要完全兼容遗留系统的功能模型和数据模型。为了保证业务的连续性，新老系统必须并行运行一段时间，再逐渐切换到新系统上运行。

改造策略：遗留系统具有较高的业务价值，基本上能够满足企业业务运作和决策支持的需要。这种系统可能建成的时间还很短，对这种遗留系统的演化策略为改造。改造包括系统功能的增强和数据模型的改造两个方面。系统功能的增强是指在原有系统的基础上增加新的应用要求，对遗留系统本身不做改变；数据模型的改造是指将遗留系统的旧的数据模型向新的数据模型的转化。

集成策略：遗留系统的技术含量较高，但其业务价值较低，可能只完成某个部门（或子公司）的业务管理。这种系统在各自的局部领域里工作良好，但对于整个企业来说，存在多个这样的系统，不同的系统基于不同的平台、不同的数据模型，形成了一个个信息孤岛，对这种遗留系统的演化策略为集成。

2. 系统转换计划-新旧系统转换策略
   

直接转换：接转换是在原有系统停止运行的某一时刻，新系统立即投入运行，中间没有过度阶段。采用这种方式时，人力和费用最省，适用于系统不太复杂或现有系统完全不能使用的场合。但是这种方式风险高。

并行转换：并行转换就是新系统和旧系统并行工作一段时间，经过这段时间的试运行后，再用新系统正式替换下现有系统。那么这种方式，它的好处就是风险很小。在转换期间还可以同时比较新旧两套系统的性能，而且能够让操作人员得到全面的培训，所以对于一些比较大的信息系统，或者处理过程比较复杂，数据比较重要的系统。并行转换是一种最常用的转换方式。那么这种转换方式也有缺点，缺点就在于两套系统并行期间。要有两套人马，或者两套处理方式同时并存，在人力和费用消耗比较大，转换的周期比较长，而且难以控制新旧系统当中数据的变化。所以这就要求要做好转换计划，并且要加强管理。

分段转换：这是直接转换和并行转换的接合，也就是分期分批、逐步转换。一般比较大的系统可以采用这种方式比较合适，他能够保证软件平稳运行，费用也不太高，就是将大的系统分成多个子系统，每成熟一个子系统就切换一个子系统，主要是分期分批。这种分段转换的策略，它的优点就是成熟一个子系统就转换一个子系统。这种新旧转换，震动比较小，用户比较容易接受。但是由于采取的是渐进的方式，会导致新旧系统的转换周期比较长。

3. 系统转换计划-数据转换与迁移 ⭐

移植工作大体上分为计划阶段、准备阶段、转换阶段、测试阶段、验证阶段。
1、计划阶段，在计划阶段，要进行现有系统的调查整理，从移植技术、系统内容（是否进行系统提炼等）、系统运行三个方面，探讨如何转换成新系统，决定移植方法，确立移植工作体制及移植日程。
2、准备阶段，在准备阶段要进行移植方面的研究，准备转换所需的资料。该阶段的作业质量将对以后的生产效率产生很大的影响。
3、转换阶段，这一阶段是将程序设计和数据转换成新机器能根据需要工作的阶段。提高转换工作的精度，减轻下一阶段的测试负担是提高移植工作效率的基本内容。
4、测试阶段，这一阶段是进行程序单元、工作单元测试的阶段。在本阶段要核实程序能否在新系统中准确地工作。所以，当有不能准确工作的程序时，就要回到转换阶段重新工作。
5、验证阶段，这是测试完的程序使新系统工作，最后核实系统，准备正式运行的阶段。

八、系统维护 ⭐

1. 概念

   软件维护是生命周期的一个完整部分。可以将软件维护定义为需要提供软件支持的全部活动，这些活动包括在交付前完成的活动，以及交付后完成的活动。交付前完成的活动包括交付后运行的计划和维护计划等；交付后的活动包括软件修改、培训、帮助资料等。

2. 分类

   正确性维护：指改正在系统开发阶段已发生而系统测试阶段尚未发现的错误。

   适应性维护：指使应用软件适应信息技术变化和管理需求变化而进行的修改。企业的外部市场环境和管理需求的不断变化也使得各级管理人员不断提出新的信息需求。

   完善性维护：扩充功能和改善性能而进行的修改。对已有的软件系统增加一些在系统分析和设计阶段中没有规定的功能与性能特征。

   预防性维护：为了改进应用软件的可靠性和可维护性，为了适应未来的软硬件环境的变化，应主动增加预防性的新的功能，以使用系统适应各类变化而不被淘汰。如将专用报表功能改成通用报表生成功能，以适应将来报表格式的变化。

九、软件开发环境与工具 ⭐

软件开发环境（Software Development Environment，SDE）是指支持软件的工程化开发和维护而使用的一组软件，由软件工具集和环境集成机制构成。
软件开发环境应支持多种集成机制，根据功能的不同，集成机制可以划分为环境信息库、过程控制与消息服务器、环境用户界面三个部分。

1. 环境机制

   环境信息库。环境信息库是软件开发环境的核心，用以存储与系统开发有关的信息，并支持信息的交流与共享。环境信息库中主要存储两类信息，一类是开发过程中产生的有关被开发系统的信息，例如，分析文档、设计文档和测试报告等；另一类是环境提供的支持信息，例如，文档模板、系统配置、过程模型和可复用构件等。

   过程控制与消息服务器。过程控制与消息服务器是实现过程集成和控制集成的基础。过程集成是按照具体软件开发过程的要求进行工具的选择与组合，控制集成使各工具之间进行并行通信和协同工作。

   环境用户界面。环境用户界面包括环境总界面和由它实行统一控制的各环境部件及工具的界面。统一的、具有一致性的用户界面是软件开发环境的重要特征，是充分发挥环境的优越性、高效地使用工具并减轻用户的学习负担的保证。

2. 工具

   在软件生命周期中，要使用很多软件工具，从其功能上进行划分，可以分为软件开发工具、软件维护工具、软件管理和支持工具三类。

   软件开发工具。软件开发工具用来辅助开发人员进行软件开发活动，包括需求分析工具、设计工具、编码与排错工具等。

   软件维护工具。软件维护工具用来辅助维护人员对软件代码及其文档进行各种维护活动，包括版本管理工具、文档分析工具、开发信息库工具、逆向工程工具和再工程工具等。

   软件管理和支持工具。软件管理和支持工具用来辅助管理人员和软件支持人员的管理活动和支持活动，以确保软件高质量的完成。包括项目管理工具、配置管理工具和软件评价工具等。

十、软件重用

软件重用是指在两次或多次不同的软件开发过程中重复使用相同或相似软件元素的过程。软件元素包括需求分析文档、设计过程、设计文档、程序代码、测试用例、领域知识等。对于新的软件开发项目而言，它们或者是构成整个目标软件系统的部件，或者在软件开发过程中发挥某种作用。通常将这些软件元素称为软部件。