适应IRISIRIS体系产品研发的系统测试过程研究

李启翮 董欢欢（北京全路通信信号研究设计院有限公司，北京 100073)

李启翮,男,博士毕业于清华大学,高级工程师,测试试验中心质量安全总监。主要研究方向包括铁道信号、图像处理与计算机视觉，曾参与武广高铁CTCS-3攻关组RBC组工作、国家科技支撑计划课题无线闭塞中心的关键技术及装备、铁道部京沪RBC关键技术深化研究等项目。

1 概述

IRIS是国际铁路行业标准（International Railw ay Industry Standard）的缩写，这是一套建立在ISO9001标准基础上，由欧洲铁路行业协会针对铁路行业的特殊要求制定的一套质量管理体系标准。随着我国高铁事业的发展，为了更好地提高产品和服务质量、参与国内国际竞争，北京全路通信信号研究设计院有限公司于2011年实施了IRIS体系导入工作，并于2012年进行了修订。

在新版IRIS体系中，为了进一步加强对产品研发流程的控制以提高产品质量，对《应用科研控制程序》做了较大修订。

1）将产品研发的质量过程与原安全保障体系对安全产品的研发要求彻底融为一体，不再区分安全与非安全产品，统一按照相同的过程实施，统一使用原来只在安全产品研发中采用的“验证”和“确认”概念；

2）将整个产品研发流程分为“项目立项”、“系统定义与项目计划”、“风险分析”、“需求规范”、“设计与实现”、“系统测试”、“检验测试”、“试验应用”、“系统确认”、“验收结题”共10个阶段（其中“风险分析”在各个阶段都需持续进行），划分更加合理，并且将项目组、技术管理、质量保证、安全确认的工作分别描述，使得整个过程更加清晰；

3）以新产品研发流程为完整过程，通过阶段裁减得到既有产品修改、先期技术研究和软课题3个副过程；

4）引入“质量门”的概念。若前后两个阶段间设置了质量门，则需要由质量保证工程师确认达到了开门条件。否则，禁止进入下一个阶段的工作。

此外，由于进一步注意到测试工作在保障产品的质量方面的重要作用，新版程序文件加强了对产品测试的要求：

1）明确了测试工作从计划阶段就必须介入，与早期那种在开发完成之后才开始测试的过程（如瀑布式开发模型）相比，更加有利于节省时间并提高测试质量；

2）要求测试人员全部与开发设计人员独立（EN 50128:2001允许在安全完善度为SIL0级的产品研发中，开发者与测试者不独立，但EN 50128:2011提高了独立性的要求，不再允许开发者与测试者相互兼任）；

3）整个研发流程中一共设置了4个质量门，第一个质量门就设置在设计与实现与系统测试之间，并明确了系统测试作为确认测试的地位。

为更好地指导测试人员的工作，有必要对流程中的测试工作过程进行研究，使之与产品研发的主流程能够紧密结合，进一步确保所交付的产品质量。本文针对“系统测试过程”从人员角色、子过程的划分、工作任务等方面进行探讨，提出一个适应IRIS体系产品研发流程的系统测试过程。

2 系统测试定义

2.1 测试层级划分

在《应用科研控制程序》中，除用户验收测试外，测试活动被分为3类（不包括试验类活动）：模块测试、集成测试、系统测试。

模块测试是针对硬件或软件的最小功能模块进行的测试，用以验证该模块的功能、接口的正确性。

集成测试包括软件集成测试、硬件集成测试以及软硬件集成测试等多个级别，其方法均是将各个模块集成在一起，对模块之间的接口、交互功能进行测试，以确保能向系统测试阶段提交一个可运行的被测系统。

系统测试是针对系统需求的测试，目的是确认系统是否满足规定的所有需求，是系统确认的重要手段之一。

2.2 系统测试与验证测试

所谓验证，指通过检查和提供客观依据，证实规定的需求已经得到满足（即是否正确的构造了产品）。在质量过程中，要求在每个阶段均实施验证活动。验证分为动态验证和静态验证两类方法，后者指评审、分析及文档检查的方法，前者采用测试与演示的方法。因此，系统测试本身也是系统测试阶段的验证测试。

2.3 系统测试与确认测试

所谓确认，指通过检查和提供客观依据，证实特定预期用途的需求是否得到满足（即是否构造了正确的产品）。根据IR IS的要求，产品研发后必须对整个系统进行确认。确认过程中需要进行相应的测试作为确认的输入，以帮助确认系统满足需求，这类测试称为系统确认测试，在安全产品研发流程中，若系统测试经过了确认工程师的见证和确认，即可作为系统确认测试，对于非安全产品的研发，通常默认以系统测试作为系统确认测试。

3 系统测试过程

由于系统测试在系统验证和确认中都承担着重要的作用，因此必须制定规范化的测试过程，以确保测试质量。

本节通过研究整个系统测试过程所需要做的工作，辨识其与设计开发过程之间的关系，并考虑所必须的输出，首先对测试任务组内人员的角色进行识别，然后将整个系统测试过程划分为数个子过程分别描述。

3.1 测试人员角色

在整个项目组中，设置一个与开发组独立的测试组，组内人员可以划分为3类。

3.1.1 测试负责人

对整个测试工作负责，包括测试的计划、过程以及最后的报告，还负责与项目负责人、开发者、确认者等项目组内其他角色的沟通协调。

3.1.2 测试工程师

在测试负责人的领导下负责实际的测试工作的执行，包括测试设计、测试执行等工作。

3.1.3 测试环境工程师

负责构建、配置特定的测试平台、工具、设备等测试环境。

3.2 测试过程

在实际实施中，阶段与流程并非是同一概念，尽管系统测试是在设计与实现之后才开始，但系统测试过程必须从系统定义与计划就介入项目工作，以确保测试人员更好的理解系统及其需求，提高测试质量。

根据系统测试全过程在产品研发流程不同阶段所执行的工作性质，将整个测试过程划分为“测试计划”、“测试规范”、“测试执行”和“测试报告”4个子过程。

由图1可以看出，系统测试过程开始于系统定义与项目计划，结束于系统测试（由于风险分析实际上贯穿于整个产品研发流程中，因此未单独体现），除测试规范子过程中的测试环境规范部分跨越两个阶段外，其余子过程都在一个阶段内结束。测试执行子过程由于测试结果会导致产品的修改，因此可能会执行多次，还会导致《测试计划》及《测试规范》等文档的更新。模块测试和集成测试都在设计与实现阶段进行，由于不属于系统测试层级，此处采用了不同的颜色显示。下面将分别对4个子过程进行描述。

3.2.1 测试计划子过程

《测试计划》是在项目计划阶段所需制定的众多计划之一，其目的如下。

1）规划测试过程中的所有行动及明确测试的范围；

2）指导测试如何开展，规定要使用的测试策略、过程、方法、工具与模板；

本子过程又可分为两个阶段：总体测试计划和每个测试层级的测试计划。

《总体测试计划》涵盖项目中所有层级的测试，并对这些测试进行协调，以优化测试过程。

各个层级的《测试计划》则根据该层级具体的测试要求撰写，若包含的测试层级较少或测试较简单，也可仅编制一个测试计划包含多个测试层级，例如，当仅关注系统测试层级时，只需编写涉及系统测试的《测试计划》即可。本子过程所包含的主要活动阶段如图2所示。

本子过程的输入包括：项目计划、安全计划、质量计划、系统定义等。通常，测试计划应包含如下内容。

1）对被测对象的描述，所用的测试度量；

2）测试活动的进入/退出准则、挂起/恢复准则；

3）所包含的测试层级，该层级所涉及的测试范围、目标、测试方案、测试环境、工具、配置、地点等；

4）测试人员组织结构、测试活动的时间表；5）整个测试过程所需提交的文档。

3.2.2 测试规范子过程

此子过程包含两个部分的内容：测试规范与测试环境规范，其输入包括所有需求、计划文档以及相应标准、规范。

测试规范部分需进行如下活动。

1）对作为测试基础的需求规范和其他规范进行可测性检查；

2）编写测试案例（Test Cases）；

3）建立系统需求与测试案例的追溯矩阵，并确保达到所需的测试覆盖率；

4）确定测试数据；

5）开发测试脚本；

正因为要对需求规范进行可测性检查，所以测试规范活动必须在“需求规范阶段”完成，该活动可能导致需求规范的更新。而测试环境规范活动则可以持续到测试执行活动开始之前，在测试执行开始之后还需要对所搭建的测试环境进行支持与维护。该部分所必须进行活动包括内容如下。

1）设计测试环境构建方案；

2）完成测试环境的构建与验证确认，并进行支持与维护；

3）描述测试环境的使用方法。

图3提供了对本子过程的简要示意。

3.2.3 测试执行子过程

当被测对象完成集成测试，通过第一个质量门后，即可进入“系统测试阶段”，根据《测试规范》和《测试环境规范》执行测试。测试执行通常并非一次性过程，往往由多个轮次组成，其中每个轮次所完成的活动基本一致。之所以需要多个轮次，原因主要分为两类。

1）根据开发计划，产品的功能采用迭代开发方式，分段实现，测试也相应的需要分轮次完成；

2）测试执行过程中发现了被测对象的缺陷（NCR），导致了代码实现、设计、甚至是需求的修改变更，当修改完成后需要再次提交测试。

由于测试执行的这个特点，本子过程可能导致一系列文档的更新，包括以下内容。

1）轮次增加导致测试计划的变更；

2）测试结果导致的设计甚至需求文档的变更；

3）案例执行过程中发现案例的错误导致的测试规范的变更；

4）测试执行中发现测试环境存在的问题导致的测试环境规范的变更。

图4是单轮测试执行子过程的简要描述。执行测试之前应当先对被测对象相关资料进行检查，包括案例、脚本、数据、环境、文档的准备情况、所交付过来的被测对象、上一轮测试的遗留项等，并对本轮测试的范围、时间等进行计划，然后开始正式执行测试。测试结果，报告当前的状态，例如一轮测试后的该轮测试报告；

2）测试迭代报告：当项目采用迭代开发时，每次迭代都需要一个测试报告，测试报告更新的次数应与迭代次数相同，每次更新都加入新一次迭代的结果，最后一次迭代的测试报告，就是最终的测试报告；

3）最终测试报告：测试的最后阶段完成的报告，包括对所有执行的测试的结果及其统计分析，对产品质量的评价以及对测试过程的评估等。

每个测试案例的结果应真实记录，如发现缺陷则须提交缺陷报告（NCR）。当本轮测试完成之后，应对测试结果进行评估，分析系统剩余的风险，以确定测试是否达到了预期目标从而可以终止，提交本轮测试报告（若测试目标已经达到，则提交最终测试报告，见3.2.4）。

3.2.4 测试报告子过程

《测试报告》的主要用途是提供项目测试的结果，通常分为3种。

1）阶段测试报告：根据测试计划、系统风险和

如图5所示，欲编写《测试报告》，首先应收集所有的测试记录、各轮测试报告、NCR、测试所用的时间、人力、物力、执行的案例数量等数据；然后分析测试过程中发现的全部NCR、系统剩余风险，以确定是否达到了测试的目标、可以终止测试；在此基础上，撰写《测试报告》。完整的报告应包括如下方面。

1）测试的目的、范围；

2）用到的测试环境、工具；

3 用到的方法、技术，及执行中所遇到的任何问题；

4）结果的记录，包括测试案例执行结果的真实记录以及执行的案例数、剩余的案例数、发现的NCR数、测试环境的问题数等；

5）结果分析，包括对案例的统计及对需求的覆盖分析、NCR的统计分析、遗留项分析以及对不可测需求的说明等；

6）测试结论，包括测试是否按计划、规范完成，执行是否充分，测试目标是否完成等信息。

在测试结束后，宜对整个测试过程进行评估和总结，为后续项目积累经验。

4 总结

随着产品功能的日益复杂，如何保证所研发的产品质量成为一个严峻课题，系统测试作为确保所交付产品质量的重要手段之一，其理论、技术、方法、流程等各方面的研究都受到日益显著的重视。本文提出了一个适应于IR IS要求的系统测试过程，并进行了详细描述，为测试工程师的工作提供参考。

需要指出的是，系统测试过程是整个产品研发流程中的一个子流程，需要与开发、验证、确认等其他子流程相互协调，不能孤立的分隔开来。

此外，本文提出的测试过程也并非只能用于产品研发的系统测试层级，其4个子过程的划分方式对于其他层级的测试也同样适用，测试计划子过程中的总体测试计划的存在也证明了这一点，实际操作中只需根据具体的测试层级进行适当的裁减或修正即可。