的方式实现，集成测试用例可通过选择、拖拽 等图形化操作生成，简化了集成测试用例的生成步骤，同时方便了用例的管理与维护。
【附图说明】
[0051] 图1是本发明提供的集成测试用例的生成方法的一个实施例的流程图；
[0052] 图2是如图1所示实施提供的步骤S2的流程图；
[0053] 图3是本发明提供的集成测试用例的生成装置的一个实施例的结构图；
[0054] 图4是本发明提供的集成测试用例的生成装置的另一个实施例的结构图。
【具体实施方式】
[0055] 下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完 整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于 本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他 实施例，都属于本发明保护的范围。
[0056] 参见图1，是本发明提供的集成测试用例的生成方法的一个实施例的流程图。
[0057] 如图1所示，所述集成测试用例的生成方法，包括步骤Sl~S3 :
[0058] S1，对前置单元测试用例的输出数据进行标准化处理，将所述输出数据转换为预 先设定的格式，获取标准化输出数据。
[0059] 其中，本发明实施例中所述标准化处理为将输出数据转换成预先设定的数据格式 和形式，可通过预先编写的输出标准化单元实现。所述预先设定的格式可以为xml格式或 者json格式，需要说明的是采用xml格式或者json格式仅是本发明的一种优选实施方式， 本领域技术人员还可以根据实际需要选择其他自描述格式，如：yaml、protobuf、msgpack、 csv、ini、自定义二进制格式和自定义文本格式等。在具体实施当中，前置单元测试用例接 收输入数据后通过执行自身的逻辑并输出用例的执行结果，即输出数据。各单元测试用例 输出数据的形式不尽相同，有的以函数或模块的调用返回的形式给出，有的以操作系统标 准输出的形式给出，有的则以日志文件或测试报告文件的形式给出。本发明通过将单元测 试用例的输入输出数据转换成统一的自描述格式，使得前置单元测试用例和后置单元测试 用例的输出输入对接变得简单，也有利于图形化辅助单元对输入输出数据的自动解析，为 通过图形化界面实现集成测试用例的生成提供基础。
[0060] S2,从所述标准化输出数据中抽取有用数据，根据所述有用数据生成后置单元测 试用例的标准化输入数据并进行对应的数据填充。其中，所述标准化输入数据的格式与所 述标准化输出数据的格式相同。
[0061] 在实际操作中，可通过以下方式从所述标准化输出数据中抽取有用数据：
[0062] 对所述标准化输出数据进行解析，获取所述标准化输出数据的解析结果。
[0063] 根据预先设定的抽取参数进行数据提取，从所述标准化输出数据的解析结果中获 取有用数据。
[0064] 如图2所示，在具体实施当中，所述步骤S2包括以下步骤：
[0065] S21，从所述标准化输出数据中抽取有用数据。
[0066] S22,对所述有用数据进行参数转换计算，获取计算结果。
[0067] S23,将所述计算结果填充到后置单元测试用例的标准化输入数据中。
[0068] 在实际应用当中，某些后置单元测试用例测试所需的输入数据无法从前置单元测 试用例的输出数据中直接抽取，而需要先对抽取的有用数据进行一定的计算，以进行参数 转换，将抽取的有用数据转换成后置单元测试用例进行测试所需的输入数据。具体地，所述 参数转换计算可以为数值计算、逻辑判断、记录用例执行进度和统计用例执行次数中的一 种或多种组合。此外，还可以根据预设条件选择后置单元测试用例，或者在必要时停止后置 单元测试用例的执行以结束整个集成测试用例，又或者触发并等待多个后置单元测试用例 的执行并对这些后置单元测试用例的输出进行汇总、二次判断等。应当说明的是，以上方式 仅为本发明的部分计算方式，本领域技术人员可以理解本发明还可以采用其他方式进行计 算以将从前置单元测试用例抽取的数据转换成后置单元测试用例执行所需的输入数据，在 没有作出创造性劳动前提下所获得的所有其他方式，均应视为本发明的保护范围。
[0069] 进一步地，后置单元测试用例往往需要多个输入参数，从前置单元测试用例的输 出数据中获取的数据可能无法完全满足后置单元测试用例的输入数据需求。因此，后置单 元测试用例除了需要从前置单元测试用例的输出数据中抽取数据外，还可能需要额外的输 入数据，本发明还可以通过直接将预设的数据追加或更新到所述后置单元测试用例的标准 化输入数据中，以保证后置单元测试用例的正常执行。
[0070] 本发明实施例的一种具体应用场景如下：某即时通信系统拥有登陆与好友两个模 块，登陆模块的单元测试用例中拥有验证登陆是否成功的单元测试用例A，好友模块的单元 测试用例中拥有验证好友是否在线的单元测试用例B，现按照上述集成测试用例的生成方 法利用单元测试用例A和单元测试用例B构造验证好友登陆时好友列表中好友在线状态是 否正确的集成测试用例。
[0071] 经过标准化处理后的单元测试用例A的输出数据为：
[0074] 其中，result表示单元测试用例A是否执行成功，info,state表示用户当前的 在线状态，所述在线状态包括"online"（在线）、"busy"（忙碌）、"leave"（离开）和 "offline"（离线）等。
[0075] 根据步骤S21~S23生成集成测试用例的配置文件如下：
[0076] [{
[0077] "fetch": "info,state",
[0078] "calc":"state2online",
[0079] "push":"is_online"
[0080] }, {
[0081] "params": friend，：，userl，}"
[0082] }]
[0083] 本实施例中使用json格式作为配置文件的格式，该配置文件中包含一个json数 组，数组中包含两个元素。
[0084] 第一个元素表示执行一次"抽取-计算-填充"操作，抽取的内容为单元测试用例A 输出数据中的"inf〇.state"，计算方式由函数"state2online"指定，并在计算后将函数返 回填充到单元测试用例B的输入数据"is_online"中。若使用python来实现state2online 函数，可将其定义为：
[0085]
[0086] 第二个元素表不直接在早兀测试用例B
的称准化湔人数据中添加 {friend:userl| 〇
[0087] 由上述举例中可以看出，参数转换的计算仅由state2online中的代码指定，而其 余逻辑主要为数据的抽取和填充操作，在实际应用当中，这部分逻辑可直接通过选取抽取 参数和填充参数的方式来自动生成。测试脚本编写过程中，数据的抽取与填充操作与测试 核心逻辑关系不大，并且由于测试过程中需要处理各种异常情况，代码冗余且易出错。本发 明可通过使用配置文件来自动生成测试脚本，大大减小了出错的机率，仅需要通过对配置 文件进行修改，即可对各单元测试用例之间的逻辑关系进行变更，便于对集成测试用例的 管理。
[0088] 获取得到经过标准化处理的单元测试用例B的标准化输入数据如下：
[0089]
[0090] 其中，单元测试用例B的标准化输入数据中friend表示用户的唯一标识，is_ online表示好友的预期在线状态，所述预期在线状态包括"true"（在线）和"false"（离 线）。
[0091] S3,将所述标准化输入数据转化为所述后置单元测试用例可接受的形式并输入到 所述后置单元测试用例中。
[0092] 在具体实施当中，标准化输入数据需要转化为后置单元测试用例可接受的形式才 能输入到后置单元测试用例中，不同单元测试用例对输入数据的格式、方式和来源等要求 往往不同，所述后置单元测试用例的可接受的输入数据可以为操作系统的标准输入，或者 用例执行所依赖的数据文件，又或者数据库中的数据项，甚至是缓存系统中的缓存内容等。
[0093] 在具体实施当中，可通过重复上述步骤Sl~S3,对多个旧有的单元测试用例进行 合理的组合，生成面向集成系统的集成测试用例。所述单元测试用例是开发人员进行冒烟 测试或测试人员对系统模块进行单元测试时积累下来的旧有测试用例，在制定出通用的输 入输出标准后，即可由各单元测试用例的原负责人编写各单元测试用例的输入标准化单元 和输出标准化单元，通过所述输入标准化和所述输出标准化单元对单元测试用例的输入输 出数