工程实践报告

PAGEPAGE1目录1.测试项目背景…………………..41）嵌入式软件的发展趋势…………………….42）单元测试对嵌入式软件的重要性………….42.项目工作阶段与技术应用……….53.项目中存在的问题及认识……….74.项目总结及单元测试工具市场前景10测试项目背景1.嵌入式软件的发展趋势自从上个世纪90年代以来，以计算机技术、通信技术和软件技术为核心的信息技术取得了更加迅猛的发展，各种装备与设备上嵌入式计算与系统的广泛应用大大地推动了行业的渗透性应用。嵌入式系统被描述为：“以应用为中心、软件硬件可裁剪的、适应应用系统对功能、可靠性、成本、体积、功耗等严格综合性要求的专用计算机系统”，由嵌入式硬件和嵌入式软件两部分组成。硬件是支撑，软件是灵魂，几乎所有的嵌入式产品中都需要嵌入式软件来提供灵活多样、而且应用特制的功能。由于嵌入式系统应用广泛，嵌入式软件在整个软件产业中占据了重要地位，并受到世界各国的广泛关注；如今已成为信息产业中最为耀眼的“明星”之一。2.单元测试对嵌入式软件的重要性单元测试是检查嵌入式系统软件缺陷的最有效的一种方法，更确切而言也即在宿主机环境下或在仿真器上进行的API测试。这能使测试尽早开始并且最大程度地降低了测试工作对目标硬件平台的依赖性。嵌入式系统软件的单元测试的一个前提是能够让软件独立于硬件进行测试，这是由桩函数对目标硬件平台的模拟而实现的。在这种情况下，代码的绝大多数功能性测试都能够独立于目标硬件系统进行测试。这对嵌入式系统开发者而言主要有两方面的好处：1）单元测试能让开发者在目标硬件平台准备好之前就开始测试周期，开发者可以直接在宿主开发环境下开始初始测试（而不需要目标硬件平台）。2）单元测试采取一种“各个击破”的策略，允许用户将复杂的系统分为相对较简单的准独立系统进行测试。测试工具能够管理模块之间的关联性并使用桩函数来模拟这些模块的行为。图：使用桩函数，开发者可以模拟真实环境和程序之间的相互影响对程序的某个模块进行测试，而不需要目标硬件平台以及暂时还未完成的其它代码模块。在测试环境中，桩函数充当了为待测模块提供外部关联性桥梁的作用。项目工作阶段与技术应用谈谈自己今年7-8月间在长沙做项目的认识吧。测试项目的前期阶段工作第一部分是在甲方单位指定的机器上搭载环境，建立测试平台，同时安装以下工具软件：1）CCS（CodeComposerStudio）2.2：是TI公司推出的DSP集成开发环境，集代码编辑、编译、调试等多功能于一体的工具，其主要作用是进行函数的拆分，编写桩、驱动等功能。2）CRESTSTESS：全数字仿真平台的自动化测试工具，全称是基于仿真目标机的半物理仿真平台系统CRESTS/TESSC(SCT-Cast)，以下对其进行简介：TESSC由宿主机系统（HostSystem）和仿真处理模块组成。仿真处理模块包含一个目标处理器的复制（targetCPU，如DSP3X）和支持与控制系统（supportsystem）。目标处理器的复制执行汇编语言程序，Ada语言程序，C语言程序程序的最终二进制代码。支持与控制系统控制目标处理器复制的行为并仿真低一级硬件的接口。宿主机用于应用测试和全面控制，以及提供更复杂环境的仿真模拟。汇编语言程序，高级语言程序，混合语言程序最终二进制代码无需任何修改，直接执行于真实目标处理器的复制中，应用于目标软件真实的外界感知环境的仿真系统中。

TESSC最重要的特性之一是目标处理器的复制和所有和它相关的时间关系都可以被支持系统与控制系统管理、控制。这就意味着在TESSC上的目标软件（包括汇编语言程序，高级语言程序）的行为过程，完全可以控制，可以在测试期间对目标软件内部的探查精确而详细。可以进行更多软件测试，对目标软件深层问题进行探究。3）Script.NETV2（免费版）：是一个集开发、编辑的TCL脚本的工具，主要用于TCl脚本开发。4）SourceInsigh：是一个代码浏览器，能够方便你分析源代码并在你工作的同时动态维护它自己的符号数据库，并自动为你显示有用的上下文信息，进行有效的代码分析。5）Snagit9.0（试用版）屏幕截图软件，用于截取测试执行时需要保存的一些图片及屏幕提示信息，达到保存屏幕信息目的。项目的前期阶段工作第二部分是在测试环境建立好后，我们先对甲方提供的项目文档进行阅读，通过阅读文档，对项目有了大致的了解，除此之外仔细阅读项目需求、概要、详设等文档还要对代码进行书面审查，在这里涉及到商业机密，就不详谈了，而后按照甲方的要求，我们对其代码进行单元测试，测试类型要求分为功能测试、逻辑测试，到了测试项目中期阶段，我们的工作进入实质性阶段，每个测试小组开始对各自审查的代码进行测试用例设计，我需要设计用例的函数来自于两个.C文件fun_1553.C和LIB_FK_861.C，共计是10个函数，分别是计算校验和、计算关键性权威授权、悬挂物数据包、传递对准数据包、任务加载数据包、UT1553B总线发送、INT6中断处理函数、时钟初始化、UART初始化、UTProcess(进程处理)等函数。对每个函数测试用例设计完成后，就开始执行测试用例的工作，执行测试用例首先是在CCS（CodeComposerStudio）2.2环境中写驱动函数，通过驱动函数调用.C源文件中的函数，之后要在CCS环境中编译运行通过后，然后在TESS自动化测试工具中载入该添加驱动函数的.C文件工程，在TESS中通过main函数调用覆盖被测函数后，用Script.NET编辑TCL脚本，利用脚本在驱动函数和被测函数有输出处进行插桩、打点，验看输出结果的准确性。通过执行的结果，判定函数是否存在问题，若存在将其提交到Bug报告单中。到了测试项目后期阶段，我们的工作是将测试用例与Bug报告单的一些基本情况进行统计，比如测试用例、Bug报告单的个数、发现问题的个数、以及用例与报告单的规范性调整，之后将统计的情况向甲方提交，并要参加由甲方组织的评审。项目中存在的问题及认识在设计测试用例过程中，第一个问题是在计算校验和函数中出现的，该函数整体结构主要是实现一个FOR循环，在FOR循环体中通过对循环次数的控制，一些使得指针左移或右移相应位数的语句和相位与、相或与语句来生成校验字（checkword）。从函数的结构分析，进行测试用例的设计从两种测试类型功能测试与逻辑测试，其中逻辑测试又分为分支测试、语句测试。该函数功能测试的目的很明确，就是是否能实现生成数据帧的校验和的结果，而分支测试（逻辑测试）的目的则是判断函数在何种情况下执行FOR循环分支或不执行该分支时分支覆盖率的情况，语句测试则是在上述两种分支覆盖的情况下，语句执行情况下，语句覆盖率的情况。在设计该函数功能测试用例输入数据时起初存在难点，因为该函数的两个输入参数一个是指针，而另一个是数据帧的长度，数据帧的长度有合理输入范围1-32之间，因此容易设立输入初值，而输入参数为指针的因为在后续的其他函数中（比如悬挂物数据包、传递对准数据包、任务加载数据包函数）对其均有调用，调用时对应输入参数指针均是上述数据包头字（headword）的地址，而该地址是由计算机随机分配的，事先无参照值，后来想到用一组数组来代替该随机分配得计算机地址，然后先将这些输入数据带入该函数，通过人工计算得出函数结果，之后再由计算机在TESS中验看函数计算结果，通过两个结果比对是否一致，来验证函数的功能。执行该函数分支测试用例时，也出现了大家共同关心的问题，这一问题使大家在设计测试用例初期产生了巨大的分歧，分歧在于功能测试与逻辑测试虽然在测试概念上完全不同，但在设计用例时可能设计出来的用例完全一致，（例如在计算校验和函数中，功能测试正反两个用例一个是执行FOR循环分支实现函数生成校验字功能；另一个是不执行FOR循环分支未实现函数生成校验字功能；而分支测试正反两个用例则与此设计完全一致）一方的意见是尽管一致但因为测试类型不同，所以测试用例还是应该分开写；另一方的意见则是因为一致，可以考虑合并到一起，只要在测试类型处标明即可；最后大家一致认为同意将其合并，用同一组测试用例表示即可。后面的几个函数如悬挂物数据包、传递对准数据包、任务加载数据包在设计测试用例时，都普遍存在一个问题，就是在来自于调用其他函数参数在给本函数参数进行传参赋值时，都缺少对传进来的数据进行正确性的判断，很显然程序员在写这几个函数的传值、赋值的语句时，心安理得的认为传值的数据正确性验证只用在该参数赋初值的函数里完成正确性验证即可，其他地方只要保证传值的正常进行就可以了，而我们测试人员却要考虑传值数据的正确性验证，尽管在我们测试的函数里找不到验证性的语句，可是在测试脚本里却要设计各种范围的数据进行测试，这时如果在脚本里输入非法数据，函数本身无法发现其错误，这里也就设计到单元测试与被测函数之间的矛盾，将被测函数纳入到一个完整.C文件去看，则不存在上述问题，但是单元测试将一个.C文件中的每个函数作为一个单独单元来进行测试，函数与函数之间的关系被测试割裂开来，使得有些函数在诸如传递参数方面在不具备独立性的情况下，丧失了验证传参数据的正确性。但在最后测试组讨论形成统一的意见是对于被测函数出现的类似的通过其他函数参数进行传递赋值的语句，不进行被传参数数据正确性的验证，一方面是不需要重复的测试（因为在参数赋初值的函数里一定会进行测试）；另一方面是由于缺少限制参数赋值范围的语句，根本无法保证被传参数数据的正确性，不具备作为测试点前提条件；所以也不可以作为Bug提交成报告单。还有一个问题是在函数悬挂物数据包中出现的，在该函数中If条件的嵌套层次很多，在开始设计其测试用例时，将分支测试与路径测试混淆在一起，将基本的分支进行分支与分支进行了组合，误认为是新的分支，其实是路径，在纠正了这个错误后，该函数的测试用例个数减少了许多，也因此弄清楚了分支测试与路径测试的区别与联系。在进行TCL脚本语言设计时，在源代码打点处输出遇到函数输出不正确的问题，这个问题是在Uart初始化函数中碰到的，在该函数中主要实现是否能正确选择串口通道、波特率值、合法FIFO级别设置、非法中断使能设置四项要素，如果有一项未能正确取值，则利用Return语句跳出整个函数，在该函数的TCL脚本中，是在这四个要素分别赋值，若其中由一个进行非法赋值，就跳出函数并返回该处的返回值，在插入脚本打点前期，始终都只能返回正确返回值0，而其他非法情况下的返回值1、2、3、4均不能返回，后来发现原因在于在CCS中编写驱动函数时，在main函数中调用该初始化函数时，语句只写到该调用语句，也就是每次执行脚本时，返回值在总是被赋初值为0时就返回了，后来在驱动函数中又加了一条语句后，每次执行脚本后，要执行到调用该初始化函数语句后面一句时，再显示返回值时就会出现在非法情况下的返回值1、2、3、4，通过对这个问题的分析我们知道TCL脚本在执行返回值时的特点，对自己以后写脚本时提高了一些认识吧。后来在写Bug问题报告单时，也是这个Uart初始化函数基于其函数结构是单入口、多出口函数结构，在测试规范上要求函数结构是单入口、单出口结构，所以该函数在结构上存在问题，但是根据该函数实现的功能来看，单入口、多出口函数结构才符合其要求，这给程序员们提出了一个难题。项目总结及单元测试工具市场前景在这次测试项目中，自己了解到了做嵌入式软件尤其是单元测试的基本操作流程和做单元测试所需的一些测试工具的使用特点，对于编写测试脚本和选取合适的脚本插入点也形成了自己的一些认识，对于单元测试工具在做测试时需要哪些测试功能，提供给测试人员哪些信息和统计数据有助于测试人员的分析以及测试用例的设计，是评价一款单元测试工具几个重要特征，在我们公司提供的单元测试工具TESS中，除了可以进行代码静态分析和插入测试人员编写的TCL脚本以外，还可以查看各个函数调用覆盖情况，另外还可以查看每次执行脚本后，调用的函数中的分支和语句覆盖率的情况，对于测试人员设计的测试用例中的预期结果和实际结果的分析有很直观的比对作用。目前嵌入式软件测