基于图的MC／DC最小测试用例集快速生成算法

基于DO-178C机载软件验证过程的研究发布时间：2023-02-22T02:56:10.592Z 来源：《中国科技信息》2022年19期作者：冯义飞荣华[导读] 本文通过对RTCA DO-178C标准机载软件生命周期过程的研究冯义飞荣华中电科航空电子有限公司四川成都 610000摘要:本文通过对RTCA DO-178C标准机载软件生命周期过程的研究，分析了软件验证过程需要开展的活动，并提出了相应的实施方法，对后续机载软件研制过程中如何开展软件验证提供了参考。

关键字:DO-178C软件生命周期软件验证方法软件验证活动Research on Software Verification Process of DO-178CFengyifei Ronghua(CETC Avionics Co., Ltd., Chengdu, Sichuan 610000)Abstract:With the research of the airbornesoftrware life cycle process which focus on DO-178C standard, this paper analyze the software verification activities and the verification method.It will provide referrence for the software verification in the subsequent onboard software development process.KeyWord:DO-178C software life cycle, software verification method, software verification activies1概述随着我国民机的发展，机载软件的验证也变得越来越重要，为了满足适航标准要求，机载软件验证活动则需要基于DO-178C标准开展。

符合ISO 26262的汽车电子软件开发流程董淑成**************************MathWorks中国ISO 26262(2011)高完整性软件开发标准和基于模型的设计01219901995200020052010基于模型设计的应用标准生效的年份DO-178B (1992)NASA-GB-8719.13(2004)IEC 61508(1998)DO-178C（2011）IEC 61508(2010)EN 50128(2001)EN 50128(2011)IEC 61511(2003)软件开发标准里出现基于模型的设计为什么？大纲▪ISO 26262软件开发项目的启动▪符合ISO 26262的软件开发过程软件开发ISO 26262定义的软件开发过程系统集成和测试系统设计软件需求验证软件集成和测试软件单元测试软件单元设计及实现软件需求定义软件架构设计系统测试软件测试软件测试软件测试设计验证设计验证设计验证软件开发ISO 26262的软件项目启动系统集成和测试系统设计软件需求验证软件集成和测试软件单元测试软件单元设计及实现软件需求定义软件架构设计系统测试软件测试软件测试软件测试设计验证设计验证设计验证1.软件开发计划2.软件验证计划3.编程、建模语言的选择4.编码、建模标准5.工具的选择6.工具应用指南建模/编程语言的选择及相关标准▪建模或者编程语言的选择标准–明确的定义–支持嵌入式实时软件和运行时错误处理–支持模块化、抽象及结构化▪语言本身不能涵盖的上述标准应通过相应的指导或开发环境涵盖TopicsASILA B C D 1a Enforcement of low complexity++++++++ 1b Use of Language subsets++++++++ 1c Enforcement of strong typing++++++++ 1d Use of defensive implementation technique O+++++ 1e Use of established design principles+++++ 1f Use of unambiguous graphical representation+++++++ 1g Use of style guides+++++++ 1h Use of naming conventions++++++++▪通常，汽车电子软件选择C语言–基础软件手工编写C代码–控制策略软件通过Simulink建模并自动生成代码C代码•建模/编码标准要涵盖的内容Simulink/Stateflow建模标准▪汽车行业建模标准（MAAB）–专门为汽车行业Simulink用户制定▪高完整性系统建模标准–专门为民航、火车、汽车等高完整性系统建模制定设计工具/验证工具的选择 工具的分类及资质审核TI 2TI 1TD 3TD 1TD 2TCL 3TCL 2TCL 1工具错误的检测工具置信水平高中无/ 低增加审核需求工具的影响ASIL 为TCL2级的资质审核无需额外的资质审核为TCL3级的资质审核工具分类工具资质审核UC 1..n 软件工具有引入错误或者不能检出错误的可能工具的功能/用例TÜV SÜD认证的工具▪Embedded Coder™功能：生产针对嵌入式优化的C和C++代码▪Simulink® Verification and Validation™功能：验证模型和模型生成的代码▪Simulink® Design Verifier™功能：定位设计错误，生成测试用例，并根据需求对设计进行验证▪Polyspace® Client™ for C/C++功能：证明源代码没有运行期错误▪Polyspace® Server™ for C/C++功能：在计算机集群执行代码验证并发布度量开发工具的应用指南▪除了选择开发工具之外，还要提供开发工具的应用指南▪Embedded Coder等工具具有非常详实的用户手册需求分析•模型架构•可实现性•可测性•可追溯•可配置模型建立•建模语言•建模标准•模型复杂度•平台化开发模型验证•建模标准•模型评审•形式化方法验证•功能测试代码实现•数据管理•等效性测试•代码验证•代码集成需求分析•模型架构•可实现性•可测性•可追溯•可配置模型建立•建模语言•建模标准•模型复杂度•平台化开发模型验证•建模标准•模型评审•形式化方法验证•功能测试代码实现•数据管理•等效性测试•代码验证•代码集成汽车电子软件的现状和复杂软件开发的困境▪GM汽车上的代码量▪软件工程师的工作效率▪解决复杂软件开发效率低下的途径–模块化开发模块化的原则和目标▪模块划分的一般原则–从功能上–高内聚–低耦合▪模块划分的目标–简化设计–便于分工–便于测试–便于后期维护▪In order to avoid failures resulting from high complexity, the software architecture design shall exhibit the following properties,–Modularity;–Encapsulation; and–Simplicity.ISO 26262软件架构设计原则▪软件架构设计原则MethodsASILA B C D1a Hierarchical structure of software components++++++++ 1b Restricted size of software components++++++++ 1c Restricted size of interfaces++++ 1d High cohesion within each software component+++++++ 1e Restricted coupling between software components+++++++ 1f Appropriate scheduling properties++++++++ 1g Restricted use of interrupts+++++软件的层次化结构设计▪模块如何划分–从功能上划分组件▪以发动机为例，分为：点火、进气、油量计算、怠速、巡航等▪模型实现上model reference发动机控制点火控制进气计算燃油控制怠速控制巡航控制其他–对复杂组件进一步划分为单元模块▪以发动机的怠速控制为例，分为暖机怠速、闭环速度控制、扭矩请求等单元▪模型实现上model reference系统级组件级单元级单元模块的设计不建议使用Model Reference.基于模型的嵌入式软件开发需求分析•模型架构•可实现性•可测性•可追溯•可配置模型建立•建模语言•建模标准•模型复杂度•平台化开发模型验证•建模标准•模型评审•形式化方法验证•功能测试代码实现•数据管理•等效性测试•代码验证•代码集成Simulink建模语言▪使用建模语言的子集▪Simulink和Stateflow之间的选择–如果算法是复杂的逻辑运算，使用Stateflow；–如果算法主要是数据运算，使用Simulink；▪Stateflow的flow chart和state chart之间的选择–如果算法本质上是计算工作状态或者离散状态，使用state chart；–如果算法本质上是if-then-else结构，使用flow chart或者真值表；ISO 26262软件单元的设计原则▪Example: Parallel states should not appear at the top level of a state-chart.--Misra Modeling GuidelineMethodsASILABCD1a One entry and one exit point in subprograms and functions++++++++1b No dynamic objects or variables, or else online test during their creation +++++++1c Initialization of variables++++++++1d No multiple use of variable names+++++++1e Avoid global variables or else justify their usage ++++++………1h No hidden data flow or control flow +++++++1jNo recursions++++++▪软件单元的设计和实现原则模型复杂度监测对单元模块进行复杂度监测–Model advisor–圈复杂度Simulink模型的平台化开发▪Model Variants–通过配置不同的参数选择不同的被引用模型–比如，K_Param== CLASS_A，选择Model_A.mdl；K_Param== CLASS_B，选择Model_B.mdl–支持生成条件编译的代码▪System Variants基于模型的嵌入式软件开发需求分析•模型架构•可实现性•可测性•可追溯•可配置模型建立•建模语言•建模标准•模型复杂度•平台化开发模型验证•建模标准•模型评审•形式化方法验证•功能测试代码实现•数据管理•等效性测试•代码验证•代码集成软件开发ISO 26262定义的软件开发过程系统集成和测试系统设计软件需求验证软件集成和测试软件单元测试软件单元设计及实现软件需求定义软件架构设计系统测试软件测试软件测试软件测试设计验证设计验证设计验证MAAB及相关规范的检查▪Model Advisor实现建模规范检查▪定制检查集▪定制检查项模型评审▪模型和需求的双向追溯–模型→需求–需求→模型▪Simulink Report Generator生成报告–为非Simulink用户生成报告▪Simulink Report Generator实现不同版本模型比较使用Simulink Design Verifier检查逻辑错误▪设定生成测试用例目标为MC/DC100%覆盖▪生成测试用例▪逻辑错误导致无法生成100%覆盖的测试用例，并提示错误逻辑使用Simulink Design Verifier检查数据错误▪通过算术运算分析定位错误–数据溢出–被零除▪证明没有错误的运算演示Simulink Design Verifier检查错误单元模块的功能测试▪仿真测试▪覆盖率分析模型测试的覆盖率要求▪对单元软件测试的结构覆盖率要求–覆盖率达到分支覆盖率100%–MC/DC 要求▪对软件架构测试的覆盖率要求MethodsASILABCD1a Statement coverage ++++++1b Branch coverage+++++++1cMC/DC (Modified Conditional/Decision Coverage)+++++MethodsASILABCD1a Function coverage ++++++1bCall coverage++++++模型的集成测试▪模型的组件级集成测试▪模型的系统级测试–模型在环测试–快速原型▪不同组件之间的接口测试▪不同组件功能上是否冲突基于模型的嵌入式软件开发需求分析•模型架构•可实现性•可测性•可追溯•可配置模型建立•建模语言•建模标准•模型复杂度•平台化开发模型验证•建模标准•模型评审•形式化方法验证•功能测试代码实现•数据管理•等效性测试•代码验证•代码集成代码生成的前提条件 模型经过充分验证模型符合建模标准功能测试覆盖率足够高模型不含有无效逻辑模型不含有数据错误GenerateCode数据对象和数据字典▪使用数据对象定义数据属性Properties （属性）Classes （类）Package （包）SimulinkSignal DataTypeData Storage ClassMin/Max ParameterData TypeData Storage ClassmodelName = 'f14';dictionaryName = 'myNewDictionary.sldd ‘;dictionaryObj =Simulink.data.dictionary.create(dictionaryName);set_param(modelName,'DataDictionary',dictionaryName);▪使用数据字典管理数据对象数据字典管理数据按照组件划分进行数据管理代码生成工具配置1. 通过系统目标文件设定回调函数2. 在代码生成设置的回调函数里固化设置软件工具除确定id 和版本号之外，还需要确定配置等效性测试▪SIL测试/PIL测试都是等效性测试–验证生成的代码和用于代码生成的模型具有相同的行为属性–PIL除等效性验证之外，还可以用来测量运行时间▪等效性测试的测试用例–功能测试的测试用例–Simulink Design Verifier自动生成▪模型覆盖率和代码覆盖率的比较代码的集成和集成测试▪代码集成的两种方式–单元模型的代码生成，代码级别做集成–模型级别集成，然后生成代码▪软硬件的系统级集成–硬件在环测试–台架测试–实车测试Plant model uController models1s2s3+Plant Model in PC uControllers1s2s3+基于模型的嵌入式软件开发需求分析•模型架构•可实现性•可测性•可追溯•可配置模型建立•建模语言•建模标准•模型复杂度•平台化开发模型验证•建模标准•模型评审•形式化方法验证•功能测试代码实现•数据管理•等效性测试•代码验证•代码集成MathWorksChange the world byAccelerating the paceof discovery, innovation, development, and learningin engineering and science。

基于DO-178的机载软件结构覆盖分析左泽轩;薛战东【摘要】随着民用飞机机载软件的应用越来越广泛，软件复杂程度越来越高，按照DO-178设计保证指南进行机载软件开发逐渐成为行业规范。

机载软件测试是验证过程的关键，对测试结果的覆盖分析中的结构覆盖，DO-178仅提出了相关目标的抽象要求，在工程实际验证软件过程中不便理解和实现。

本文结合适机载软件工程实践，浅析对测试覆盖分析过程的理解。

%With the wider use of airborne software on civil airplane, and its higher complicity, it is gradually becoming a common standard to develop the airborne software according to DO-178 design guidance. Airborne software test is the key method of verification process. But for structural coverage, which is a step of test coverage analysis, only general requirements has been claimed in DO-178, which leads to the inconvenience of understanding and realization for software verification in engineering. In this essay, combined with experience from both suppliers management and communication with airworthiness certification side, test coverage analysis process is explained from engineering side.【期刊名称】《科技视界》【年(卷),期】2016(000)015【总页数】3页(P1-2,25)【关键词】DO-178;机载软件;结构覆盖;MC/DC【作者】左泽轩;薛战东【作者单位】上海飞机设计研究院，中国上海201210;上海飞机设计研究院，中国上海201210【正文语种】中文随着电子信息技术的发展，机载电子设备和机载软件在民用运输飞机上的应用越来越广泛。

Release Notes - VectorCAST 6.1VectorCAST C,C++,Ada (Core)19605: 新的覆盖率选项：针对语句覆盖率进行区域插桩VectorCAST 6.1版本实现了一个新的覆盖率选项叫做“针对语句覆盖率进行区域插桩”，该功能针对应用程序内存有限的用户。

该选项在插桩过程中的覆盖率选项中包含语句覆盖率时或相应的测试等级包含语句覆盖率（如DO-178B 等级B，该等级同时包含语句覆盖率与分支覆盖率）时有效。

设置完毕后，该选项将导致覆盖率插桩生成更小的执行数据，因为VectorCAST将只对连续的代码块的最后一个语句进行插桩以确定语句覆盖率。

中间的语句将被推理为已覆盖，但并不会针对它们生成覆盖率数据，这样最终生成的TESTINSS.DAT文件和插桩后的文件都会更小。

在将VectorCAST的覆盖率从一个环境导入到另一个环境的时候，两个环境插桩过程中的这个选项“针对语句覆盖率进行区域插桩”配置都要是相同的，否则VectorCAST将会提示一个错误，覆盖率不能被成功导入。

该选项目前只针对C和C++源代码文件有效，不能和原有的其他种类插装文件一起使用。

clicast -lc option VCAST_COVER_STATEMENTS_BY_BLOCK True|False默认情况下为False。

22134: 可分离的MDI窗口VectorCAST 6.1版本支持所有的MDI窗口从VectorCAST程序主窗口中分离。

用户现在经常有至少两个到三个显示器或更多，这个新的窗口分离功能允许用户在使用VectorCAST的时候在其他桌面上开辟新的使用区域。

要激活该功能，请针对一组窗口或单个窗口单击新添加的方向按钮。

或者直接双击某标签来分离或结合某MDI窗口。

基于一直以来的情况，VectorCAST MDI 窗口一般按照类型在被包含的窗口中打开。

例如查看每个测试用例都会被包含到一个叫做“测试用例”的窗口中，我们称这些包含窗口为“父窗口”，用户可以从父窗口中分离单独的窗口，或者直接将父窗口分离，一旦这些分离后的窗口重置，独立的窗口将会恢复到父窗口下，父窗口将会返回VectorCAST主程序窗口。

mst检测原理
MST（最小生成树）是用于在一个带权无向连通图中找到一棵生成树，使得树的所有边的权重之和最小。

常用的MST算法有Prim算法和Kruskal算法，下面分别介绍它们的工作原理：
1. Prim算法：
- 选择一个起始节点作为生成树的根节点，并将其加入集合V（已访问节点集合）。

- 在集合V与剩余节点的边中选择一条权重最小的边，并将其对应的节点加入集合V。

- 重复上一步骤，每次选择与集合V中节点相连的权重最小的边，并将对应的节点加入集合V，直到集合V包含了图中的所有节点。

- 最终得到的生成树即为最小生成树。

2. Kruskal算法：
- 将图中的所有边按照权重从小到大进行排序。

- 依次选取权重最小的边，若将该边加入当前的生成树中不会形成回路，则将该边加入生成树。

- 重复上一步骤，直到生成树中包含了图中的所有节点。

- 最终得到的生成树即为最小生成树。

无论是Prim算法还是Kruskal算法，它们的目标都是选择权重最小的边，并构建一个连通的生成树，直到生成树包含了图中的所有节点。

不同之处在于Prim算法是基于节点的选择，而Kruskal算法是基于边的选择。

这两种算法的时间复杂度都与图中的边数E和节点数V相关。

Prim算法适用于稠密图，时间复杂度为O(V^2)或O(VlogV)；Kruskal算法适用于稀疏图，时间复杂度为O(ElogE)或O(ElogV)。

MST算法在网络设计、电力传输网络、路径规划等领域有广泛的应用，通过构建最小生成树，可以实现高效的资源利用、减少成本和提升系统性能。

2022年嵌入式系统设计师下午真题卷2022年嵌入式系统设计师下午真题卷问答题（共5题，共5分）1.阅读以下关于数据采集与处理系统的说明，回答下列问题。

[说明] 某公司承接了一个数据采集与处理系统的项目，由刘工负责系统的方案设计，刘工的设计方案如图1所示。

该方案是基于PCI总线的多功能处理系统，PCI设备1是以太网，PCI设备2用于数据采集，PCI设备3、PCI设备4用于和该系统中的其他处理模块进行互联，LEGACY设备1、LEGACY设备2用于处理系统中一些慢速设备。

1、在以下描述PCI总线的基本概念中，正确的表述有______、______、______、______、______、______。

A．PCI总线是一个与处理器有关的高速外围总线B．PCI总线的基本传输机制是猝发式传送C．PCI 设备一定是主设备D．PCI的物理地址与其他总线一样，是由内存地址空间和I/O地址组成E．PCI设备的地址译码不能对配置空间直接寻址F．PCI设备识别主要是对开发商代码和设备代码进行识别G．访问配置空间时，PCI桥应提供IDSEL信号以选择PCI设备H．系统中只允许有一条PCI总线I．PCI总线是高速串行总线J．PCI总线有3种桥，即HOST/PCI桥，PCI/PCI桥，PCI/LEGACY桥K．PCI桥是可以把一条总线的地址空间映射到另一条总线的地址空间2、PCI设备2和主CPU之间采用双口RAM方式交换数据，双口RAM是常见的共享式多端口存储器，其最大的特点是存储数据共享。

它允许两个独立的CPU或控制器同时异步访问存储单元。

既然数据共享，就必须存在访问仲裁控制，否则就会出现错误或冲突。

内部仲裁逻辑控制提供以下功能：对同一地址单元访问的时序控制；存储单元数据块的访问权限分配；信令交换逻辑(例如中断信号)等。

两个端口对同一内存操作有4种情况：A．两个端口同时对同一地址单元读出数据；B．两个端口同时对同一地址单元写入数据；C．两个端口不同时对同一地址单元存取数据；D．两个端口同时对同一地址单元，一个写入数据，另一个读出数据。

Tessy —嵌入式软件单元测试/ 集成测试工具Tessy是一款专门针对嵌入式软件进行单元/ 集成测试的工具。

它可以对C/C++ 代码进行单元、集成测试，可以自动化搭建测试环境、执行测试、评估测试结果并生成测试报告，其多样化的测试用例导入生成方式和与测试需求关联的特色，使Tessy 在测试组织和测试管理上也发挥了良好的作用。

目前Tessy广泛应用在汽车电子主流客户中。

主要特点在V 模型开发中，Tessy 主要应用在单元测试和集成测试阶段。

单元测试通过运行代码检测出函数中错误，比如算法错误、接口问题等；集成测试则在单元测试的基础上验证单元之间接口的正确性。

基于越早发现bug 开发成本越低的原则，在进行代码功能验证的过程中，按照V 流程右半部分先完成单元测试再进行集成测试的测试顺序更为有效。

另外，Tessy 也可以满足各类标准（如ISO26262、IEC61508、EN 50128/50129 等）对测试的需求，比如Tessy 可以满足ISO26262 中各等级对单元/ 集成测试的要求，当然Tessy 本身也通过了TUV 的认证，证明该软件是安全可靠的，可以在安全相关的软件研发过程中使用。

主要功能•自动生成测试环境、一键执行及评估结果Tessy 可以自动生成驱动程序、桩函数，帮助测试人员提高单元测试效率。

Tessy 支持一键执行测试，并自动对测试结果进行评估，可生成多种形式的报告。

•便捷的测试用例设计方式除软件界面手动设计测试用例外，Tessy 还支持导入导出多种格式的测试用例。

另外，Tessy 集成了分类树编辑器CTE，有效利用等价类划分以及边界值法，辅助设计出更全面更有效的测试用例。

•高度自动化的回归测试Tessy 通过分析源文件自动识别函数及相关接口，在接口发生变更时，支持通过简便的操作进行测试数据复用，保证便捷有效的回归测试。

•测试覆盖度分析Tessy 提供分支覆盖、修正条件/ 判定覆盖MC/DC（Modified Codition/Decision Coverage）、多条件覆盖MCC(Multiple ConditionCoverage) 等多种覆盖度分析。

软考软件评测师2017年下半年下午题试题一阅读下列C程序，回答问题1至问题3，将解答填入答题纸的对应栏内。

【C程序】Int DoString(char*string){char *argv[100];Int argc=1;while(1) { //1while(*string&& *string!='-')//2,3String++;//4if(!*string) //5break; //6argv[argc]=string;while(*string && *string!="&& *string!='\n'&& *string!= '\t')//7,8,9,10 string++; //11argc++;//12｝return 0; //13｝【问题1】请针对上述C程序给出满足100%DC（判定覆盖）所需的逻辑条件。

【问题2】请画出上述程序的控制流图，并计算其控制流图的环路复杂度V（G）。

【问题3】请给出问题2中控制流图的线性无关路径。

试题二阅读下列说明，回答问题1至问题3，将解答填入答题纸的对应栏内。

【说明】某银行B和某公司C发行联名信用卡，用户使用联名信用卡刷卡可累计积分，积分累计规则与刷卡金额和刷卡日期有关，具体积分规则如表2-1所示。

此外，公司C的会员分为普通会员、超级会员和PASS会员三个级别，超级会员和PASS会员在刷卡时有额外积分奖励，奖励规则如表2-2所示。

银行B开发了一个程序来计算用户每次刷卡所累积的积分，程序的输入包括会员级别L、刷卡日期D和刷卡金额A，程序的输出为本次积分S。

其中，L为单个字母且大小写不敏感，D由程序直接获取系统日期，A为正浮点数最多保留两位小数，S为整数。

【问题1】（5分）采用等价类划分法对该程序进行测试，等价类表如下表所示，请补充表2-3中空（1）~（5）【问题2】（9分）根据以上等价类表设计的测试用例如下表所示，请补充表2-4中空（1）~（9）【问题3】（6分）如果规定了单次刷卡的积分上限为20000( 即S取值大于等于0且小于等于20000)，则还需要针对S的取值补充一些测试用例。

C++Test9.2简明手册版本：1.0华中数控软件开发部版本说明目录1创建项目 (1)1.1导入V ISUAL S TUDIO 6.0项目来创建C++TEST 项目 (1)1.2导入现有项目到工作空间： (2)2导入测试配置文件 (4)3单元测试的步骤 (5)3.1自动生成测试套件——G ENERATE T EST S UITES (5)3.2生成自动定义/桩函数——G ENERATE S TUBS (6)3.3扩展和修改测试套件——E XTENDING AND M ODIFYING THE T EST S UITES (8)3.4构建测试可执行文件——B UILD T EST E XECUTABLE (9)3.5执行测试用例——R UN U NIT T ESTS (9)3.6复审测试执行结果——R EVIEW T EST E XECUTION R ESULTS (10)3.7复审覆盖率信息——R EVIEWING C OVERAGE I NFORMATION (12)4桩函数介绍 (14)5C++TEST API (15)5.1常用的测试套件/测试用例注册 (15)5.2部分测试用例/桩函数API数据源宏 (15)5.3测试用例后置条件宏 (15)5.4常用的测试用例验证宏 (16)5.5被测试用例驱动的函数 (17)1创建项目1.1导入Visual Studio 6.0 项目来创建C++test 项目1. 选择文件(File)> 新建(New)> 项目(Project)。

2. 选择C++test> 导入Microsoft Visual Studio 6.0 项目。

3. 单击下一步(Next)。

会打开导入Microsoft Visual Studio 6.0 项目向导。

4. 在向导顶部的文本字段中，指定Microsoft Visual Studio 6.0 项目文件(.dsp),Microsoft Visual Studio 6.0 工作空间文件(.dsw)，或者想要让C++test 从中搜索Microsoft Visual Studio 6.0 项目的根目录。

基于IBM RTRT的嵌入式软件单元测试摘要：单元测试是对嵌入式软件进行测试的最低级别的活动，是保障整个测试效果、保证产品质量的基础。

rtrt（rational test realtime）是ibm ratioanl提供的典型嵌入式软件代码级自动化测试工具，可同时对宿主机和目标机进行测试和调试，自动生成测试脚本、测试桩和测试报告。

通过研究应用表明利用rtrt进行嵌入式软件单元测试实现自动化，能大量减少测试工作量，有效提高测试效率和软件质量。

关键词：单元测试；嵌入式软件；rtrt信息技术的飞速发展带动在嵌入式系统中软件越来越多地取代硬件的功能，研究嵌入式软件测试技术用以保证软件质量成为近年来关注的热点。

单元测试作为软件测试过程中的第一阶段，是软件测试的基础，效果会直接影响后期测试；另外，从修复软件缺陷与花费的成本关系考虑，在单元测试阶段修复缺陷将比在后一个阶段发现缺陷节约5~10倍的成本，可见无论从质量还是成本的角度单元测试都是非常关键的。

但在实际测试中，仅依靠人工编写函数并统计分析结果的测试方法已不能满足测试准确性和测试效率的要求，要引进自动化的测试工具。

rtrt是一个跨平台组件和运行时分析测试工具，支持测试的各个阶段，其单元测试自动生成测试用例模板，自动生成测试桩程序，自动运行测试程序，自动生成测试报告。

一、单元测试基本理论（一）单元测试定义单元测试是对每个最小的软件模块进行的正确性检验的测试，在于发现各模块内部可能存在的各种差错。

包含模块接口测试、局部数据结构测试、路径测试、错误处理测试和边界测试，依据详细设计说明书和源程序清单，从程序的内部结构出发设计测试用例。

主要采用白盒测试的测试用例，辅之以黑盒测试，使之对任何合理和不合理的输入，都能鉴别和响应。

（二）单元测试环境单元是软件的基本组成模块，但本身不是一个独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，必须为每个单元测试开发驱动模块和桩模块。

软件线测试方法与软件测试工具----------------------------------------------------------------------------------------------------------------------摘要：本文简要介绍了软件测试基本理论和基本概念，分析软件测试在在产品研发过程中的地位与作用，并依据本人多年嵌入式系统开发应用和从事软件测试的经验，提出了针对我国企业软件测试现状的软件测试解决方案，与此同时向大家介绍了几种高效，实用的软件测试工具。

关键字：嵌入式软件软件测试引言：软件已成为现代智能系统中的核心和灵魂，其规模和复杂性随系统规模增长不断提高，软件的质量和开发周期对产品的最终质量和上市时间有举足轻重的影响力，因此软件工程管理、软件分析与测试已成为研究和应用的热点。

本文结合软件工程管理、软件分析与测试在嵌入式软件的开发中应用经验与体会，指出了现今人们对软件分析与测试应用于产品开发中存在的误区，并针对这一误区，提出了针对我国企业如何根椐自身现状配置软件测试工具及解决方案。

一. 软件分析与测试的作用产品开发包括软硬件的设计和调试，而在整个产品设计所涉及到的各个技术层面中，由于大规模集成电路发展，致使元件的集成度也大大增加，从而为产品硬件设计的模块化和透明化提供了方便，同时，硬件调试与测试的可操作性为产品性能和可靠性的提高提供了保证。

相反，有关软件调试与测试工作则复杂和困难得多，伴随着系统规模增长，其软件复杂性指数式增长，隐藏在软件中的问题就越多，这些问题直接影响了系统性能和可靠性。

一般来讲，软件的开发要经历需求分析、设计、编程和调试、测试几个阶段。

由于分析、设计和编程都由人来完成，软件中的错误在所难免。

软件错误往往会导致无可挽回的、致命的损失，因此软件必须测试，测试必须有效和可行。

软件测试的目的在于充分暴露软件中存在的问题和缺陷，发现其中的错误并提交测试报告，最终排除软件中存在的问题，满足和实现用户的需求。

2022年下半年（下午）《软件评测师》真题2022年下半年（下午）《软件评测师》真题问答题（共5题，共5分）1.某互联网企业开发了一个大型电子商务平台，平台主要功能是支持注册卖家与买家的在线交易。

在线交易的安全性是保证平台上正常运行的重要因素，安全中心是平台上提供安全保护措施的核心系统，该系统的主要功能包括：（1）密钥管理功能，包括公钥加密体系中的公钥及私钥生成与管理，会话密的协商、生成、更新及分发等。

（2）基础加解密服务，包括基于RSA、ECC及AES 等多密码算法的期本加解密服务。

（3）认证服务，提供基于PKI及用户名/口令的认证机制。

（4）授权服务，为应用提供资源及功能的授权管理和访问控制服务。

现企业测试部门拟对平台的密钥管理与加密服务系统进行安全性测试，以检验平台的安全性。

【问题1】（4分）给出安全中心需应对的常见安全攻击手段并简要说明。

【问题2】（6分）针对安全中心的安全性测试，可采用哪些基本的安全性测试方法【问题3】（5分）请分别说明针对密钥管理功能进行功能测试和性能测试各自应包含的基本测试点。

【问题4】（5分）请分别说明针对加解密服务功能进行功能测试和性能测试各自应包含的基本测试点。

2.【Java程序】public int addAppTask(Acitivity activity，Intent intent，TaskDescription description，Bitmapthumbnail）{Point size=getSize()；//1final int tw=thumbnail.getWidth();final int th=thumbmail.getHeight();if(tw!=size.x||th!=size.y){//2,3Bitmap bm=Bitmap.createBitmap(size.x，size.y，thumbmail.getConfig()); //4float scale;float dx=0，dy=0;if(tw*size.xsize.y*th){//5scale=(float)size.x/(float)th;//6dx=(size.y-tw*scale)*0.5f;}else{ //7scale=(float)size.y/(float)tw;dy=(size.x-th*scale)*0.5f;}Matrix matrix=new Matrix();matrix.setScale(scale, scale);matrix.postTranslate((int)(dx+0.5f)，0);Canvas canvas=new Canvas(bm);canvas.drawBitmap(thumbmail，matrix，null);canvase.serBitmap(null);thumbnail=bm;}if(description==null){//8description =new TaskDescription(); //9}}//10【问题1】（2分）请简述基本路径测试法的概念。

1.技术测试分析师在基于风险的测试中的任务-30分钟.关键词产品风险（product risk）、风险分析（risk analysis）、风险评估（risk assessment）、风险识别（riskidentification）、风险级别（risk level）、风险缓解（risk mitigation）、基于风险的测试（risk-basedtesting）技术测试分析师在基于风险的测试中的任务相关的学习目标1.3风险评估TTA-1.3.1(K2)总结技术测试分析师需要考虑的、典型的风险因素通用的学习目标TTA-1.x.1(K2)总结在基于风险的测试方法中，技术测试分析师在测试计划和测试执行过程中的相关活动。

1.1简介测试经理具有建立和管理基于风险的测试策略的全面责任。

测试经理往往要求技术测试分析师的介入以确保正确执行基于风险的方法。

由于其独有的技术特长，技术测试分析师与以下基于风险的测试任务密切相关：●风险识别●风险评估●风险缓解为了处理出现的产品风险和变更优先级，以及定期地评估和沟通风险状态，以上任务会迭代地贯穿在整个项目中。

技术测试分析师在由测试经理为项目制定的、基于风险的测试框架中工作。

他们贡献出与项目内在密切相关的技术风险知识，比如安全相关的风险、系统可靠性和性能相关风险。

1.2风险识别在风险识别过程中越广泛地接触各类项目干系人，能识别出最大数量的重大风险的可能性也就越大。

由于技术测试分析师掌握独特的专门技能，他们特别适合进行专家访谈，与同事头脑风暴以及分析当前和以前的工作经验来确定可能存在产品风险的区域。

特别地，技术测试分析师与其他技术同行（例如，开发人员、架构师、运维工程师）工作密切，有利于确定存在技术风险的区域。

识别的风险样本可能包括：●性能风险（例如，在高负载条件下无法达到响应时间的要求）●安全风险（例如，在安全攻击下泄露敏感数据）●可靠性方面风险（例如，应用程序无法满足服务等级协议中指定的可用性）与特定的软件质量特性相关的风险区域将在本大纲的相关章节中介绍。

Testbed可行性报告Testbed质量保证工具在嵌入式系统开发中的应用摘要：嵌入式软件的应用与开发是当今计算机软件发展的一个热点。

本文首先分析了在嵌入式系统开发中软件开发的重要性，接着描述了LDRA公司的Testbe/Tbrun质量保证工具解决方案的功能，并列举了几个典型的应用。

关键字：嵌入式软件分析测试静态分析动态测试白盒测试覆盖率分析单元测试高可靠性软件测试引言：随着嵌入式技术的发展，嵌入式应用的不断增长以及嵌入式系统复杂性不断提高，要求嵌入式软件的规模和复杂性也不断提高。

这样，嵌入式软件的质量和开发周期对产品的最终质量和上市时间起到决定性的影响，嵌入式软件的开发、分析与测试成为了研究的热点。

针对这一变化，本文提出了一种为嵌入式软件的开发、分析与测试特别设计的一种测试工具——Testbed。

一.前言本文分别介绍了LDRA公司的Testbed嵌入式软件分析与测试解决方案的功能和应用、原理和比较，希望读者通过阅读后，可以对Testbed工具包有一个完整清晰的认识，回答大家经常提出的做什么、为什么可以做、怎样做的问题。

借此，方便广大用户在开发和测试的过程中恰如其分的选择、使用Testbed，真正做到“花费适当的费用，购买适当的设备，解决适当的问题”。

二.嵌入式软件分析与测试的重要性随着社会科技水平的发展，计算机技术越来越深入社会生活的方方面面，它已不再只是少数IT人士的工具，而是以智能化、嵌入式为特点，方便、灵活的服务于人类，并存在于众多的关键性运用中。

而在整个嵌入式系统设计所涉及到的各个技术层面中，由于计算机硬件元件质量逐步提高，元件的集成量也大大增加，从而使嵌入式系统的硬件设计方便，性能和可靠性得到了极大的提高；与此同时，通过采用成熟的商用操作系统，使系统运行在一个高性能的、可靠的软件平台上，为实现各种大型的复杂的应用打下了良好的基础。

这样，使得用户自己编写的应用软件成为影响整个系统性能的关键，应用软件设计的质量和消耗的时间，对产品的最终质量和开发进度起到了决定性的作用。