《基于模型自动化检测测验工具实现》由会员分享，可在线阅读，更多相关《基于模型自动化检测测验工具实现（29页珍藏版）》请在金锄头文库上搜索。
1、 基于模型的自动化测试工具的实现基于模型的自动化测试工具的实现摘要基于模型的测试是本文首先介绍了Atmel-View框架以及菜单系统UI在其中所将扮演的角色、与各个功能模块间的关系。其次讲解了Atmel-View内存映射窗口结合OSD应用的UI设计思想，涉及了多图层表现的想法，硬件OSD与伪OSD的比较使用。然后详细阐述了基于Atmel-View的菜单系统方案和框架结构，针对最重要的MenuMode菜单构建函数分析其数据抽象、界面绘制和事件响应处理过程。其后介绍Nucleus Plus，给出进程通信、进程同步在菜单系统中支持蓝牙模块的应用方法。本方案的实现提供了一套层次化、结构化、可扩展的电子
2、相框菜单系统，并有效支持了蓝牙模块的应用。矚慫润厲钐瘗睞枥庑赖。关键词：OSD，内存映射窗口，菜单系统，UIFULFILL UI OF DIGITAL PHOTO FRAMEBASED ON ATMEL-VIEWABSTRACTAtmel Corporations Atmel-View is the application for board AT76C120, it has already provided low level realization for digital photo frame, and it could be an extendable and mature solut
3、ion. Based on current functions of Atmel-View, we will design and fulfill the Menu System.聞創沟燴鐺險爱氇谴净。Firstly the framework of Atmel-View, which role Menu System UI acts and how it relates with other function modules were introduced in this paper. Then the concept ofSDRAM-Mapping Window with OSDs usa
4、ge was proposed. It referred to the idea of multiple image layer interface and the comparison the usage of hardware OSD and Pseudo OSD. Then the details of Menu Systems framework were illustrated. The process of data abstraction, interface drawing and event handling were analyzed for the most import
5、ant Menu building function MenuMode. After that Nucleus Plus was introduced and the method to use process communication, process synchronization for supporting Bluetooth module in Menu System was given.The UI solution provides a layered, structural and extendable Menu System for digital photo frame.
6、 And it effectively supports Bluetooth module.残骛楼諍锩瀨濟溆塹籟。Key words:OSD, SDRAM-Mapping Window, Menu System, UI酽锕极額閉镇桧猪訣锥。目 录第一章绪论2彈贸摄尔霁毙攬砖卤庑。1.1.软件测试简介2謀荞抟箧飆鐸怼类蒋薔。1.2.软件测试工具发展现状2厦礴恳蹒骈時盡继價骚。1.3.项目背景和论文结构2茕桢广鳓鯡选块网羈泪。1.3.1.项目背景2鹅娅尽損鹌惨歷茏鴛賴。1.3.2.论文结构2籟丛妈羥为贍偾蛏练淨。第二章基于模型的测试2預頌圣鉉儐歲龈讶骅籴。2.1.MBT一般操作流程2渗釤呛俨匀谔鱉
7、调硯錦。2.2.MBT模型表现形式2铙誅卧泻噦圣骋贶頂廡。2.3.MBT测试用例生成2擁締凤袜备訊顎轮烂蔷。2.4.MBT预期输出生成2贓熱俣阃歲匱阊邺镓騷。第三章系统架构2坛摶乡囂忏蒌鍥铃氈淚。3.1.功能概述及流程2蜡變黲癟報伥铉锚鈰赘。3.2.系统架构2買鲷鴯譖昙膚遙闫撷凄。第四章系统各功能实现2綾镝鯛駕櫬鹕踪韦辚糴。第五章实例分析：ATM系统2驅踬髏彦浃绥譎饴憂锦。第六章结论及展望2猫虿驢绘燈鮒诛髅貺庑。参考文献2锹籁饗迳琐筆襖鸥娅薔。第一章 绪论1.1. 软件测试简介随着电子信息化的飞速发展，计算机软件已经遍布于人类社会的各个角落，远至月球探测卫星的发射系统，近至个人携带的MP3音乐
8、播放器。但是软件带来巨大便利的同时，软件中的任何微小缺陷也可能带来难以估量的损失。据美国国家标准技术研究院（NIST）2002年公布的一份研究报告显示，软件故障平均每年对美国经济造成的损失约为595亿美元，占其国民生产总值的0.6% 1 。構氽頑黉碩饨荠龈话骛。因此，如何保证软件的质量显得尤为关键。软件测试能够有效地帮助软件开发人员找出系统中存在的错误，从而在很大程度上保证软件的质量。现代软件工程理论将软件测试作为软件开发过程的重要组成部分，软件开发过程中有一半以上的资源都花费在软件测试上。輒峄陽檉簖疖網儂號泶。早期的软件测试等同于程序调试，1957年Charles Baker才正式将两者区别
9、开来，他认为调试侧重于保证程序运行，而测试侧重于保证程序解决问题2。1979年Myers提出“测试是带有发现错误意图去执行程序的过程”3，越是发现了错误才说明测试过程的成功。1983年美国国家标准局（NBS）发表了评估软件生命周期各阶段的测试方法4，同年美国电气和电子工程师协会（IEEE）发布了八大软件测试相关文档的标准5，人们开始利用这些评估标准来衡量测试软件的质量。1988年David Gelperin等在书中写道，“测试是为了证明软件符合需求规约，发现缺陷和防止错误”6。尧侧閆繭絳闕绚勵蜆贅。时间测试阶段 -1956面向调试时期1957-1978面向论证时期1979-1982面向破坏时期
10、1983-1987面向评估时期1988- 面向防止时期表1-1 测试的发展阶段6测试不可能遍历所有可能出现的情况，必须在适当的时候终止测试。如果一味地追求缺陷数量，很可能得不偿失。常用的判断标准有：代码覆盖率、测试用例通过率、缺陷数量收敛率等等。识饒鎂錕缢灩筧嚌俨淒。图1-1 缺陷数量收敛图1.2. 软件测试工具发展现状纯手工地进行软件测试往往是费时费力的，而且测试人员容易因为疏忽产生失误，测试准确性无法得到足够的保证。于是人们需要开发一些自动化工具来管理或者执行测试过程，虽然编写软件测试工具需要引入额外的工作量，但是软件测试工具能大大提高软件测试的效率和质量，并且市面上也已经存在着许多现成的
11、测试工具。凍鈹鋨劳臘锴痫婦胫籴。名称产商简介WinRunnerMercury Interactive支持自动录制、检测和回放用户操作LoadRunnerMercury Interactive模拟大量并发负载来预测系统性能TestDirectorMercury Interactive基于Web的测试管理系统RobotIBM具有测试和管理的双重功能xUnit最流行的开源单元测试框架SilkTestBorland软件功能测试工具WASMicrosoft强大的网站压力测试工具JTestParasoft针对Java语言的自动化白盒测试工具JMeterApache100%用Java实现的功能和性能测试工具
12、WebLoadRadViewWeb性能测试和分析工具表1-2 常用软件测试工具一般来说，自动化测试可以分为：基于代码的测试和基于图形化用户界面的测试。基于代码的测试是指通过程序提供的公共接口，直接验证各个类、库和模块在不同的输入情况下返回结果的正确性与否，如xUnit系列框架。而基于图形化用户界面的测试则是通过模拟用户动作行为（比如键盘输入、鼠标点击），产生某些事件来观察和判断程序响应是否满足预期，如WinRunner。恥諤銪灭萦欢煬鞏鹜錦。绝大部分软件测试工具并不能自动完成整个测试过程，测试人员依然需要事先编写好测试脚本或测试用例，即一组测试输入、执行条件和预期结果。测试用例能够被快速和反复
13、地执行，方便地使得发现的软件错误重现。当测试本身就需要多次重复时（比如回归测试、压力测试），其优点将更加显著。鯊腎鑰诎褳鉀沩懼統庫。基于模型的测试（MBT, Model-Based Testing）是一种轻量级自动生成测试用例的方法，测试人员的关注点在于构建一个能够描述被测系统各方面数据和行为的形式化机器可读模型。为了抽象出理想的模型可能需要花费一定的时间，但是模型构建的工作可以在软件开发生命周期的早期就开始，只要求被测系统的需求定义完成即可。而且往往在将非形式化的需求转化为形式化的模型过程中，需求中的遗漏和不足部分将被发现。模型所带来的回报也是巨大的，因为一旦模型被确立且其能够准确反映被测系
14、统的真实需求，软件测试工具就能够分析模型自动得到测试用例。硕癘鄴颃诌攆檸攜驤蔹。软件测试的主要目的就是发现错误。事实证明，MBT确实具有很强的错误发现能力。IBM公司和BMW公司的研究表明，MBT发现的错误和手工设计的测试集发现的错误数量差不多。而微软公司的某一应用中，MBT发现了多10倍的错误14。其它的一些研究结果中（如图1-2），和人工测试相比MBT都是发现更多或者相同数量的错误。当然MBT也不是万能的，它发现错误的能力很大程度上依赖于建模和选择测试用例选择要求人员的水平。阌擻輳嬪諫迁择楨秘騖。图1-2 各种测试方法整个测试过程的花费时间图14MBT能否降低测试的花费和时间，取决于建立和
15、维护模型加上生成测试用例花费的时间是否比其它方法设计和维护测试集所需要的时间少，通常情况下答案是肯定的。而且MBT可以提高测试效率，因为人工测试受限于测试人员的思维活跃程度，MBT使用的测试用例生成算法和启发式用例选择机制能够快速生成大量测试用例，达到对模型更高的覆盖率却仅需要多花费少量运行测试用例生成程序的时间。如果SUT支持大规模地测试，MBT必然将发现更多的错误。氬嚕躑竄贸恳彈瀘颔澩。有时侯测试用例没有通过，并不是因为程序编写的错误，而是因为系统需求定义存在错误。其它形式的软件测试一般无法发现此类错误，但是MBT可以。我们知道，软件开发中的错误越早发现需要付出的修复代价越小，MBT把一些错误扼杀在需求阶段，贡献无疑是巨大的。此外， MBT具有良好的应付软件需求变更的能力。传统的测试方法很可能需要重新设计编写所有测试用例，MBT只需要调整模型后再自动生成测试用例。釷鹆資贏車贖孙滅獅赘。凡事有利必有弊，好的模型可以让测试过程一帆风顺，模型也给测试过程带来了许多问题。实施MBT的测试人员需要具有比普通测试人员更强的系统抽象能力，因为SUT很可能并不容易建模。当MBT的测试用例没有通过时，测试人员无法断定是SUT存在错误还是建模存在错误，增加了错误分析的代价。传统的人工测试的测试用例
