01

什么是软件测试

1.1 测试的定义

“测试是一个证明错误不存在的过程”

“测试的目的是为了显示一个程序正确的实现了预期的功能”

“测试是建立对程序做了他应该做的事情的信心的过程”

“测试只能证明缺陷的存在，而不能证明测试的不存在”

IEEE定义的软件测试：“使用人工或自动的手段来运行或测定某个系统的过程，其目的在于它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。”

“Testing is the process of executing a program with the intent of finding errors.”--- Glen Myers 

1.2 软件测试的目的

验证软件的所有构件是否正确集成；验证所有需求是否已经正确实现；发现缺陷并确保在部署软件之前将缺陷解决。

1.3 软件测试的意义

测试在开发总成本中占30-50%；保证程序的正确性、完整性和一致性；显著降低完成和维护软件的开支；大大降低部署质量低劣的软件相关的责任或风险。

02

软件生命周期

常用的软件生命周期模型有：传统瀑布模型、瀑布V模型 、增量模型 、迭代模型。

图1 传统瀑布模型

图2 瀑布V模型

增量模型：需求基本明确，第一次需求分析包括所有需求，后续阶段提需求变更。

迭代模型：需求不明确，每阶段需求分析只包含这一阶段的需求。

03

轨交软件测试流程、策略

3.1 轨交软件测试的基本流程

测试计划→测试用例→准备数据→执行测试→输出、分析测试结果。

图3 轨交软件测试的基本流程

（紫色背景为执行的操作，蓝色背景为输出的文档或过程数据）

3.2 轨交软件测试的测试策略

需要根据不同的输入，在不同的测试阶段中，采用相适应的测试策略。如，软件模块设计需要在单元测试阶段进行测试。软件结构设计需要集成测试进行测试，并对该阶段的文档进行验证。对于软件的需求，需要软件确认测试活动进行确认测试。系统结构设计，以及多个子系统集成，在系统集成阶段集成验证。系统需求需要进行系统级的确认测试，对其验证和确认。

图4 轨交软件各测试阶段的测试策略

3.3 各测试阶段输出的测试文件

图5 各测试阶段输出的测试文件

3.4 测试缺陷管理与跟踪

测试中发现的缺陷可能是代码缺陷，也可能是文档缺陷。对于文档缺陷，测试人员仍按照与预期的差异提交CR，由分析人员进行分析，明确修改文档。如果是代码缺陷，需要按照流程，修改代码，重新发布代码。对于回归测试，如果有影响分析报告，本次回归的用例范围应不少于影响分析所要求的范围。

测试过程中，应严格按照用例的预期结果判断用例是否通过。如果执行测试中发现用例有误或步骤需要细化或需要增加步骤，可以对用例修改，但在测试报告中，测试用例的版本为新版本，确保测试执行与实际用例版本一致。

3.5 白盒测试和黑盒测试的区别

白盒测试又叫逻辑驱动测试，具备以下特点：已知程序的内部工作逻辑；基于程序逻辑结构设计和构造测试用例和测试数据；测试程序内部的变量状态、逻辑结构、运行路径等；检验每条路径是否按预定要求正确工作；检查程序内部动作或运行是否符合设计规格要求。

黑盒测试的特点：不考虑程序的内部工作逻辑；从用户角度出发；基于程序应实现的功能和定义好的需求规格设计测试用例和测试数据；验证功能是否实现且与需求一致。

黑盒测试设计方法：等价类划分（EP）、边界值分析（BVA）、错误猜测（EG）、因果图等。

04

软件测试常用的几个阶段

4.1 单元测试

单元测试包括动态测试、代码审核和代码走读。

动态测试是通过插桩和驱动，动态运行程序的最小组成单位（一般是函数），验证函数是否与模块设计文档定义的功能一致。动态测试依据软件详细设计规格书进行。

代码审核是利用工具或人工，检查代码是否满足定义的编码规则。

代码走读是通过人工阅读代码，检查代码中的逻辑错误或对结构优化提出改进。代码走读的形式可以是小组评审或纯粹个人读代码。

图6 单元测试动态测试

模块接口：验证数据能否正确的输入、输出；

边界条件：边界上出现的错误是很常见的；

覆盖条件：或称路径分析，即对执行的基本路径和循环进行测试；

出错处理：良好的设计应该估计到投入使用后可能发生的错误，并给出相应的处理措施，保证逻辑上的正确性。

测试用例设计遵循：基于结构化测试（白盒）原则设计足够的测试，达到要求的覆盖率（语句覆盖；判定覆盖；条件覆盖；判定/条件覆盖；条件组合覆盖；路径覆盖）

推荐：首先设计黑盒测试用例，然后分析代码，从白盒角度分析，根据覆盖率要求增减测试用例。

注意：在实践中存在不好的倾向，单元测试人员纯粹为了完成覆盖率目标，不去理解被测模块实现的功能，仅从白盒角度建立测试用例，往往不能发现模块功能性的错误。

4.2 软件集成测试

在单元测试的基础上，根据选择的集成方式，将模块或任务或线程组装，验证被集成对象之间消息传递是否正确（必要时需要通过插桩来验证）。

本测试依据软件结构设计规格书进行。测试的对象是模块间的接口、函数调用接口、消息接口、共享队列、文件等。集成的对象可以根据实际情况分析后确定，可以是函数之间集成，也可以是任务或线程之间集成。

软件集成测试的方式：大爆炸集成 (Big-bang integration)；自顶向下集成 (Top-down integration)；自底向上集成 (Bottom-up integration)。

图7 大爆炸集成

大爆炸集成 (Big-bang integration)：也叫非增量式集成。其优点：不需要插桩与驱动；缺点：不容易定位问题。

图8 自顶向下集成

深度优先：M1-M2-M5-M8；M1-M2-M5-M8-M6；M1-M2-M5-M8-M6 -M3-S7；M1-M2-M5-M8-M6-M3-S7-S4。

宽度优先：M1-M2-M3-S4；M1-M2-M3-S4-M5-M6-S7；M1-M2-M3-S4-M5-M6-S7-M8。

优点：一开始就能看到系统的框架；

缺点：需要插桩，桩不能反映真实情况，所以测试可能不充分，且在桩中查看输出不方便。

图9 自底向上集成

自底向上集成 (Bottom-up integration)：属于增量式集成。其优点：方便查看输出。关键模块在底部时，这种方式更有优越性。缺点：要在最后才能看到系统的框架。

执行集成测试的建议：核心任务应执行模块级别的集成；非核心任务可只执行任务之间或进程之间的集成；集成测试以接口测试为主，功能测试为辅；集成策略采用大爆炸方式还是增量式集成方式视情况而定；集成测试集成的模块可以是以线程为单位，或者以功能模块为单位，或者以接口为单位或者以函数为单位。

需要工具支持：模块集成可使用相应的白盒测试工具；任务/进程集成应使用协议分析软件或逻辑分析仪、示波器等硬件测试分析设备。

4.3 软件确认测试

将已经集成好的软件，作为整个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他软件元素结合在一起，在实际运行环境下，对软件进行一系列的组装和确认测试。

本测试依据软件需求规格书进行。

图10 软件确认测试

安全测试（Safety Test）：验证软件是否会产生危险输出，比如联锁软件中如果板卡位置放置错误，软件应宕机。

恢复性测试（Recovery Test）：人为使软件出错，检查软件是否能自动恢复，及自动恢复时初始化、参数等是否正确。

备份测试（Backup Test）：验证软件能够自动进行数据备份。

GUI测试：界面显示，是否友好

健壮性测试（Robust Test），也叫容错性测试。忽略故障，继续运行。比如，联锁备机故障不影响软件输出；联锁主机故障时，备机升级为主机，整个软件仍能正确输出。

安装测试（Installation Test）：验证是否能够根据安装说明书完成安装，安装过程中是否有合理的提示信息，是否对安装环境有限制。验证是否可以卸载。

4.4 系统集成测试

验证各子系统的独立功能及其接口、数据传输的正确性，满足整个系统设计所规定的特性。该测试依据系统结构设计进行。

图 11 系统集成测试

4.5 系统确认测试

功能测试 （Functional Test）：验证功能实现是否符合软件需求。

性能测试（Performance Test）：特定负荷下，CPU，网络，内存，系统反应时间，指令执行时间等。

压力测试（Stress Test）：也叫强度测试。资源超负荷（比如用户），验证系统能承受的最大压力、找到系统在哪里失效及如何失效。

容量测试（Volume Test）：超额的数据容量 ，验证系统的最大容量，一般和数据库有关。

安全性测试（Security Test）：防范非法侵入。

安全测试（Safety Test）：验证系统是否会产生危险输出，比如联锁系统中如果板卡位置放置错误，系统应宕机。

恢复性测试（Recovery Test）：人为使软件出错，检查系统是否能自动恢复，及自动恢复时初始化、系统参数等是否正确。

备份测试（Backup Test）：验证系统能够自动进行数据备份。

GUI测试：界面显示，是否友好。

健壮性测试（Robust Test），也叫容错性测试。忽略故障，继续运行。比如，联锁系统备机故障不影响系统输出；联锁主机故障时，备机升级为主机，整个系统仍能正确输出。

4.6 验收测试

最后正式将被测系统放到实际运行环境运行之前，完全真实的环境和操作过程，不使用任何模拟设备或模拟程序 。本测试在现场进行。

05

总 结

轨交软件系统大多采用瀑布V模型的生命周期模型，因涉及到需求分析、概要设计、详细设计等，所以会有单元测试、集成测试、软件系统测试对应各个阶段的输入进行验证或确认测试。

各个阶段的测试关注点不同，需要进行各种测试方法的适应性改变，如，EG的方法，在程序中植入错误，验证既有测试用例是否能发现也可以验证用例是否充分。测试用例中必须包含期望输出，程序员应避免测试自己编写的代码、程序开发组织应避免测试自己编写的代码，彻底检查每一个测试的结果，应为非法的、非预期的条件以及正常的、预期的条件设计测试用例，检查程序是否执行了指定的行为只是测试的一部分，还应检查程序是否执行了未指定的行为，这些是在设计用例、执行测试过程中的注意点，分别从独立性、充分性等方面考虑。

参考文献：

[1] 软件测试的基本概念和方法

https://wenku.so.com/d/fd880b6a210bf899575fa128313b820b.

[2] 浅析软件测试技术在C程序开发中的应用 https://wenku.so.com/d/f78781bb1f8160cbc1cc8cd26c361db4.

[3] 系统测试类型 

https://blog.csdn.net/weixin_44819949/article/details/125059604.