CN106844193B - 一种嵌入式模块交叉测试的系统化设计方法 - Google Patents

Abstract

本发明涉及一种嵌入式模块交叉测试的系统化设计方法。该方法：首先，对嵌入式系统中所有模块进行分类或归类，建立完整的模块间交叉关联矩阵；其次，按照第一步交叉测试用例缩减策略，分析并确定参与两两交叉的模块类别及具体模块，得到原始的交叉测试用例集；而后，按照第二步交叉测试用例缩减策略，对原始的交叉测试用例集进行分析和进一步缩减，得到初步的交叉测试用例集；最后，对初步的交叉测试用例集的各交叉测试用例的交叉深度和强度进行分析与选择，得到最终的交叉测试用例集。本发明良好的系统化的测试设计保障了下一阶段具体测试实现的质量，也减少了最终测试实施的工作量，使得交叉测试的“又快又好”优势得以体现。

Description

一种嵌入式模块交叉测试的系统化设计方法

技术领域

本发明涉及一种嵌入式模块交叉测试的系统化设计方法。

背景技术

随着嵌入式软件的规模和复杂性的日益增长，嵌入式软件质量在整个嵌入式系统质量中所占的比重也越来越大，越来越多的行业内厂商对嵌入式软件测试的重要性也是有共识的。但由于嵌入式系统具有实时性强，存储、计算等资源有限，与硬件紧密相关等特点，使得传统软件测试理论直接用于嵌入式软件测试时，效果未必就好。比如，传统测试理论中被证实有效的压力测试等系统测试方法应用于嵌入式软件测试时，往往会出现测试时间周期较长、测试效率较低、测试费用(如，人力成本)高等问题，于是，在嵌入式软件测试业界，一种新的测试方法出现了，它就是“模块交叉测试(也有称为“模块组合测试”的，英文叫cross-test。以下简称为“交叉测试”)”。相比于压力测试，交叉测试具有高测试效率(若存在相关BUG，则交叉测试所运行的次数比压力测试少得多，时间也短得多)、高BUG检出效果(在模块存在资源共享或复用的情况下，单纯的压力测试往往发现不了模块间关联的问题，而交叉测试却可以轻易检出)的特点，非常适合在集成测试(即，单个模块集成到系统的过程)或系统测试阶段使用，可以很有效地发现模块间相互干扰影响等问题。

虽然大家都同意“交叉测试方法是一种可以“又快又好”地发现BUG的手段”的观点，但在实际使用中，我们发现实际效果却未必理想。究其根本，主要原因是不良的交叉测试设计限制了这种方法所能发挥的最大威力，效果受限。具体原因有两点：一、不良的交叉测试设计(主要指“过度设计”)不加分析地进行了过多的交叉组合设计，而使得用例数激增，具体测试实施的工作量大，使得交叉测试“快”不起来；二、不良的交叉测试设计(主要指“随意设计”)又很可能遗漏了重要的交叉组合，而使得用例设计得不完整，之后虽投入工作量进行了相应的测试执行，却未能发现本可发现的BUG，使得交叉测试在BUG检出方面看上去，不那么“好”，不那么有效。

鉴于现行交叉测试设计存在“过度设计”和“随意设计”而使得交叉测试的最终效果大打折扣的情况，本发明方法将给出一种新思路新方法，以一种系统化的科学思维来进行嵌入式模块的交叉测试设计，既不“过度”，也不“随意”，设计方法系统化且有章可循。应用本发明的系统化设计方法可以使得交叉测试在检出模块关联问题方面的“快”与“好”的优势得到最充分的体现，交叉测试得到最大的收益。

发明内容

本发明的目的在于提供一种嵌入式模块交叉测试的系统化设计方法，该方法良好的系统化的测试设计保障了下一阶段具体测试实现的质量，也减少了最终测试实施的工作量，使得交叉测试的“又快又好”优势得以体现。

为实现上述目的，本发明的技术方案是：一种嵌入式模块交叉测试的系统化设计方法，包括如下步骤，

S1：对嵌入式系统中所有模块进行分类或归类，建立完整的模块间交叉关联矩阵；

S2：按照第一步交叉测试用例缩减策略，分析并确定参与两两交叉的模块类别及具体模块，得到原始的交叉测试用例集；

S3：按照第二步交叉测试用例缩减策略，对原始的交叉测试用例集进行分析和进一步缩减，得到初步的交叉测试用例集；

S4：对初步的交叉测试用例集的各交叉测试用例的交叉深度和强度进行分析与选择，得到最终的交叉测试用例集。

在本发明一实施例中，所述步骤S1中，是将嵌入式系统中的三个模块以上的复杂的交叉测试分解为若干组两个模块间的交叉测试，从而使得嵌入式系统中所有模块的交叉测试，均分解为两两交叉的交叉测试的组合，而后依据关联矩阵工具，建立完整的模块间交叉关联矩阵。

在本发明一实施例中，所述步骤S2，具体实现如下，

设模块间交叉关联矩阵在横纵方向上分别有n个模块，则需要分析的交叉测试情况有n*n种；根据第一步交叉测试用例缩减策略，考虑模块间交叉关联矩阵对角线及模块间交叉关联矩阵交叉组合依对角线对称的情况，将需要分析的n*n种交叉测试情况缩减为n*(n-1)/2种情况；而后将嵌入式系统中属于纯软件类及基础模块类的模块剔除，对交叉测试情况进一步缩减，得到原始的交叉测试用例集。

在本发明一实施例中，所述步骤S3，具体实现如下，

根据步骤S2得到的原始的交叉测试用例集，按照第二步交叉测试用例缩减策略，剔除嵌入式系统中包括过时的、基本不用的、不可能交叉使用的、存在上下层关系的、对外表现为同一接口的、通过纯软件类及基础模块类功能实现的模块，从而对原始的交叉测试用例集进一步缩减，得到初步的交叉测试用例集。

在本发明一实施例中，按照第二步交叉测试用例缩减策略，还需考虑包括有外设硬件模块或芯片的软件模块、存在硬件复用或软件复用的模块、硬件上存在包括光、电、磁、温度、射线信号干扰的模块、历史上出现过模块间交叉问题的模块，来对原始的交叉测试用例集进行缩减。

相较于现有技术，本发明具有以下有益效果：

本发明设计方法系统化且有章可循：按照科学的思维、工具、法则以及合理的步骤来进行交叉测试的设计；保障了下一阶段具体测试(脚本或用例)实现的质量，也减少了最终测试实施的工作量，使得交叉测试的“又快又好”优势得以体现；

保证交叉测试用例集是正确的：既强调了交叉测试的交叉深度要以“深度交叉”优先，也强调了交叉测试要保证一定的交叉强度；

保证交叉测试用例集是完备的：系统中全部模块都会被列到关联矩阵中，同时，在借助模块间交叉关联矩阵来找出某个模块与其它模块的交叉组合结果时，会在矩阵的横纵2个方向上把所有相关组合都做一遍YesOrNo的分析判断，确保了不会造成测试设计的遗漏，保证了测试设计的完备性；

保证交叉测试用例集是最小化的/最简的；

可扩展性：本发明方法充分考虑到了当系统扩展、模块新增时的情况，基于已有交叉测试设计(模块关联矩阵)的基础上，可以轻松地分析并设计出相应的交叉测试用例。

附图说明

图1为本发明方法总体框图。

图2为以POS机为例的关联矩阵部分图。

图3为本发明方法在情况一的应用框图。

图4为本发明情况二中的矩阵图一。

图5为本发明情况二中的矩阵图二。

图6为本发明情况二中的矩阵图三。

具体实施方式

下面结合附图，对本发明的技术方案进行具体说明。

如图1所示，本发明的一种嵌入式模块交叉测试的系统化设计方法，包括如下步骤，

S1：对嵌入式系统中所有模块进行分类或归类，建立完整的模块间交叉关联矩阵；

S2：按照第一步交叉测试用例缩减策略，分析并确定参与两两交叉的模块类别及具体模块，得到原始的交叉测试用例集；

S3：按照第二步交叉测试用例缩减策略，对原始的交叉测试用例集进行分析和进一步缩减，得到初步的交叉测试用例集；

S4：对初步的交叉测试用例集的各交叉测试用例的交叉深度和强度进行分析与选择，得到最终的交叉测试用例集。

所述步骤S1中，是将嵌入式系统中的三个模块以上的复杂的交叉测试分解为若干组两个模块间的交叉测试，从而使得嵌入式系统中所有模块的交叉测试，均分解为两两交叉的交叉测试的组合，而后依据关联矩阵工具，建立完整的模块间交叉关联矩阵。

所述步骤S2，具体实现如下，

设模块间交叉关联矩阵在横纵方向上分别有n个模块，则需要分析的交叉测试情况有n*n种；根据第一步交叉测试用例缩减策略，考虑模块间交叉关联矩阵对角线及模块间交叉关联矩阵交叉组合依对角线对称的情况，将需要分析的n*n种交叉测试情况缩减为n*(n-1)/2种情况；而后将嵌入式系统中属于纯软件类及基础模块类的模块剔除，对交叉测试情况进一步缩减，得到原始的交叉测试用例集。

所述步骤S3，具体实现如下，

根据步骤S2得到的原始的交叉测试用例集，按照第二步交叉测试用例缩减策略，剔除嵌入式系统中包括过时的、基本不用的、不可能交叉使用的、存在上下层关系的、对外表现为同一接口的、通过纯软件类及基础模块类功能实现的模块，从而对原始的交叉测试用例集进一步缩减，得到初步的交叉测试用例集。按照第二步交叉测试用例缩减策略，还需考虑包括有外设硬件模块或芯片的软件模块、存在硬件复用或软件复用的模块、硬件上存在包括光、电、磁、温度、射线信号干扰的模块、历史上出现过模块间交叉问题的模块，来对原始的交叉测试用例集进行缩减。

以下为本发明的具体实施过程。

本发明方法主要给出了一种系统化地进行嵌入式模块间交叉测试的设计思路和方法，并最终总结成具备实际可行性的套路步骤。

本发明方法在交叉测试设计时的依次有4个步骤：对系统中所有模块进行分类或归类，建立完整的交叉关联矩阵→按照交叉测试用例缩减策略1，分析并确定参与两两交叉的模块类别及具体模块，得到原始的交叉测试用例集→按照交叉测试用例缩减策略2，对原始的交叉测试用例集进行分析和进一步缩减，得到初步的交叉测试用例集→对初步的交叉测试用例集的各交叉测试用例的交叉深度和强度策略进行分析与选择，得到最终的交叉测试用例集。在设计过程中，会用到“关联矩阵”工具以及相应的用例缩减策略来帮助完成测试设计。在实际使用中，依这里的步骤进行系统化的交叉测试设计即可。用流程图来表达本发明方法的总体使用步骤就类似图1。

通过以上系统化的测试设计方法，我们就会得到正确的、完备的、最小化的/最简的交叉测试用例集。当然，在具体应用本发明方法时，具体作法会依是否是首次进行交叉关联的系统化分析设计，而在具体实施的步骤细节上略有不同，具体如下。

在具体实施第1步(即“对参与两两交叉的模块进行分析、确定与归类”)之前，我们需要先回答一个问题，即“在交叉测试设计中，为何只需要考虑两两交叉的简单组合情况，而不用考虑其它复杂的组合情况？”。这是因为复杂的多于两个模块的交叉组合情况(比如，完成一个业务功能会调到多个功能模块)总是可以分解为几组两个模块的交叉组合情况。比如，在某个业务场景中，会同时用到A、B、C三个基础模块，但我们总能在时间轴上找出仅有其中两个模块同时存在或起作用的时候或时间段。那么，我们将三个模块划分为化简为3个两两组合的作法就存在了合理性。纵使在实际场景中，三个模块确实是同时起作用的，我们也可以通过几个两两用例的依次运行来等效模拟出来，如，依次执行AB和BC或BC和AC等两两交叉用例的组合，都可以模拟出ABC同时使用的情况。当然，应认识到：在几种用例组合情况中，仅会有几种组合情况最为接近实际ABC同时使用的情况，这看上去会使得“找出最接近实际情况的两两交叉用例的组合”成为一个新问题，但实际操作起来，这并不是一个问题，因为交叉测试集作为集成测试和系统测试阶段的必测项目，所有的交叉测试用例都会得到执行，相应地，用例间不同的组合情况也会被全部执行过，既然有条件全部执行相关用例来验证所有可能情况，那么，上面的“找出最接近实际情况的两两交叉用例的组合”的问题就不再是个问题。以上的分析是基于三个模块的情况，但分析思路在三个以上模块的更复杂情况却同样适用，即可以直接推广到三个以上模块的情况。

总之，正是因为“三个模块以上的复杂的交叉测试总可以分解为几组两个模块间的交叉测试，复杂的交叉情况本质上都可以化简为两两交叉的简单情况，反过来，用简单的两两交叉及它们的组合情况又可以组合出或近似等效于复杂的三个模块以上的交叉情况”，所以，我们在进行交叉测试设计时，只需要考虑两两交叉这一种简单情况。

基于上述“化繁为简”理论分析，在之后的交叉测试设计中，我们就只会仅考虑两两交叉简单情况而不再考虑其它的复杂交叉情况。这是没有问题的，不会导致交叉测试设计的不完整。在后续具体实施和使用本发明方法时，我们不会也不必每次都证明一次上述理论分析的正确性(本分析步骤也不会出现在使用流程图中)，而是直接使用该结论进行模块间两两交叉的测试设计即可。

在具体使用本发明方法思路来进行嵌入式模块的交叉测试设计时，又依是否是首次进行交叉关联的系统化分析设计，可以分成主要有如下2种情况：

情况1：首次进行交叉关联的系统化分析设计

因为在首次进行系统化分析之前，相应表格的分析工具尚不存在，模块间的关联未全面分析过，也未使用过一定的缩减策略和原则对初步的交叉用例集做缩减，也没有为每一个交叉用例进行交叉深度和强度的策略选择，所以，在情况1下，需要从0开始进行两两交叉的测试设计，具体步骤如下：

1、对系统中所有模块进行分类，使用关联矩阵这一工具来建立完整的《模块间交叉关联矩阵》。

1.1、将众多的模块进行更高层次的抽象与分类有利于简化后续的设计分析，以便于我们从中分析并发现一些普适的规律，如，某类模块与另一类模块通常需要考虑进行交叉测试的设计、某类模块与其它类模块通常都不需要考虑进行交叉测试的设计等。同时，因为同类别的模块往往具备一些共性，于是，可以以“模块类别”这种大颗粒度的视角进行与其它“模块类别”的交叉测试设计，有利于交叉测试用例数量的缩减，提高了测试设计与测试用例的复用度。这里，我们以POS机这种嵌入式产品为实例来说明上述过程。我们对POS现有功能模块进行更高层次的抽象和分类，把模块分成“识别类”、“通讯类”、“未归类”、“基础模块”、“纯软件类(算法、协议等)”。这样一来，我们从“识别类”和“通讯类”的各模块中将功能接近的接口抽象为更高层次的接口，就构建出“识别类”和“通讯类”的大类之间的交叉测试用例。在使用时，通过相应的配置函数将“识别类”和“通讯类”配置成具体的功能模块，就可以实现识别类具体模块和通讯类具体模块之间的多个具体的交叉测试，达到了“设计一个测试用例，却可以复用多种具体场景的交叉测试”的目的，减少了用例数量，提高了用例的复用度。

1.2、交叉测试设计中的关联矩阵称为“交叉关联矩阵”，我们在横纵方向上都建立所有“模块类别+该类下具体模块”的轴线，就得到了该完整的所有模块的交叉关联矩阵(可借助excel表格工具来建矩阵)。仍以POS机为例，可以得到类似的关联矩阵图，如图2所示：

2、《模块间交叉关联矩阵》中，按照交叉测试用例缩减策略1，分析并确定参与两两交叉的模块类别及具体模块，得到原始的交叉测试用例集。

2.1、交叉测试用例缩减策略1，如下(以下为了描述方便，我们均假设系统中有n个不同的模块)：

2.1.1、从关联矩阵角度说，在横纵方向上分别有n个模块时，需要分析的情况数共有n*n，但矩阵对角线上的两两模块实际为某个模块与自身的“交叉”，并非真正的“模块两两交叉”，故矩阵对角线不予考虑。同时，还注意到矩阵平面上(N，M)的交叉组合情况实际上与(M，N)的情况依对角线对称，因为我们考虑的是不讲究顺序的“组合”情况，而不是讲究顺序的“排列”情况，故视(N，M)和(M，N)为同一种交叉组合。所以，我们使用关联矩阵来做交叉测试设计时，不要去分析对角线及下三角(或上三角)的情况。即，经过这里的策略分析，可以将原矩阵中n*n种两两组合情况缩减为n*(n-1)/2种情况(由排列组合公式n！/((n-2)！*2！)也可化简到这个结论)，缩减率达(n+1)/2n(即50％以上)。

到此，我们似乎还需要为系统中大约n*n/2种组合情况来做交叉测试设计，但事实上，我们仍可以做进一步缩减。

2.1.2.特别在嵌入式系统中，根据嵌入式系统与硬件紧密相关等特点，交叉测试设计一般多考虑可能存在相互干扰影响的外设模块，而不考虑独立的纯软件模块(如，算法、协议等)，即对于在步骤1中我们对模块分出的“纯软件类”，我们一般不会考虑它们与其它模块的交叉测试，而由其它测试方法(如，模块级单元测试、压力测试、性能测试等)去保证它们的质量就够了。通过构建完整关联矩阵图可以得出，纯软件类内部各模块之间以及该类与其它模块类之间，矩阵上相应关联位置都被标上X的记号(表示不考虑交叉测试的设计)。

2.1.3.类似地，“基础模块类”也是不必太多地考虑它们与其它模块类的交叉使用的。这类模块由于在日常使用中，使用得非常频繁(不论是显式使用还是隐式使用)，它们是整个系统的基础，在其它类模块工作时，事实上，它们也在工作着，于是对其它类模块进行单独使用的情况就可以视为是其它类模块与“基础模块类”共同工作的情况，于是也就不必再专门考虑其它模块类与“基础模块类”之间进行显式的交叉测试设计了。如，液显、键盘、串口、文件系统、(文件型)软FRAM、(文件型)软ESAM、rtc等，这些可视为基础模块。通过构建完整关联矩阵图可以得出，基础模块类内部各模块之间以及该类与其它模块类之间，矩阵上相应关联位置绝大多数都被标上X的记号(表示不考虑交叉测试的设计)。在步骤3给的策略中，我们到时还会对本步骤缩减的用例集做分析、调整、修正，对少部分需要考虑交叉使用的情况再标上√(表示需要考虑交叉测试的设计)。

正是因为步骤2.1.2和2.1.3所提及的“纯软件类”和“基础模块类”的存在以及我们处置它们的策略，使得交叉用例集在步骤2.1.1基础上进一步大大地缩减了。缩减的效果通过构建的完整关联矩阵图可以得出：在整个矩阵中，因为“纯软件类”和“基础模块类”的标黄(表示通常无需考虑它们与其它模块的交叉测试设计)，使得矩阵中标X的地方(表示不考虑交叉测试的设计)的数量大大提高了。

3、在《模块间交叉关联矩阵》中，按照交叉测试用例缩减策略2，对原始的交叉测试用例集进行分析和进一步缩减，得到初步的交叉测试用例集。

在经过了步骤2的缩减后，虽然交叉测试用例已被大幅地缩减了，但随着新模块加入到系统中，系统总模块数n会变大，矩阵也会向横纵向膨胀。以步骤2.1.1推出的“从理论上说，n种不同的模块就需要进行n！/((n-2)！*2！)种交叉测试(即n*(n-1)/2)”结论为基准，n每加1，交叉测试的用例量将会以“n的平方”进行增长(即n每加1，实际增加的最大用例数可达n个(n为增加1个新模块前的系统模块总数))。可见，随着新模块的加入，交叉用例数将快速地增长，加大了交叉测试设计的工作量，加重了相关用例管理的负担。所以，在步骤2基础上，我们仍有必要进行更精细化的缩减。

3.1.交叉测试用例缩减策略2，具体规则如下(以该策略在POS上交叉测试设计为实例)：

3.1.1.过时的或基本不用的模块可以不考虑与其它模块的交叉测试设计，如log、memory卡；

3.1.2.在实际应用场景中，两个模块存在交叉使用的情况，就有必要进行交叉测试设计。在实际应用场景中，不可能出现交叉使用的两两模块组合不考虑交叉测试设计；

3.1.3.若两个模块存在上下层的关系，那么该两个模块也不考虑交叉测试设计。比如，上层模块的功能是通过下层模块的功能来实现，那么，对上层模块进行压力测试等其它系统测试，就必然会交叉地用到上层模块和下层模块，所以，对它们的组合不考虑交叉测试设计；

3.1.4.对外表现为同一接口的两个模块(如，同步MODEM和异步MODEM都可以归纳为MODEM，而二者对外的接口是一样的)，它们之间不考虑交叉测试设计。同理，对于各种无线广域网通讯模块、各种机制的socket模块，也不考虑交叉测试设计，只要在单个模块的系统测试中分别配置各方式或机制后进行系统测试，即可模拟依次使用多种方式或机制的交叉组合情况；

3.1.5.鉴于“步骤2.1.交叉测试用例缩减策略1”中所提及的“纯软件类”与“基础模块类”是不考虑它们与其它模块类或模块进行交叉测试设计的，所以，通过这2个类的功能来实现的模块也不考虑交叉测试设计；

3.1.6.有外设硬件模块或芯片的软件模块，一般应该考虑模块间交叉测试设计(也间接地对硬件切换做了验证)，若不考虑，需要给出理由并通过相关评审；

3.1.7.已明确知道存在硬件复用(如：复用了相同的I/O、硬件引脚、其它介质等)或软件复用(如：存在硬件寄存器、状态变量、全局变量、信号量、中断、内存、文件等其它共享形式)的模块必须考虑交叉测试设计；

3.1.8.已明确知道硬件上存在光、电(压、流、场)、磁(场)、温度、射线等信号干扰的模块必须考虑交叉测试设计(即，虽然不存在共享，但是却对其它模块进行了干扰破坏的情况)；

3.1.9.已知历史上出现过的模块间交叉问题，则相关两两模块必须考虑交叉测试设计。若能给出该历史问题在以后的产品中不会出现的理由(需通过相关评审)，可以不考虑交叉测试设计；

3.1.10.根据历史问题数据分析，一般地，通讯类模块、识别类模块、打印模块之间必须考虑交叉测试设计。即当新增模块属于这三者之一时，必须考虑与另两个模块类别的交叉测试设计，以及与本类其它模块的交叉测试设计；

3.1.11.除上述明确规则外，若不需要进行交叉测试，则需要给出相应的理由，并通过相关评审；

3.1.12.理论上，虽然模块A、B有交叉使用的可能，但实际中实在不存在模块交叉使用的情况，则可不进行交叉测试设计，但需要给出相应的理由，并通过相关评审；

只要我们依据上述的交叉测试用例缩减策略2，对在《模块间交叉关联矩阵》中的两两交叉用例是否需要进行交叉测试设计做分析，交叉测试用例集就会在步骤2的基础上得到进一步的缩减，最终得到初步的交叉测试用例集。

4、对初步的交叉测试用例集的各交叉测试用例的交叉深度和强度进行分析与选择，得到最终的交叉测试用例集。

若没有选对交叉深度和强度，则交叉测试可能仍无法发现问题。总的一句话，“通常，交叉测试要尽可能做到深度交叉，同时要保证一定的强度，才能检出模块间可能存在的干扰影响问题。”

4.1.交叉测试的“深度交叉”是指如果A、B两个模块进行交叉使用，其中，A模块的完整功能由A1、A2、A3等动作完成，B模块的完整功能由B1、B2、B3等动作完成，则依次调用A1、B1、A2、B2、A3、B3…就是“深度交叉”，它保证了在使用某个模块时，另一个模块处于待调用态(功能也是打开的)。所以，“深度交叉”擅长于发现有关联的模块进行并发使用时，对共享资源的切换使用是否正常，同时，它也能发现在前一个模块使用完毕完全退出后，对之前占用的资源是否释放得完全，是否释放得及时，是否释放得恰当等等情况。相应地，依次调用A1、A2、A3…B1、B2、B3…就是“浅度交叉”，因为B模块是在A模块使用完毕完全退出后，才开始进行使用。所以，“浅度交叉”只能发现在前一个模块使用完毕完全退出后，对其它也共享相关资源的模块是否有影响。正是因为“深度交叉”可以比“浅度交叉”发现更多的BUG，所以，在交叉测试设计上只要有条件，应尽可能采用“深度交叉”策略，只有在相关模块已显式声称不支持“深度交叉”的使用方式的情况下，才采用“浅度交叉”策略。

4.2.交叉测试的强度设计参考一般性压力测试的强度设计即可。由于模块间可能存在的干扰影响问题未必通过一次的交叉使用就暴露出来，所以，强调交叉测试也要有一定的强度，但这个强度要求也远小于一般性压力测试的强度要求，实际经验显示：如果某模块存在一些深层次的问题，那么，通过压力测试的方法，可能需要运行1000次才能暴露出来(也可能因为压力强度不够而暴露不了)；通过交叉测试的方法，一般只需要运行10次就能暴露出来。这表明交叉测试在检错效率和效果方面优于压力测试。

我们将情况1上述操作的主要步骤用流程图3来表达。

情况2、非首次进行交叉关联的系统化分析设计

因为是非首次进行交叉关联的系统化分析，所以，使用交叉测试用例缩减策略1&2缩减过的用例集矩阵已存在了。故在这种情况下，如果有新增模块，我们可以在之前分析设计的基础上进行增量式的两两交叉测试设计，具体步骤如下：

1、将新增模块归为某一类，加到现有的《模块间交叉关联矩阵》的横纵轴上，就会得到类似图4的矩阵(图中假设新增模块归属于“识别类”)：

2、使用情况1中步骤2所述的“交叉测试用例缩减策略1”对上面的矩阵进行“去对角线”和“去下三角”的处理，就得到了图5的矩阵：

3、使用情况1中步骤3所述的“交叉测试用例缩减策略2”，逐一分析新增模块与现存模块的关系，并将“是否要进行交叉测试设计”的结果标记在上图中浅绿底的空白格子上，就得到了图6的矩阵：

图6(部分的关联矩阵，而非完整的)所示的效果显示：新增模块与无线模块需要考虑交叉测试设计，而与其它之间不考虑交叉测试设计。

4、至于因新增模块而产生的新的交叉测试用例的交叉深度和强度的设计与情况1中步骤4的作法是一样的，参照那里的作法即可。

综上本发明方法具有以下优点：

设计方法系统化且有章可循：本发明方法是一种系统化方法，按照科学的思维、工具、法则以及合理的步骤来进行交叉测试的设计。既避免了“随意设计”带来的“想到哪就写到哪，在系统模块数上升，模块组合数爆炸式地增长时，难免出现遗漏或冗余”的情况，也避免了“过度设计”带来的“全部排列组合都测试，虽然测试完全，在实际中却往往因为没有那么多测试时间而欠可行性，在某种程度上，不加分析地“穷举”也是一种测试浪费”等问题。良好的系统化的测试设计保障了下一阶段具体测试(脚本或用例)实现的质量，也减少了最终测试实施的工作量，使得交叉测试的“又快又好”优势得以体现；

保证交叉测试用例集是正确的：本发明的设计方法既强调了交叉测试的交叉深度要以“深度交叉”优先，也强调了交叉测试要保证一定的交叉强度。这一设计原则保证了所设计出的交叉用例是有效的、正确的；

保证交叉测试用例集是完备的：系统中全部模块都会被列到关联矩阵中，同时，在借助《模块间交叉关联矩阵》来找出某个模块与其它模块的交叉组合结果时，会在矩阵的横纵2个方向上把所有相关组合都做一遍YesOrNo(√或X)的分析判断，确保了不会造成测试设计的遗漏，保证了测试设计的完备性；

保证交叉测试用例集是最小化的/最简的：不论从情况1还是情况2所列举的实例及数据来看，本发明的设计方法在交叉用例缩减方面的效果是很显著的。上述情况1中的1.2所展示的交叉关联矩阵为例(n＝36，即36个模块)，全矩阵有36*36＝1296种两两组合情况，经过“交叉测试用例缩减策略1”的缩减，得到原始的交叉测试用例数为36*35/2＝630种两两不重复组合情况，经过“交叉测试用例缩减策略2”的缩减，得到初步的/最终的交叉测试用例数为67种，即用例缩减率达(630-67)/630*100％＝89.37％。若在交叉测试用例的具体实现阶段，使用了抽象与复用等技术(不在本文中提及)，则最终的用例缩减率甚至可达95％左右。可见，本发明方法设计出的交叉测试用例集是最小的/最简的；

可扩展性：本发明方法充分考虑到了当系统扩展、模块新增时的情况，基于已有交叉测试设计(模块关联矩阵)的基础上，可以轻松地分析并设计出相应的交叉测试用例。

以上是本发明的较佳实施例，凡依本发明技术方案所作的改变，所产生的功能作用未超出本发明技术方案的范围时，均属于本发明的保护范围。

Claims (1)

1.一种嵌入式模块交叉测试的系统化设计方法，其特征在于：包括如下步骤，

S1：对嵌入式系统中所有模块进行分类或归类，建立完整的模块间交叉关联矩阵；

S2：按照第一步交叉测试用例缩减策略，分析并确定参与两两交叉的模块类别及具体模块，得到原始的交叉测试用例集；

S3：按照第二步交叉测试用例缩减策略，对原始的交叉测试用例集进行分析和进一步缩减，得到初步的交叉测试用例集；

S4：对初步的交叉测试用例集的各交叉测试用例的交叉深度和强度进行分析与选择，得到最终的交叉测试用例集；

所述步骤S1中，是将嵌入式系统中的三个模块以上的复杂的交叉测试分解为若干组两个模块间的交叉测试，从而使得嵌入式系统中所有模块的交叉测试，均分解为两两交叉的交叉测试的组合，而后依据关联矩阵工具，建立完整的模块间交叉关联矩阵；

所述步骤S2，具体实现如下，

设模块间交叉关联矩阵在横纵方向上分别有n个模块，则需要分析的交叉测试情况有n*n种；根据第一步交叉测试用例缩减策略，考虑模块间交叉关联矩阵对角线及模块间交叉关联矩阵交叉组合依对角线对称的情况，将需要分析的n*n种交叉测试情况缩减为n*(n-1)/2种情况；而后将嵌入式系统中属于纯软件类及基础模块类的模块剔除，对交叉测试情况进一步缩减，得到原始的交叉测试用例集；

所述步骤S3，具体实现如下，

根据步骤S2得到的原始的交叉测试用例集，按照第二步交叉测试用例缩减策略，剔除嵌入式系统中包括过时的、基本不用的、不可能交叉使用的、存在上下层关系的、对外表现为同一接口的、通过纯软件类及基础模块类功能实现的模块，从而对原始的交叉测试用例集进一步缩减，得到初步的交叉测试用例集；

按照第二步交叉测试用例缩减策略，还需考虑包括有外设硬件模块或芯片的软件模块、存在硬件复用或软件复用的模块、硬件上存在包括光、电、磁、温度、射线信号干扰的模块、历史上出现过模块间交叉问题的模块，来对原始的交叉测试用例集进行缩减。