嵌入式软件测试 - CSDN
精华内容
参与话题
  • 本书具有很强的实践性,不仅适用于专门从事嵌入式系统开发和测试的人员,也适用于那些负责嵌入式系统开发和测试的项目经理或团队领导。同时,本书对于其他系统的软件开发和测试人员也非常有参考价值。
  • 嵌入式软件测试——1.简介

    千次阅读 2019-02-13 11:20:57
    嵌入式软件测试在4个阶段上进行,即模块测试、集成测试、系统测试、硬件/软件集成测试。前3个阶段适用于任何软件的测试,硬件/软件集成测试阶段是嵌入式软件所特有的,目的是验证嵌入式软件与其所控制的硬件设备能否...

    #百科介绍
    一般来说,软件测试有7个基本阶段,即单元或模块测试、集成测试外部功能测试、回归测试、系统测试、验收测试、安装测试。嵌入式软件测试在4个阶段上进行,即模块测试、集成测试、系统测试、硬件/软件集成测试。前3个阶段适用于任何软件的测试,硬件/软件集成测试阶段是嵌入式软件所特有的,目的是验证嵌入式软件与其所控制的硬件设备能否正确地交互。
    一般来说,软件测试有两种基本的方式,即白盒测试方法与黑盒测试方法,嵌入式软件测试也不例外。
    白盒测试或基本代码的测试检查程序的内部设计。根据源代码的组织结构查找软件缺陷,一般要求测试人员对软件的结构和作用有详细的了解,白盒测试与代码覆盖率密切相关,可以在白盒测试的同时计算出测试的代码的覆盖率,保证测试的充分性。把100%的代码都测试到几乎是不可能的, 所以要选择最重要的代码进行白盒测试。由于严格的安全性和可靠性的要求,嵌入式软件测试同非嵌入式软件测试相比,通常要求有更高的代码覆盖率。对于嵌入式软件,白盒测试一般不必在目标硬件上进行,更为实际的方式是在开发环境中通过硬件仿真进行,所以选取的测试工具应该支持在宿主环境中的测试。
    黑盒测试在某些情况下也称为功能测试。这类测试方法根据软件的用途和外部特征查找软件缺陷,不需要了解程序的内部结构。黑盒测试最大的优势在于不依赖代码,而是从实际使用的角度进行测试,通过黑盒测试可以发现白盒测试发现不了的问题。因为黑盒测试与需求紧密相关,需求规格说明的质量会直接影响测试的结果,黑盒测试只能限制在需求的范围内进行。在进行嵌入式软件黑盒测试时,要把系统的预期用途作为重要依据,根据需求中对负载、定时、性能的要求,判断软件是否满足这些需求规范。为了保证正确地测试,还须要检验软硬件之间的接口。嵌入式软件黑盒测试的一个重要方面是极限测试。在使用环境中,通常要求嵌入式软件的失效过程要平稳,所以,黑盒测试不仅要检查软件工作过程,也要检查软件换效过程
    #测试工具
    ##内存分析工具
    ##性能分析工具
    ##GUI测试工具
    ##覆盖分析工具

    展开全文
  • 嵌入式软件测试

    千次阅读 2019-06-22 00:20:24
    嵌入式软件开发过程中,一般来说,花在测试和花在编码的时间比为3:1(实际上可能更多)。这个比例随着你的编程和测试水平的提高而不断下降,但不论怎样,软件测试对一般人来讲很重要。很多年前,一位开发人员为了在...

    在嵌入式软件开发过程中,一般来说,花在测试和花在编码的时间比为3:1(实际上可能更多)。这个比例随着你的编程和测试水平的提高而不断下降,但不论怎样,软件测试对一般人来讲很重要。很多年前,一位开发人员为了在对嵌入式有更深层次的理解,向Oracle询问了这样的一个问题:我怎么才能知道并懂得我的系统到底在干些什么呢? 

      Oracle面对这个问题有些吃惊,因为在当时没有人这么问过,而同时代的嵌入式开发人员问的最多的大都围绕“我怎么才能使程序跑的更快”、“什么编译器最好”等肤浅的问题。所以,面对这个不同寻常却异乎成熟的问题,Oracle感到欣喜并认真回复了他:你的问题很有深度很成熟,因为只有不断地去深入理解才有可能不断地提高水平。并且Oracle为了鼓励这位执着的程序员,把10条关于嵌入式软件开发测试的秘诀告诉了他:

       1、懂得使用工具
       2、尽早发现内存问题
       3、深入理解代码优化
       4、不要让自己大海捞针
       5、重现并隔离问题
       6、以退为进
       7、确定测试的完整性
       8、提高代码质量意味着节省时间
       9、发现它,分析它,解决它
       10、利用初学者的思维
     
    这十条秘诀在业界广为流传,使很多人受益。本文围绕这十条秘诀展开论述。
     

    1.懂得使用工具

      通常嵌入式系统对可靠性的要求比较高。嵌入式系统安全性的失效可能会导致灾难性的后果,即使是非安全性系统,由于大批量生产也会导致严重的经济损失。这就要求对嵌入式系统,包括嵌入式软件进行严格的测试、确认和验证。随着越来越多的领域使用软件和微处理器控制各种嵌入式设备,对门益复杂的嵌入式软件进行快速有效的测试愈加显得重要。

      就象修车需要工具一样,好的程序员应该能够熟练运用各种软件工具。不同的工具,有不同的使用范围,有不同的功能。使用这些工具,你可以看到你的系统在干些什么,它又占用什么资源,它到底和哪些外界的东西打交道。让你郁闷好几天的问题可能通过某个工具就能轻松搞定,可惜你就是不知道。那么为什么那么多的人总是在折腾个半死之后才想到要用测试工具呢?原因很多,主要有两个。一个是害怕,另一个是惰性。害怕是因为加入测试用具或测试模块到代码需要技巧同时有可能引入新的错误,所以他们总喜欢寄希望于通过不断地修改重编译代码来消除bug,结果却无济于事。懒惰是因为他们习惯了使用printf之类的简单测试手段。下面来介绍一些嵌入式常用的测试工具。

      .源码级调试器[Source-level Debugger]
      这种调试器一般提供单步或多步调试、断点设置、内存检测、变量查看等功能,是嵌入式调试最根本有效的调试方法。比如VxWorks TornadoII提供的gdb就属于这一种。

      .简单实用的打印显示工具[printf]
      printf或其它类似的打印显示工具估计是最灵活最简单的调试工具。打印代码执行过程中的各种变量可以让你知道代码执行的情况。但是,printf对正常的代码执行干扰比较大(一般printf占用CPU比较长的时间),需要慎重使用,最好设置打印开关来控制打印。

      .ICE或JTAG调试器[In-circuit Emulator]
      ICE是用来仿真CPU核心的设备,它可以在不干扰运算器的正常运行情况下,实时的检测CPU的内部工作情况。像桌面调试软件所提供的:复杂的条件断点、先进的实时跟踪、性能分析和端口分析这些功能,它也都能提供。ICE一般都有一个比较特殊的CPU,称为外合(bond-out)CPU。这是一种被打开了封装的CPU,并且通过特殊的连接,可以访问到CPU的内部信号,而这些信号,在CPU被封装时,是没法“看到”的。当和工作站上强大的调试软件联合使用时,ICE就能提供你所能找到的最全面的调试功能。但ICE同样有一些缺点:昂贵;不能全速工作;同样,并不是所有的CPU都可以作为外合CPU的,从另一个角度说,这些外合CPU也不大可能及时的被新出的CPU所更换。JTAG(Joint Test Action Group)虽然它最初开发出来是为了监测IC和电路连接,但是这种串行接口扩展了用途,包括对调试的支持。.ROM监视器[ROM Monitor]

      .ROM监视器[ROM Monitor]
       ROM监控器是一小程序,驻留在嵌入系统ROM中,通过串行的或网络的连接和运行在工作站上的调试软件通信。这是一种便宜的方式,当然也是最低端的技术。它除了要求一个通信端口和少量的内存空间外,不需要其它任何专门的硬件。并提供了如下功能:下载代码、运行控制、断点、单步步进、以及观察、修改寄存器和内存。因为ROM监控器是操作软件的一部分,只有当你的应用程序运行时,它才会工作。如果你想检查CPU和应用程序的状态,你就必须停下应用程序,再次进入ROM监控器。

      .Data监视器[Data Monitor]
      这种监视器在不停止CPU运行的情况下不仅可以显示指定变量内容,还可以收集并以图形形式显示各个变量的变化过程。

      .OS监视器[Operating System Monitor]
      操作系统监视器可以显示诸如任务切换、信号量收发、中断等事件。一方面,这些监视器能够为你呈现事件之间的关系和时间联系;另一方面,还可以提供对信号量优先级反转、死锁和中断延时等问题的诊断。

      .性能分析工具[Profiler]
      可以用来测试CPU到底耗在那里。profiler工具可以让你知道系统的瓶颈在那里、CPU的使用率以及需要优化的地方。

      .内存测试工具[Memory Teseter]
      可以找到内存使用的问题所在,比如内存泄露、内存碎片、内存崩溃等问题。如果发现系统出现一些不可预知的或间歇性的问题,就应该使用内存测试工具测测看。

      .运行跟踪器[Execution Tracer]
      可以显示CPU执行了哪些函数、谁在调用、参数是什么、何时调用等情况。这种工具主要用于测试代码逻辑,可以在大量的事件中发现异常的那些。

      .覆盖工具[Coverage Tester]
      主要显示CPU具体执行了那些代码,并让你知道那些代码分支没有被执行到。这样有助于提高代码质量并消除无用代码。

      .GUI测试工具[GUI Tester]
      很多嵌入式应用带有某种形式的图形用户界面进行交互,有些系统性能测试足根掘用户输入响应时间进行的。GUI测试工具可以作为脚本工具有开发环境中运行测试用例,其功能包括对操作的记录和回放、抓取屏幕显示供以后分析和比较、设置和管理测试过程(Rational公司的robot和Mercury的Loadrunner工具是杰出的代表)。很多嵌入式设备没有GUI,但常常可以对嵌入式设备进行插装来运行GUI测试脚本,虽然这种方式可能要求对被测代码进行更改,但是节省了功能测试和回归测试的时间。

      .自制工具[Home-made tester]
      在嵌入式应用中,有时候为了特定的目的,需要自行编写一些工具来达到某种测试目的。本人曾经编写的视频流录显工具在测试视频会议数据流向和变化上帮了大忙,帮公司找到了几个隐藏很深的bug。
     

    2.尽早发现内存问题

      内存问题危害很大,不容易排查,主要有三种类型:内存泄露、内存碎片和内存崩溃。对于内存问题态度必须要明确,那就是早发现早“治疗”。在软件设计中,内存泄露的“名气”最大,主要由于不断分配的内存无法及时地被释放,久而久之,系统的内存耗尽。即使细心的编程老手有时后也会遭遇内存泄露问题。有测试过内存泄露的朋友估计都有深刻地体验,那就是内存泄露问题一般隐藏很深,很难通过代码阅读来发现。有些内存泄露甚至可能出现在库当中。有可能这本身是库中的bug,也有可能是因为程序员没有正确理解它们的接口说明文档造成错用。

      在很多时候,大多数的内存泄露问题无法探测,但可能表现为随机的故障。程序员们往往会把这种现象怪罪于硬件问题。如果用户对系统稳定性不是很高,那么重启系统问题也不大;但,如果用户对系统稳定很高,那么这种故障就有可能使用户对产品失去信心,同时也意味着你的项目是个失败的项目。由于内存泄露危害巨大,现在已经有许多工具来解决这个问题。这些工具通过查找没有引用或重复使用的代码块、垃圾内存收集、库跟踪等技术来发现内存泄露的问题。每个工具都有利有弊,不过总的来说,用要比不用好。总之,负责的开发人员应该去测试内存泄露的问题,做到防患于未然。

      内存碎片比内存泄露隐藏还要深。随着内存的不断分配并释放,大块内存不断分解为小块内存,从而形成碎片,久而久之,当需要申请大块内存是,有可能就会失败。如果系统内存够大,那么坚持的时间会长一些,但最终还是逃不出分配失败的厄运。在使用动态分配的系统中,内存碎片经常发生。目前,解决这个问题最效的方法就是使用工具通过显示系统中内存的使用情况来发现谁是导致内存碎片的罪魁祸首,然后改进相应的部分。

      由于动态内存管理的种种问题,在嵌入式应用中,很多公司干脆就禁用malloc/free的以绝后患。  

      内存崩溃是内存使用最严重的结果,主要原因有数组访问越界、写已经释放的内存、指针计算错误、访问堆栈地址越界等等。这种内存崩溃造成系统故障是随机的,而且很难查找,目前提供用于排查的工具也很少。

      总之,如果要使用内存管理单元的话,必须要小心,并严格遵守它们的使用规则,比如谁分配谁释放。


    3.深入理解代码优化  

      讲到系统稳定性,人们更多地会想到实时性和速度,因为代码效率对嵌入式系统来说太重要了。知道怎么优化代码是每个嵌入式软件开发人员必须具备的技能。就象女孩子减肥一样,起码知道她哪个地方最需要减,才能去购买减肥药或器材来减掉它。可见,代码优化的前提是找到真正需要优化的地方,然后对症下药,优化相应部分的代码。前面提到的profile(性能分析工具,一些功能齐全IDE都提供这种内置的工具)能够记录各种情况比如各个任务的CPU占用率、各个任务的优先级是否分配妥当、某个数据被拷贝了多少次、访问磁盘多少次、是否调用了网络收发的程序、测试代码是否已经关闭等等。

      但是,profile工具在分析实时系统性能方面还是有不够的地方。一方面,人们使用profile工具往往是在系统出现问题即CPU耗尽之后,而profile工具本身对CPU占用较大,所以profile对这种情况很可能不起作用。根据Heisenberg效应,任何测试手段或多或少都会改变系统运行,这个对profiler同样适用!  总之,提高运行效率的前提是你必须要知道CPU到底干了些什么干的怎么样。

    4.不要让自己大海捞针

      大海捞针只是对调试的一种生动比喻。经常听到组里有人对自己正在调试的代码说shit!可以理解,因为代码不是他写的,他有足够的理由去shit bug百出的代码,只要他自己不要写出这种代码,否则有一天同组的其它人可能同样会shit他写的代码。为何会有大海捞针呢?肯定是有人把针掉到海里咯;那针为何会掉在海里呢?肯定是有人不小心或草率呗。所以当你在抱怨针那么难找的时候,你是否想过是你自己草率地丢掉的。同样,当你调试个半死的时候,你是否想过你要好好反省一下当初为了寻求捷径可能没有严格地遵守好的编码设计规范、没有检测一些假设条件或算法的正确性、没有将一些可能存在问题的代码打上记号呢?

      如果你确实已经把针掉在海里是,为了防止在找到之前刺到自己,你必须要做一些防范工作,比如戴上安全手套。同样,为了尽能地暴露和捕捉问题根源,我们可以设计比较全面的错误跟踪代码。怎么来做呢?尽可能对每个函数调用失败作出处理,尽可能检测每个参数输入输出的有效性包括指针以及检测是否过多或过少地调用某个过程。错误跟踪能够让你知道你大概把针掉在哪个位置。


    5.重现并隔离问题  

      如果你不是把针掉在大海了,而是掉在草堆里,那要好办些。因为至少我们可以把草堆分成很多块,一块一块的找。对于模块独立的大型项目,使用隔离方法往往是对付那些隐藏极深bug的最后方法。如果问题的出现是间歇性的,我们有必要设法去重现它并记录使其重现的整个过程以备在下一次可以利用这些条件去重现问题。如果你确信可以使用记录的那些条件去重现问题,那么我们就可以着手去隔离问题。怎么隔离呢?我们可以用#ifdef把一些可能和问题无关的代码关闭,把系统最小化到仍能够重现问题的地步。如果还是无法定位问题所在,那么有必要打开“工具箱”了。可以试着用ICE或数据监视器去查看某个可疑变量的变化;可以使用跟踪工具获得函数调用的情况包括参数的传递;检查内存是否崩溃以及堆栈溢出的问题。


    6.以退为进  

      猎人为了不使自己在森林里迷路,他常常会在树木上流下一些标记,以备自己将来有一天迷路时可以根据这些标记找到出路。对过去代码的修改进行跟踪记录对将来出现问题之后的调试很有帮助。假如有一天,你最近一次修改的程序跑了很久之后忽然死掉了,那么你这时的第一反映就是我到底改动了些什么呢,因为上次修改之前是好的。那么如何检测这次相对于上次的修改呢?没错,代码控制系统SCS或称版本控制系统VCS(Concurrent Version Control,CVS是VCS的演化版本)。将上个版本check in下来后和当前测试版本比较。比较的工具可以是SCS/VCS/CVS自带的diff工具或其它功能更强的比较工具,比如BeyondCompare和ExamDiff。通过比较,记录所有改动的代码,分析所有可能导致问题的可疑代码。


    7.确定测试的完整性  

      你怎么知道你的测试有多全面呢?覆盖测试(coverage testing)可以回答这个问题。覆盖测试工具可以告诉你CPU到底执行了那些代码。好的覆盖工具通常可以告诉你大概20%到40%代码没有问题,而其余的可能存在bug。覆盖工具有不同的测试级别,用户可以根据自己的需要选择某个级别。即使你很确信你的单元测试已经很全面并且没有dead code,覆盖工具还是可以为你指出一些潜在的问题,看下面的代码:if (i >= 0 && (almostAlwaysZero == 0 || (last = i)))如果almostAlwaysZero为非0,那么last=i赋值语句就被跳过,这可能不是你所期望的。这种问题通过覆盖工具的条件测试功能可以轻松的被发现。总之,覆盖测试对于提高代码质量很有帮助。 


    8.提高代码质量意味着节省时间

      有研究表明软件开发的时间超过80%被用在下面几个方面:.调试自己的代码(单元测试).调试自己和其他相关的代码(模块间测试).调试整个系统(系统测试)更糟糕的是你可能需要花费10-200倍的时间来找一个bug,而这个bug在开始的时候可能很容易就能找到。一个小bug可能让你付出巨大的代价,即使这个bug对整个系统的性能没有太大的影响,但很可能会影响让那些你可以看得到的部分。所以我们必须要养成良好的编码和测试手段以求更高的代码质量,以便缩短调试的代码。 


    9.发现它,分析它,解决它  

      这世界没有万能的膏药。profile再强大也有力不从心的时候;内存监视器再好,也有无法发现的时候;覆盖工具再好用,也有不能覆盖的地方。一些隐藏很深的问题即使用尽所有工具也有可能无法查到其根源,这时我们能做的就是通过这些问题所表现出来的外在现象或一些数据输出来发现其中的规律或异常。一旦发现任何异常,一定要深入地理解并回溯其根源,直到解决为止。


    10.利用初学者的思维  

      有人这样说过:“有些事情在初学者的脑子里可能有各种各样的情况,可在专家的头脑里可能就很单一”。有时候,有些简单的问题会被想的很复杂,有些简单的系统别设计的很复杂,就是由于你的“专家思维”。当你被问题难住时,关掉电脑,出去走走,把你的问题和你的朋友甚至你的小狗说说,或许他们可以给你意想不到的启发。 总结:嵌入式调试也是一门艺术。就想其它的艺术一样,如果你想取得成功,你必须具备智慧、经验并懂得使用工具。只要我们能够很好地领悟Oracle这十条秘诀,我相信我们在嵌入式测试方面就能够取得成功。

    转载于:https://www.cnblogs.com/dujian/archive/2011/12/01/2270396.html

    展开全文
  • 嵌入式软件测试的10个方法总结

    千次阅读 2017-10-28 18:52:31
    嵌入式软件开发过程中,一般来说,花在测试和花在编码的 时间比为3:1(实际上可能更多)。这个比例随着你的编程和测试水平的提高而不断下降,但不论怎样,软件测试对一般人来讲很重要。很多年前,一位开发人员为了...

    引用:http://blog.csdn.net/tiandijun/article/details/54929378

    在嵌入式软件开发过程中,一般来说,花在测试和花在编码的 时间比为3:1(实际上可能更多)。这个比例随着你的编程和测试水平的提高而不断下降,但不论怎样,软件测试对一般人来讲很重要。很多年前,一位开发人员为了在对嵌入式有更深层次的理解,向Oracle询问了这样的一个问题:我怎么才能知道并懂得我的系统到底在干些什么呢?Oracle面对这个问题有些吃惊,因为在当时没有人这么问过,而同时代的嵌入式开发人员问的最多的大都围绕“我怎么才能使程序跑的更快”、“什么编译器最好”等肤浅的问题。所以,面对这个不同寻常却异乎成熟的问题,Oracle感到欣喜并认真回复了他:你的问题很有深度很成熟,因为只有不断地去深入理解才有可能不断地提高水平。并且Oracle为了鼓励这位执着的程序员,把10条关于嵌入式软件开发测试的秘诀告诉了他。下面我们一起来看看。

      这十条秘诀在业界广为流传,使很多人受益。本文围绕这十条秘诀展开论述。
    1.懂得使用工具
      通常嵌入式系统对可靠性的要求比较高。嵌入式系统安全性的失效可能会导致灾难性的后果,即使是非安全性系统,由于大批量生产也会导致严重的经济损失。这就要求对嵌入式系统,包括嵌入式软件进行严格的测试、确认和验证。随着越来越多的领域使用软件和微处理器控制各种嵌入式设备,对日益复杂的嵌入式软件进行快速有效的测试愈加显得重要。
      就像修车需要工具一样,好的程序员应该能够熟练运用各种软件工具。不同的工具,有不同的使用范围,有不同的功能。使用这些工具,你可以看到你的系统在干些什么,它又占用什么资源,它到底和哪些外界的东西打交道。让你郁闷好几天的问题可能通过某个工具就能轻松搞定,可惜你就是不知道。那么为什么那么多的人总是在折腾个半死之后才想到要用测试工具呢?原因很多,主要有两个。一个是害怕,另一个是惰性。害怕是因为加入测试工具或测试模块到代码需要技巧同时有可能引入新的错误,所以他们总喜欢寄希望于通过不断地修改重编译代码来消除bug,结果却无济于事。懒惰是因为他们习惯了使用printf之类的简单测试手段。下面来介绍一些嵌入式常用的测试工具。
      源码级调试器[Source-levelDebugger]这种调试器一般提供单步或多步调试、断点设置、内存检测、变量查看等功能,是嵌入式调试最根本有效的调试方法。比如VxWorksTornadoII提供的gdb就属于这一种。
      简单实用的打印显示工具[printf]printf或其它类似的打印显示工具估计是最灵活最简单的调试工具。打印代码执行过程中的各种变量可以让你知道代码执行的情况。但是,printf对正常的代码执行干扰比较大(一般printf占用CPU比较长的时间),需要慎重使用,最好设置打印开关来控制打印。
      ICE或JTAG调试器[In- circuitEmulator]ICE是用来仿真CPU核心的设备,它可以在不干扰运算器的正常运行情况下,实时的检测CPU的内部工作情况。像桌面调试软件所提供的:复杂的条件断点、先进的实时跟踪、性能分析和端口分析这些功能,它也都能提供。ICE一般都有一个比较特殊的CPU,称为外合(bond-out)CPU.这是一种被打开了封装的CPU,并且通过特殊的连接,可以访问到CPU的内部信号,而这些信号,在CPU被封装时,是没法 “看到”的。当和工作站上强大的调试软件联合使用时,ICE就能提供你所能找到的最全面的调试功能。但ICE同样有一些缺点:昂贵;不能全速工作;同样,并不是所有的CPU都可以作为外合CPU的,从另一个角度说,这些外合CPU也不大可能及时的被新出的CPU所更换。 JTAG(JointTestActionGroup)虽然它最初开发出来是为了监测IC和电路连接,但是这种串行接口扩展了用途,包括对调试的支持。
      ROM监视器[ROMMonitor]ROM监控器是一小程序,驻留在嵌入系统ROM中,通过串行的或网络的连接和运行在工作站上的调试软件通信。这是一种便宜的方式,当然也是最低端的技术。它除了要求一个通信端口和少量的内存空间外,不需要其它任何专门的硬件。并提供了如下功能:下载代码、运行控制、断点、单步步进、以及观察、修改寄存器和内存。因为ROM监控器是操作软件的一部分,只有当你的应用程序运行时,它才会工作。如果你想检查CPU和应用程序的状态,你就必须停下应用程序,再次进入ROM监控器。
      Data监视器[DataMonitor]这种监视器在不停止CPU运行的情况下不仅可以显示指定变量内容,还可以收集并以图形形式显示各个变量的变化过程。
      OS监视器[OperatingSystemMonitor]操作系统监视器可以显示诸如任务切换、信号量收发、中断等事件。一方面,这些监视器能够为你呈现事件之间的关系和时间联系;另一方面,还可以提供对信号量优先级反转、死锁和中断延时等问题的诊断。
      性能分析工具[Profiler]可以用来测试CPU到底耗在那里。profiler工具可以让你知道系统的瓶颈在那里、CPU的使用率以及需要优化的地方。
      内存测试工具[MemoryTeseter]可以找到内存使用的问题所在,比如内存泄露、内存碎片、内存崩溃等问题。如果发现系统出现一些不可预知的或间歇性的问题,就应该使用内存测试工具测测看。
      运行跟踪器[ExecutionTracer]可以显示CPU执行了哪些函数、谁在调用、参数是什么、何时调用等情况。这种工具主要用于测试代码逻辑,可以在大量的事件中发现异常的那些。
    覆盖工具[CoverageTester]主要显示CPU具体执行了那些代码,并让你知道那些代码分支没有被执行到。这样有助于提高代码质量并消除无用代码。
      GUI测试工具[GUITester]很多嵌入式应用带有某种形式的图形用户界面进行交互,有些系统性能测试是根据用户输入响应时间进行的。GUI测试工具可以作为脚本工具有开发环境中运行测试用例,其功能包括对操作的记录和回放、抓取屏幕显示供以后分析和比较、设置和管理测试过程(Rational 公司的robot和Mercury的Loadrunner工具是杰出的代表)。很多嵌入式设备没有GUI,但常常可以对嵌入式设备进行插装来运行GUI测试脚本,虽然这种方式可能要求对被测代码进行更改,但是节省了功能测试和回归测试的时间。
      自制工具[Home-madetester]在嵌入式应用中,有时候为了特定的目的,需要自行编写一些工具来达到某种测试目的。本人曾经编写的视频流录显工具在测试视频会议数据流向和变化上帮了大忙,帮公司找到了几个隐藏很深的bug。
    2.尽早发现内存问题
      内存问题危害很大,不容易排查,主要有三种类型:内存泄露、内存碎片和内存崩溃。对于内存问题态度必须要明确,那就是早发现早“治疗”。在软件设计中,内存泄露的“名气”最大,主要由于不断分配的内存无法及时地被释放,久而久之,系统的内存耗尽。即使细心的编程老手有时后也会遭遇内存泄露问题。有测试过内存泄露的朋友估计都有深刻地体验,那就是内存泄露问题一般隐藏很深,很难通过代码阅读来发现。有些内存泄露甚至可能出现在库当中。有可能这本身是库中的bug,也有可能是因为程序员没有正确理解它们的接口说明文档造成错用。
      在很多时候,大多数的内存泄露问题无法探测,但可能表现为随机的故障。程序员们往往会把这种现象怪罪于硬件问题。如果用户对系统稳定性不是很高,那么重启系统问题也不大;但,如果用户对系统稳定很高,那么这种故障就有可能使用户对产品失去信心,同时也意味着你的项目是个失败的项目。由于内存泄露危害巨大,现在已经有许多工具来解决这个问题。这些工具通过查找没有引用或重复使用的代码块、垃圾内存收集、库跟踪等技术来发现内存泄露的问题。每个工具都有利有弊,不过总的来说,用要比不用好。总之,负责的开发人员应该去测试内存泄露的问题,做到防患于未然。
      内存碎片比内存泄露隐藏还要深。随着内存的不断分配并释放,大块内存不断分解为小块内存,从而形成碎片,久而久之,当需要申请大块内存是,有可能就会失败。如果系统内存够大,那么坚持的时间会长一些,但最终还是逃不出分配失败的厄运。在使用动态分配的系统中,内存碎片经常发生。目前,解决这个问题最效的方法就是使用工具通过显示系统中内存的使用情况来发现谁是导致内存碎片的罪魁祸首,然后改进相应的部分。
    由于动态内存管理的种种问题,在嵌入式应用中,很多公司干脆就禁用malloc/free的以绝后患。
      内存崩溃是内存使用最严重的结果,主要原因有数组访问越界、写已经释放的内存、指针计算错误、访问堆栈地址越界等等。这种内存崩溃造成系统故障是随机的,而且很难查找,目前提供用于排查的工具也很少。
      总之,如果要使用内存管理单元的话,必须要小心,并严格遵守它们的使用规则,比如谁分配谁释放。
    3.深入理解代码优化
      讲到系统稳定性,人们更多地会想到实时性和速度,因为代码效率对嵌入式系统来说太重要了。知道怎么优化代码是每个嵌入式软件开发人员必须具备的技能。就像女孩子减肥一样,起码知道她哪个地方最需要减,才能去购买减肥药或器材来减掉它。可见,代码优化的前提是找到真正需要优化的地方,然后对症下药,优化相应部分的代码。前面提到的profile(性能分析工具,一些功能齐全IDE都提供这种内置的工具)能够记录各种情况比如各个任务的CPU占用率、各个任务的优先级是否分配妥当、某个数据被拷贝了多少次、访问磁盘多少次、是否调用了网络收发的程序、测试代码是否已经关闭等等。
      但是,profile工具在分析实时系统性能方面还是有不够的地方。一方面,人们使用profile工具往往是在系统出现问题即CPU耗尽之后,而 profile工具本身对CPU占用较大,所以profile对这种情况很可能不起作用。根据Heisenberg效应,任何测试手段或多或少都会改变系统运行,这个对profiler同样适用!
      总之,提高运行效率的前提是你必须要知道CPU到底干了些什么干的怎么样。
    4.不要让自己大海捞针
      大海捞针只是对调试的一种生动比喻。经常听到组里有人对自己正在调试的代码说shit!可以理解,因为代码不是他写的,他有足够的理由去 shitbug百出的代码,只要他自己不要写出这种代码,否则有一天同组的其它人可能同样会shit他写的代码。为何会有大海捞针呢?肯定是有人把针掉到海里咯;那针为何会掉在海里呢?肯定是有人不小心或草率呗。所以当你在抱怨针那么难找的时候,你是否想过是你自己草率地丢掉的。同样,当你调试个半死的时候,你是否想过你要好好反省一下当初为了寻求捷径可能没有严格地遵守好的编码设计规范、没有检测一些假设条件或算法的正确性、没有将一些可能存在问题的代码打上记号呢?关于如何写高质量请参考林锐的《高质量c++/c编程指南》或《关于C的0x8本“经书》。
      如果你确实已经把针掉在海里是,为了防止在找到之前刺到自己,你必须要做一些防范工作,比如戴上安全手套。同样,为了尽能地暴露和捕捉问题根源,我们可以设计比较全面的错误跟踪代码。怎么来做呢?尽可能对每个函数调用失败作出处理,尽可能检测每个参数输入输出的有效性,包括指针以及检测是否过多或过少地调用某个过程。错误跟踪能够让你知道你大概把针掉在哪个位置。
    5.重现并隔离问题
      如果你不是把针掉在大海了,而是掉在草堆里,那要好办些。因为至少我们可以把草堆分成很多块,一块一块的找。对于模块独立的大型项目,使用隔离方法往往是对付那些隐藏极深bug的最后方法。如果问题的出现是间歇性的,我们有必要设法去重现它并记录使其重现的整个过程以备在下一次可以利用这些条件去重现问题。如果你确信可以使用记录的那些条件去重现问题,那么我们就可以着手去隔离问题。怎么隔离呢?我们可以用#ifdef把一些可能和问题无关的代码关闭,把系统最小化到仍能够重现问题的地步。如果还是无法定位问题所在,那么有必要打开“工具箱”了。可以试着用ICE或数据监视器去查看某个可疑变量的变化;可以使用跟踪工具获得函数调用的情况包括参数的传递;检查内存是否崩溃以及堆栈溢出的问题。
     6.以退为进
      猎人为了不使自己在森林里迷路,他常常会在树木上流下一些标记,以备自己将来有一天迷路时可以根据这些标记找到出路。对过去代码的修改进行跟踪记录对将来出现问题之后的调试很有帮助。假如有一天,你最近一次修改的程序跑了很久之后忽然死掉了,那么你这时的第一反映就是我到底改动了些什么呢,因为上次修改之前是好的。那么如何检测这次相对于上次的修改呢?没错,代码控制系统SCS或称版本控制系统 VCS(ConcurrentVersionControl,CVS是VCS的演化版本)。将上个版本checkin下来后和当前测试版本比较。比较的工 具可以是SCS/VCS/CVS自带的diff工具或其它功能更强的比较工具,比如BeyondCompare和 ExamDiff.通过比较,记录所有改动的代码,分析所有可能导致问题的可疑代码。
    7.确定测试的完整性
      你怎么知道你的测试有多全面呢?覆盖测试(coveragetesting)可以回答这个问题。覆盖测试工具可以告诉你CPU到底执行了那些代码。好的覆盖工具通常可以告诉你大概20%到40% 代码没有问题,而其余的可能存在bug.覆盖工具有不同的测试级别,用户可以根据自己的需要选择某个级别。即使你很确信你的单元测试已经很全面并且没有 deadcode,覆盖工具还是可以为你指出一些潜在的问题,看下面的代码:if(i>=0&& (almostAlwaysZero==0||(last=i)))如果almostAlwaysZero为非0,那么last=i赋值语句就被跳过,这可能不是你所期望的。这种问题通过覆盖工具的条件测试功能可以轻松的被发现。总之,覆盖测试对于提高代码质量很有帮助。
     8.提高代码质量意味着节省时间
      有研究表明软件开发的时间超过80%被用在下面几个方面:调试自己的代码(单元测试)。调试自己和其他相关的代码(模块间测试)。调试整个系统(系统测试),更糟糕的是你可能需要花费10-200倍的时间来找一个 bug,而这个bug在开始的时候可能很容易就能找到。一个小bug可能让你付出巨大的代价,即使这个bug对整个系统的性能没有太大的影响,但很可能会影响让那些你可以看得到的部分。所以我们必须要养成良好的编码和测试手段以求更高的代码质量,以便缩短调试的代码。
     9.发现它,分析它,解决它
      这世界没有万能的膏药。profile再强大也有力不从心的时候;内存监视器再好,也有无法发现的时候;覆盖工具再好用,也有不能覆盖的地方。一些隐藏很深的问题即使用尽所有工具也有可能无法查到其根源,这时我们能做的就是通过这些问题所表现出来的外在现象或一些数据输出来发现其中的规律或异常。一旦发现任何异常,一定要深入地理解并回溯其根源,直到解决为止。
     10.利用初学者的思维
      有人这样说过:“有些事情在初学者的脑子里可能有各种各样的情况,可在专家的头脑里可能就很单一”。有时候,有些简单的问题会被想的很复杂,有些简单的系统被设计得很复杂,就是由于你的“专家思维”。当你被问题难住时,关掉电脑,出去走走,把你的问题和你的朋友甚至你的小狗说说,或许他们可以给你意想不到的启发。
      总结:嵌入式调试也是一门艺术。就想其它的艺术一样,如果你想取得成功,你必须具备智慧、经验并懂得使用工具。只要我们能够很好地领悟Oracle这十条秘诀,我相信我们在嵌入式测试方面就能够取得成功。

    展开全文
  • 嵌入式软件测试工具和测试方法

    千次阅读 2015-08-04 11:31:24
    嵌入式软件有其特殊的失效判定准则,但是,嵌入式软件测试的目的与非嵌入式软件是相同的。在嵌入式系统设计中,软件正越来越多地取代硬件,以降低系统的成本,获得更大的灵活性,这就需要使用更好的软件测试方法和...

    http://www.cnblogs.com/emanlee/archive/2009/07/01/1514621.html

    摘要:软件测试的目的是保证软件满足需求规格说明。嵌入式软件有其特殊的失效判定准则,但是,嵌入式软件测试的目的与非嵌入式软件是相同的。在嵌入式系统设计中,软件正越来越多地取代硬件,以降低系统的成本,获得更大的灵活性,这就需要使用更好的软件测试方法和软件测试工具进行嵌入式和实时软件测试。本文讨论可应用于嵌入式软件的测试方法;介绍现有嵌入式软件的测试工具。

    一、 嵌入式软件的测试工具

    用于辅助嵌入式软件测试的工具很多,下面对几类比较有用的有关嵌入式软件的测试工具加以介绍和分析。

    1 内存分析工具

    在嵌入式系统中,内存约束通常是有限的。内存分析工具用来处理在动态内存分配中存在的缺陷。当动态内存被错误地分配后,通常难以再现,可能导致的失效难以追踪,使用内存分析工具可以避免这类缺陷进入功能测试阶段。目前有两类内存分析工具--软件的和硬件的。基于软件的内存分析工具可能会对代码的性能造成很大影响,从而严重影响实时操作;基于硬件的内存分析工具价格昂贵,而且只能在工具所限定的运行环境中使用。

    2 性能分析工具

    在嵌入式系统中,程序的性能通常是非常重要的。经常会有这样的要求,在特定时间内处理一个中断,或生成具有特定定时要求的一帧。开发人员面临的问题是决定应该对哪一部分代码进行优化来改进性能,常常会花大量的时间去优化那些对性能没有任何影响的代码。性能分析工具会提供有关的数据,说明执行时间是如何消耗的,是什么时候消耗的,以及每个例程所用的时间。根据这些数据,确定哪些例程消耗大部分执行时间,从而可以决定如何优化软件,获得更好的时间性能。对于大多数应用来说,大部分执行时间用在相对少量的代码上,费时的代码估计占所有软件总量的5%~20%。性能分析工具不仅能指出哪些例程花费时间,而且与调试工具联合使用可以引导开发人员查看需要优化的特定函数,性能分析工具还可以引导开发人员发现在系统调用中存在的错误以及程序结构上的缺陷。

    3 GUI测试工具

    很多嵌入式应用带有某种形式的图形用户界面进行交互,有些系统性能测试是根据用户输入响应时间进行的。GUI测试工具可以作为脚本工具在开发环境中运行测试用例,其功能包括对操作的记录和回放、抓取屏幕显示供以后分析和比较、设置和管理测试过程。很多嵌入式设备没有GUI,但常常可以对嵌入式设备进行插装来运行GUI测试脚本。虽然这种方式可能要求对被测代码进行更改,但是节省了功能测试和回归测试的时间。

    4 覆盖分析工具

    在进行白盒测试时,可以使用代码覆盖分析工具追踪哪些代码被执行过。分析过程可以通过插装来完成,插装可以是在测试环境中嵌入硬件,也可以是在可执行代码中加入软件,也可以是二者相结合。测试人员对结果数据加以总结,确定哪些代码被执行过,哪些代码被遗漏了。覆盖分析工具一般会提供有关功能覆盖、分支覆盖、条件覆盖的信息。对于嵌入式软件来说,代码覆盖分析工具可能侵入代码的执行,影响实时代码的运行过程。基于硬件的代码覆盖分析工具的侵入程度要小一些,但是价格一般比较昂贵,而且限制被测代码的数量。

    二、 嵌入式软件的测试方法

    一般来说,软件测试有7个基本阶段,即单元或模块测试、集成测试、外部功能测试、回归测试、系统测试、验收测试、安装测试。嵌入式软件测试在4个阶段上进行,即模块测试、集成测试、系统测试、硬件/软件集成测试。前3个阶段适用于任何软件的测试,硬件/软件集成测试阶段是嵌入式软件所特有的,目的是验证嵌入式软件与其所控制的硬件设备能否正确地交互。

    1 白盒测试与黑盒测试 一般来说,软件测试有两种基本的方式,即白盒测试方法与黑盒测试方法,嵌入式软件测试也不例外。

    白盒测试或基于代码的测试检查程序的内部设计。根据源代码的组织结构查找软件缺陷,一般要求测试人员对软件的结构和作用有详细的了解。白盒测试与代码覆盖率密切相关,可以在白盒测试的同时计算出测试的代码覆盖率,保证测试的充分性。把100%的代码都测试到几乎是不可能的,所以要选择最重要的代码进行白盒测试。由于严格的安全性和可靠性的要求,嵌入式软件测试同非嵌入式软件测试相比,通常要求有更高的代码覆盖率。对于嵌入式软件,白盒测试一般不必在目标硬件上进行,更为实际的方式是在开发环境中通过硬件仿真进行,所以选取的测试工具应该支持在宿主环境中的测试。

    黑盒测试在某些情况下也称为功能测试。这类测试方法根据软件的用途和外部特征查找软件缺陷,不需要了解程序的内部结构。黑盒测试最大的优势在于不依赖代码,而是从实际使用的角度进行测试,通过黑盒测试可以发现白盒测试发现不了的问题。因为黑盒测试与需求紧密相关,需求规格说明的质量会直接影响测试的结果,黑盒测试只能限制在需求的范围内进行。在进行嵌入式软件黑盒测试时,要把系统的预期用途作为重要依据,根据需求中对负载、定时、性能的要求,判断软件是否满足这些需求规范。为了保证正确地测试,还须要检验软硬件之间的接口。嵌入式软件黑盒测试的一个重要方面是极限测试。在使用环境中,通常要求嵌入式软件的失效过程要平稳,所以,黑盒测试不仅要检查软件工作过程,也要检查软件失效过程。

    2 目标环境测试和宿主环境测试

    在嵌入式软件测试中,常常要在基于目标的测试和基于宿主的测试之间作出折衷。基于目标的测试消耗较多的经费和时间,而基于宿主的测试代价较小,但毕竟是在模拟环境中进行的。目前的趋势是把更多的测试转移到宿主环境中进行,但是,目标环境的复杂性和独特性不可能完全模拟。

    在两个环境中可以发现不同的软件缺陷,重要的是对目标环境和宿主环境的测试内容有所选择。在宿主环境中,可以进行逻辑或界面的测试、其它非实时测试以及与硬件无关的测试。在模拟或宿主环境中的测试消耗时间通常相对较少,用调试工具可以更快地完成调试和测试任务。而与定时问题有关的白盒测试、中断测试、硬件接口测试只能在目标环境中进行。在软件测试周期中,基于目标的测试是在较晚的"硬件/软件集成测试"阶段开始的,如果不更早地在模拟环境中进行白盒测试,而是等到"硬件/软件集成测试"阶段进行全部的白盒测试,将耗费更多的财力和人力。

    结论

    嵌入式系统在人类生活中发挥着重要的作用,包括飞行控制器这样的控制系统,以及洗衣机这样的家用电器。目前,嵌入式系统中软件的比重越来越大,也越来越复杂,保证嵌入式软件的可靠性正面临严峻的挑战。

    大多数软件测试方法都可以直接或间接地用于嵌入式软件的测试,但是由于操作系统的实时和嵌入式特性,嵌入式软件测试也面临一些特殊的问题。虽然目前已经有一些针对嵌入式软件的测试和调试工具,但是在有些方面仍存在不足,包括多任务操作系统的并发、非侵入式的测试和调试、嵌入式系统的软件抽象等。对于嵌入式软件测试技术的研究和软件测试工具的开发,仍须要做很多进一步的工作。


    展开全文
  • 嵌入式软件测试之初体验

    千次阅读 2019-07-05 19:26:02
    记得,在2009年初入软件测试这个行业时,是在一家外企,尽管,这家外企在某些方面,有着不足之处,但,这是一家在测试流程这个方面,相对来说,比较规范的一家软件公司。 这家外企,无论是操作系统,还是测试过程中...
  • 嵌入式软件测试的十大方法

    千次阅读 2017-02-08 17:12:49
    嵌入式软件开发过程中,一般来说,花在测试和花在编码的 时间比为3:1(实际上可能更多)。这个比例随着你的编程和测试水平的提高而不断下降,但不论怎样,软件测试对一般人来讲很重要。很多年前,一位开发人员为了...
  • 嵌入式软件测试的基本方法

    万次阅读 2017-02-09 14:32:53
    1、引言 随着数字化时代的到来,大量系统架构复杂、功能日益强大的嵌入式系统正不断进入市场,应用也日趋复杂,这对嵌人式软件的开发技术和测试技术提出了更高的要求。嵌人式系统的复杂性和集成度越来越高,其中的...
  • 嵌入式开发常用工具软件

    万次阅读 2018-09-02 11:59:32
    软件版本控制软件:Git、SVN、CVS bug管理软件:bugzilla 文件管理:有道云笔记、evernote、Wiki Server、Google DOCs 项目文件管理系统:trac Project 代码静态测试:PC-Lint、LogiScope 嵌入式集成开发环境...
  • 嵌入式系统开发流程

    万次阅读 2017-02-19 21:18:18
    一、嵌入式系统开发流程 1、系统需求分析:根据需求,确定设计任务和设计目标,指定设计说明书。 2、体系结构设计:描述...一般情况下嵌入式系统设计的工作大部分都集中在软件设计上,现代软件工程经常采用的方法是
  • 嵌入式软件开发的特点、设计流程、嵌入式软件的结构   一:嵌入式软件开发的特点 1.嵌入式软件设计时更强调软硬件协同工作的效率和稳定性。 2.嵌入式软件的结果通常需要固化在目标系统的储存器或处理器内部...
  • 嵌入式系统硬件组成

    千次阅读 2014-08-04 17:04:33
    嵌入式系统的硬件主要包括:嵌入式处理芯片、嵌入式系统存储器、I/O接口及常用的I/O设备、典型ARM处理芯片以及嵌入式互连通信接口。 嵌入式最小硬件系统有: 1、电源电路 2、时钟电路 3、复位电路 4、JTAG...
  • 关于嵌入式软件架构的一点理解

    千次阅读 2016-01-24 19:54:16
    本人学生,在参与企业开发的过程中了解到关于嵌入式软件框架设计问题,通过不断的深入学习,本人决定在乘着广州的雪意书写此文章。
  • 嵌入式软件工程师的必备知识

    千次阅读 2017-04-17 16:38:55
    嵌入式软件工程师也需要掌握很多知识,并且相对门槛较高,下面我们来说一说 1 了解处理器的相关知识,比如了解x86, arm, mips中的其中一种  相关图书 《编码的奥秘》《深入理解计算机系统》《see mips run》 ...
  • 嵌入式项目开发说明

    2015-12-09 13:50:52
    1.了解嵌入式项目开发方法流程 2.掌握基本的嵌入式项目开发能力 3.串口服务项目实践 4.嵌入式WEB服务器移植 5.数据采集控制系统实践
  • 嵌入式软件测试——初探

    千次阅读 2018-08-11 10:22:58
    软件测试级别包括单元测试,部件(集成)测试,配置项测试与系统测试。 单元测试:检查每个软件单位能否正确的实现设计说明中的功能、性能、接口和其他设计约束等要求,发现单元内可能存在的各种错误。 ...
  • 嵌入式测试自动化(一)

    千次阅读 2018-08-20 12:06:03
    为什么要做测试自动化?  一直以来,看着测试的同事日复一日做着毫无成就可言的重复劳动,总觉得要尽快的推进测试自动化,让他们从繁复的劳动中解脱,以便于留出更多的时间来思考测试方法。  目前公司的一个现状...
  • 基于模块化设计的嵌入式软件测试方法 摘要:分析嵌入式软件的特点,综述传统的软件测试方法;针对嵌入式软件的特点,提出嵌入式软件的四级测试流程和集成测试的测试模型,并结合开发数控系统的实例进行分析。 ...
  • 嵌入式软件测试参考书籍

    千次阅读 2019-06-17 19:18:32
    嵌入式软件测试的几本参考书籍: 1、《嵌入式软件测试》; 2、《嵌入式软件测试 方法、案例与模板详解》; 3、《嵌入式软件测试实用技术》; 4、《嵌入式系统软件测试》 1、《嵌入式软件测试》 《嵌入式...
  • 摘要:随着计算机技术的普及,软件系统已经深入到生活的各个方面,从普通的计算机软件,到银行或超市的终端系统,甚至到手机的软件系统。...对于嵌入式软件系统,因其多样性,基于操作系统,使用的开发环...
1 2 3 4 5 ... 20
收藏数 69,373
精华内容 27,749
热门标签
关键字:

嵌入式软件测试