当前位置:文档之家› Trace32 基础配置与调试

Trace32 基础配置与调试

高通平台常用调试Tool介绍1

高通平台的常用的调试tool: QPST, QRCT, QXDM, Trace32(use JTAG) 2013年09月07日?综合?共 4410字?字号小中大?评论关闭 OverView: QPST 综合工具, 传输文件, 查看device的EFS文件系统, 代码烧录 QRCT 测试RF QXDM 看log JTAG trace32调试 QPST,QXDM的使用说明,具体的可以看我上传到csdn的资源文件,我都是看它,看了那个user guide就完全会了,很简单的 QPST是一个针对高通芯片开发的传输软件。简单的说就是用高通处理芯片的手机理论上都可以用 QPST传输文件,可以修改C网机器内部参数的软件。 一次可以track多台电脑 QPST还可进行代码烧入 包括: 5个 client applications ? QPST Configuration monitor the status of: Active phones Available serial ports Active clients To start QPST Configuration, from the Start menu, select Programs → QPS T → QPST Configuration. ? Service Programming provide service programming for CDMA phones that contain Qual comm ASICs. With it, you can save SP data to a file, then download the data in that file to multiple pho nes. The SP application accesses settings regardless of the phone’ s internal memory implementation. It is feature- aware and displays settings pages appropriate to the phone being programmed. To start SP, from the Start menu, select Programs → QPST → Service Programming.

TRACE32-使用

目录 1.系统组成 1.1硬件 1.1.1主机 1.1.2调试电缆 1.1.3通过USB与PC连接 1.1.4通过JTAG与目标连接 1.1.5对PC硬件的要求 1.1.6对目标板硬件的要求 1.1.7加电 1.2软件 1.2.1驱动程序的安装 2.PowerView调试界面的使用 3.1 打开调试界面 3.2 JTAG连接设置 3.3 运行脚本文件 3.4 观察/修改寄存器 3.5 观察/修改存储器 3.6 下载程序 3.7 观察符号表 3.8 打开程序列表窗口 3.9 单步执行程序 3.10 设置软件断点 3.11 设置Onchip硬件断点 3.12 设置数据观察断点 3.13 全速运行程序 3.14 停止运行程序 3.15 观察变量 3.16 观察堆栈 3.17 在线Flash编程 1.系统组成 TRACE-ICP调试系统由硬件和软件两部分组成,硬件是自行研发的,软件是第三方的。 下面分成硬件和软件两部分来介绍。 1.1硬件 TRACE-ICP的硬件设计采用模块化的结构,分为主机和调试电缆两部分。 1.1.1主机 下面三张照片是TRACE-ICP主机的顶视图和前视图以及后视图。 图一、TRACE-ICP顶视图

图二、TRACE-ICP前视图 图三、TRACE-ICP后视图 在图二中的连接器是标准DB25/M连接器,用于连接调试电缆。在图三 中,有两个连接器和一个LED指示灯。左边的连接器是USB接口,用于 通过USB电缆和PC连接。右边的连接器是TRACE-ICP的外接5VDC电 源接口。TRACE-ICP可以通过USB供电,在USB供电不足的情况下, 使用外接电源。LED指示灯是TRACE-ICP的电源指示灯。 1.1.2调试电缆 下图是TRACE-ICP的调试电缆的照片。 图四、TRACE-ICP的调试电缆

TRACE32SimulatorforARM

1 前言 Trace32 ICD ARM USB能实时DEBUG代码在手机中的运行情况,功能强大,但需要连接TRACE32硬件才能工作。更重要的是,对于概率性死机的BUG,用Trace32 ICD ARM USB应该是很难找到问题,因为你不能确定手机什么时候crash。 其实TRACE32还有一个WIN32版本,用户只需要把手机crash时候的寄存器信息dump出来,就能在WIN32下定位到死在代码的那一行,非常类似于EMP 平台的CHKARM工具。 这就是本文将要描述的Trace32 Simulator for ARM工具。 2 安装 WIN32版的TRACE32需要重新安装,安装文件和硬件版TRACE32是一样的,只是安装时候的选项不同,而且WIN32版的需要安装在不同的目录下(比如trace32-win32)。 z运行安装文件\trace32\bin\setup\setup.exe。首先设置安装路径,注意不要和硬件版TRACE32安装在同一个目录下,请新建一个文件夹(比如 trace32-win32)

z选择【New Installation】,然后Next z选择【Simulator】,这个是WIN32版TRACE32的选项(硬件版TRACE32是选择第2项,注意不要搞错了)

z选择默认值,然后Next z选择【SIM ARM7 ARM9 ARM10 ARM11】,和硬件版TRACE32一样

z安装中,安装完毕后就可以使用了。 3 使用 首先请确保你有保存当前手机软件的原始ARM文件。 手机死机时,按“#”键进入downloading模式。 z运行【QPST】→【Memory Debug】,制指定数据线端口

使用 Trace32 对 FLASH 编程

使用 Trace32 对 FLASH 编程 随着软硬件复杂性的增加,在嵌入式系统开发中,调试器对项目的开发进度、质量起着越来越重要的作用。在众多的调试器中,Lauterbach 公司的 Trace32 凭借其强大的功能,出色的性能,成为目前嵌入式系统开发中,尤其是高端系统中普遍采用的调试工具。 Trace32 除了具有对代码设置断点、跟踪调试等常规的功能以外,还能够控制对目标系统的FLASH 进行编程。本文首先对比了 Trace32 FLASH 编程的两种方式:"Emulator controlled flash programming" 和 "Target controlled flash programming",指出"Target controlled flash programming"方式的优点;然后介绍了与 FLASH 编程相关的 Trace32 脚本命令,以及Trace32 脚本命令与 FLASH 编程软件之间的通信机制;最后,给出了 "Target controlled flash programming" 方式的控制流程。 注:本文中使用的"编程"一词,除了具有对 FLASH 烧写的含义外,还包括擦除、校验等其它对 FLASH 的操作。 一、FLASH 编程的两种方式 对目标系统中的 FLASH 有两种方式进行编程,分别是 "Emulator controlled flash programming" 和"Target controlled flash programming"。 在 "Emulator controlled flash programming" 方式下,所有对 FLASH 编程的操作都是由Emulator 完成的,不使用目标系统的资源。Trace32 软件支持市面上几乎所有的 FLASH芯片,只要在脚本命令 FLASH.Create 中指明目标 FLASH 的型号,地址范围以及总线的配置,用户就可以使用脚本命令直接将数据烧写到 FLASH,不需要编写任何对 FLASH 操作的代码。 在"Target controlled flash programming"方式下,对 FLASH 的编程控制是由运行在目标系统上的 FLASH 编程软件完成的,而这个软件必须由用户自行开发。此时,Trace32通过使用脚本对目标系统内存地址空间的访问,向 FLASH 编程软件传送控制参数和数据。 由于直接在目标系统的处理器上运行,采用"Target controlled flash programming" 方式可以获得比"Emulator controlled flash programming"方式快得多的编程速度。这对于烧写大的文件,以及生产线等场合来说十分重要。另外,只要编写相应的 FLASH 编程软件,用户选择的任何 FLASH 都能够被支持。 因此,对于 FLASH 编程的内容较少,或者对编程的时间要求不高的情况下,可以使用"Emulator controlled flash programming" 方式;但是,对于需要编程较大的文件,而且对速度要求较高的情况下,"Target controlled flash programming" 方式是唯一的选择。本文中只讨论"Target controlled flash programming" 方式。 二、Trace32 脚本 在 Trace32 的界面中,可以使用菜单,鼠标完成操作,也可以完全使用命令操作。事实上,Trace32 内嵌了强大的命令和脚本处理功能。使用 Trace32 的命令不仅可以完成所有的功能,而且可以获得比菜单方式更大的操纵性和灵活性。脚本以 .CMM 为后缀。 下面就介绍 Trace32 中与 FLASH 操作相关的命令,见下表:

trace32使用手册

Trace32软件使用 (亦可见TRACE32-使用.pdf与icd_tutorial.pdf) 一、首先安装软件Trace32。 二、启动软件,Trace32 ICD ARM USB; 2.1 启动之后的调试界面如下图所示。 Pic1. 调试界面 红圈中的“system down”指示目标板已经供电,如果目标板电源电压低或没有的话,红圈的区域会显示“POWER DOWN”。TRACE-ICP通过JTAG 接口的1 脚检测目标板电压,电压范围应该在1.8 到3.3 伏之间。如Pic1中红色字体所指示的那样,调试界面分成五个区域,从上到下依次是主菜单区、快捷按钮区、工作区、行命令输入区、行命令软件区、状态显示区。主菜单区是各种菜单命令的入口区域。快捷按钮区是各种常用命令的快捷使用按钮。用户可以自定义主菜单和快捷按钮。工作区是各种对话框窗口的显示区域。行命令输入区是各种命令通过手动输入执行的区域。行命令软键区是协助用户输入行命令的区域,它提供所有行命令的软键输入方法。状态显示区指示当前的调试状态。 2.2JTAG 连接设置 该设置的作用是告诉调试界面目标板JTAG 链路的设置情况,以便能够正确连接,

这些设置主要包括: 1、选择要调试的处理器型号。 2、是否有多个器件串联在同一个JTAG 链路里,连接顺序如何,每个器件的JTAG IR 寄存器的宽度是多少。(情况一) 3、JTAG 时钟使用TCK 还是RTCK。TCK 由TRACE-ICP 提供,一般情况下选用 10MHz。RTCK 是TRACE-ICP 的TCK 进入目标JTAG 链路之后,从目标JTAG 链路返回的时钟,它与目标处理器的时钟同步。一般情况下,具有睡眠模式的处理器多选用RTCK 作JTAG 时钟,如ARM926EJ-S。(情况二) 4、通过JTAG 与目标连接时,是否要先复位目标板。JTAG 口上的SRST 信号产生复 位信号。(情况三) 5、通过JTAG 与目标连接时,是否要停止目标处理器运行。(情况四) 从主菜单“CPU”中选择“System Settings…”,打开如下图所示对话框。从“CPU”下拉菜单里选择要调试的处理器。 Pic2. System Settings 对话框 对于前面描述的第一种情况,多个器件串联在同一个JTAG 链上,用户需要在图二十三所示的对话框中选择“MultiCore”,打开MultiCore 对话窗口,如下图所示。 Pic3. MultiCore 对话框

trace32仿真器使用教程+

简介 大家可能会对uTrace-ICD比较陌生,简单介绍一下,uTrace-ICD 是TRACE32-ICD的兼容机。在这里我首先感谢国人的努力能让我用很少的RMB用上这么高端仿真器。废话少说,下面我给大家介绍一下uTrace-ICD下具体实现Linux调试的具体过程。 大概介绍一下实现的具体原理,首先要有一块可用的目标板,我选用的是SMDK2410评估板。编译环境是在虚拟VMware+RedHat9.0,调试环境是uTRACE。在这里有个问题:就是在虚拟机下编译的arm linux内核如何传递给安装在Windows下的uTRACE。我用的方法就是通过SMB服务器。在Redhat9.0下配置SMB Server将arm linux的源码包通过网络共享的方式共享给Windows XP。在XP下的Windows 资源管理器中将Redhat9.0共享的arm linux源码包影射为本地的一个虚拟盘比如是:Z盘。这样uTRACE就可以象操作本地盘一样来读取Redhat9.0中的arm linux源码包以及编译生成的内核映像及内核的符号表。 对于uTRACE调试器来说,需要的东东就是包含调试信息的arm linux的内核映像vmlinux。在这里要注意"包含调试信息",arm linux内核配置选项默认可能是不包含调试信息,如果将没有包含调试信息的vmlinux供uTRACE使用是实现不了内核源码级调试的。所以我们在配置arm linux内核时一定要将包含内核调试信息的选项选上。具在

"kernel hacking"下。其次uTRACE调试器需要的就是arm linux内核源码树。调试器的工作原理就是通过给定的地址查找对应的符号表找到对应的符号,以及符号所在文件的路径信息,行信息等,近而找到源程序所对应的函数或变量。 简单介绍了uTRACE调试的基本原理,接下来,具体介绍一下arm linux内核,驱动,及应用层源码级调试的具体实现过程。 具体实现 上一节简单介绍了uTrace-ICD调试的基本原理,下面将详细介绍调试的具体实现过程。 首先介绍一下我用的评估板SMDK2410的具体情况。目标板是nor flash启动,大小为8M,SDRAM配置情况是32M,首地址是 0x30000000。软件配置情况:bootloader为ppcboot2.0,arm linux内核为2.4内核(实现过程对2.6内核也适用)。 第一步:配置虚拟机Redhat9.0编译环境。 安装交叉编译器arm-elf-gcc,解压arm linux源码包到 “\SMDK2410\kernel”下,解压ppcboot到“\SMDK2410\ppcboot-2.0.0”下。 配置SMB Server将“\SMDK2410”目录网络共享出去。在Windows

TRACE32调试常用命令总结

TRACE32的一些常用命令 我们使用Trace32最主要用途有两个:程序下载和程序调试。下载目前各个项目都有相应的.cmm文件(类似于批处理文件.bat),在此文件中,Trace32把对FLASH擦除/编程的插件下载到手机的SRAM中,然后把控制权交给此插件,详细过程就不在此叙述,这里主要是介绍一些我们在程序调试过程中常用的一些命令。 1.把调试用的.elf文件下载到目标板中 命令:d.load.elf *.elf 或者直接输入elf文件路径:d.load.elf d:\p200\surfcr.elf 说明:此命令把.elf文件中的调试符号信息下载到Trace32中,二进制代码下载到目标板中的代码段存储区域。如果代码段对应的存储体是SRAM,那么代码 能够真实的下载到SRAM中(最常见的就是EVB板条死)。如果存储体是FLASH ,由于FLASH程序的擦写需要特殊的命令序列,所以执行完下载命令后,虽然 Trace32没有报错,但实际上代码没有下载进去。这个时候需要用cmm文件把代 码下载到FLASH中去。 2.elf文件下载进去后,在调试之前还需要做一些准备工作 a.map.bonchip 0x0—0x3ffff(FLASH的地址范围) 如果程序下载到SRAM中,此命令不用执行,如果是FLASH,一般情况下都需要执行此条命令,否则无法设置断点,目前大多数CPU在ICD调试模式下只支持两个硬件断点。 b.y.spath + 路径(eg: y.spath d:\z2100\qct) 支持所加路径的C源码以及汇编代码显示。 3.以上工作做完后,就可以利用Trace32强大的调试功能来调试程序了(可惜到现在我 们只是用到了其中的一部分)。 a.查看ARM寄存器。一般使用在调试/查看汇编代码的情况下使用。 b.查看存储器单元以及存储器映射的寄存器内容。注意:MSM5105的寄存器具有只 读和只写属性(SoftWare Interface中有描述),对于只写属性的寄存器,虽然能够看到寄存器的内容,但不可信。

TRACE32调试技巧

TRACE32调试技巧 1. 调试步骤 l 连接好 TRACE32-ICD 和目标板,注意不要带电插拔 JTAG ,容易损坏 TRACE32 或目标板,然后依次打开 TRACE32-ICD 和目标板的电源。 l 开启调试软件 TRACE32 l 设置 CPU 类型,状态等,可以通过命令或菜单,命令如下: sys.reset sys.CPU ARM7TDMI ; 这里设置 CPU 类型 sys.up ; 启动调试,如果正常的话,状态为 system.ready; 否则会报错,需要检查 CPU 设置是否正确,TRACE32 和目标板的连接和电源是否正常 如果调试正常启动后,就可以下载编译好的文件(可以是 .elf 、 .binary 等文件) 到 RAM 或 FLASH 中调试了 l 下载编译文件,命令如下: data.load.elf E:/source/test.elf /PATH E:/source 这里的/PATH选项是用来指明源代码的路径,在调试时TRACE就可以查找到源代码 了。这里 TRACE会根据 .elf 文件里包含的目标代码起始地址加载到 RAM 的对应地址上,也可以指定加载到 RAM 的地址,但须和编译时的设置一致,否则程序不能正常运行。 注: TRACE 也可以把编译目标文件烧录到 flash 中进行调试,需要使用 flash 烧录相关命令,这里就不详述了。 l 然后就可以设置断点进行调试了,如:

break.set 0x0c008000 TRACE32 的断点有两种,一种是硬件断点(在 FLASH 中的断点),另一种是软断点 (在 RAM 中的断点);硬件断点需要 CPU 的支持,如 ARM7 最多只支持 2 个硬件断点,如果使用了软断点的话,就只能使用一个硬断点了;而软断点没有限制,可以设置很多个。 注:在TRACE32中,如果要使用硬件断点,需要先设置好FLASH内存映射范围,如下命令: Map.bonchip 0x0000--0xfffff ; 具体范围根据目标板 FLASH 的范围设置 l 设置好断点就可以正常调试了。 2. 源代码调试 在编译源码的时候,编译成 ( 加 -g 选项 )debug 版本的目标文件(可以是 axf/elf 等格式),用 TRACE32 就可以直接进行源代码调试了。 TRACE32 几乎支持所有的编译器的编译文件,具体格式参见 TRACE32 的帮助。 axf/elf 等编译文件也叫符号文件,即在文件中把源码的符号表(函数 / 变量等)保存下来了,供调试时使用,但里面的符号表只是起定位作用,在调试时还需要有目标源代码,否则只能进行汇编级调试,TRACE32 支持把机器码反汇编成汇编语言进行调试,而且不需要目标文件支持, TRACE32 可以自动从FLASH/RAM 中读取机器码,然后反汇编成汇编代码。 通过 data.load 命令把符号表文件 (.elf 等 ) 下载到目标机器上,指定源代码路径,就可以进行代码调试。 data.load.elf E:/source/test.elf /PATH E:/source 3. 死机定位方法

高通平台编译方法.doc

Qualcomm平台编译之我见 jinjing.zhao@https://www.doczj.com/doc/0319185762.html, 一、平台简介 高通平台的应用层的开发是在brew上进行的,brew提供了很多接口供应用层调用相关的api。高通平台的思想是用c语言实现面向对象的功能,具体通过结构体以及虚表来实现。在oem层中实现具体的api函数,用来填虚表。通过oem层以及service代码的修改,来实现上层应用具体需要的功能。 为了开发界面的方便,高通又在brew的基础上推出了buit,包括widget(控件),form (窗体),decorator(修饰),container(容器)以及model(模型)。 bar文件:资源文件,用高通自带的工具生成,程序运行的时候从此文件中读取字符串以及图片。可以将此文件放到文件系统中,也可以将此文件编译成.c文件,然后再编译成.o 文件,放到代码段里面去。 Mif文件:module imformation file,存放模块的相关信息。可以将此文件放到文件系统中,也可以将此文件编译成.c文件,然后再编译成.o文件,放到代码段里面去。 二、编译解析 平台的编译命令放在了\build\ms目录下。 可以有两种编译方法:一种是使用cmd命令,还有是在cygwin下使用bash脚本。但道理都是一样的,就是执行一个makefile文件dmss6250.mak。 顺序如下: 1)运行cmd,cd到\build\ms目录下,键入ads12; ads12是个批处理命令,功能是为ads1.2,perl,以及gnu设置编译环境变量。 2)执行****.cmd命令。 1、dmss6250.mak 整个编译过程就是在执行这个makefile。 在这个makefile的开头处,我们可以看到 include dmss_flags.min

mtk memroy dump分析流程

mtk memroy dump分析流程: 1.如何抓memory dump。 2.解析memroy dump。 3.tarce 32 分析。

一.如何抓memory dump。 完整的memorydump包含以下文件: 1. memorydump.bin (此文件是透过Catcher保存的,请参考后面的操作步骤) 2. catcher log (*.clg, 此文件是透过Catcher保存的,请参考后面的操作步骤) 3. ELF 文件(\build\\*.elf) (请注意NFB项目会有两个ELF(for Bootloader and for MAUI),请提供for MAUI的,即size较大的) 提示:只有当抓memory dump对应的binary与所提供的ELF文件是同一次编译生成的(需要参考ELF文件中的debug信息),且只有debug版本的ELF文件,我们才能分析,请务必注意!!! 您可以按如下步骤进行: 1. 打开debug选项 before 10A: 在makefile(\make\.mak)中设置CUSTOM_CFLAGS = -g -gtp 10A的项目(因RVCT存在bug, 全部module都开debug会出现link error"out of memory", 请参考下面的说明仅开部分解决问题需要的module, 但init和nvram中包含debug所需的basic 信息, 请确保init和nvram打开debug): (1)确保makefile中--debug --no_debug_macros处于关闭状态,正确设置为CUSTOM_CFLAGS = # --debug --no_debug_macros (2)make\USER_SPECIFIC.mak文件末尾处添加如下两行语句后保存, DEBUG_MODULES = init nvram # means only init and nvram will apply --debug --no_debug_macros, 若有其他module也需要debug symbol, 可以加在nvram后面CUSTOM_CFLAGS := 11A and after(不建议全部模块打开debug,原因同10A): (1)确保makefile中--debug --no_debug_macros处于关闭状态,正确设置为CUSTOM_CFLAGS = # --debug --no_debug_macros (2)makefile中设置CUSTOM_DEBUG_MODULES = INIT NVRAM #means only init and nvram will apply --debug --no_debug_macros, 若有其他module也需要debug symbol, 可以加在nvram后面, 若没有CUSTOM_DEBUG_MODULES定义, 可自行添加 2. 编译生成debug版本(make new), 并Download Binary. 10A及以后的项目, 由于只是部分模块开debug, 可以只m c,r这些模块 3. 打开Memory dump开关; 进入工程模式,选择Misc.\Memory dump, 将其设置为On 提示:该开关默认为关,并且开机时系统会将其恢复成默认值,所以您的设置只对当次开机有效,若需抓Memory dump,请在每次开机的重新开启此开关 若无法进入工模操作请尝试修改代码来打开,方法如下: (1)在application_initialize之前extern kal_uint32 INT_MemoryDumpFlag; (2)在application_initialize中调用mainp的上一行添加INT_MemoryDumpFlag = 0x26409001; [Note]: 项目MP时请务必删除上述代码, 否则手机在end user端遇到异常时无法自动重启 4. 连上Catcher(Catcher 的filter设置为Field Trial),复制问题; 5. 当发生异常时,选择Advance\Memory Dump,在弹出的窗口中选择Start按钮开始Memory

TRACE32的常用命令和调试技巧

TRACE32的常用命令 TRACE32是由德国Lauterbach公司研制开发的一款仿真测试工具。我们使用Trace32最主要用途有两个:程序下载和程序调试。下载目前各个项目都有相应的.cmm文件(类似于批处理文件.bat),在此文件中,Trace32把对FLASH擦除/编程的插件下载到手机的SRAM中,然后把控制权交给此插件,详细过程就不在此叙述,这里主要是介绍一些我们在程序调试过程中常用的一些命令。 1.把调试用的.elf文件下载到目标板中 命令:d.load.elf *.elf 或者直接输入elf文件路径:d.load.elf d:\p200\surfcr.elf 说明:此命令把.elf文件中的调试符号信息下载到Trace32中,二进制代码下载到目标板中的代码段存储区域。如果代码段对应的存储体是SRAM,那么代码 能够真实的下载到SRAM中(最常见的就是EVB板条死)。如果存储体是FLASH ,由于FLASH程序的擦写需要特殊的命令序列,所以执行完下载命令后,虽然 Trace32没有报错,但实际上代码没有下载进去。这个时候需要用cmm文件把代 码下载到FLASH中去。 2.elf文件下载进去后,在调试之前还需要做一些准备工作 a.map.bonchip 0x0—0x3ffff(FLASH的地址范围) 如果程序下载到SRAM中,此命令不用执行,如果是FLASH,一般情况下都需要执行此条命令,否则无法设置断点,目前大多数CPU在ICD调试模式下只支持两个硬件断点。 b.y.spath + 路径(eg: y.spath d:\z2100\qct) 支持所加路径的C源码以及汇编代码显示。 3.以上工作做完后,就可以利用Trace32强大的调试功能来调试程序了(可惜到现在我 们只是用到了其中的一部分)。 a.查看ARM寄存器。一般使用在调试/查看汇编代码的情况下使用。 b.查看存储器单元以及存储器映射的寄存器内容。注意:MSM5105的寄存器具有只 读和只写属性(SoftWare Interface中有描述),对于只写属性的寄存器,虽然能够看到寄存器的内容,但不可信。

Trace32测试工具

软件线测试方法与软件测试工具 ---------------------------------------------------------------------------------------------------------------------- 摘要:本文简要介绍了软件测试基本理论和基本概念,分析软件测试在在产品研发过程中的地位与作用,并依据本人多年嵌入式系统开发应用和从事软件测试的经验,提出了针对我国企业软件测试现状的软件测试解决方案,与此同时向大家介绍了几种高效,实用的软件测试工具。 关键字:嵌入式软件软件测试 引言:软件已成为现代智能系统中的核心和灵魂,其规模和复杂性随系统规模增长不断提高,软件的质量和开发周期对产品的最终质量和上市时间有举足轻重的影响力,因此软件工程管理、软件分析与测试已成为研究和应用的热点。本文结合软件工程管理、软件分析与测试在嵌入式软件的开发中应用经验与体会,指出了现今人们对软件分析与测试应用于产品开发中存在的误区,并针对这一误区,提出了针对我国企业如何根椐自身现状配置软件测试工具及解决方案。 一. 软件分析与测试的作用 产品开发包括软硬件的设计和调试,而在整个产品设计所涉及到的各个技术层面中,由于大规模集成电路发展,致使元件的集成度也大大增加,从而为产品硬件设计的模块化和透明化提供了方便,同时,硬件调试与测试的可操作性为产品性能和可靠性的提高提供了保证。相反,有关软件调试与测试工作则复杂和困难得多,伴随着系统规模增长,其软件复杂性指数式增长,隐藏在软件中的问题就越多,这些问题直接影响了系统性能和可靠性。 一般来讲,软件的开发要经历需求分析、设计、编程和调试、测试几个阶段。由于分析、设计和编程都由人来完成,软件中的错误在所难免。软件错误往往会导致无可挽回的、致命的损失,因此软件必须测试,测试必须有效和可行。软件测试的目的在于充分暴露软件中存在的问题和缺陷,发现其中的错误并提交测试报告,最终排除软件中存在的问题,满足和实现用户的需求。 二. 软件检验的手段和流程 目前,软件检验的手段有三类:需求测试,静态测试,动态测试。 静态测试,指无须执行被测代码,而是借助专用的软件测试工具评审软件文档或程序,度量程序静态复杂度,检查软件是否符合编程标准,借以发现编写的程序的不足之处,减少错误出现的概率。静态测试在主机上完成,不需目标系统支持,测试的主要内容有:(1).编程标准验证 (2).数据流分析技术 (3).质量度量信息 (4).代码结构可视化显示 (5).测试外壳的创建 从以上几点可以看出,静态测试只是对代码进行扫描分析,检测它的语法规则复杂度等是否符合要求,它主要是为软件的质量保证提供依据,以提高软件的可靠性和易维护性。 动态测试,是使被测代码在相对真实环境下运行,从多角度观察程序运行时能体现的功能、

相关主题
文本预览
相关文档 最新文档