嵌入式系统软件测试.docx
《嵌入式系统软件测试.docx》由会员分享，可在线阅读，更多相关《嵌入式系统软件测试.docx（11页珍藏版）》请在冰点文库上搜索。
嵌入式系统软件测试
嵌入式系统软件测试
1.1概述软件测试
软件测试是设计测试用例，并利用测试用例运行程序，发现错误的过程。
而测试用例的设计则需要借助软件开发阶段的规格说明书以与程序的部结构。
软件测试是软件工程研究领域的重要分支，是保证软件质量的关键步骤。
发生于上世纪70年代末的“软件危机”，对软件理论的研究起到了极大的促进作用，同时“软件工程”作为一项新兴学科也在此时开创。
经过30多年的发展，尽管没有找到真正的“银弹（silverbullet）”来彻底解决“软件危机”问题，但是软件工程的研究，在软件开发技术和软件项目管理两大领域，依然硕果累累。
从结构化程序设计思想到面向对象理论；从简单无序的手工作坊式编程到较为规、可控制的各种开发模型；从富于个人英雄主义气质的牛仔式的程序员到分工明确、迅速高效的现代化开发团队；从只要求程序能够运行到追求程序的可靠性、兼容性、设计重用性等高质量属性；这一系列思想的进步和方法的改进，都表明了软件工程领域的研究正在不断的取得进步。
与此同时，对高质量软件的日益需求，促进了软件工程领域的重要容之一：
软件测试理论的研究和实践。
三十多年的发展，为我们提供了丰富的经验，使得软件测试成为一门十分成熟的学科。
1.1.1软件测试目的
软件测试的过程是寻找和发现软件中潜在的错误的过程，因此，软件测试的首要目的是与早的发现软件中所包含的各种错误，以此来使软件获得相应级别的质量保证。
其次，通过软件测试，还可以验证软件实现的功能是否符合设计说明书的要求；验证软件的性能是否达到设计要求；通过收集测试过程中的各种数据，为软件质量的评价提供一定的依据。
另外，在指定具体的测试目标时，人们通常会将投入的时间和人力等成本考虑进去，所以，成功的软件测试往往是通过最少的人力和时间成本，尽可能多的找出软件中潜在的各种错误和设计缺陷。
1.1.2软件测试对象
一种常见的观点认为软件测试单指程序测试，这种观点显然是不全面的。
软件测试贯穿于整个软件定义和软件开发过程。
因此，由需求分析得到的需求说明书、由概要设计得到的概要设计说明书、由详细设计得到的详细设计说明书以与由程序编码得到的源程序等，均应该被视为软件测试的对象。
在软件的开发过程中，越早发现的错误，改正错误的代价就越低，对于软件开发过程的影响就越小，见图3-1。
因此，对于软件生存周期的各个阶段所要传递的信息，都应该尽可能的保证理解和表达的正确性。
对每个阶段所得到的阶段性成果，都应该独立的进行确认和验证，以求尽早地发现软件缺陷。
图31随时间推移，修复软件错误费用惊人增长
1.1.3软件测试数据流图
软件测试数据流图描述了软件测试的基本流程，如图3-2所示。
测试过程需要两类输入，分别是软件配置和测试配置。
软件配置包括：
软件需求规格说明书，软件设计规格说明书，源代码等；测试配置包括：
测试计划，测试用例，测试驱动程序和测试工具等。
图32软件测试数据流图
1.1.4软件测试方法
软件测试的方法多种多样，从不同的角度来看，可以有不同的分类方法。
从其贯穿软件生命周期的过程来看，可以分为模块测试、集成测试、系统测试和确认测试等测试阶段；另外，测试还可以分为静态测试和动态测试；在动态测试中，又分为基于程序结构的白盒测试和基于功能的黑盒测试。
总的来讲，目前软件测试存在两大类测试方法，第一类测试方法是将软件在设计的环境下运行以得出结果，并将该结果与预期结果作对照，如果二者相符则测试通过，如果二者存在出入不相符则视为错误。
最终在设计规定的环境中将软件的所有功能加以运行，以逐一发现错误。
该方法基于用户需求和设计，将测试工作的畴加以界定，可有针对性地部署测试的侧重点。
第二类方法与需求和设计没有必然的联系，更强调测试人员利用逆向思维发挥主观能动性，不断反思开发人员的不良习惯、理解的误区、无效数据的输入、程序代码的边界以与系统本身的各种弱点，站在破坏和摧毁系统的角度，不断寻找系统中各种各样的问题。
实践中，结合使用以上两种测试方法往往能够取得较好的效果。
1.2嵌入式软件的测试
1.2.1关于测试策略
嵌入式平台，资源相对稀少，但其却是嵌入式系统软件最终的运行环境,而一般软件可能运行在超级计算机上或高性能的PC机上。
适当条件下,嵌入式系统软件的测试同样适用一般软件的单元测试、系统测试、集成测试和确认测试策略。
我们也可以将所谓的适当条件看作是关于嵌入式系统软件测试的独特策略。
嵌入式系统中的开发环境和最终运行环境又分别被称为主机（Host）平台和目标（Target）平台。
两种典型的嵌入式软件开发方式分别为:
一种是在实际目标（Target）平台上编辑、编译和调试代码进而开发源代码;另一种则是将编辑和编译源代码的工作在主机平台上完成,而后移动可执行代码到目标机上进行调试。
第二种方法也叫做交叉开发,如图3-3所示。
图33交叉开发
选择交叉开发方法使得目标机和主机在运行速度上的差别得以缓解。
交叉开发环境,同时也是交叉测试环境，因为在交叉测试过程中同样体现了交叉开发的有利因素。
这即是前面提到的适当条件,即关于嵌入式软件测试的独特的交叉测试策略。
在主机环境下，无论是嵌入式软件的单元测试还是嵌入式软件的集成测试均可以完成;然而关于最终的硬软件集成测试则必须在目标环境下,利用目标机与主机间的信息通道,进而实现测试控制和信息反馈通信。
1.2.2测试方法
关于测试方法，覆盖和质量是主要的评测方法。
测试覆盖可用测试需求和测试用例的覆盖来表示，亦可用已执行代码的覆盖来表示，主要是评测测试的完全程度。
将针对测试对象的稳定性、可靠性以与性能的评测称作是质量。
不管是对测试结果的评估，还是在测试过程中针对确定的变更请求（缺陷）所进行的分析，均可作为质量评测的基础。
（1）覆盖测评
测试的完全程度由覆盖指标表示。
黑盒的测试覆盖和白盒的测试覆盖是最常用的覆盖测评方法，前者是基于需求的测试覆盖，而后者则是基于代码的测试覆盖。
简单地说，测试覆盖是对基于需求或基于代码的完全程度的评测，前者是核实测试用例，后者是评测代码执行。
系统的测试活动必须以测试覆盖策略为基础，测试的一般目的由覆盖策略述，用例的设计也由覆盖策略指导。
此外，所有性能也可由覆盖策略的述简单说明。
倘若已经将需求完全分类，那么覆盖策略基于需求足以生成测试为完全程度的可计量评测。
举例说明，如若所有性能的测试需求都已经被确定，那么评测就可引用测试结果得到。
如若应用基于代码的测试覆盖，那么测试策略只能根据测试所得的已执行的源代码的多少来确定。
对于安全之上的系统来说，该测试覆盖策略类型具有非常重要的意义。
在测试生命周期中，基于需求的测试覆盖要评测数次。
测试覆盖可用以下公式计算：
测试覆盖
T是用已计划或已实施或成功的测试过程或测试用例表示的测试（Test）数。
表示测试需求（RequirementforTest）总数。
制定测试计划时，通过计算测试覆盖以确定已计划的测试覆盖，计算方法为：
测试覆盖（已计划的）
是已计划测试数，其用测试过程或测试用例表示。
实施测试活动时，测试过程按照测试脚本正在实施中，可采用以下公式计算测试覆盖：
测试覆盖（已执行的）
是已执行的测试数，其用测试过程或测试用例表示。
执行测试活动时，两个测试覆盖评测同时使用，其一用来确定由执行测试得到的测试覆盖，另一个用来确定执行时未出现失败即成功的测试覆盖（如没有缺陷出现或意外结果产生的测试）。
利用以下公式计算这些覆盖评测：
测试覆盖（已执行的）
是已执行的测试数，其用测试过程或测试用例表示。
成功的测试覆盖（已执行的）
也是已执行的测试数，不同的是，其是由没有缺陷的已完成的测试过程或测试用例来表示。
倘若用百分数表示以上比率，那么以下有关基于需求的测试覆盖的述同样成立：
已经覆盖的测试用例（同上述公式中的
）为x﹪，成功率为y﹪。
关于测试覆盖的该种述是有意义的，其与已定义的成功标准作比较，如果不相符，则可利用此述为基础来预测剩余测试工作。
基于代码的测试覆盖，在测试过程中，其可以测评已经执行的代码的多少，而要执行的剩余代码则与之相对。
控制流包括语句、分支或路径，而代码覆盖则即可建立在控制流上，亦可建立在数据流上。
无论是测试代码行、测试分支条件、还是测试代码中的路径，甚至软件控制流中的其它元素都被当作了控制流覆盖的目的。
数据流覆盖的目的是利用软件操作对数据状态的有效与否进行测试。
例如，测试在使用之前数据元素是否已作定义。
利用以下公式对基于代码的测试覆盖进行计算：
测试覆盖
是已执行项目数，其既可用代码语句、分支或路径来表示，还可用数据元素名或数据状态判定点数来表示。
表示代码中的项目总数。
倘若用百分数表示以上比率，那么以下有关基于代码的测试覆盖的述同样成立：
已经覆盖的测试用例（同上述公式中的I）为x﹪，成功率为y﹪。
关于测试覆盖的该种述是有意义的，其与已定义的成功标准作比较，如果不相符，则可利用此述为基础来预测剩余测试工作。
（2）质量评测
适用于硬件可靠性设计中的“简单就是可靠”原则同样也适合软件，随着功能的增多或增强软件需要不断升级与补丁。
软件质量是由因应用方面和用户观点不同而各异的多种因素组成的混合体或综合体。
按照能否直接度量的标准可将影响软件质量的因素分为两大类：
其一是可直接度量的因素，其二是只能间接度量的因素，前者如单位时间所发现的每千行源代码的错误个数，后者如可维护性、可复用性等。
以上两大类影响软件质量的因素都能够被度量，且都可以具体数据描述软件质量的不同方面。
关于软件的可维护性，主要有三种度量参数，分别为：
Line复杂度、Halstead复杂度和McCabe复杂度。
Line复杂度的计算基准是代码的行数。
Halstead复杂度将程序中使用到的运算元与运算符数量作为直接测量指标,然后计算出程序容量和工作量等。
McCabe复杂度又被称作是圈复杂度，它定量了测试困难度以与最终可靠性指标的度量。
经试验证明，McCabe度量、存在于源代码中的错误数、发现并纠正这些错误所需的时间，该三者之间存在特定的关系。
McCabe&Associates公司成立于1976年，该公司针对软件进行结构测试而开发出了McCabeCylomaticComplexityMetric（圈复杂度）技术。
将软件复杂度测量的数目作为基础的Meric，可帮助工程师较为轻松地识别出难于测试和维护的模块。
人们将圈复杂度作为评估软件质量的重要标准，利用其来衡量软件的复杂度和质量，奔着在成本、进度以与性能之间寻求平衡的目的来安排工程进度。
McCabe复杂度包括基本复杂度、圈复杂度、设计复杂度、模块设计复杂度和集成复杂度。
1.2.3测试工具
1.2.3.1软件测试工具
纯软件方式的测试大多都是利用软件仿真技术，在宿主机上模拟目标机，从而在仿真的宿主机上进行大部分的测试。
现在大多数的嵌入式测试工具，包括Logiscope、CoverageScope等都采用了这种方式。
作为纯软件测试工具Host/Target采用的是软件插桩技术。
将一些函数或一段语句插入到被测代码中，再利用插入的函数或语句来生成数据，并将这些数据上送到目标系统的共享存中。
与此同时，在目标系统中利用预处理任务对这些数据进行预处理，之后通过目标机的调试口将处理后的数据上送到主机平台，所有的这些都在目标处理器的参与下完成。
测试者通过以上过程可以得知程序当前的运行状态。
插桩函数和预处理任务作为两个特点必然存在于纯软件的测试方式中。
而插桩函数和预处理任务的存在也增大了系统的代码，更有甚者，某些代码会极影响系统的运行效率。
预处理任务不但占用目标系统CPU存，而且需要时间在通信通道中处理和传送数据。
鉴于这些弊端的存在，基于Host/Target的纯软件测试工具在进行测试时，其不能对目标系统进行精确的性能分析，甚至，在分析覆盖率时，系统的运行还要受到大量插桩的影响。
所以，Host/Target作为一种纯软件测试工具，其缺乏性能分析功能，既不能针对目标系统中相关的时间指标做出精确的分析，也不能动态观察存的动态分配。
1.2.3.2硬件测试工具
纯硬件的手段，如万用表、示波器、逻辑分析仪等，通常被用于设计和测试系统的硬件，但也可用来分析测试软件。
逻辑分析仪是最常用的一种纯硬件测试工具，其通过监控系统运行时总线上的指令周期，利用一定频率捕获信号，分析数据，通过了解用户系统的工作状态，进而对当前程序运行的状况做出判断。
逻辑分析仪使用采样的方式，难免会遗漏重要信号，而且，其分析围也非常有限。
举例说明，逻辑分析仪只能采用抽样的方式，对有限的函数进行性能分析，故其要得出满意的结果十分困难。
针对程序分析覆盖率时，硬件工具需要从系统总线上捕获数据，例如当打开Cache时系统会基于指令预取技术，将外存中的一段代码读入到一级Cache中，此时，逻辑分析仪利用频率捕获到代码被读取的信号，然后报告这些代码已被执行，然而实际上被读入到一级Cache中的代码可能根本没有被命中。
只有把Cache关掉才可能避免这种误差，而把Cache关掉之后系统的运行环境就不真实了，更有甚者系统都可能出现无常运行的现象。
由此可知，纯硬件工具根本不具备分析和检查存分配的能力。
1.2.3.3软硬结合测试工具
所谓的软硬结合测试工具，也即能够利用纯软件和纯硬件测试工具各自的优点，并摒弃它们各自的缺点。
例如高性能测试工具CodeTest，其采用插桩技术由AppliedMicrosystemsCorporation（AMc）公司专为嵌入式开发者而设计，可用于本机测试（native）甚至在线测试（in-circuit）。
区别于纯软件测试工具，CodeTest以插入一条赋值语句来替代插桩函数，从而大大缩短了执行时间，同时也避免了被中断，相互间的影响都非常小。
同时，CodeTest又吸取并改进了纯硬件测试工具里从总线捕获数据的技术，CodeTest摒弃采样的方式，通过监视系统总线，只有在程序运行到插入的特殊点时才会主动捕获数据总线上的数据，所以，利用CodeTest所做的数据观察可以很精确。
CodeTest主要的功能有:
（l）分析性能。
（2）分析测试覆盖。
（3）分析动态存储器分配。
（4）分析执行追踪（TRACE）。
所以，虽然现在市面上的一些测试工具在某些应用中达到了一定或较好的效果，但由于嵌入式的多样性，使得这些测试工具在针对某些特定的应用时又无法达到要求的效果，故很难形成一种适合所有具体测试工作的测试方法。
1.2.4嵌入式系统测试流程
关于嵌入式系统的完整的测试流程见图34:
图35模块化设计的嵌入式软件四级测试流程
通过观察测试流程图不难看出测试过程的步骤:
首先将被测软件系统的源码根目录交由测试系统管理，同时命名被测软件系统，提供相关的简要描述以与自动分析被测软件的源码。
创建测试工程，将其与测试系统管理的某一个被测软件系统进行绑定，并命名该测试工程，提供相关的简要描述。
创建测试集，在测试工程中，每个测试集对应一个被测模块或模块集合。
在创建测试集时，使用者需要将被测的一个或多个模块加以指定，同时命名该测试集，提供相关的简要描述。
创建测试用例，在测试集中，每个测试用例针对与其相对应的某一个函数进行测试，在创建测试用例时，使用者需要指定这个函数，同时命名该测试用例，提供相关的简要描述。
关于测试用例的设计与临时执行，根据测试的需要，使用者可利用由测试系统提供的协助手段设计测试用例。
使用者还可在设计过程中临时运行该测试用例并利用测试结果信息或是进一步设计测试用例，或是重新创建设计新的测试用例。
用户在完成一个测试用例的设计之后，也可以选择创建新的测试用例，或是选择创建新的测试集。
有关测试用例的批量执行，用户可针对一个测试工程中的部分或所有测试用例进行批量的连续的执行，同时将包括覆盖信息在的所有被运行的测试用例的结果信息加以收集。
查看测试结果，包括测试用例运行结果和代码覆盖信息。
测试系统可根据测试结果信息生成测试报告。
升级会员 