软件系统测试中的场景建模技术应用

封亮　吴振宇

软件系统测试是保障软件质量、降低维护成本、改善研发过程的重要工作环节。然而面对结构体系庞大、逻辑功能繁复的应用软件系统，其输入空间、执行顺序、运行依赖因素间的逻辑组合几乎趋于无限，工程技术人员如何保证测试工作的充分性与有效性？国家工程软件产品质量监督检验中心通过总结大型任务电子系统软件测试实施经验，提出了“利用UML顺序图构建业务流程运行场景及基于场景建模进行软件系统测试”，其实现途径或将为广大工程技术人员所借鉴。

软件系统测试现状

作为现代信息系统的核心，软件的作用日益突出。为了令软件产品功能更完善、架构更健壮、性能更可靠，系统测试工作贯穿于软件生命周期的每个阶段。软件研发过程中，工程人员需要开展各种不同类型的测试，包括单元测试、部件测试、配置项测试、系统联试和系统测试等。

系统联试是由软件研制单位组织的系统连通性验证试验，重点关注系统主要功能的正确性，而受软件研制人员自身思维定势所限，测试粒度、完备性都不够理想。

配置项测试是对组成系统的各个软件配置项进行测试，重点考查软件功能实现的正确性和完备性，能够较好地发现软件中存在的问题，但受制于配置项测试的环境因素，往往不能如实反应外部相关软件的实际影响，难以验证系统主要业务流程的正确性和协调性。

面对上述问题，进行软件系统测试就显得尤为重要。系统测试是软件测试工作的重要环节，目的是在实装环境（包含真实的人、机、数据环境）或接近实装的环境中，考查系统各业务流程执行的正确性和协调性，从而验证系统软件是否达到研制总要求，以及系统和子系统段设计文档中所列出的全部功能和指标需求。

目前，复杂任务电子信息系统多为庞大的系统工程，硬件结构繁复，软件架构庞大，且由众多不同领域的企业协同开发……这为系统的软件测试工作带来了诸多困难：多单位协同开发，测评环境往往分布于多地，且侧重点不同；系统规模庞大，系统内外部接口复杂，测试人员需要理解整个被测系统，作为测试依据的被测系统设计/输入类文档的质量及详细程度影响着整个系统测试质量。面对上述情况，探寻有效的系统级测试实施策略与技术方法显得尤为重要。

软件系统测试技术研究

若干实践经验表明，有效的软件系统测试必须包括选取确定的测试范围、系统场景建模、测试内容策划等关键环节。

大型任务电子系统的内外部接口关系复杂，由不同专业的分系统构成，按照严格的科研管理流程，通常由研制企业内部进行软件单元/部件测试，配置项测试以及出厂（所）测试，由经国家授权的软件测评机构执行第三方配置型测试、分系统测试以及系统测试。其中分系统软件测试工作将重点关注构成分系统的软件配置项的功能、内外部接口、性能等要求的实现情况，并能给出分系统的测试结果。考虑到系统的规模、复杂度以及分系统测试工作的实际情况，在启动系统测试时，需对系统功能进行筛选，选取出需要进行系统级测试的系统功能。因此必须确立相应的筛选原则，以保证系统测试的有效性与逻辑覆盖的完备性，在工作中总结出以下原则：涉及分系统之间交互的功能点需被选取，而在分系统内部闭环的功能点不被选取；在测评环境满足的前提下，选取覆盖最大闭环路径长度的业务流程进行系统功能验证。

随着UML在软件开发过程中的广泛运用，基于UML 的测试技术逐渐受到人们的关注。UML顺序图是一种常用的UML动态建模模型，可以建模系统的使用逻辑（或称为应用场景），具有直观、半形式化等特点，包含丰富的、体现设计架构的系统信息。适用于描述对象之间的动态交互关系，显示一个协作涉及对象的消息传递关系，它着重体现对象间消息传递的时间顺序。

UML的顺序图有两个维度：纵向是时间线，定义对象在交互活动中的生命周期；横向是不同的对象。顺序图中用一个带有垂直虚线的矩形框表示对象，矩形框内标有类名、对象名或角色名。垂直虚线称为生命线，代表在对象之间的交互作用中该对象的生命周期。对象间的通信消息通过对象生命线之间的箭头表示，箭头上方标注消息名和一些控制信息。接收对象收到消息时被激活，在对象生命线上显示一个细长矩形框来表示，激活描述在一定时间段内对象执行操作的持续时间。

在场景建模阶段，通过分析系统研制总要求、系统/子系统段设计文档等测试依据类技术文档，以及与软件研发人员和系统使用人员进行交流沟通，获取被测任务电子系统的主要业务流程。根据提取的业务流程，利用UML顺序图进行场景建模，不仅能够清晰地展现系统业务流程中的动态交互关系，还有助于测试项的确定以及潜在业务流程的发掘。

根据系统典型应用场景对各系统的综合应用工作流程进行测试。各应用场景用例主要用来验证各分系统间的协调性和正确性。系统级应用场景是指至少涉及两个分系统之间的集成工作流程。任务电子系统测试时基于分系统间的交互关系进行系统应用场景分析，首先建立获取顶层的系统应用场景，再逐层细化分析出各分系统之间的集成工作流程，如任务执行场景等。

清晰完整、合理可行的测试项集合是测试项目顺利开展的必要条件，进行场景建模的目的正是为了提取系统测试的测试项。业务流程场景图的建立能够清晰地展示业务流程相关的测试项，方便了测试项的确定。

然而测试项的划定必须考虑测评环境的制约——环境因素可能会影响业务流程执行的畅通性，还必须对环境带来的差异进行有效地分析确认，使其能够充分支持业务流程的验证。

在确定测试范围的基础上，依托场景图和实际环境因素，给出测试项相关的测试类型并明确各种测试类型的测试方法、测试输入/输出数据以及测试通过判断准则等信息，从而完成在特定场景下对相应系统功能的测试内容策划，并填写相关信息。

测试项的建立过程中需要积极和软件研制人员与系统分析使用人员沟通交流，确保测试项内容的正确性、完整性。测试项的完整性体现了对顶层需求（包括隐含需求）覆盖的完整程度，同时能够反映测试的充分性。为了及时掌握测试项完整性情况，可建立需求追溯矩阵来反映当前测试项对顶层需求的覆盖情况。

软件系统测试用例开发设计辅助环境

根据UML顺序图应用场景建模执行软件系统测试，可以实现软件系统测试用例开发设计环境，其中内嵌了符合UML 2.0规范的建模组件，能够针对软件系统应用场景进行建模，然后基于模型，结合软件配置项测试、子系统测试阶段设计的测试用例，生成软件系统测试应用场景的测试用例集，满足软件系统、分系统、子系统的测试需求。

软件系统测试用例开发设计环境使用UML描述应用场景模型，并基于该场景模型生成对应的测试用例集合。系统测试人员可根据自动生成的测试用例集合进行修改或优化，得到最终测试用例集。

软件系统测试用例开发设计环境由场景顺序图建模、测试用例生成两个子系统，由图形用户界面、模型生成、模型解析、场景树生成、用例生成等模块共同组成。

进行系统测试场景模型建模时，使用符合UML 2.0规范的顺序图描述系统级的事件交互及事件的顺序，对系统的参与者（用户、子系统或配置项）、参与者之间传递的数据或调用命令等系统组成要素进行建模。在顺序图中，须测试的应用场景被定义为在相互交互过程中的各对象间传递的一个消息序列，每个消息序列代表一个可能的事件流，在一个顺序图中通过分支和循环结构可实现多个场景的定义。

对于每一个测试场景，建立各对象（用户输入、子系统或配置项）的测试用例，其输入和输出参数化，定义各对象测试用例的执行流程顺序；按照执行流程顺序，关联各测试用例的输入.输出参数；测试场景的测试用例实例化按照覆盖正常值和边界值的原则，对测试场景的测试用例进行实例化脚本生成。

基于UML2.0的被测系统应用场景建模主要基于顺序图完成给定的典型应用场景的建模，其建模过程可按照系统、子系统分层建立，建模后形成基于元数据交换格式XMI（XML Metadata Interchange Format）模型文件。

解析由XML表示的UML顺序图，提取相关信息建立场景测试树；对于要进行测试的具体场景，记录该场景的条件约束、各对象状态等模型中的语义信息。基于顺序图的用例生成技术使用这些信息生成测试用例所需数据，并与场景结合生成实际的测试用例，场景实例化主要基于XML解释程序解析由XMI表示的UML顺序图或状态图，主要对IF、While等进行处理，生成无分子转移的顺序流程，形成场景测试树，其叶节点可为子系统或配置项。

系统测试用例生成过程读入UML 2.0实例化场景模型文件解析后的信息、对于每一个被测应用系统测试场景，按照分层原则，完成测试用例的开发、设计，必要时，建立相应的测试控制脚本。包括输入和输出参数化，定义各配置项测试用例的执行流程顺序；按照执行流程顺序，关联各测试用例的输入输出参数；测试场景的测试用例实例化按照覆盖正常值和边界值的原则。

软件系统测试用例开发设计环境的运行过程分为“场景建模”与“测试用例生成与优化”两个主要阶段。

软件系统测试用例开发设计环境场景建模工具提供图形用户界面，包括符合UML2.0规范的建模界面和模型元素，对任务电子信息系统、分布式应用系统的典型应用场景进行UML顺序图建模，根据典型应用场景建模生成的顺序图保存为可解析的模型文件（XML格式）。

测试用例生成包含模型解析、场景树生成与用例生成三个主要过程。“模型解析”提取场景顺序图的模型文件，将其转换为XML格式的中间文件，获取该场景的参与者、消息及相关约束等信息；“场景树生成”，根据模型解析生成的XML文件生成测试场景树数据文件；“用例生成”根据生成的测试场景树文件生成测试用例集，并进行优化，最终产生该场景的最小测试用例集，以XML格式存储到本地文件系统。

算法实现的基本过程包括：查找顺序图中的基本流，基本流即无警戒条件的消息。将找出的基本流序号按次序放入容器m_BaseFlow中，另外对于那些有警戒条件的消息，根据他们的值，将这些消息分组，有相同警戒条件值的消息划分在同一组，有些警戒条件是由若干个其他警戒条件用连接符AND，OR和NOT组合而成，那么还要记录这些警戒条件是由哪些其他警戒条件共同组成。

找出顺序图中所有的场景结束点，将所有的结束点的序号按次序存放在m_EndPoint容器中，所谓顺序图的场景结束点就是被标注了<>的消息。

根据警戒条件进行排列组合运算，得到相应的场景序列。查找生成的场景序列中是否有多个结束点，如果有多个结束点，这个场景就不正确，将在场景容器m_SceneVec中删除。最后，去除重复的场景序列以及含有子场景的场景序列。

综上所述，针对复杂电子信息系统软件系统测试的实施过程，基于场景建模的系统测试技术方法给出了基本实现方法和软件实现实例，目前已在多个大型系统测试项目开展过程中运用，在保证系统测试完备性、提高工作效率方面，可以取得很好的效果。