1 背景

基于需求生成测试用例后，我们希望测试用例能够程序化执行，从而实现用例自动生成、自动执行、自动判决的全过程自动化，降低测试验证工作量。

测试用例是面向需求的，基于需求产生，一般不具备可执行性。需要补充信息，将测试用例转换为测试规程/测试脚本，才具备可执行性。

用基于需求生成的用例，来测试基于需求开发的软件或系统，典型有两类信息需要扩展，即设计/实现信息以及运行信息。本文通过实例，对测试用例的可执行转换进行讨论。

2 扩展实现信息

根据需求的层次不同，需求中所使用的数据对象，一般是概念数据或者逻辑数据，是独立于实现、平台无关的。而作用到被测对象的数据，则是具体的实现数据，一般体现在接口数据定义文件。需要将测试用例中的逻辑数据，映射到具体的接口数据。

以下述需求为例：

Req01：当舱温大于等于68℃，保持时间超过2s但不超过10秒，则触发短时超温事件；

Req02：当舱温大于等于68℃，保持时间超过10秒，则触发长时超温事件；

OneLogic生成的测试用例如下所示。

用例中的“舱温”数据，需要转换为被测对象的接口数据定义。转换方式与设计实现相关。

如果在实现中，仅有一个传感器检测舱温，则仅需进行变量指称转换，例如“cabin_temperature”。

如果舱温数据有高安全性要求，设计了3个传感器进行舱温检测，则用例中的“舱温”需要转换为3个传感器的接口数据定义。多个数据的冗余逻辑则是另一个测试目标。

3 扩展运行信息

被测对象的部分逻辑是由运行时数据（如配置数据）决定的。使该类逻辑的测试用例可执行，则需补充相关运行信息。

以如下FMS飞行计划设置场景为例：

Req1：如果设置的起飞机场代码在导航数据库中存在，FSM应显示机场名称、坐标及其他相关信息；

Req2：如果设置的起飞机场代码在导航数据库中不存在，FSM应发送告警消息；

针对上述需求，其测试用例的激励输入应为机场代码，该机场代码应满足使“起飞机场代码在导航数据库中存在”这一谓词逻辑为真、为假两种情况，以实现需求覆盖。然而，在基于需求的用例中，由于缺乏导航数据库信息，不能生成机场代码的具体值。

此时，在用例中，仅包含该谓词逻辑为真或假的条件。在用例转换过程中，通过对导航数据库的访问，获得满足该逻辑的机场代码具体值，生成可执行的测试脚本。

4 关于测试环境信息

测试环境为被测对象提供交联数据/信号模拟，使被测对象运行在期望状态。测试脚本的执行，也需要调用测试环境的接口实现数据访问。然而，并不建议在测试脚本中加入特定的测试环境信息。

一套设计良好的测试系统，应使测试脚本与特定的测试环境无关，实现一套测试脚本在不同测试环境上执行。其关键是测试环境能够对外提供被测对象接口数据的统一访问，即实现基于信号的测试（相对于基于仪器的测试）。目前满足这一要求的测试环境日渐成为主流。

5 总结

本文举例说明了基于需求的测试用例转换为可执行规程/脚本的过程中典型需要扩展的信息。有两方面的认识。

一方面，要使测试用例转换为可执行脚本，往往补充信息是必须的，包括从需求的逻辑数据到接口数据的映射，以及补充运行时数据（典型如数据库）以获得满足条件的具体值。

另一方面，测试用例转换为可执行脚本这一过程也存在复杂性，这往往也是由被测对象的设计信息和运行信息的复杂性所引起的。这是应用场景下需要解决的问题。

通过本文讨论，我们也希望说明，从需求生成用例、从用例生成脚本这两个活动，存在各自的侧重，应合理划分二者的功能分配，以取长补短，各尽其能。