《嵌入式软件界面设计》由会员分享，可在线阅读，更多相关《嵌入式软件界面设计（9页珍藏版）》请在金锄头文库上搜索。
1、一：程序界面设计1.1主界面设计 图1界面：把项目导入平台，在编辑区域左边显示一个项目清单列表、右上部分显示与项目清单列表下.xml .doc文件相对应的图形化结构（图1）、把测试用例下的测试函数用编程文本显示出来且能够对其进行编辑、把源代码文件下的源程序显示出来并且提供源代码和结构图（见图2）两种显示方式（见下图3）。右下部分显示控制台信息、运行信息、属性信息和其他相关信息。默认的显示：左边是项目清单列表，右上是源代码中文档的源代码和结构图，右下是控制台，和运行信息。功能：在对项目清单上的文件进行操作时要触发对其文件相应的显示界面，这里涉及到事件的分发和接受。例如项目清单下打开测试用例文件夹
2、下的函数时，在右上显示这个函数，同时允许对其进行编辑，修改；还能够显示这个函数的图形结构。要保持函数和图形的一致性，当对函数修改后，进行刷新，其图形结构也进行重新生成新的图形。源代码下的文件也是如此。这里主要涉及到各种关系的同步问题。 在现有软件中界面出现的问题有：对操作步骤提供撤销和返回，以方便在出现错误或要返回到以前的位置时提供方便。 （图2）1.2项目清单树形结构 在左边的项目清单透视图的树形结构中单击右键出现的静态代码分析、源程序插桩、结构流程图、函数关联图、文件关联图、折叠全部、展开全部、更新等操作时，要实现其功能。同时在右上部分要显示其相应的图形等。例如在项目清单的树形结构中右击源
3、代码文件夹下的函数时，可以对其函数进行上述静态代码分析、源程序插桩、结构流程图等操作，在界面的右上方应该做出相应的编辑区，或结构流程图等结果显示；当单击静态代码分析时，要能够对该源函数做DD图结构分析，找出函数的支配树、蕴含树、控制流关系。根据先前的论文（陈恩慧师兄的论文：程序分支覆盖方法的研究）中的理论找出函数中的关键分支，然后进行标记。当点击源程序插桩时，要把插桩库的插桩函数（参照于全喜师兄的论文：在这里要建插桩函数库，定义插桩规则）插到关键分支点上；当单击结构流程图时要把函数的结构如调用关系等显示出来；当单击函数关联图时要把这个函数和项目中的其他函数的关系显示出来如被其他函数调用或调用其
4、他函数；文件关联图是把各个文件之间的关系表示出来如头文件与源文件的关系。对这些操作进行执行时，要及时更新与之相关的内容如对源代码修改后要保证它的结构图也相应得到更新，这里就要对更新操作实现。见图41.3右上界面设计 把在项目清单上的相应操作在右上部分表示出来。见下图1.4右下部分界面设计 显示相应操作的控制台信息和程序的运行信息。这一部分透视图要固定在下面。2用户登录与退出 在进入平台时先要求输入用户名和密码进行验证后，才能进行后续的平台运行。如果输入出现错误，则提供帮助信息和返回到登录状态。这里选用基于Preferences的用户登录。 登录的流程：用户双击图标运行程序，在基本配置完后，进入
5、主界面之前。要求用户输入用户名和密码在实现时要对用户的信息进行加密处理，进入系统时要把设定的主界面显示出来；退出系统时，把当前打开的各个对象关闭后才完全退出程序。同时在平台中要提供用户的管理。类似登录界面如下图5 图53各个菜单的功能分析3.1 文件菜单 新建与新建项目重叠，要删除一个。 打开子菜单项功能：能够打开word,txt等格式的文件。有一个向导窗口来寻找需要打开文件的位置。 导入项目子菜单功能：是导入一个已经存在的项目（在项目文件夹内会有一个.properties格式的文件，选择这个文件即可） 导出项目子菜单功能：是对新建的项目经过下图的处理后，生成一个独立的文件以便于保存属性子菜单
6、功能：显示整个系统的配置情况，可以参见Eclipse平台的属性菜单项。3.2源代码菜单 源代码加载子菜单：源程序经过C编译器编译后会产生相应的源文件，把此处所有的源代码加载到平台中。并以树型方式将其呈现，并提供对这些文件的操作功能，主要操作功能可以包括：在平台上打开文件、静态分析文件、查看文件的结构流图、查看文件函数、查看与其它代码文件的静态关联关系等等。 静态代码分析子菜单：是指对被测源代码进行词法语法分析，对关键路径节点进行标识，已完成下一步对其插桩的过程。静态分析要从源程序中提取必要的数据(比如函数名、用面向对象语言编写的类名、行号等信息)，对源程序的控制流进行分析，为源程序划分块，然后
7、把得到的数据都保存到以XML格式的数据文件中。这些数据文件为实现图形化呈现作好了准备。这一步主要是生成程序的DD图。以便后续进行寻找关键分支。源代码插桩子菜单：是在源程序的适当位置插上编码人员需要知道的信息，由于编码人员需要的信息千变万化，要想完全做到自动化是不现实的。插装模块主要是根据用户的需要，把用户的需要变成模板化的插装代码，通过预编译条件控制语句来控制调试版本和发行版本间的切换。用户需要告知程序插装模块需要做什么样的服务，比如需要知道某个变量在运行中的值的变化，某个函数在某处被调用时的返回值和传入值等，程序插装模块在相应的位置上插入相应的代码，并通过相关的机制把用户所需要的功能信息通知
8、给用户。程序插装就是要往源程序的特定位置中插入自己的代码，当插装后的可执行程序运行时就可以获取动态数据。插装后的可执行程序为实现覆盖分析自动化和动态跟踪自动化作好了准备。此模块主要实现对源代码在标记分析的基础上进行对关键路径，关键程序结点的插桩，完成程序在运行过程中对动态测试数据的获取和监控，生成测试结果数据。对程序的关键路径的计算（参考陈恩慧大论文）：由源程序生成的DD图，找出图形中的支配树DT，蕴含树IT。通过UE(G)=DTL(G)ITL(G)，KB(G)= KB(G)UE(G)找出非约束关键分支，通过算法for（each eDTL(G)-UE(G)） if（e在支配树中与父结点非连续）
9、 continue; /* 排除与父结点非连续的叶子结点 */ 获取e在DT(G)中祖先集合DTAncestor(e); if（DTAncestor(e)ITL(G)） KB(G)=KB(G)e; 找出图形中约束分支中的关键分支。所以通过上述的计算可以找到要测试程序的关键分支为：KB(G)。找到关键分支后，根据关键分支的不同特点，利用插桩库函数对关键分支进行标记。（参考于全喜插桩方法）这里还关系到要建立一个基于C语言的插桩库（参见20090527嵌入式软件双向关联追溯可视化平台设计说明书.doc：5.2.2测试核心业务实现策略）。3.3文档菜单文档加载子菜单：指将被测软件项目所包含的文档（需求
10、文档、概要设计文档、设计文档）引用到平台上。文档结构化子菜单：是指提取、标记软件文档的结构信息，并将其结构信息以XML方式存储起来，提取文档的结构信息并以树型方式将其呈现，并提供对这些文档的操作功能，例如：文档的打开方式、关闭、保存、修改。文档索引库子菜单：对加载的文档能够根据关键词检索其内容所在的相关文件，提供显示出来。3.4测试用例测试用例辅助设计子菜单：根据需求文档中的功能需求结合概要设计、详细设计、源代码来设计测试用例。在设计测试用例是应该根据关键分支、语句覆盖、分支覆盖、数据流覆盖信息设计测试用例，以便达到较高的覆盖准则。测试用例自动生成子菜单：把从测试用例辅助设计子菜单中设计好的测
11、试用例，进行自动生成测试脚本。测试用例脚本加载子菜单：把生成的测试用例脚本加载到源程序中，并进行运行。3.5程序运行编译器设置：对被测项目所需的编译器参数进行设置源代码编译：对进行关键分支插桩后的代码进行编译（这里的编译环境由于是在linux系统中进行的，所以考虑把gcc编译器集成到平台中）代码下载执行：源代码进行编译后下载到目标机上，执行测试用例。执行结果收集：运行测试用例后，收集程序在目标机上运行后的信息，然后传输到软件平台。这里主要涉及到的对收集到的结果信息进行分析。由于主机收集到的是一定格式的二进制信息。在此要对这些二进制信息进行分析，以便获得测试信息。其数据处理过程如下：1) 有效数
12、据提取：数据解析处理从分离只读形式保存的*.out文件开始，解析处理中间过程及规范结果的数据全部存储为利于连续的提取分析的XML数据文档。首先逐行读取动态跟踪数据记录，分离出数据接收时间及isl；因为嵌入式系统一般集成了秒级的时钟芯片，无法提取出准确的探针函数动态执行，系统设计采用数据接收时间模拟探针函数动态执行时间，实现近似的性能测试。然后就要根据isl编码结构分离出以下结构体信息：基础数据存储文件信息、测试用例信息、测试函数信息、探针定位及返回数据信息等。对每条记录结构体信息为XML元素值，分离出的具体内容为各元素的属性值。2) 格式规范处理：测试数据的规范化处理是降低成本的必然措施，得到
13、的测试结果数据表示要有利于测试平台中各个子系统调用测试结果数据完成各自的分析功能。有效数据提取过程仅得到的简单XML数据文档，只能说是对测试数据的简单的、非规范化描述，且属性或元素信息全是用块划分编码表示，可读性和易分析性及差。格式规范处理的目的就是采用dom4j技术规范测试结果，把提取的有效测试数据写入静态分析所的XML文档中，为测试与维护平台提供标准的数据支持。3）对取得的信息进行分析，产生测试报告：报告中包含分析出的被测程序容易存在缺陷的位置点、影响级别，指导纠正缺陷，同时指明进一步测试的方向。报告包含如下三点信息：错误定位分析采用随机均匀路径生成法，构造实际执行路径。从测试数据文档中选
14、取同条测试用例t执行采集的测试数据，定位数据中代表实际经过(数据不为零)的各个插桩位置，在BCFG图邻接表中更改以上插桩位置点后一个程序块的节点元素信息域为1；然后深度搜索邻接表信息域为1的节点程序块，按公式(2)要求构造实际执行路径p(t)。理论路径p(t)与p(t)分析比较可定位软件缺陷：如果路径相同程序运行正常，如果不同采用如图3-5的操作定位软件缺陷： 测试覆盖率分析由于全面的软件插桩采集测试数据、计算分析软件缺陷是不现实的，即使对所有的理论插桩点，也难以实现全面的测试，测试数据采集需要至少一个测试覆盖策略支持。覆盖策略是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的，其中路径覆盖
15、插桩策略明显，能达到很高的测试覆盖率。测试报告制作测试总结报告应该包括测试过程的成功与失败经验，从测试过程的管理经验，具体到某个Bug的分析总结，或者是与开发人员合作交流的经验，都可以总结出来。测试数据采集处理系统能自动提供测试数据支持，方便基础测试报告的编写。这里所说的报告是测试数据处理阶段最后的文档产出物，编写目的是为系统开发人员提供测试数据参考资料，最好要附上缺陷隔离等相关方面的解释，方便开发人员迅速定位缺陷，解决问题。3.6关联 对需求文档、设计文档、代码、测试用例按照一定的规则把它们关联起来，可以从任一的制品中追溯到其他制品。例如当从需求文档中选中某一功能后选择从文档追溯，能够把与此对应的代码、用例等高亮显示出来。
