|
在软件或系统测试与验证过程中测试用例设计是极为重要的一项工作。目前不论是在单元测试、集成测试、以及系统测试阶段大都采用人工的方式进行测试用例设计。这种方式存在的主要的问题是：
测试用例的设计策略有两种，即基于功能或者基于代码实现，T-VEC工具是基于功能的测试用例设计与验证工具，可适合于各种平台与系统，并支持单元、集成与系统等各阶段的测试与验证。
T-VEC测试与验证系统主要包含三个部分：
一、被测系统或软件功能的描述；
二、测试向量生成；
三、测试驱动、测试结果分析与测试报告生成。
其中T-VEC支持的功能描述提供两种方式，一是T-VEC
TTM表格化需求建模，二是基于Mathworks
Simulink设计模型。T-VEC产品中核心技术是自动测试向量生成，它决定测试的输入值和期望输出值，并且直接从需求中把和每个测试相关的需求进行映射，同时T-VEC工具可以验证需求与设计，并发现需求与设计中存在的缺陷。T-VEC可以生成各种环境下的测试驱动，并提供标准模板与第三方测试执行工具集成，并提供标准模板以便于定制支持平台。
T-VEC产品包括：
1)基于需求的测试与验证工具RAVE™；
2)基于设计模型的测试与验证工具Simulink
Tester™；
基于功能测试与基于代码结构测试
测试用例设计策略分为基于功能的测试用例设计(也称黑盒测试)与基于代码结构的测试用例设计(也称白盒测试)。基于代码结构的测试用例设计直接与代码具体实现相关，主要从代码的结构和逻辑出发验证所构造的程序是否符合设计要求；在实际系统或软件中，存在两种形式的功能：需求功能和设计功能，需求功能描述了系统或软件的预期行为即系统或软件做什么，而设计功能则描述系统或软件如何实现，因此基于功能的测试用例设计则可以划分为基于需求的测试用例设计与基于设计的测试用例设计，基于需求的测试依赖于对需求的描述(即需求模型)，基于设计的测试则依赖于对设计的描述(即设计模型)。根据需求与设计模型所定义的软件或系统的特性而不是代码进行测试用例设计，因此基于功能的测试方法将测试与验证由基于代码实现的测试技术拓展到基于需求或设计模型的测试。
T-VEC测试向量设计策略
T-VEC采用基于需求与设计模型的功能性测试策略，其测试用例设计机制采用广为接受的测试概念和策略，即基于系统或软件中缺陷与错误的分类。
测试与验证的目的是为了发现系统或软件中的缺陷与错误，根据Zeil修改过的Howden定义，软件存在两种类型的错误即计算错误(Computation
Errors)与域错误(Domain
Errors)，计算错误是指程序按照正确的路径执行，由于计算的错误导致输出的结果不正确；域错误是指由于程序执行了错误的路径(做出错误的判定)引起输出的结果不正确。
T-VEC的测试用例设计机制基于域测试并在域测试技术上进行扩展，不仅能发现域错误，同时能发现计算错误。域测试的的基本思想是对系统或软件进行输入空间的分析，将系统或软件化分为若干个等效的输入子空间，验证每个子空间是否产生正确的结果。T-VEC采用形式化方法描述系统或软件，通过分析将系统或软件功能描述转换为一系列由“与或”逻辑所表示的DNF“析取范式“(Disjunction
Normal Form)，每个DNF代表一个独特的系统或软件功能，从而实现自动根据对系统或软件的功能描述划分输入子空间，针对每个输入子空间选择边界数据作为测试向量。
T-VEC测试向量设计技术特点
-
T-VEC支持为使用非线性不等式描述的规格说明生成测试向量，这里不等式两边都可以是包含依赖变量的表达式，而不仅仅局限于包含常量的线性不等式；
-
T-VEC支持为输入输出空间生成包括复杂结构和数值在内的测试向量；
-
T-VEC支持使用经验选择方法来生成测试向量（例如，不受约束的输入变量的所有上限和下限的组合数目的限制）；
-
T-VEC支持为层次化规格说明生成测试用例，在对高层次的子系统进行集成测试的时候，不需要将该子系统所包含的低层次的子系统的测试向量全部重新生成一遍。当采用自底向上的测试策略来保证全面的覆盖时，这种机制可以避免基于层次化的子系统的约束条件进行测试生成时条件组合过多。
T-VEC工具生成的测试向量可以以各种形式保存，并提供通用测试向量模板以适应不同平台的要求，T-VEC支持如下方式的测试向量格式：
T-vec产品的两大部分介绍：
1）RAVE™基于需求的测试与验证工具---介绍...
2）Simulink
Tester™基于设计的测试与验证工具---介绍...
|
