生成测试用例的方法、装置和电子设备与流程

1.本技术涉及软件测试技术领域，尤其涉及一种生成测试用例的方法、装置和电子设备。


背景技术：

2.网络协议的安全设计与实现，不仅关系着人们的隐私和财产安全，更关系着国家的利益。网络协议漏洞已成为信息安全领域的一个研究热点。
3.申请人发现在工业控制(简称工控)安全控制领域，涉及对众多工业协议的控制与测试。工控协议的测试，需覆盖几十种协议，每种协议具有不同的特征，并且每次测试过程所关注的测试维度不确定。因此，在每次进行协议测试时，可能需要对各测试维度以及不同测试维度之间的互相影响做充分的测试，该过程需要耗费大量人力成本和时间成本来对每种协议逐次回归总结补充，以得到适用的测试用例。


技术实现要素：

4.为至少部分地解决相关技术中存在的问题，本技术提供一种生成测试用例的方法、装置和电子设备，能够有效提升获得测试用例的便捷度和测试用例覆盖率。
5.本技术的第一个方面提供了一种生成测试用例的方法，包括：确定与待检测协议对应的至少一个测试流程模型、测试数据模型和模型驱动文件；遍历经拼接的至少一个测试流程模型，得到至少一条测试路径，每条测试路径存在对应的测试操作序列；对于至少部分测试路径中的每一条，基于与该测试路径对应的测试操作序列和测试数据生成测试用例；其中，测试数据包括基于待检测协议、模型驱动文件从测试数据模型中确定的数据，测试数据作为测试操作序列中测试操作的测试参数值。
6.本技术的第二方面提供了一种生成测试用例的装置，包括：模型确定模块、模型遍历模块和测试用例生成模块。其中，模型确定模块用于确定与待检测协议对应的至少一个测试流程模型、测试数据模型和模型驱动文件；模型遍历模块用于遍历经拼接的至少一个测试流程模型，得到至少一条测试路径，每条测试路径存在对应的测试操作序列；测试用例生成模块用于对于至少部分测试路径中的每一条，基于与该测试路径对应的测试操作序列和测试数据生成测试用例；其中，测试数据包括基于待检测协议、模型驱动文件从测试数据模型中确定的数据，测试数据作为测试操作序列中测试操作的测试参数值。
7.本技术的第三方面提供了一种电子设备，包括：处理器；存储器，其上存储有可执行代码，当可执行代码被处理器执行时，使得处理器执行上述方法。
8.本技术的第四方面还提供了一种计算机可读存储介质，其上存储有可执行代码，当可执行代码被电子设备的处理器执行时，使处理器执行上述方法。
9.本技术的第五方面还提供了一种计算机程序产品，包括可执行代码，可执行代码被处理器执行时实现上述方法。
10.本技术提供的生成测试用例的方法、装置和电子设备，可以针对不同的测试场景
预先构建测试流程模型和测试数据模型等，这些测试流程模型和测试数据模型等可以是经过多次验证和能够复用的协议，在进行测试协议进行测试时，可以直接调用这些测试流程模型和测试数据模型等进行测试，比较全面地考虑了不同测试维度以及不同测试维度之间的互相影响，并且无需耗费大量人力成本和时间成本来，有效提升测试效果。
11.此外，在某些实施例中，测试数据可以是来自于工控协议的协议内容的字段，这样便于确定哪些边界条件可以需要进行测试，以提升测试过程对边界条件的覆盖度，并且可以应对测试流量数据不充足的测试场景。
12.此外，在某些实施例中，测试数据可以根据用户选取的目标测试参数对上述测试流程模型进行调整，仅对与目标测试参数相关的测试操作进行测试，有效减少了测试参数的冗余度，提升资源利用效率和提升测试效率。
13.此外，在某些实施例中，可以通过遍历的方式确定多条测试路径，确定至少部分测试路径的测试操作序列，提升了测试的灵活度，满足多种多样的用户测试需求。
14.应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本技术。
附图说明
15.通过结合附图对本技术示例性实施方式进行更详细地描述，本技术的以及其它目的、特征和优势将变得更加明显，其中，在本技术示例性实施方式中，相同的参考标号通常代表相同部件。
16.图1示意性示出了根据本技术实施例的可以应用生成测试用例的方法、装置和电子设备的一种示例性系统架构；
17.图2示意性示出了根据本技术实施例的一种生成测试用例的方法的流程图；
18.图3示意性示出了根据本技术实施例的工业控制网络常用协议的示意图；
19.图4示意性示出了根据本技术实施例的测试流程模型的结构示意图；
20.图5示意性示出了根据本技术实施例的检测协议的过程示意图；
21.图6示意性示出了根据本技术实施例的经拼接的测试流程模型的结构示意图；
22.图7示意性示出了根据本技术实施例的调整前的测试流程模型的结构示意图；
23.图8示意性示出了根据本技术实施例的调整后的测试流程模型的示意图；
24.图9示意性示出了根据本技术实施例的基于测试用例进行测试的方法的流程图；
25.图10示意性示出了根据本技术实施例的一种生成测试用例的装置的方框图；
26.图11示意性示出了根据本技术实施例的一种电子设备的方框图。
具体实施方式
27.下面将参照附图更详细地描述本技术的实施方式。虽然附图中显示了本技术的实施方式，然而应该理解，可以以各种形式实现本技术而不应被这里阐述的实施方式所限制。相反，提供这些实施方式是为了使本技术更加透彻和完整，并且能够将本技术的范围完整地传达给本领域的技术人员。
28.在本技术使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本技术。在此使用的术语“包括”、“包含”等表明了特征、步骤、操作和/或部件的存在，但是并不排除
存在或添加一个或多个其他特征、步骤、操作或部件。
29.在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。
30.应当理解，尽管在本技术可能采用术语“第一”、“第二”、“第三”等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本技术范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多的该特征。在本技术的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。
31.为了便于理解本技术的技术方案，首先对部分术语进行说明。
32.工业控制系统，是对诸如图像、语音信号等大数据量、高速率传输的要求，催生的以太网与控制网络的结合。工业控制系统网络化浪潮将诸如多标准工业控制网络互联、无线技术等多种当今流行技术融合在一起，拓展了工业控制领域的发展空间。
33.网络协议，是网络节点之间的通信规则的集合，规定了通信时信息所必须采用的格式和这些格式的意义。网络节点包括但不限于：网络服务器、交换机、路由器中至少一种。
34.有限状态机，表示有限数量的状态以及在这些状态之间的转移和动作等行为的数学模型。
35.相关技术在进行协议测试时，需覆盖几十种协议，为了提升测试效率，可以利用自动化脚本测试方法对工业控制的各个工业协议的配置及功能进行测试。然而，每种协议具有不同的特征，并且测试维度不确定。因此，需对每个维度以及不同维度之间的互相影响做充分的测试，导致需要耗费大量人力成本和时间成本对每种协议逐次回归总结补充。此外，基于工业协议的应用场景，获取到的测试流量数据有限，需针对此场景进行更深入的测试，如容易遗漏针对边界条件的测试。
36.申请人对相关技术进行总结后，发现相关技术进行协议测试时至少存在如下所示的缺陷。
37.例如，工控协议增加，相应的脚本堆积加快，导致维护成本增加。
38.例如，实际网络环境中的报文结构多种多样，而测试深度和广度受测试人员经验的限制，对协议的测试存在不确定性。如在控制领域较有影响的现场总线系统有多种总线网络。虽然行业己经制定了统一标准(ff)。但是由于商业利润、技术垄断等原因，现场总线产品仍然是百花齐放的局面，导致对测试人员的经验要求较高。
39.例如，不同协议特征不同，测试方法难以复用。
40.例如，测试数据(如测试流量报文)有限，覆盖测试场景较少。
41.本技术实施例中，针对不同种类的协议预先构建测试流程模型和测试数据模型等，这些测试流程模型和测试数据模型等可以是经过多次验证和能够复用的模型。当需要对某些协议进行测试时，可以直接调用与该协议对应的测试流程模型和测试数据模型，比较全面地考虑了不同测试维度以及不同测试维度之间的互相影响，无需耗费大量人力成本和时间成本来确定相互影响，有效提升测试准确度和便捷度。
42.以下结合图1至图11对本技术的技术方案进行示例性说明。
process control，简称opc)、东芝开发的tcnet、wnet等。
55.工业无线网络协议包括但不限于：局域网/城域网标准委员会(lan/man standards committee)制定的ieee 802标准、r现场总线(rfieldbus)、紫蜂(zigbee)等。
56.控制网络的协议发展趋势是逐渐趋向于开放性、透明的通讯协议。以太网具有传输速度高、低耗、易于安装和兼容性好等方面的优势，由于它支持几乎所有流行的网络协议，所以在商业系统中被广泛采用。随着网络技术的发展，以太网进入了控制领域，形成了基于以太网的控制网络技术。这至少部分地是由于工业自动化系统向分布化、智能化控制方面发展，开放的、透明的通讯协议是可能的趋势。现场总线由于种类繁多，互不兼容，尚不能满足这一要求。但是，以太网的tcp/ip协议等在短期内也无法替代现场总线协议，两者会共存较长时间，这就进一步增加了需要测试协议的种类和测试的困难度。
57.本实施例中，可以基于经验、规则等从历史测试用例中抽象出针对不同种类的协议的测试流程模型、测试数据模型等。这些测试流程模型、测试数据模型可以复用，能确保各模型和文件的准确度和覆盖率。在需要对某种类型的协议进行测试时，用户输入待测试协议，服务器可以自动选取与待测试协议对应的测试流程模型、测试数据模型。用户也可以手动选取与待测试协议对应的测试流程模型、测试数据模型。模型驱动文件同样可以是预先编辑好的文件，用户也可以根据自身对驱动模型文件进行编辑。
58.具体地，确定与待检测协议对应的至少一个测试流程模型、测试数据模型和模型驱动文件可以包括如下操作：基于模型驱动文件中的映射关系确定与待检测协议对应的至少一个测试流程模型和测试数据模型。其中，待检测协议包括测试参数，映射关系包括测试参数、测试流程模型和测试数据模型之间的对应关系，测试流程模型包括至少一个节点和至少一个边，节点表征状态机模型，边表征测试操作，通过执行测试操作以在不同状态机模型之间跳转。
59.对于包括多种状态的网络协议，其是一种上下文信息、数据信息和历史轨迹有关的协议。包括多种状态的网络协议的通信过程非常复杂。例如，可以包括握手、认证等过程，相关技术进行协议测试时，采用的测试数据可能仅覆盖第一个交互状态，很难覆盖后续状态轨迹。因此，包括多种状态的网络协议，须要考虑有状态网络协议的状态特性。
60.状态机模型适合于描述网络协议的状态变迁特性，是可以被采用的形式化描述方式。状态机模型一般用一个有向图来表示，顶点表示状态，有向边表示操作，通过操作可以实现状态的迁移。有向边上面标记输入和输出，是状态变迁的条件。状态机模型不仅直观性强，而且方便于自动实现。例如，状态机模型可以表示为一个多元组。状态机模型可以为有限状态机模型。
61.例如，状态机模型中可以包括如下所示的多个状态：读取线圈状态、线圈状态处于状态1、线圈状态处于状态2等。测试操作可以为接收消息1，对应的状态迁徙为线圈状态从状态1迁徙至状态2。
62.在操作s220中，遍历经拼接的至少一个测试流程模型，得到至少一条测试路径，每条测试路径存在对应的测试操作序列。
63.在本实施例中，由于在对一个协议进行测试的过程中，可能涉及到多个测试流程模型和/或测试数据模型，在生成测试用例过程中，需要先对多个测试流程模型进行拼接操作，得到完整的测试模型，以便进行遍历。
64.例如，测试流程模型可以包括多个状态机模型和测试操作，通过不同的测试操作可以实现多个状态机之间的跳转，这样便于基于状态判断测试结果是否正确。
65.图4示意性示出了根据本技术实施例的测试流程模型的结构示意图。
66.参见图4，该测试流程模型可以包括状态机模型1～状态机模型7，状态机模型可以被展示为节点，多个节点之间可以存在连接关系。其中，连接关系可以表征测试操作，通过测试操作实现不同状态机之间的跳转。其中，至少部分测试流程模型各自包括入口和出口，以便不同测试流程模型之间的连接。在某些实施例中，至少部分测试流程模型各自包括入口和出口。
67.参考图4所示，该测试流程模型中即可包括三条测试路径。
68.例如，测试路径1：状态机模型1-状态机模型2-状态机模型6-状态机模型7。相应地，测试操作序列可以包括：测试操作0-测试操作1-测试操作2-测试操作6-测试操作7。其中，各测试操作可以相同或者不同。
69.例如，测试路径2：状态机模型1-状态机模型2-状态机模型3-状态机模型4-状态机模型6-状态机模型7。相应地，测试操作序列可以包括：测试操作0-测试操作1-测试操作2-测试操作3-测试操作4-测试操作6-测试操作7。其中，各测试操作可以相同或者不同。
70.例如，测试路径3：状态机模型1-状态机模型2-状态机模型3-状态机模型4-状态机模型5-状态机模型6-状态机模型7。相应地，测试操作序列可以包括：测试操作0-测试操作1-测试操作2-测试操作3-测试操作4-测试操作5-测试操作6-测试操作7。其中，各测试操作可以相同或者不同。
71.应当能够理解的是，当拼接多个测试流程模型后，可能得到更多条测试路径。
72.在操作s230中，对于至少部分测试路径中的每一条，基于与该测试路径对应的测试操作序列和测试数据生成测试用例。
73.其中，测试数据包括基于待检测协议、模型驱动文件从测试数据模型中确定的数据，测试数据作为测试操作序列中测试操作的测试参数值。
74.测试操作可以包括至少一个参数，测试数据可以为该至少一个参数赋值。
75.在某些实施例中，基于与该测试路径对应的测试操作序列和测试数据生成测试用例可以包括如下操作：对于测试操作序列中的每个测试操作，将测试数据赋值给与该测试操作对应的测试参数，生成可执行测试操作。
76.模型驱动文件作为模型实例化的参数，来驱动整个模型的运作。对于工控协议而言，模型驱动文件中定义了各个工控协议的测试对象及测试范围。此外，模型驱动文件还可以规定了测试数据的合法性。
77.图5示意性示出了根据本技术实施例的检测协议的过程示意图。
78.参见图5，虚线框表示测试模型相关数据，这些数据可以是从预先开发的库中调用的数据。如可以开发包括测试流程模型的数据库和包括测试数据模型的数据库。此外，还可以开发包括驱动文件的数据库。用户在需要针对某种类型的协议进行测试时，可以从库中选取对应的测试流程模型、测试数据模型和模型驱动文件中至少一种，以便生成测试用例，以及基于该测试用例进行测试。其中，测试流程模型可以是通过流程建模得到的。测试数据模型可以是基于历史的测试数据构建的。需要说明的是，用户可以根据自身需求，对模型驱动文件等进行配置，如新增、删除或者修改设置信息等中至少一种。
79.例如，模型驱动文件中可以提供协议相关的约束条件，如条件1至条件4所示。
80.条件1，协议记录的日志格式。
81.条件2，协议待测试特征参数个数。
82.条件3，协议待测试特征参数取值范围。
83.条件4，协议待测试特征参数映射关系。
84.以上约束条件仅为示例性示出，不能理解为对本技术的限定。
85.例如，本实施例中可以使用基于模型的测试方法，将对工控协议的全部测试流程进行建模，构造测试数据模型和测试流程模型。然后，可以以模型驱动文件为输入，实例化测试数据模型和测试流程模型，生成测试用例。这样便于执行测试用例，并基于检查结果对协议的检测。
86.在某些实施例中，上述方法还可以包括如下操作：构建测试数据模型。其中，针对工控协议的测试数据模型中的至少部分测试数据，来自于工控协议的协议内容的字段。将从协议内容中选取的字段作为测试数，使得本实施例可以适用于工业流量有限的场景进行覆盖测试。
87.具体地，测试数据模型可以包括协议的可测试字段、与可测试字段对应的取值范围、与报文特征相匹配的条件以及约束条件中的至少一种。
88.例如，工控协议的测试数据可以来源于协议内容各个字段，针对具有某种特征的流量，工控设备(如工控防火墙)能否正确识别流量的行为，而且可以采取与之对应的动作。
89.在某些实施例中，构建测试数据模型可以包括如下操作。首先，获取测试样本数据，测试样本数据包括测试参数值。然后，对测试参数值的至少部分维度和参数值的组合进行反向匹配处理，得到多个测试数据条目。接着，将多个测试数据条目作为测试数据模型。
90.具体地，实际的测试环境不会覆盖到所有场景，可以采用反向匹配测试方法来减少测试数量冗余量。例如，通过对已知工业协议流量报文进行基于报文描述的建模，使用配对算法(如pairwise/all-pairs testing)或正交法测试策略(orthogonal array testing strategy，简称oats)等，筛选某种协议的测试变量的所有维度及值的组合，避免穷举测试所有维度的所有值及其组合来获取有效测试数据，对解析引擎的多种可能性进行遍历测试。
91.例如，测试参数包括类别、设备组和产品测试结果。其中，类别包括类别1和类别2。设备组包括组1和组2。产品测试结果包括合格和不合格。经过排列组合，可以得到8组测试数据，如表1所示。
92.表1
93.序号类别设备组产品测试结果1类别1组1合格2类别2组1合格3类别1组2合格4类别2组2合格5类别1组1不合格6类别2组1不合格7类别1组2不合格
8类别2组2不合格
94.反向匹配过程可以如下所示。
95.首先，从序号8开始分析。序号8是“类别2、组2、不合格”的组合，两两组合是“类别2组2”、“组2不合格”、“类别2不合格”。检查这三个组合在序号1-7中是否出现过，可以看出“类别2组2”在4号，“组2不合格”在7号，“类别2不合格”在6号中出现过。因此，根据配对测试法思想，8号可以舍去。此时，剩下的测试数据如表2所示。
96.表2
[0097][0098][0099]
接着，分析序号7。序号7的两两组合“类别1组2”在3号出现过，“类别1不合格”在序号5中出现过，但“组2不合格”仅此一个，因此序号7需要保留。
[0100]
接着，分析序号6。同理分析可得，序号6的组合“类别2组1”在2号出现过，“组1不合格”在5号出现过，“类别2不合格”仅此一个，因此6号用要保留。
[0101]
接着，分析序号5。同理分析可得，5号的组合“类别1组1”在1号出现过，“组1不合格”在6号出现过，“类别1不合格”在7号出现过，因此6号用例可以舍去，剩下的测试数据如表3所示。
[0102]
表3
[0103]
序号类别设备组产品测试结果1类别1组1合格2类别2组1合格3类别1组2合格4类别2组2合格6类别2组1不合格7类别1组2不合格
[0104]
接着，按照上述方式依次分析序号4、序号3、序号2、序号1，可得最终保留测试数据如表4所示。
[0105]
表4
[0106][0107][0108]
可以看出，经过反向匹配处理后的测试数据为原来的一半，有效减少了测试数据，并且具有较好的测试覆盖率。需要说明的是，上述反向匹配处理仅为示例性说明，不能理解为对本技术的限定。
[0109]
测试数据模型中规定了协议的可测试字段及取值范围，与报文特征相匹配的条件以及一些常规的约束，使得测试数据更有针对性。
[0110]
例如，测试数据可以是通过pariwise算法得到的部分测试数据，测试数据覆盖正向和反向测试的多组测试数据。测试数据可以如表5所示。
[0111]
表5
[0112]
arg1arg2arg3match001 read coil(读取线圈状态)-10nany-1100y015 write multiple coils(强制多线圈)065535n004 read input registers(读取输入寄存器)00n024 read fifo queue6553565535n003 read holding registers(读取保持寄存器)1100n006 write single register(预制单寄存器)6553565535nany00n016 write multiple registers(预制多寄存器)00n006 write single register(预制单寄存器)1100n002 read discrete inputs(读取输入状态)-165535n023 read write register-10n001 read coil(读取线圈状态)165535y005 write single coil(强制单线圈)-1-1n022 mask write register165535n
[0113]
在某些实施例中，上述方法还可以包括：构建测试流程模型。
[0114]
对工业协议的控制测试，可以包括两个部分，一部分是配置工业协议相关的策略(如涉及协议的特征或是控制的动作)。另一部分是流量的实际控制检查。在之前的实施例中已经得到了测试数据，构建测试流程模型的过程是通过建模的方式获取测试操作，从而组合成完整的测试用例。
[0115]
测试步骤的建模首先要分析该模块的功能，之后分析测试步骤和测试步骤之间的关系，以及测试步骤和状态机模型之间关系。根据被测系统的状态、之前设置的约束条件来
做测试设计，生成并执行测试用例。此外，生成测试用例时还可以采用测试策略(参见图7和图8相关部分说明)。
[0116]
具体地，构建测试流程模型可以包括如下操作。
[0117]
首先，绘制与状态机模型对应的节点，并且确定该节点的关联节点，状态机模型用于按照预先设定的状态进行状态转移。然后，连接节点和关联节点，得到边。接着，建立边和测试操作之间的映射关系，得到测试流程模型。
[0118]
例如，使用绘图工具(如graphwalker)绘制状态机模型和连接关系，描述测试的每个操作步骤，将所有可能产生联系的操作步骤之间连接起来，绘制成一个尽可能覆盖全部流程的完整模型。
[0119]
在一个具体实施例中，利用graphwalker绘制节点和边。其中，每条边代表一种变迁操作，每个节点代表一种状态。需要说明的是，多模型组合需在每个模型中提供出口和入口，方便模型之间切换。
[0120]
图6示意性示出了根据本技术实施例的经拼接的测试流程模型的结构示意图。
[0121]
参见图6，示出了测试流程模型1、测试流程模型2和测试流程模型3。其中，测试流程模型1包括状态机模型1～7，测试流程模型2包括状态机模型8～10，测试流程模型3包括状态机模型11～13。状态机模型1～7各自与状态机模型8～10之间可以相同或不同。
[0122]
在某些实施例中，可以采用自动的方式生成测试用例，或者采用手动的方式生成测试用例。
[0123]
具体地，遍历经拼接的至少一个测试流程模型可以包括如下至少一种方式。
[0124]
例如，响应于接收的操作指令，拼接至少一个测试流程模型，然后对拼接后的至少一个测试流程模型进行遍历，操作指令是针对测试流程模型的指令。
[0125]
例如，按照至少一个测试流程模型各自的功能之间的依赖关系，对至少一个测试流程模型进行拼接，然后对拼接后的至少一个测试流程模型进行遍历。
[0126]
图6中描述了一个简单的生成测试用例的过程。先做配置，模型生成后通过手动或自动方式加载模型，生成测试步骤的序列。图中示例采用的有限状态机模型，根据状态机的特点和路径遍历算法来生成测试用例。
[0127]
遍历过程可以采用如下任意一种或多种方式。
[0128]
有限状态机(finite state machine，简称fsm)，自动生成用例原理：结合不同的算法和策略来遍历模型。
[0129]
模型根据大量的不同路径来列举所有的转换和状态，自动生成一系列的测试用例。
[0130]
其中，基于模型的测试技术的主要功效就体现在路径遍历的算法中。遍历算法：随机遍历、加权遍历、覆盖所有变迁等等。
[0131]
在某些实施例中，按照至少一个测试流程模型各自的功能之间的依赖关系，对至少一个测试流程模型进行拼接可以包括：按照至少一个测试流程模型各自的功能之间的依赖关系，将测试流程模型的入口和被依赖的测试流程模型的出口相连。
[0132]
例如，对拼接后的至少一个测试流程模型进行遍历可以包括如下操作。
[0133]
首先，将首个测试流程模型的入口对应的节点作为起始节点，依次从起始节点的未被访问的相连节点出发，深度优先遍历所有节点，直至访问到与最后一个测试流程模型
的出口对应的节点。
[0134]
然后，重复以下操作，直至所有测试流程模型的所有节点都被访问到为止：如果存在未被访问的节点，则从未被访问的节点中选取一个节点作为起始节点，依次从起始节点的未被访问的相连节点出发，深度优先遍历未被访问的节点，直至访问到与最后一个测试流程模型的出口对应的节点。
[0135]
例如，参见图6，测试路径可以包括：状态机模型1-状态机模型2-状态状态机模型7-状态机模型8-状态机模型10-状态机模型11-状态机模型12-状态机模型13。其它测试路径不再一一示出。
[0136]
一种工控协议可以支持对多个工业设备的不同功能、部件进行不同的操作。本实施例中可以通过对多个测试流程模型进行拼接的方式来满足多种测试场景的需求。
[0137]
在某些实施例中，可以针对用户所关注的测试参数对测试流程模型和/或测试数据模型进行调整，以提升测试效率。
[0138]
具体地，上述方法还可以包括如下操作。首先，响应于从测试参数中确定的目标测试参数，对测试流程模型进行调整，得到子测试流程模型，并且，从测试数据模型中选取与目标测试参数对应的目标测试数据。然后，利用子测试流程模型替换测试流程模型。其中，目标测试参数可以由用户指定的参数。由于测试参数和测试数据之间存在对应关系，可以基于用户指定的参数确定所需的测试数据。
[0139]
例如，对测试流程模型进行调整，得到子测试流程模型可以包括如下操作。首先，确定与目标测试参数相关联的状态机。然后，从测试流程模型中删除相关联的状态机之外的非关联状态机和非关联测试操作，得到子测试流程模型。
[0140]
图7示意性示出了根据本技术实施例的调整前的测试流程模型的结构示意图。图8示意性示出了根据本技术实施例的调整后的测试流程模型的示意图。
[0141]
参见图7，某个测试流程模型包括状态机模型1～状态机模型12，其中，状态机模型1分别与状态机模型2、状态机模型6、状态机模型7、状态机模型9、状态机模型10、状态机模型11、状态机模型12相连。当前需要对测试参数a进行测试，与测试参数a相关联的状态机模型包括：状态机模型6、状态机模型7、状态机模型9、状态机模型10、状态机模型11、状态机模型12，则可以将图7所示的测试流程模型简化为如图8所示的测试流程模型。
[0142]
该模型设计方式具有动态自适应的特点，可以根据模型驱动文件中的不同的协议类型或者不同的测试需求，对模型的节点或流程进行删减修改，自动生成一个适用于当前测试需求的模型
[0143]
图9示意性示出了根据本技术实施例的基于测试用例进行测试的方法的流程图。上述测试样本数据还可以包括正确测试结果标识信息。
[0144]
参见图9，上述方法在执行操作s230之后，还可以包括操作s940和操作s950。
[0145]
在操作s940，基于测试用例对待检测协议进行测试，获得针对测试用例的测试结果。
[0146]
在操作s950，比对与正确测试结果标识信息对应的正确测试结果和测试结果。
[0147]
例如，可以基于生成的多条测试用例进行测试，测试过程可以如下所示。
[0148]
例如，用户
→
选择工业协议a
→
工业协议特征配置(匹配)
→
工控流量测试
→
检查控制结果。
[0149]
例如，用户
→
选择工业协议b
→
工业协议特征配置(不匹配)
→
工控流量测试
→
检查控制结果。
[0150]
例如，用户
→
选择工业协议b
→
工业协议特征配置(匹配)
→
控制动作
→
工控流量测试
→
检查控制结果。
[0151]
本实施例中基于对工业协议流量的描述建模得到测试数据模型，并基于测试数据模型获取到测试数据。基于对工控设备测试流程建模生成测试流程模型，并基于测试流程模型得到测试步骤序列，从而生成可执行的测试用例。上述方式生成的测试用例具有动态生成、可追溯、无需维护固态用例的特征。此外，用户可以通过自定义数据驱动，自适应生成具体模型。
[0152]
本技术的另一方面还提供了一种生成测试用例的装置。
[0153]
图10示意性示出了根据本技术实施例的一种生成测试用例的装置的方框图。
[0154]
参见图10，该生成测试用例的装置1000可以包括：模型确定模块1010、模型遍历模块1020和测试用例生成模块1030。
[0155]
模型确定模块1010用于确定与待检测协议对应的至少一个测试流程模型、测试数据模型和模型驱动文件。
[0156]
模型遍历模块1020用于遍历经拼接的至少一个测试流程模型，得到至少一条测试路径，每条测试路径存在对应的测试操作序列。
[0157]
测试用例生成模块1030用于对于至少部分测试路径中的每一条，基于与该测试路径对应的测试操作序列和测试数据生成测试用例.其中，测试数据包括基于待检测协议、模型驱动文件从测试数据模型中确定的数据，测试数据作为测试操作序列中测试操作的测试参数值。
[0158]
在某些实施例中，模型确定模块具体用于基于模型驱动文件中的映射关系确定与待检测协议对应的至少一个测试流程模型和测试数据模型，其中，待检测协议包括测试参数，映射关系包括测试参数、测试流程模型和测试数据模型之间的对应关系，测试流程模型包括至少一个节点和至少一个边，节点表征状态机模型，边表征测试操作，通过执行测试操作以在不同状态机模型之间跳转。
[0159]
在某些实施例中，上述装置1000还可以包括：测试数据模型构建模块，用于构建测试数据模型，其中，针对工控协议的测试数据模型中的至少部分测试数据，来自于工控协议的协议内容的字段。
[0160]
在某些实施例中，测试数据模型包括协议的可测试字段、与可测试字段对应的取值范围、与报文特征相匹配的条件以及约束条件中的至少一种。
[0161]
在某些实施例中，测试数据模型构建模块包括：数据获取单元、反相匹配单元和模型替换单元。
[0162]
数据获取单元用于获取测试样本数据，测试样本数据包括测试参数值；
[0163]
反相匹配单元用于对测试参数值的至少部分维度和参数值的组合进行反向匹配处理，得到多个测试数据条目；
[0164]
模型替换单元用于将多个测试数据条目作为测试数据模型。
[0165]
在某些实施例中，测试样本数据还包括正确测试结果标识信息。相应地，上述装置1000还可以包括测试模块和比对模块。
[0166]
测试模块用于基于测试用例对待检测协议进行测试，获得针对测试用例的测试结果；
[0167]
比对模块用于比对与正确测试结果标识信息对应的正确测试结果和测试结果。
[0168]
在某些实施例中，上述装置1000还可以包括：数据和参数确定模块、模型调整模块。
[0169]
数据和参数确定模块用于响应于从测试参数中确定的目标测试参数，对测试流程模型进行调整，得到子测试流程模型，并且从测试数据模型中选取与目标测试参数对应的目标测试数据。
[0170]
模型调整模块用于利用子测试流程模型替换测试流程模型。
[0171]
在某些实施例中，数据和参数确定模块具体用于确定与目标测试参数相关联的状态机，以及从测试流程模型中删除相关联的状态机之外的非关联状态机和非关联测试操作，得到子测试流程模型。
[0172]
在某些实施例中，上述装置1000还可以包括：测试流程模型构建模块。
[0173]
测试流程模型构建模块包括节点绘制单元、边绘制单元和建立映射单元。
[0174]
节点绘制单元用于绘制与状态机模型对应的节点，并且确定该节点的关联节点，状态机模型用于按照预先设定的状态进行状态转移。
[0175]
边绘制单元用于连接节点和关联节点，得到边。
[0176]
建立映射单元用于建立边和测试操作之间的映射关系，得到测试流程模型。
[0177]
在某些实施例中，模型遍历模块包括第一遍历单元和第二遍历单元。
[0178]
第一遍历单元用于响应于接收的操作指令，拼接至少一个测试流程模型，然后对拼接后的至少一个测试流程模型进行遍历，操作指令是针对测试流程模型的指令。
[0179]
第二遍历单元用于按照至少一个测试流程模型各自的功能之间的依赖关系，对至少一个测试流程模型进行拼接，然后对拼接后的至少一个测试流程模型进行遍历。
[0180]
在某些实施例中，至少部分测试流程模型各自包括入口和出口。相应的，第二遍历单元具体用于按照至少一个测试流程模型各自的功能之间的依赖关系，将测试流程模型的入口和被依赖的测试流程模型的出口相连，得到测试模型。
[0181]
在某些实施例中，所述第二遍历单元包括：遍历子单元和循环子单元。
[0182]
其中，遍历子单元，用于将首个测试流程模型的入口对应的节点作为起始节点，依次从起始节点的未被访问的相连节点出发，深度优先遍历所有节点，直至访问到与最后一个测试流程模型的出口对应的节点。
[0183]
循环子单元，用于重复以下操作，直至所有测试流程模型的所有节点都被访问到为止：如果存在未被访问的节点，则从未被访问的节点中选取一个节点作为起始节点，依次从起始节点的未被访问的相连节点出发，深度优先遍历未被访问的节点，直至访问到与最后一个测试流程模型的出口对应的节点。
[0184]
在某些实施例中，所述测试用例生成模块1030具体用于对于所述测试操作序列中的每个测试操作，将所述测试数据赋值给与该测试操作对应的测试参数，生成可执行测试操作。
[0185]
本技术实施例提供的生成测试用例的装置，测试流程模型和/或测试数据模型自适应度高且改动灵活，无固定用例，维护更方便。此外，覆盖测试范围更广泛，更易发现隐藏
问题及设计缺陷。另外，同时适用于工业流量有限的场景进行覆盖测试。
[0186]
关于上述实施例中的装置1000，其中各个模块、单元、子单元执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不再做详细阐述说明。
[0187]
本技术的另一方面还提供了一种电子设备。
[0188]
图11示意性示出了根据本技术实施例的一种电子设备的方框图。
[0189]
参见图11，电子设备1100包括存储器1110和处理器1120。
[0190]
处理器1120可以是中央处理单元(central processing unit，cpu)，还可以是其他通用处理器、数字信号处理器(digital signal processor，dsp)、专用集成电路(application specific integrated circuit，asic)、现场可编程门阵列(field-programmable gate array，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
[0191]
存储器1110可以包括各种类型的存储单元，例如系统内存、只读存储器(rom)和永久存储装置。其中，rom可以存储处理器1120或者计算机的其他模块需要的静态数据或者指令。永久存储装置可以是可读写的存储装置。永久存储装置可以是即使计算机断电后也不会失去存储的指令和数据的非易失性存储设备。在一些实施方式中，永久性存储装置采用大容量存储装置(例如磁或光盘、闪存)作为永久存储装置。另外一些实施方式中，永久性存储装置可以是可移除的存储设备(例如软盘、光驱)。系统内存可以是可读写存储设备或者易失性可读写存储设备，例如动态随机访问内存。系统内存可以存储一些或者所有处理器在运行时需要的指令和数据。此外，存储器1110可以包括任意计算机可读存储媒介的组合，包括各种类型的半导体存储芯片(例如dram，sram，sdram，闪存，可编程只读存储器)，磁盘和/或光盘也可以采用。在一些实施方式中，存储器1110可以包括可读和/或写的可移除的存储设备，例如激光唱片(cd)、只读数字多功能光盘(例如dvd-rom，双层dvd-rom)、只读蓝光光盘、超密度光盘、闪存卡(例如sd卡、min sd卡、micro-sd卡等)、磁性软盘等。计算机可读存储媒介不包含载波和通过无线或有线传输的瞬间电子信号。
[0192]
存储器1110上存储有可执行代码，当可执行代码被处理器1120处理时，可以使处理器1120执行上文述及的方法中的部分或全部。
[0193]
此外，根据本技术的方法还可以实现为一种计算机程序或计算机程序产品，该计算机程序或计算机程序产品包括用于执行本技术的上述方法中部分或全部步骤的计算机程序代码指令。
[0194]
或者，本技术还可以实施为一种计算机可读存储介质(或非暂时性机器可读存储介质或机器可读存储介质)，其上存储有可执行代码(或计算机程序或计算机指令代码)，当可执行代码(或计算机程序或计算机指令代码)被电子设备(或服务器等)的处理器执行时，使处理器执行根据本技术的上述方法的各个步骤的部分或全部。
[0195]
以上已经描述了本技术的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中的技术的改进，或者使本技术领域的其他普通技术人员能理解本文披露的各实施例。