S22H73整车控制软件设计规范.docx

S22H73整车控制软件设计规范.docx

《S22H73整车控制软件设计规范.docx》由会员分享，可在线阅读，更多相关《S22H73整车控制软件设计规范.docx（17页珍藏版）》请在冰豆网上搜索。

S22H73整车控制软件设计规范

Q/XX

XX公司企业标准

Q/XX

整车控制软件设计规范

版本：

受控号：

20XX-XX-XX发布20XX-XX-XX实施

XX有限公司发布

文档修订记录表

版本号

修订标记及内容

修订人员

时间

备注

A0

初稿

1.前言

1.1.适用范围

本文档适用于XX有限公司电动车整车控制软件设计开发项目，用于指导和约束设计和开发人员的工作。

1.2.概述

软件设计是把需求转化为软件系统的最重要的环节，系统设计的优劣在根本上决定了软件系统的质量。

在此，主要阐述软件系统设计的5个核心内容：

体系结构设计、用户界面设计、数据库设计、模块设计、数据结构和算法设计。

旨在帮助开发人员搞清楚“设计什么”以及“如何设计”。

一般把设计过程划分为两个阶段：

概要设计阶段和详细设计阶段。

概要设计阶段的重点是体系结构设计；详细设计阶段的重点是用户界面设计、数据库设计、模块设计、数据结构与算法设计等。

可根据项目的情况进行文档裁减和过程合并，如项目开发过程只有一个设计阶段和设计文档。

软件设计部分主要可分为功能模块的程序设计和总体的功能实现，实际上功能模块的程序设计是可以与硬件设计部分同时进行的。

功能模块的程序主要就是实现各个功能模块的驱动程序，例如串行通信、键盘、液晶显示等。

这部分程序实验室很大一部分是有基础的，可以在参考的基础上进行相应的改动。

总体功能的实现就需求方最终的产品功能，就是按照需求分析的结果来进行程序设计。

在程序设计上需要安装一定的规范来编写，如头文件的合理安排、一行的长度、注释声明等的规范，具体请参见详细的软件设计规范。

需要注意的是，在项目交付前，必须检查以下工作是否已经完成：

1.考虑热复位和冷复位，防止死机现象，即使是有休眠状态的设备也要考虑该问题。

在重要的阶段将变量值写到flash。

冷复位（Restart）：

单片机从没加电到加上电源，而自动产生的复位称为冷复位。

热复位（Reset）：

单片机在已经通电的情况下，给它一个复位信号，称为热复位。

冷复位会使单片机的特殊功能寄存器（SFR）和数据存储器（RAM）的内容都改变；而热复位只是特殊功能寄存器（SFR）的内容改变而单片机的内部数据存储器（RAM）的内容不变。

2.在程序合适的地方加看门狗。

3.重视对一些特殊的模块定期做初始化，如LCD、LED、IC卡和时钟模块等。

4.在适当的时间将整个系统人工复位一下。

5.充分利用指示灯，如运行、故障、报警指示灯等；充分利用显示器件，如LCD等。

在主循环之前就要对指示灯进行干预。

6.加上保密字节。

1.2.1.体系结构

体系结构如同人的骨架。

目前业界比较流行的软件结构模式有C/S（客户/服务器）、B/S（BROWSE/SERVER）、层次结构（上下级层次结构、顺序相邻的层次结构、含中间件的层次结构）

1.2.1.1.体系结构设计原则

1.合适性

即体系结构是否适合于软件的“功能性需求”和“非功能性需求”。

高水平的设计师高就高在“设计出恰好满足客户需求的软件，并且使开发方和客户方获取最大的利益，而不是不惜代价设计出最先进的软件。

2.结构稳定性

详细设计阶段的工作如用户界面设计、数据库设计、模块设计、数据结构与算法设计等等，都是在体系结构确定之后开展的，而编程和测试则是更后面的工作，因此体系结构应在一定的时间内保持稳定。

软件开发最怕的就是需求变化，但“需求会发生变化”是个无法逃避的现实。

人们希望在需求发生变化时，最好只对软件做些皮毛的修改，尽量不要改动软件的体系结构。

如果当需求发生变化时，程序员不得不去修改软件的体系结构，那么这个软件的系统设计是失败的。

高水平的设计师应当能够分析需求文档，判断出哪些需求是稳定不变的，哪些需求是可能变动的。

于是根据那些稳定不变的需求设计体系结构，而根据那些可变的需求设计软件的“可扩展性”。

3.可扩展性

可扩展性是指软件扩展新功能的容易程度。

可扩展性越好，表示软件适应“变化”的能力越强。

可扩展性越来越重要，这是由现代软件的商业模式决定的：

社会的商业越发达，需求变化就越快。

需求变化必将导致修改（或者扩展）软件的功能，现代软件的规模和复杂性要比十年前的大得多（对比一下操作系统的变化就明白了），如果软件的可扩展性比较差的话，那么修改（或者扩展）功能的代价会很高。

现代软件产品通常采用“增量开发模式”，开发商不断地推出软件产品的新版本，从而不断地获取增值利润。

如果软件的可扩展性比较差的话，每次开发新版本的代价就会很高。

虽然开发商抓住了商机，但却由于设计水平差而导致没有赚取多少利润，真是要活活气死。

4.可复用性

由经验可知，通常在一个新系统中，大部分的内容是成熟的，只有小部分内容是创新的。

一般地可以相信成熟的东西总是比较可靠的（即具有高质量），而大量成熟的工作可以通过复用来快速实现（即具有高生产率）。

可复用性是设计出来的，而不是偶然碰到的。

要使体系结构具有良好的可复用性，设计师应当分析应用域的共性问题，然后设计出一种通用的体系结构模式，这样的体系结构才可以被复用。

2.针对整车控制软件的设计规范

2.1.目的和范围

本文档是测试团队的日常工作规范，本规范是对项目软件测试的一份指导性文件，对软件测试过程中所涉及到的测试理论、测试类型、测试方法、测试标准、测试流程以及软件产品开发单位所承担的职责进行总体规范，以有效保证软件产品的质量。

2.2.测试范围

本文档主要描述在产品开发阶段中的测试环节中，需要用到的各种测试要求和方法以及相关规范，包括单元测试、集成测试、系统测试以及一些专项测试。

2.3.测试设计

2.3.1.测试设计的主要内容

测试设计是按照一定的编写格式、内容及注意事项编制的文档，为测试人员在测试执行过程提供测试过程、方法、步骤及使用的测试数据，保证测试过程顺利进行。

测试设计主要指的是《测试用例》的设计。

一般按照测试关注点的不同，将测试用例分为：

“功能类用例”、“流程类用例”、“数据类用例”、“综合类用例”、“非功能测试用例”五大类。

其中，“非功能测试”主要包括性能（压力）测试、稳定（可靠）性测试、容灾容难测试、安全性测试及可用性测试等内容。

通常在《测试用例》还包含测试大纲。

测试大纲是按一定的逻辑结构对被测试产品功能进行框架性描述，由于其关系到测试用例设计完整性及BUG填写定位准确性的问题，所以是测试设计中的重要环节。

可以按照软件系统中大的模块划分，或者软件功能菜单及链接为基础进行大纲的设计。

2.3.2.测试用例设计方法

标准的测试用例应包括用例描述、操作过程及数据、测试结果等内容，测试结果通常有“通过/不通过/未测试/不适用”四种情况。

黑盒测试中最常用的三种测试用例设计方法如下：

2.3.2.1.边界值分析

经验表明，程序在边界值处理方面经常出现问题，一般边界值类用例的设计可考虑如下这些情况：

1.Null：

如果碰到空值，程序会如何处理；

2.最大值，最小值，第一个，最后一个，在这些情况下如何处理；

3.最大值+1，最小值-1时会怎么样；

4.循环的边界值：

初始值是0还是1，循环次数是0..count-1还是1..count等；

5.数据库的边界值：

数据库表为空等。

2.3.2.2.非法操作

大量的测试实践发现，程序在对非法操作处理方面经常出现问题，但对非法操作情况的设计没有固定的方法，需根据项目的实际情况分析。

在设计时要充分考虑对目标功能进行特殊操作，遍历程序所有可能分支情况。

2.3.2.3.等价类划分

等价类是指某个输入域的子集合。

在该子集合中，各个输入数据对于揭露程序中的错误都是等效的，并合理地假定：

测试某等价类的代表值就等于对这一类其他值的测试。

等价类划分设计方法是把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少量具有代表性的数据作为测试用例。

2.3.2.4.因果图方法

前面介绍的等价类划分方法和边界值分析方法，都是着重考虑输入条件，但未考虑输入条件之间的联系，相互组合等。

考虑输入条件之间的相互组合，可能会产生一些新的情况。

但要检查输入条件的组合不是一件容易的事情，即使把所有输入条件划分成等价类，他们之间的组合情况也相当多。

因此必须考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例。

这就需要利用因果图（逻辑模型）。

因果图方法最终生成的就是判定表。

它适合于检查程序输入条件的各种组合情况。

2.3.2.5.正交表分析法

有时候，可能因为大量的参数的组合而引起测试用例数量上的激增，同时，这些测试用例并没有明显的优先级上的差距，而测试人员又无法完成这么多数量的测试，就可以通过正交表来进行缩减一些用例，从而达到尽量少的用例覆盖尽量大的范围的可能性。

2.3.2.6.场景分析方法

指根据用户场景来模拟用户的操作步骤，这个比较类似因果图，但是可能执行的深度和可行性更好。

2.3.2.7.功能分析方法

功能图方法其实是一种灰盒测试（因其兼有黑盒和白盒测试，所以称为灰盒测度比较体贴）用例设计方法；通常情况一个程序的功能说明通常由动态说明和静态说明组成。

动态说明描述了输入数据的次序或转移的次序，静态说明描述了输入条件与输出条件之间的对应关系。

用功能图形象地表示程序的功能说明，并机械地生成功能图的测试用例。

对于较复杂的程序，由于存在大量的组合情况，因此，仅用静态说明组成的规格说明对于测试来说往往是不够的。

必须用动态说明来补充功能说明。

2.3.2.8.错误推测法

基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。

错误推测方法的基本思想：

列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例。

例如，在单元测试时曾列出的许多在模块中常见的错误。

以前产品测试中曾经发现的错误等，这些就是经验的总结。

还有，输入数据和输出数据为0的情况。

输入表格为空格或输入表格只有一行。

这些都是容易发生错误的情况。

2.4.测试分类

根据测试要求，可以将一个项目的测试分成四个阶段的测试，如下图1：

图1测试阶段图

在软件测试的阶段，可以搭建五种测试环境：

模型在环测试

软件在环测试

处理器在环测试

硬件在环测试

真实环境测试

系统中的各组成部分按照系统设计进行集成，并按照其系统测试案例进行测试验证。

测试的目的是验证系统各组成部分能否正确的进行交互，并满足功能需求和技术安全需求。

2.5.测试依据

详细设计是模块测试的依据。

因此设计人员应向测试人员提供《系统需求规格说明书》、《详细设计方案》、《系统接口定义》、《故障代码及处理方案》等有关资料。

测试人员必须认真阅读，真正弄懂系统需求和详细设计。

2.6.测试需求验证

本阶段的目标是验证嵌入式软件符合软件安全需求，其所规定的要求和建议如下：

1.软件安全需求的验证需要制定计划，定义再执行。

2.为了验证嵌入式软件实现了软件安全需求，表1列了所需的测试环境。

3.已有的测试案例，例如在软件集成测试阶段使用的可以重用。

4.对于软件安全需求实现的测试需要在目标硬件平台上完成。

5.软件安全需求验证的结果需要考虑下面这些因素来评估：

6.和预期结果一致；

7.软件安全需求的覆盖率；

8.成功或失败的标准。

表1验证软件安全需求的测试环境

方法

安全等级（ASIL）

A

B

C

D

1a

硬件在环测试环境

+

+

++

++

1b

ECU网络环境

++

++

++

++

1c

真实车辆

++

++

++

++

并且，在开始测试之前，需按照测试流程完成以下工作：

1.测试环境、工具和测试软件的建立；

2.测试用例、测试数据和预期的结果的列表。

3.单元测试

软件单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

3.1.测试步骤

软件单元测试需按照验证要求来有计划的定义和执行。

软件单元测试的对象是具体的软件实现单元，在基于模型的软件开发过程中，软件单元测试的对象是其单元模型。

3.2.测试目标

软件单元测试需要按照表2中列的方法进行，以完成以下目标：

3.2.1.检查是否符合软件单元设计的具体要求；

1.检查是否符合软硬件接口要求；

2.检查功能是否正确实现；

3.检查是否有异常功能；

4.检查软件实现的鲁棒性，比如错误处理效率等；

5.检查功能所需资源的完整性。

3.2.2.测试用例

软件单元测试中的测试用例需要按照下表4中的方法进行分析设计。

3.2.3.测试方法

软件单元测试中，对于需求的覆盖度、代码的覆盖度都需要进行衡量，具体方法如表3所示。

如果覆盖度不够，还需要增加其他测试案例。

代码的覆盖度都可以借助一些软件工具来实现；

1.如果是基于模型的开发，其软件单元测试需要利用类似的模型的结构化覆盖指标来衡量；

2.如果通过代码的打桩来进行测试覆盖度的衡量，必须保证打桩的代码和正常的代码的执行功能是一致的；

3.对于覆盖度衡量目标，都需要给出一个合理理由来表示其不同的级别，对于无法覆盖的代码，可以通过检查等其他方法来进行验证。

3.2.4.测试环境

软件单元测试需要尽可能的在真实的目标环境上执行，如果利用其他环境，则需要评估其与真实环境的差异、源代码和目标代码的差异，分析设计测试案例，以便在接下来的测试阶段中得到执行。

1.测试环境的不同，会导致源代码或目标代码的不一致，比如不同处理器的位数不一样，会导致编译后的目标代码不一致。

2.如果能利用目标环境中的相同处理器来运行软件单元测试案例，那是最有效的，但如果不行，则可以用处理器模拟器来代替，否则软件单元测试只能在开发系统中进行测试。

3.软件单元测试可以在不同的环境中执行，比如模型在环测试（MIL）、软件在环测试（SIL）、处理器在环测试（PIL）、硬件在环测试（HIL）等。

4.在基于模型的开发系统中，软件单元测试可以在模型级别进行，但模型与代码的执行比较测试必须要做，以保证模型与自动生成的代码的结果一致性。

下面是针对软件单元测试需要进行的一些的测试方法。

表2软件单元测试用例的设计方法

方法

安全等级（ASIL）

A

B

C

D

a

需求分析

++

++

++

++

b

等价类划分

+

++

++

++

c

边界值分析

+

++

++

++

d

错误推导

+

+

+

+

表3软件单元的测试方法

方法

安全等级（ASIL）

A

B

C

D

a

基于需求的测试

++

++

++

++

b

接口测试

++

++

++

++

c

故障注入测试

+

+

+

++

d

资源利用率测试

+

+

+

++

e

模型和代码的比较测试

+

+

++

++

表4软件单元测试覆盖度衡量指标

方法

安全等级（ASIL）

A

B

C

D

1a

语句覆盖度

++

++

+

+

1b

分支覆盖度

+

++

++

++

1c

MC/DC（修正条件/判定覆盖）

+

+

+

++

项目开发实现过程中，每个程序单元（程序单元的划分视具体开发工具而定，一般定为函数或子模块）调试通过后，要及时进行单元测试。

1.单元测试使用白盒测试方法，根据程序单元的控制流程，争取达到分支覆盖。

对于交互式运行的产品，不便于进行自动测试的，可以采用功能测试的方法进行。

2.单元测试针对程序模块，从程序或者模型的内部结构出发设计测试用例。

多个模块可以独立进行单元测试。

3.单元测试内容包括模块接口测试、局部数据结构测试、路径测试、错误处理测试等；

4.单元测试组织原则一遍根据开发进度安排对已开发完成的单一模块进行测试；

5.单元测试停止标准：

完成了所有规定单元的测试，单元测试中发现的bug已经得到修改。

3.3.集成测试

软件集成和测试主要对实现的各软件模块进行集成，并验证其嵌入式软件实现是否符合软件架构设计。

该阶段的要求和建议如下：

3.3.1.软件单元测试

软件集成计划应该描述层次化的集成单个软件单元进软件组件中，直到嵌入式软件完全集成，并且应该考虑如下：

1.软件集成功能的相互关系；

2.软件集成和软硬件集成的相互关系。

注意：

对于基于模型的开发，可以先集成各模型，然后对集成好的模型进行自动代码生成以完成整体软件的集成。

3.4.软件集成测试

软件集成测试的测试对象是软件组件。

对于基于模型的开发，测试对象可以是和软件组件相关的模型。

3.4.1.软件测试目标

1.软件集成测试需要按照表6的方法进行，以完成以下目标：

2.检查集成的软件是否和软件架构设计一致；

3.检查集成的软件是否满足软硬件接口规格；

4.验证功能的正确性；

5.检查其鲁棒性，比如错误检测、错误处理机制的有效性；

6.检查是否有足够的资源来支持。

3.4.2.软件测试用例

测试用例需要按照表5中的方法进行分析设计。

3.4.3.软件测试范围

对于软件架构级别的需求测试覆盖度，可以用来衡量测试的完整性，以及用于证明没有设计之外的功能实现。

如果有需要，可以增加新的测试案例，或者提供一个合理的理由说明。

3.4.4.测试结果评价

为了评估测试案例的完整性，同时确保没有多余的功能，根据表7列出的指标需要衡量出其结构覆盖率。

如果覆盖率不够高，要么需要添加额外的测试案例，或者提供一个合理的理由说明。

例如，结构覆盖率的分析可以用于发现测试案例的不足、无用代码、无效代码或者多余功能等。

结构覆盖率可以利用工具计算出来。

如果是基于模型的开发，结构覆盖率可以通过模型级别的模型结构覆盖率来统一计算。

3.4.5.功能性测试

作为产品发布的一部分，嵌入式软件需要被验证其包含设计的所有功能。

如果嵌入式软件包含了设计之外的功能（比如用于调试的代码），则这些功能需要被验证是不影响软件的安全需求的。

如果这些设计之外的功能在真实产品中保证不会被激活执行，那也是符合这个要求的；否则删除这些功能，也需要按照需求变更流程来统一处理。

3.4.6.集成环境测试

软件集成测试需要尽可能地在真实环境中运行，如果不行，则需要评估测试环境与真实环境的差异性，并针对这些差异，在后续的阶段的真实环境的测试中设计专门的案例来执行。

1.测试环境的不同，会导致源代码或目标代码的不一致，比如不同处理器的位数不一样，会导致编译后的目标代码不一致。

2.针对各种测试，需要建立合适的测试环境。

比如目标处理器的测试环境、仿真处理器的测试环境、开发测试环境等。

3.软件集成测试可以利用模型在环测试（MIL）、软件在环测试（SIL）、处理器在环测试（PIL）、硬件在环测试（HIL）等测试手段进行测试。

表5软件集成测试的测试用例的设计方法

方法

安全等级（ASIL）

A

B

C

D

1a

需求分析

++

++

++

++

1b

等价类划分

+

++

++

++

1c

边界值分析

+

++

++

++

1d

错误推导

+

+

+

+

表6软件集成测试方法

方法

安全等级（ASIL）

A

B

C

D

1a

基于需求的测试

++

++

++

++

1b

接口测试

++

++

++

++

1c

故障注入测试

+

+

+

++

1d

资源利用率测试

+

+

+

++

1e

模型和代码的比较测试

+

+

++

++

表7软件集成结构覆盖度衡量指标

方法

安全等级（ASIL）

A

B

C

D

1a

功能覆盖率

+

+

++

++

1b

函数覆盖率

+

+

++

++

集成测试着重对各功能模块之间的接口进行测试，验证各功能模块是否能协调工作、参数传递及功能调用是否正常。

测试采用交叉方法，即个人开发的软件应由其他的项目组成员进行测试。

3.5.系统测试

在项目开发完成之后，应对整个系统软件和硬件进行系统测试。

对性能、可靠性、鲁棒性、压力承受力等方面分别进行评价，以验证系统是否满足规定的需要。

系统测试一般进行如下几种情况的测试：

1.正常情况

2.非正常情况

3.破坏性测试

4.边界情况

5.非法情况

6.强度测试

7.性能测试

8.兼容性测试

输入值测试：

1.数据类型

2.数据长度

3.约束条件是否满足，是否完整

4.故障注入测试

4.测试总结

在软件的所有模块达到测试通过准则后，需要对测试工作进行总结并编制《测试总结报告》。

测试总结报告的主要内容包括并不限于：

1.测试的策略、测试环境、测试人员、时间周期、对测试过程及软件质量的评价等内容，对测试总体工作的描述及总结；

2.软件问题统计分析对BUG进行分类统计；

3.遗留问题分析将测试遗留下来的问题整理到遗留分析表中，已备以后查看；

4.测试结束检查检查所做的测试工作及完成情况，检查提交的工作成果，包括：

测试文档、可执行程序等。