《嵌入式系统软件测试》由会员分享，可在线阅读，更多相关《嵌入式系统软件测试（11页珍藏版）》请在金锄头文库上搜索。
1、嵌入式系统软件测试嵌入式系统软件测试1.11.1 概述软件测试概述软件测试软件测试是设计测试用例，并利用测试用例运行程序，发现错误的过程。而测试用例的设计则需要借助软件开发阶段的规格说明书以及程序的内部结构。软件测试是软件工程研究领域的重要分支，是保证软件质量的关键步骤。发生于上世纪 70 年代末的“软件危机” ， 对软件理论的研究起到了极大的促进作用，同时“软件工程”作为一项新兴学科也在此时开创。经过 30 多年的发展，尽管没有找到真正的“银弹(silver bullet)”来彻底解决“软件危机”问题，但是软件工程的研究，在软件开发技术和软件项目管理两大领域，依然硕果累累。从结构化程序设计思
2、想到面向对象理论；从简单无序的手工作坊式编程到较为规范、可控制的各种开发模型；从富于个人英雄主义气质的牛仔式的程序员到分工明确、迅速高效的现代化开发团队；从只要求程序能够运行到追求程序的可靠性、兼容性、设计重用性等高质量属性；这一系列思想的进步和方法的改进，都表明了软件工程领域的研究正在不断的取得进步。与此同时，对高质量软件的日益需求，促进了软件工程领域的重要内容之一：软件测试理论的研究和实践。三十多年的发展，为我们提供了丰富的经验，使得软件测试成为一门十分成熟的学科。1.1.11.1.1 软件测试目的软件测试目的软件测试的过程是寻找和发现软件中潜在的错误的过程，因此，软件测试的首要目的是及早
3、的发现软件中所包含的各种错误，以此来使软件获得相应级别的质量保证。其次，通过软件测试，还可以验证软件实现的功能是否符合设计说明书的要求；验证软件的性能是否达到设计要求；通过收集测试过程中的各种数据，为软件质量的评价提供一定的依据。另外，在指定具体的测试目标时，人们通常会将投入的时间和人力等成本考虑进去，所以，成功的软件测试往往是通过最少的人力和时间成本，尽可能多的找出软件中潜在的各种错误和设计缺陷。1.1.21.1.2 软件测试对象软件测试对象一种常见的观点认为软件测试单指程序测试，这种观点显然是不全面的。软件测试贯穿于整个软件定义和软件开发过程。因此，由需求分析得到的需求说明书、由概要设计得
4、到的概要设计说明书、由详细设计得到的详细设计说明书以及由程序编码得到的源程序等，均应该被视为软件测试的对象。在软件的开发过程中，越早发现的错误，改正错误的代价就越低，对于软件开发过程的影响就越小，见图 3-1。因此，对于软件生存周期的各个阶段所要传递的信息，都应该尽可能的保证理解和表达的正确性。对每个阶段所得到的阶段性成果，都应该独立的进行确认和验证，以求尽早地发现软件缺陷。图 0-1 随时间推移，修复软件错误费用惊人增长1.1.31.1.3 软件测试数据流图软件测试数据流图软件测试数据流图描述了软件测试的基本流程，如图 3-2 所示。测试过程需要两类输入，分别是软件配置和测试配置。软件配置包
5、括：软件需求规格说明书，软件设计规格说明书，源代码等；测试配置包括：测试计划，测试用例，测试驱动程序和测试工具等。图 0-2 软件测试数据流图1.1.41.1.4 软件测试方法软件测试方法软件测试的方法多种多样，从不同的角度来看，可以有不同的分类方法。从其贯穿软件生命周期的过程来看，可以分为模块测试、集成测试、系统测试和确认测试等测试阶段；另外，测试还可以分为静态测试和动态测试；在动态测试中，又分为基于程序结构的白盒测试和基于功能的黑盒测试。总的来讲，目前软件测试存在两大类测试方法，第一类测试方法是将软件在设计的环境下运行以得出结果，并将该结果与预期结果作对照，如果二者相符则测试通过，如果二者
6、存在出入不相符则视为错误。最终在设计规定的环境中将软件的所有功能加以运行，以逐一发现错误。该方法基于用户需求和设计，将测试工作的范畴加以界定，可有针对性地部署测试的侧重点。第二类方法与需求和设计没有必然的联系，更强调测试人员利用逆向思维发挥主观能动性，不断反思开发人员的不良习惯、理解的误区、无效数据的输入、程序代码的边界以及系统本身的各种弱点，站在破坏和摧毁系统的角度，不断寻找系统中各种各样的问题。实践中，结合使用以上两种测试方法往往能够取得较好的效果。1.21.2 嵌入式软件的测试嵌入式软件的测试1.2.11.2.1 关于测试策略关于测试策略嵌入式平台，资源相对稀少，但其却是嵌入式系统软件最
7、终的运行环境,而一般软件可能运行在超级计算机上或高性能的 PC 机上。适当条件下, 嵌入式系统软件的测试同样适用一般软件的单元测试、系统测试、集成测试和确认测试策略。我们也可以将所谓的适当条件看作是关于嵌入式系统软件测试的独特策略。嵌入式系统中的开发环境和最终运行环境又分别被称为主机(Host)平台和目标(Target)平台。两种典型的嵌入式软件开发方式分别为:一种是在实际目标(Target)平台上编辑、编译和调试代码进而开发源代码;另一种则是将编辑和编译源代码的工作在主机平台上完成,而后移动可执行代码到目标机上进行调试。第二种方法也叫做交叉开发,如图 3-3 所示。图 0-3 交叉开发选择交
8、叉开发方法使得目标机和主机在运行速度上的差别得以缓解。交叉开发环境,同时也是交叉测试环境，因为在交叉测试过程中同样体现了交叉开发的有利因素。这即是前面提到的适当条件,即关于嵌入式软件测试的独特的交叉测试策略。在主机环境下，无论是嵌入式软件的单元测试还是嵌入式软件的集成测试均可以完成;然而关于最终的硬软件集成测试则必须在目标环境下,利用目标机与主机间的信息通道,进而实现测试控制和信息反馈通信。1.2.21.2.2 测试方法测试方法关于测试方法，覆盖和质量是主要的评测方法。测试覆盖可用测试需求和测试用例的覆盖来表示，亦可用已执行代码的覆盖来表示，主要是评测测试的完全程度。将针对测试对象的稳定性、可
9、靠性以及性能的评测称作是质量。不管是对测试结果的评估，还是在测试过程中针对确定的变更请求(缺陷)所进行的分析，均可作为质量评测的基础。(1)覆盖测评 测试的完全程度由覆盖指标表示。黑盒的测试覆盖和白盒的测试覆盖是最常用的覆盖测评方法，前者是基于需求的测试覆盖，而后者则是基于代码的测试覆盖。简单地说，测试覆盖是对基于需求或基于代码的完全程度的评测，前者是核实测试用例，后者是评测代码执行。系统的测试活动必须以测试覆盖策略为基础，测试的一般目的由覆盖策略陈述，用例的设计也由覆盖策略指导。此外，所有性能也可由覆盖策略的陈述简单说明。倘若已经将需求完全分类，那么覆盖策略基于需求足以生成测试为完全程度的可
10、计量评测。举例说明，如若所有性能的测试需求都已经被确定，那么评测就可引用测试结果得到。如若应用基于代码的测试覆盖，那么测试策略只能根据测试所得的已执行的源代码的多少来确定。对于安全之上的系统来说，该测试覆盖策略类型具有非常重要的意义。在测试生命周期中，基于需求的测试覆盖要评测数次。测试覆盖可用以下公式计算：测试覆盖( , , , )/p i x sTRfTT 是用已计划或已实施或成功的测试过程或测试用例表示的测试(Test)数。表示测试需求(Requirement for Test)总数。RfT制定测试计划时，通过计算测试覆盖以确定已计划的测试覆盖，计算方法为：测试覆盖(已计划的) /pTRf
11、T是已计划测试数，其用测试过程或测试用例表示。pT实施测试活动时，测试过程按照测试脚本正在实施中，可采用以下公式计算测试覆盖：测试覆盖(已执行的) /iTRfT是已执行的测试数，其用测试过程或测试用例表示。iT执行测试活动时，两个测试覆盖评测同时使用，其一用来确定由执行测试得到的测试覆盖，另一个用来确定执行时未出现失败即成功的测试覆盖(如没有缺陷出现或意外结果产生的测试)。利用以下公式计算这些覆盖评测：测试覆盖(已执行的) /xTRfT是已执行的测试数，其用测试过程或测试用例表示。xT成功的测试覆盖(已执行的) /sTRfT也是已执行的测试数，不同的是，其是由没有缺陷的已完成的测试过程sT或测
12、试用例来表示。倘若用百分数表示以上比率，那么以下有关基于需求的测试覆盖的陈述同样成立：已经覆盖的测试用例(同上述公式中的)为 x，成功率为 y。( , , , )p i x sT关于测试覆盖的该种陈述是有意义的，其与已定义的成功标准作比较，如果不相符，则可利用此陈述为基础来预测剩余测试工作。基于代码的测试覆盖，在测试过程中，其可以测评已经执行的代码的多少，而要执行的剩余代码则与之相对。控制流包括语句、分支或路径，而代码覆盖则即可建立在控制流上，亦可建立在数据流上。无论是测试代码行、测试分支条件、还是测试代码中的路径，甚至软件控制流中的其它元素都被当作了控制流覆盖的目的。数据流覆盖的目的是利用软
13、件操作对数据状态的有效与否进行测试。例如，测试在使用之前数据元素是否已作定义。利用以下公式对基于代码的测试覆盖进行计算：测试覆盖/eITIic是已执行项目数，其既可用代码语句、分支或路径来表示，还可用数据eI元素名或数据状态判定点数来表示。表示代码中的项目总数。TIic倘若用百分数表示以上比率，那么以下有关基于代码的测试覆盖的陈述同样成立：已经覆盖的测试用例(同上述公式中的 I)为 x，成功率为 y。关于测试覆盖的该种陈述是有意义的，其与已定义的成功标准作比较，如果不相符，则可利用此陈述为基础来预测剩余测试工作。(2)质量评测适用于硬件可靠性设计中的“简单就是可靠”原则同样也适合软件，随着功能
14、的增多或增强软件需要不断升级与补丁。软件质量是由因应用方面和用户观点不同而各异的多种因素组成的混合体或综合体。按照能否直接度量的标准可将影响软件质量的因素分为两大类：其一是可直接度量的因素，其二是只能间接度量的因素，前者如单位时间内所发现的每千行源代码的错误个数，后者如可维护性、可复用性等。以上两大类影响软件质量的因素都能够被度量，且都可以具体数据描述软件质量的不同方面。关于软件的可维护性，主要有三种度量参数，分别为：Line 复杂度、Halstead 复杂度和 McCabe 复杂度。Line 复杂度的计算基准是代码的行数。Halstead 复杂度将程序中使用到的运算元与运算符数量作为直接测量
15、指标,然后计算出程序容量和工作量等。McCabe 复杂度又被称作是圈复杂度，它定量了测试困难度以及最终可靠性指标的度量。经试验证明，McCabe 度量、存在于源代码中的错误数、发现并纠正这些错误所需的时间，该三者之间存在特定的关系。McCabe&Associates 公司成立于 1976 年，该公司针对软件进行结构测试而开发出了 McCabe Cylomatic Complexity Metric（圈复杂度）技术。将软件复杂度测量的数目作为基础的 Meric，可帮助工程师较为轻松地识别出难于测试和维护的模块。人们将圈复杂度作为评估软件质量的重要标准，利用其来衡量软件的复杂度和质量，奔着在成本、
16、进度以及性能之间寻求平衡的目的来安排工程进度。McCabe 复杂度包括基本复杂度、圈复杂度、设计复杂度、模块设计复杂度和集成复杂度。1.2.31.2.3 测试工具测试工具1.2.3.11.2.3.1 软件测试工具软件测试工具纯软件方式的测试大多都是利用软件仿真技术，在宿主机上模拟目标机，从而在仿真的宿主机上进行大部分的测试。现在大多数的嵌入式测试工具，包括 Logiscope、Coverage Scope 等都采用了这种方式。作为纯软件测试工具 Host/Target 采用的是软件插桩技术。将一些函数或一段语句插入到被测代码中，再利用插入的函数或语句来生成数据，并将这些数据上送到目标系统的共享内存中。与此同时，在目标系统中利用预处理任务对这些数据进行预处理，之后通过目标机的调试口将处理后的数据上送到主机平台，所有的这些都在目标处理器的参与下完成。测试者通过以上过程可以得知程序当前的运行状态。插桩函数和预处理任务作为两个特点必然存在于纯软件的测试方式中。而插桩函数和预处理任务的存在也增大了系统的代码，更有甚者，某些代码会极大地影响系统的运行效率。预
