整车控制器MIL软件测试规范.docx

1、整车控制器软件MIL测试规范编制：_校对：_审核：_目录1概述12测试设计12.1测试设计的主要内容12.2测试用例设计方法13测试分类23.1测试依据33.2测试需求验证33.3单元测试43.4集成测试63.5系统测试74测试总结81 概述本文档主要描述在产品开发阶段中的测试环节中，需要用到的各种测试要求和方法以及相关规范，包括单元测试、集成测试、系统测试以及一些专项测试。2 测试设计2.1 测试设计的主要内容测试设计是按照一定的编写格式、内容及注意事项编制的文档，为测试人员在测试执行过程提供测试过程、方法、步骤及使用的测试数据，保证测试过程顺利进行。测试设计主要指的是测试用例的设计。一般按

2、照测试关注点的不同，将测试用例分为：“功能类用例”、“流程类用例”、“数据类用例”、“综合类用例”、“非功能测试用例”五大类。其中，“非功能测试”主要包括性能(压力)测试、稳定(可靠)性测试、容灾容难测试、安全性测试及可用性测试等内容。通常在测试用例还包含测试大纲。测试大纲是按一定的逻辑结构对被测试产品功能进行框架性描述，由于其关系到测试用例设计完整性及BUG填写定位准确性的问题，所以是测试设计中的重要环节。可以按照软件系统中大的模块划分，或者软件功能菜单及链接为基础进行大纲的设计。2.2 测试用例设计方法标准的测试用例应包括用例描述、操作过程及数据、测试结果等内容，测试结果通常有“通过/不通

3、过/未测试/不适用”四种情况。黑盒测试中最常用的三种测试用例设计方法如下：1. 边界值分析经验表明，程序在边界值处理方面经常出现问题，一般边界值类用例的设计可考虑如下这些情况：(1) Null：如果碰到空值，程序会如何处理；(2) 最大值，最小值，第一个，最后一个，在这些情况下如何处理；(3) 最大值+1，最小值-1时会怎么样；(4) 循环的边界值：初始值是0 还是1，循环次数是0.count-1 还是1.count 等；(5) 数据库的边界值：数据库表为空等。2. 非法操作大量的测试实践发现，程序在对非法操作处理方面经常出现问题，但对非法操作情况的设计没有固定的方法，需根据项目的实际情况分析

4、。在设计时要充分考虑对目标功能进行特殊操作，遍历程序所有可能分支情况。3. 等价类划分等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的，并合理地假定：测试某等价类的代表值就等于对这一类其他值的测试。等价类划分设计方法是把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少量具有代表性的数据作为测试用例。4. 因果图方法前面介绍的等价类划分方法和边界值分析方法，都是着重考虑输入条件，但未考虑输入条件之间的联系，相互组合等。考虑输入条件之间的相互组合，可能会产生一些新的情况。但要检查输入条件的组合不是一件容易的事情，即使把所有输入

5、条件划分成等价类，他们之间的组合情况也相当多。因此必须考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例。这就需要利用因果图（逻辑模型）。因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。5. 正交表分析法有时候，可能因为大量的参数的组合而引起测试用例数量上的激增，同时，这些测试用例并没有明显的优先级上的差距，而测试人员又无法完成这么多数量的测试，就可以通过正交表来进行缩减一些用例，从而达到尽量少的用例覆盖尽量大的范围的可能性。6. 场景分析方法指根据用户场景来模拟用户的操作步骤，这个比较类似因果图，但是可能执行的深度和可行性更好。7. 功

6、能分析方法功能图方法其实是一种灰盒测试（因其兼有黑盒和白盒测试，所以称为灰盒测度比较体贴）用例设计方法；通常情况一个程序的功能说明通常由动态说明和静态说明组成。动态说明描述了输入数据的次序或转移的次序，静态说明描述了输入条件与输出条件之间的对应关系。用功能图形象地表示程序的功能说明，并机械地生成功能图的测试用例。对于较复杂的程序，由于存在大量的组合情况，因此，仅用静态说明组成的规格说明对于测试来说往往是不够的。必须用动态说明来补充功能说明。8. 错误推测法基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。错误推测方法的基本思想：列举出程序中所有可能有的错误和容易

7、发生错误的特殊情况，根据他们选择测试用例。例如，在单元测试时曾列出的许多在模块中常见的错误。以前产品测试中曾经发现的错误等，这些就是经验的总结。还有，输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行。这些都是容易发生错误的情况。3 测试分类根据测试要求，可以将一个项目的测试分成四个阶段的测试，如下图1：图1测试阶段图在软件测试的阶段，可以搭建五种测试环境：1. 模型在环测试2. 软件在环测试3. 处理器在环测试4. 硬件在环测试5. 真实环境测试系统中的各组成部分按照系统设计进行集成，并按照其系统测试案例进行测试验证。测试的目的是验证系统各组成部分能否正确的进行交互，并满足功能需

8、求和技术安全需求。3.1 测试依据详细设计是模块测试的依据。因此设计人员应向测试人员提供系统需求规格说明书、详细设计方案、系统接口定义、故障代码及处理方案等有关资料。测试人员必须认真阅读，真正弄懂系统需求和详细设计。3.2 测试需求验证本阶段的目标是验证嵌入式软件符合软件安全需求，其所规定的要求和建议如下：1. 软件安全需求的验证需要制定计划，定义再执行。2. 为了验证嵌入式软件实现了软件安全需求，表1列了所需的测试环境。3. 已有的测试案例，例如在软件集成测试阶段使用的可以重用。4. 对于软件安全需求实现的测试需要在目标硬件平台上完成。软件安全需求验证的结果需要考虑下面这些因素来评估：1.

9、和预期结果一致。2. 软件安全需求的覆盖率。3. 成功或失败的标准。表1 验证软件安全需求的测试环境方法安全等级（ASIL）ABCD1a硬件在环测试环境+1bECU网络环境+1c真实车辆+并且，在开始测试之前，需按照测试流程完成以下工作：1. 测试环境、工具和测试软件的建立；2. 测试用例、测试数据和预期的结果的列表。3.3 单元测试软件单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。1. 软件单元测试需按照验证要求来有计划的定义和执行。软件单元测试的对象是具体的软件实现单元，在基于模型的软件开发过程中，软件单元测试的对象是其单元

10、模型。2. 软件单元测试需要按照表2中列的方法进行，以完成以下目标：（1） 检查是否符合软件单元设计的具体要求。（2） 检查是否符合软硬件接口要求。（3） 检查功能是否正确实现。（4） 检查是否有异常功能。（5） 检查软件实现的鲁棒性，比如错误处理效率等。（6） 检查功能所需资源的完整性。3. 软件单元测试中的测试用例需要按照下表3中的方法进行分析设计。4. 软件单元测试中，对于需求的覆盖度、代码的覆盖度都需要进行衡量，具体方法如表4所示。如果覆盖度不够，还需要增加其他测试案例。（1） 代码的覆盖度都可以借助一些软件工具来实现。（2） 如果是基于模型的开发，其软件单元测试需要利用类似的模型的结

11、构化覆盖指标来衡量。（3） 如果通过代码的打桩来进行测试覆盖度的衡量，必须保证打桩的代码和正常的代码的执行功能是一致的。（4） 对于覆盖度衡量目标，都需要给出一个合理理由来表示其不同的级别，对于无法覆盖的代码，可以通过检查等其他方法来进行验证。5. 软件单元测试需要尽可能的在真实的目标环境上执行，如果利用其他环境，则需要评估其与真实环境的差异、源代码和目标代码的差异，分析设计测试案例，以便在接下来的测试阶段中得到执行。（1） 测试环境的不同，会导致源代码或目标代码的不一致，比如不同处理器的位数不一样，会导致编译后的目标代码不一致。（2） 如果能利用目标环境中的相同处理器来运行软件单元测试案例，

12、那是最有效的，但如果不行，则可以用处理器模拟器来代替，否则软件单元测试只能在开发系统中进行测试。（3） 软件单元测试可以在不同的环境中执行，比如模型在环测试(MIL)、软件在环测试(SIL)、处理器在环测试(PIL)、硬件在环测试(HIL)等。（4） 在基于模型的开发系统中，软件单元测试可以在模型级别进行，但模型与代码的执行比较测试必须要做，以保证模型与自动生成的代码的结果一致性。下面是针对软件单元测试需要进行的一些的测试方法。表2软件单元测试用例的设计方法方法安全等级（ASIL）ABCD1a需求分析+1b等价类划分+1c边界值分析+1d错误推导+表3软件单元的测试方法方法安全等级（ASIL）

13、ABCD1a基于需求的测试+1b接口测试+1c故障注入测试+1d资源利用率测试+1e模型和代码的比较测试+表4软件单元测试覆盖度衡量指标方法安全等级（ASIL）ABCD1a语句覆盖度+1b分支覆盖度+1cMC/DC(修正条件/判定覆盖)+项目开发实现过程中，每个程序单元（程序单元的划分视具体开发工具而定，一般定为函数或子模块）调试通过后，要及时进行单元测试。单元测试使用白盒测试方法，根据程序单元的控制流程，争取达到分支覆盖。对于交互式运行的产品，不便于进行自动测试的，可以采用功能测试的方法进行。单元测试针对程序模块，从程序或者模型的内部结构出发设计测试用例。多个模块可以独立进行单元测试。1.

14、单元测试内容包括模块接口测试、局部数据结构测试、路径测试、错误处理测试等。2. 单元测试组织原则一遍根据开发进度安排对已开发完成的单一模块进行测试。3. 单元测试停止标准：完成了所有规定单元的测试，单元测试中发现的bug已经得到修改。3.4 集成测试软件集成和测试主要对实现的各软件模块进行集成，并验证其嵌入式软件实现是否符合软件架构设计。该阶段的要求和建议如下：1. 软件集成计划应该描述层次化的集成单个软件单元进软件组件中，直到嵌入式软件完全集成，并且应该考虑如下：（1） 软件集成功能的相互关系。（2） 软件集成和软硬件集成的相互关系。注意：对于基于模型的开发，可以先集成各模型，然后对集成好的

15、模型进行自动代码生成以完成整体软件的集成。2. 软件集成测试的测试对象是软件组件。对于基于模型的开发，测试对象可以是和软件组件相关的模型。3. 软件集成测试需要按照表6的方法进行，以完成以下目标：（1） 检查集成的软件是否和软件架构设计一致。（2） 检查集成的软件是否满足软硬件接口规格。（3） 验证功能的正确性。（4） 检查其鲁棒性，比如错误检测、错误处理机制的有效性。（5） 检查是否有足够的资源来支持。4. 测试用例需要按照表5中的方法进行分析设计。5. 对于软件架构级别的需求测试覆盖度，可以用来衡量测试的完整性，以及用于证明没有设计之外的功能实现。如果有需要，可以增加新的测试案例，或者提供

16、一个合理的理由说明。6. 为了评估测试案例的完整性，同时确保没有多余的功能，根据表7列出的指标需要衡量出其结构覆盖率。如果覆盖率不够高，要么需要添加额外的测试案例，或者提供一个合理的理由说明。例如，结构覆盖率的分析可以用于发现测试案例的不足、无用代码、无效代码或者多余功能等。（1） 结构覆盖率可以利用工具计算出来。（2） 如果是基于模型的开发，结构覆盖率可以通过模型级别的模型结构覆盖率来统一计算。7. 作为产品发布的一部分，嵌入式软件需要被验证其包含设计的所有功能。如果嵌入式软件包含了设计之外的功能(比如用于调试的代码)，则这些功能需要被验证是不影响软件的安全需求的。如果这些设计之外的功能在真

17、实产品中保证不会被激活执行，那也是符合这个要求的;否则删除这些功能，也需要按照需求变更流程来统一处理。8. 软件集成测试需要尽可能地在真实环境中运行，如果不行，则需要评估测试环境与真实环境的差异性，并针对这些差异，在后续的阶段的真实环境的测试中设计专门的案例来执行。（1） 测试环境的不同，会导致源代码或目标代码的不一致，比如不同处理器的位数不一样，会导致编译后的目标代码不一致。（2） 针对各种测试，需要建立合适的测试环境。比如目标处理器的测试环境、仿真处理器的测试环境、开发测试环境等。（3） 软件集成测试可以利用模型在环测试(MIL)、软件在环测试(SIL)、处理器在环测试(PIL)、硬件在环

18、测试(HIL)等测试手段进行测试。表5软件集成测试的测试用例的设计方法方法安全等级（ASIL）ABCD1a需求分析+1b等价类划分+1c边界值分析+1d错误推导+表6软件集成测试方法方法安全等级（ASIL）ABCD1a基于需求的测试+1b接口测试+1c故障注入测试+1d资源利用率测试+1e模型和代码的比较测试+表7软件集成结构覆盖度衡量指标方法安全等级（ASIL）ABCD1a功能覆盖率+1b函数覆盖率+集成测试着重对各功能模块之间的接口进行测试，验证各功能模块是否能协调工作、参数传递及功能调用是否正常。测试采用交叉方法，即个人开发的软件应由其他的项目组成员进行测试。3.5 系统测试在项目开发完

19、成之后，应对整个系统软件和硬件进行系统测试。对性能、可靠性、鲁棒性、压力承受力等方面分别进行评价，以验证系统是否满足规定的需要。系统测试一般进行如下几种情况的测试：1. 正常情况2. 非正常情况3. 破坏性测试4. 边界情况5. 非法情况6. 强度测试7. 性能测试8. 兼容性测试输入值测试：1. 数据类型2. 数据长度3. 约束条件是否满足，是否完整4. 故障注入测试4 测试总结在软件的所有模块达到测试通过准则后，需要对测试工作进行总结并编制测试总结报告。测试总结报告的主要内容包括并不限于：1. 测试的策略、测试环境、测试人员、时间周期、对测试过程及软件质量的评价等内容，对测试总体工作的描述及总结；2. 软件问题统计分析对BUG进行分类统计；3. 遗留问题分析将测试遗留下来的问题整理到遗留分析表中，已备以后查看；4. 测试结束检查所做的测试工作及完成情况，检查提交的工作成果，包括：测试文档、可执行程序等。第9页共8 页