- 上一篇：Matlab一维条形码的识别+文献综述
- 下一篇：基于CORDIC算法的数控振荡器设计+文献综述
2.1.2 功能分析
（1）能够实现用例工程的编辑功能
主界面设计图如下：
新建菜单设计图如下：
新建用例集、用例、命令组和命令
删除用例集、用例、命令组和命令
插入用例集、用例、命令组和命令
快速添加用例、命令组和命令
显示用例集、用例、命令组和命令的属性
保存工程
（2）工程运行界面
运行界面图如下：
根据配置文件自动配置仪表群
将主界面中配置好的工程文件显示在测试窗口中，并能够手动勾选用例集或者用例，设置执行的次数
（3）信息反馈
实现PC-UE之间的信息交互
在信息框中实时显示用例执行的情况
2.1.3 性能分析
课题中的工具既然是集成测试工具，那么首先要求程序要完全稳定可靠，具有鲁棒性，能够在长时间的工作中保持很低的出错率，并提前设想到类似的尽可能多的可能发生的事件，做出相应的应对措施，并弹出警告窗口提示用户。
程序要求测试范围广，作为一个测试工具，需要尽可能的测试更多的用例，在建立桩时考虑更多的测试情况并在今后的文护升级中对其进行扩展和完善。
测试程序经常需要进行升级或者文护，所以在程序设计时应采用模块化开发，各个模块之间不要有太多的联系，以便未来的文护和扩展
程序要有良好的容错性，当用户进行非法操作时或者系统本身出现问题时要能以最好的方式退出程序，避免发生程序假死现象，甚至崩溃现象。
在程序中配有一份开发文档，开发文档需要具有易理解性，方便日后测试人员的工作和系统的文护升级，或者系统需要移交他人文护。
要求程序对所运行之系统的硬件条件要求尽可能低，运行时内存占用尽可能小，响应速度要尽可能快，并且不发生内存泄漏之类影响系统运行的错误事件。
2.1.4 系统基本流程图系统流程图如下：UE桩流程图如下：
2.1.5 测试环境
（1）装有测试工具的PC
（2）测试所需的仪表群，例如Aeroflex7100等
（3）测试UE
测试时，根据自动配置仪表群的情况，来连接需要使用的仪表群，并将PC和UE通过串口由数据线连接起来。
2．2 可行性研究
2.2.1 成本可行性分析
该工具作为组内的附属项目，在成本上并不是很高，付诸的人力为4人，但是可以提高之后版本的测试速度，所以在成本可行性上完全可以接受。
2.2.2 技术可行性分析
该程序是用Visual Studio 2010 编写的，在软硬件平台的搭建上没有太大的难度。在实现程序前，多次开会讨论设计方案，经过筛选后，最终选择本课题中的方法实现程序。在实现的过程中主要运用的是Win32编程原理，MFC框架，和VC++的编程方法，在运行时再将工程文件转换成码流形式通过串口进行数据的交互，实现信息反馈。
3 软件设计
3．1 总体设计
总体设计初期设计了2套方案，主要分别在于是否在传输到UE桩时转换成C代码，两个设计都有各自的优缺点。
（1）不转换成C代码：
建立UE桩，UE桩需要适应更多用例的执行，所以在建立上会有一些麻烦，尤其在用例格式上面要相对固定。
优点：省去了一而再再而三对ARM侧上的烧录，在这点的耗时上比较少，而且相对于转换C代码的方案整个测试系统的变动相对小点。