行为驱动开发
行为驱动开发（简称BDD）是测试驱动开发的升级版。它是一套软件工程实践方法，能帮助研发团队更快地构建和交付更有价值和更高质量的软件产品。采用BDD思想编写的测试读起来更像规格说明书而不是单元测试，所以它是使用测试作为表达和验证行为的一种手段。基于这个特性，BDD也非常适合应用在需求分析中。
一、行为驱动开发的原则
1．聚焦交付业务价值。使用验收标准作为目标，帮助业务实现更实际的可交付的功能。
2．团队共同确定交付标准。业务分析人员，开发人员，测试人员与最终用户一起定义和指定功能。
3．拥抱变化。项目开始时不锁定需求，而是假设需求，从用户那里得到早期的反馈，对需求的理解将在项目的整个生命周期中演进和变更。
4．不仅仅编写自动化测试，而是编写可执行规范和底层规范。团队将验收标准转换为自动化的验收测试，更准确地说是转换为可执行规范。在编写任何代码之前，开发人员将考虑代码实际上应该做什么，并将其表示为底层的可执行规范。可执行规范是一种自动化测试，它演示和验证应用程序如何交付特定的业务需求。自动化测试作为构建过程的一部分运行，并在对应用程序进行更改时运行，进行验收测试和回归测试。
5．交付活文档，并使用活文档来支持后续维护工作。在项目结束后持续维护项目可执行规范。
二、行为驱动开发的优势
1．专注业务目标，避免工程师把工作量浪费在不提供业务价值的功能上，能够降低成本，减少浪费。
2．完整的可执行规范，可充当开发人员的辅助技术文档，更容易理解现有的代码库并进行更改。
3．全面的自动化验收测试和回归测试，不仅可以提升执行效率，也能降低手工测试的出错率，使得迭代速度更快更可靠。
三、行为驱动开发的缺陷
1. 需要多个角色高度参与和协作，涉众如果不愿意或不能参与对话和协作，或者等到项目结束后才给出反馈，就很难充分利用BDD的优点。
2．比较适用于敏捷开发，但不太适用于瀑布式开发。
3．对参与角色能力要求很高，尤其是测试团队，不仅需要精通业务，对业务目标清晰，而且对测试技术能力要求更高，如果编写的自动化测试很烂，会导致更高的测试维护成本。
白皮书 模型驱动开发和UML 2.0 传统编程方式的终结？ 本文档包含Telelogic AB专有信息。未经Telelogic AB书面许可，不得使用本文档内的任何信息，不得复印、影印本文档的任何部分。
前言 “模型驱动开发”——体会一下这几个词。它们说出了这个不断变化的工业中一个新的改变。这里不是说一种革命，而是一种缓慢的变化，但是肯定会渗透到我们开发系统的方式中。这种推动将降低代码的重要性，并且专注于一些开发中的真正事情：最终的应用程序被期望怎样工作，并确保你能够根据客户的需求可靠地建立起它来。 模型驱动开发是更伟大视景MDA中的一部分。MDA是模型驱动体系架构（Model-Dri ven Architecture）的简称，由对象管理组织OMG（Object Management Group）所驱动。M DA表示了一种模型驱动开发方法的概念框架。然而，尽管完整的MDA还没有成为现实，模型驱动开发现在已成为可能。实际上，它已以较低级的形式存在了较长一段时间，所以我们并不是在做某种新的东西（当然，除非你在听某些市场人员的宣传）。 没有魔法 如果模型驱动开发这么好的话，为什么不是每个人立刻加入到这个潮流中来呢？首先，模型驱动开发不是一个银子弹，能神奇地解决你所有的问题。总有某人需要去实现系统的功能，并且还找不到任何工具来完成这一点。所有你能发现的工具只是使这项工作更容易和直接一些。 第二，采用模型驱动开发，并不只是在开发项目的过程中更换一种工具。它还必须和已根深蒂固的开发过程结合起来（如果没有的话，你就可以开始使用模型驱动开发了；否则你就只能改善当前的情况），但实际上更重要的是，你还会担心它对现有应用程序的影响。决定改用基于模型的方法前确实需要有一些仔细的考虑，并且，一般说来，为了不影响当前的工作，你只会在新项目中改变开发方法。 第三，你还需要获得那些使用工具的人们的支持（你需要一些工具来应用模型驱动开发）。开发人员常会认为“模型驱动开发不是编程”而回避它，并且当心他们的工作难于被接受。他们还可能担心模型驱动开发将会使他们以前辛苦学来的一些技巧过时。他们的担心也不是完全没有理由。采用模型驱动开发后，市场确实很有可能会减少对那些精通好几种编程语言的开发人员的需求。但是另一方面，所有好的开发人员，首先和最主要的是，他们是问题的解决者。他们感兴趣的是尽可能地为手边的主要问题找到新的更好的解决方案。模型 第 2 页/共 2 页
WDM驱动开发之路 写在前面：在专栏的前几期中，我们一起初步学习了vxd的开发技术。Vxd技术是很深奥的，不是一篇两篇文章能讲清楚，但你已经入了门，剩下的就要看你的修行了。多看书，多泡论坛(当然是上咱们的驱动开发网论坛了:->)，多写程序…我的手不够用了。功到自然成嘛。不过话又说回来，vxd只是权宜之计，WDM才符合当今的潮流(程序员都是时髦人士，君不见先是VB、VC然后是asp、JSP、PHP,数也数不过来呀)，Win9x寿终正寝时也就是vxd的末日，你不想随它而去吧(开个玩笑)，那就随我来。 按笔者的想法，这篇文章写成连载形式，一次讲一个主题，并且必要时带着例子，让大伙step by step地把WDM驱动弄个透底，不想让大家觉得稀里糊涂，也不想让大家觉得白买杂志了。 今天我们一起讨论第一部分，了解篇。 (一)了解篇 WDM模型（Windows Driver Model）是微软公司为当前主流操作系统Windows98和Windows 2000的驱动程序设计的一种构架。它和传统的win3.x和win95使用的vxd的驱动是完全不同的体系结构。不过对于最终用户来说，WDM驱动程序在Windows98和Windows2000下的表现很相似。作为驱动开发人员来说，它在两者中有很多的不同。并且Windows98中的WDM只能算是Windowss2000中的WDM的一个了集。在Windows98中有一些驱动程序只能使用VXD来实现，如串行通讯驱动等。 要写驱动程序，首先要了解操作系统的结构。在WDM体系中，windows2000操作系统中是最标准的实现方式，Windows98则是部分兼容WDM结构。照微软的说法，Windows98和Windows2000 X86(Intel 架构)版本实现二进制码兼容(参见98DDK)，Windows2000 x86版本与其它CPU平台版本实现源码级兼容(因为Windows 2000是基本NT相似的结构，最底层是硬件抽象层HAL，所有我们相信它们之间能源码级兼容)。但实际上，Windows2000的WDM实现中有很多例程在Windows98中没有实现，一旦试图加载这样的WDM驱动程序到Windows98中，则不能正常加载，当然我们也有办法实现它，那就是利用“桩”技术。具体可参见Walter Oney写的《Programming the Microsoft Windows Driver Model》一书。我们首先来看看Windows 2000的系统结构，然后再来看看Windows 98的。 图一是Windows 2000的系统结构图。从图中我们可以看出：整个系统被分为两个态，用户态和核心态。 从图中可以明显看出I/O操作最后是怎样作用到硬件上的。用户态应用程序对Windows 子系统进行win32 API调用，这个调用由系统服务接口作用到I/O管理器(严格地说，在Windows 系统中不存在I/O管理器这样的独立模块，这个只是为了方便叙述而将各种核心功能调用的集合称作I/O管理器,业界人士都这样称呼这个部分)，I/O管理器进行必要的参数匹配和操作安全性检查，然后由这个请求构造出合适的IRP(IO Request Package,I/O请求包),并把此IRP传给驱动程序。简单情况下，驱动程序直接执行这个请求包，并与硬件打交道，从而完成I/O请求工作，最后由I/O管理器将执行结果返回给用户态程序。但在WDM体系结构中，大部分实行分层处理。即在图中“设备驱动“这部分，分成了若干层，典型地分成高层驱动程序、中间层驱动程序、底层驱动程序。每层驱动再把I/O请求划分成更简单的请求，以传给更下层的驱动执行。以文件系统驱动为例，最高层驱动只知道文件如何在磁盘上表示，但不知到怎样得到数据。最低层驱动程序只知道怎样从磁盘取出512B为单的数据块，但不知道文件怎样表示。举个更具体的生活例子。主人(最高层驱动)知道（并且需要）笔计本电脑，但不知道具体放在什么位置；而仆人(最底层驱动)却知道它放在具体什么地方，但
社会化电子商务的驱动机制探究 一、导论 论文首先将梳理社会化电子商务的概念,识别出社会化电子商务的内涵要素与外延范围;接下来将基于科技接受模型提出社会化电子商务中用户参与行为的驱动机制理论模型,为后续研究提供借鉴价值。二、理论背景与模型提出 社会化电子商务的重要驱动力量来自于用户的不断参与,如何驱动用户不断地参与社会化电子商务便成为了研究的重点问题。已有研究表明,虚拟社区成员的参与行为能给企业带来积极的营销效应,如提升品牌关系、建立社区承诺、创建忠诚顾客的友谊群组、促进购买行为和社区推广、激励新产品开发中的创意贡献等。四位学者在《虚拟社区成员参与心理机制研究述评》一文中,对近十年来有关虚拟社区参与行为的实证研究进行了系统回顾,并认为在后续研究中应当加强对虚拟社区参与行为心理机制的理论解释。而已有研究表明,一种电脑科技越能被成员所接受,成员参与使用该科技的行为意向就会越高。同时,当成员认为某个博客网站更容易使用,更具有乐趣时,他们对博客的参与意向也更高。鉴于“容易使用”与“更有乐趣”都属于科技接受模型的范畴,而博客与虚拟社区之间存在诸多关联之处,本研究将基于科技接受模型的视角分析虚拟社区成员参与行为的驱动机制。这一视角在我国当前社会化电子商务的大背景下也具有特殊的意义。原因在于,社会化电子商务在我国目前还处于起步阶段,社会化电子商务中的虚拟社区对于大多数用户来说还是一个新生事物,需要一个
接受过程。因此,在已有研究视角的基础上,基于科技接受模型视角的研究能够拓展相关领域的研究成果,加强相关领域的理论解释。科技接受模型源于理性行为理论（TheTheoryofReasonedAction,TRA）。理性行为理论由Fishbein和Azjen所提出,主要用以探讨实际行为,行为意向,行为态度,主观规范与信念之间的关系,目的是为了预测个人的实际行为,两位学者在理性行为理论中对于个人行为提出了两项基本假设：第一,个人行为在自我意志的控制之下而发生。第二,个人采取特定行为的意向是该行为发生的立即决定因素。理性行为理论被广泛运用于各领域之行为研究,以预测并解释个人的行为。Davis将理性行为理论简化,并聚焦于电脑科技研究领域提出了科技接受模型。该模型延续了理性行为理论中对于个人行为的两项前提假设,但是删除了理性行为理论中的“主观规范”及其前因变量“规范性信念与动机”,并以“感知有用性”与“感知易用性”作为使用态度的前因变量。科技接受模型自提出后,便在实证研究中广为应用,并为本研究垫定了坚实的研究基础,也进一步支持了基于科技接受模型视角研究虚拟社区成员参与行为的合理性。原因在于：第一,科技接受模型的产生,便是为了了解使用者对于信息科技的使用行为;第二,科技接受模型架构简单易用,并具有较好的解释能力;第三,科技接受模型运用的量表在信度和效度上都获得了支持,同时,科技接受模型也经过许多学者的探讨、实验与修正,不需要针对所涉及的科技的差异而特别制定衡量工具;第四,科技接受模型获得了许多实证研究的支持,验证了科技接受模型对于信息科技使用行为的解释力与重要性;第五,科
浅谈验收测试驱动开发 【摘要】软件行业已经发展了很多年，尽管新技术不断涌现，但是软件质量问题依然存在，最突出的两点就是较高的缺陷率和较差的可维护性。为了应对此类问题，驱动测试开发技术（ADD）应运而生，但是随着ADD技术的普及，它所隐藏的问题也浮出水面，最为人诟病的就是“不能满足客户需求”，因为测试人员只注重代码缺陷率而忽视了系统具体功能。本文阐述如何在ADD开发模式的基础上，结合验收测试驱动开发（ATDD）探讨如何开发适应于用户的系统。 【关键词】敏捷开发；验收测试驱动开发；软件工程 一、引言 极限编程方法理论中“测试驱动开发”是其一个重要组成部分，最早是由Kent Beck提出，并积极推广的一种软件开发方法。Kent Beck在他所著的《测试驱动开发》一书中指出“测试驱动开发”遵循“为明天编码，为今天设计”的观点。相比传统遵循“需求-设计-开发-测试”的软件开发流程而言，更强调测试优先，再通过编码和重构反复迭代最终构筑一个完整的软件系统。“测试驱动开发”在相当程度上了的确提高了开发人员的代码质量，而且在应对系统的可靠性也教之传统软件开发有着更大的优势，主要体现在客户需求变更时能灵活应对。然而软件问题中另一项“是否满足客户需求”确没有很好地解决。验收测试驱动开发（ATDD）针对这个问题，提出让客户参与到测试标准的制定，让软件满足客户需求。用ATDD 方法开发软件，开发人员更注重的是系统行为测试，而不是软件中每个模块，甚至每行代码的测试。构筑一个满足客户需求的软件系统，不仅仅是软件设计开发人员和测试人员靠个人能力能解决的，在此过程中需要客户参与进来，为打造可靠的软件提供有力的保障。 二、什么是ATDD 测试驱动开发（ADD）能够帮助开发人员开发出高质量的代码，保证开发人员所开发出的代码执行正确，但是这些执行正确的代码在很大程度上是针对的具体模块而不是整体的系统功能。在一定程度上不一定能够满足客户的需求。验收测试驱动开发（ATDD）是建立在TDD的基础上，TDD和ATDD既可以分开使用也可以配合使用，在帮助开发人员在提高软件质量的同时，也帮助开发人员开发出用户真正需要的软件系统。软件测试是软件工程的重要组成部分，在传统的软件开发当中，软件测试大概包括软件执行过程中是否存在BUG、系统中是否还存在其它缺陷以及系统是否与系统设计书保持一致几项内容，ATDD则在此基础上赋予了软件软件测试新的任务，即利用验收测试从系统功能的角度上驱动软件开发，解决软件不能满足客户需求或者是与客户设想相背离的问题。 总体而言验收测试驱动开发是包括客户在内的一个团体组织的活动，围绕着客户需求引入“用户故事”（user story）这种灵活的客户需求管理方式。客户和技术人员（包括设计、开发和测试）通过紧密的写作、有效的交流和沟通构筑可靠
模型驱动的开发方法——基于面向对象的开发 2012210874 魏翔案例 案例名称：《基于UML的GRAPPLE在数字化医院信息系统设计中的应用》 案例简述： GRAPPLE (Guidelines for Rapid application Engineering: 快速应用工程指导原则)主要适用于面向对象系统。因此，每个段中的动作主要是生成面向对象的工作产品。GRAPPLE 所包括的5个段分别为： 1需求收集 1.1发现业务过程 首先要分析员要用客户业务常用的词汇与客户进一步面谈，从而建立一个或者一组能够捕获业务过程中的步骤和判定点的活动图，即从客户的业务流程出发理解系统。 1.2领域分析 领域分析可以与前一个动作同时进行，它们的共同目标是达到对某特定领域的理解。在此过程中，分析员需要分析与客户的会谈从而开发初步类图、建立和标记类之间的关联并且找出关联的多重性。 1.3发现系统需求 在此阶段，GRAPPLE 要求开发组举行一次联合应用开发会议，参加者包括客户的决策者、用户以及开发组成员。会议的参加者一同收集系统需求，需求收集的结果是一个包图，这个包图中的每个包代表系统的一个主要功能模块，每个包中包括一组用例，它们详细说明这个包代表的功能。本系统最重要的是事务对象包，它包括了系统涉及的大部分功能模块，例如挂号收费模块、看病诊断模块、取药模块、住院出院模块等；用户接口包定义了数据导入导出接口、打印接口；数据库包则定义了系统使用的数据库表、视图、存储过程。 2分析 2.1开发用例 “发现系统需求”阶段得到的每个功能包中的用例说明系统必须要做的事。在“开发用例”阶段开发组还必须分析和理解每个用例，描述用例执行步骤以便绘制详细用例图。HIS 系统案例的用例图如图 1所示。
Windows 内核技术与驱动开发笔记 1.简述Driver Entry例程 动程序的某些全局初始化操作只能在第一次被装入时执行一次，而Driver Entry例程就是这个目的。 * Driver Entry是内核模式驱动程序主入口点常用的名字。 * Driver Entry的第一个参数是一个指针，指向一个刚被初始化的驱动程序对象，该对象就代表你的驱动程序。WDM驱动程序的Driver Entry例程应完成对这个对象的初始化并返回。非WDM驱动程序需要做大量额外的工作，它们必须探测自己的硬件，为硬件创建设备对象（用于代表硬件），配置并初始化硬件使其正常工作。 * Driver Entry的第二个参数是设备服务键的键名。这个串不是长期存在的（函数返回后可能消失）。如果以后想使用该串就必须先把它复制到安全的地方。 * 对于WDM驱动程序的Driver Entry例程，其主要工作是把各种函数指针填入驱动程序对象，这些指针为操作系统指明了驱动程序容器中各种例程的位置。 2.简述使用VC进行内核程序编译的步骤 编译方式是使用VC++进行编译 1.用VC新建工程。 2.将两个源文件Driver.h和Driver.cpp拷贝到工程目录中，并添加到工程中。 3.增加新的编译版本。 4.修改工程属性，选择“project | setting”将IterMediate file和Output file 都改为MyDriver_Check。 5.选择C/C++选项卡，将原有的Project Options内容全部删除替换成相关参数。 6.选择Link选项卡，将原有的Project Options内容删除替换成相关Link。 7.修改VC的lib目录和include的目录。 8.在VC中选择tools | options，在弹出的对话框中选择“Directories”选项卡，在“Show directories for”下拉菜单中选择“Include file”菜单。添加DDK的相关路径。 3.简述单机内核调试技术 答:1.下载和安装WinDbg能够调试windows内核模块的调试工具不多，其中一个选择是微软提供的WinDbg 下载WinDbg后直接双击安装包执行安装。 2.安装好虚拟机以后必须把这个虚拟机上的windows设置为调试执行。在被调试系统2000、2003或是xp的情况下打开虚拟机中的windows系统盘。 3.将boot.ini文件最后一行复制一下，并加上新的参数使之以调试的方法启动。重启系统，在启动时就可以看到菜单，可以进入正常windows xp，也可以进入Debug模式的windows xp。 4.设置VMware管道虚拟串口。调试机与被调试机用串口相连，但是有被调试机是虚拟机的情况下，就不可能用真正的串口连接了，但是可以在虚拟机上生成一个用管道虚拟机的串口，从而可以继续内核调试。 4.请画出Windows架构简图
城市居民绿色出行行为的驱动机理与政策研究随着城镇化和机动化的快速发展,我国城市汽车保有量急剧增加,由此引发的城市道路交通拥堵、交通能耗增加、城市空气环境污染等一系列问题也日益严重,并逐步从大城市蔓延至中小城市,成为全社 会关注的热点问题。为缓解城市道路交通拥堵、降低交通能耗、减少空气环境污染,2012年我国已将绿色出行纳入到“十二五”规划,明确提出“鼓励居民选择绿色出行方式”、“倡导绿色出行”;2013年在“循环经济发展战略及近期行动计划”和“大气污染防治行动计划”中也明确提出“倡导绿色出行”、“鼓励绿色出行”;2014年在“能源发展战略行动计划”中再次明确提出“实行绿色交通行动计划”。居民是绿色出行的主体,而高人口密度和高社会经济发展水平的我国东部地区,其机动化程度和汽车保有量为全国最高,随之产生的一系列 问题也最为严重,因此,有必要探讨东部地区城市居民的绿色出行行 为驱动机理,以提出促进城市居民绿色出行的相关政策建议。本文旨在依据理论铺底—质化研究—量化检验—结论与政策建议的技术路线,对我国东部地区城市居民的绿色出行行为及其驱动机理进行系统的深入研究,厘清我国城市居民绿色出行行为的影响因素体系、影响因素变量与行为变量的作用关系以及各变量间的相互作用机制。首先在文献回顾的基础上,界定了城市居民绿色出行行为的概念和种类, 然后通过扎根理论这一质性研究方法找出了城市居民绿色出行行为 的关键影响因素并构建了城市居民绿色出行行为驱动机理理论模型。在此基础上,开发了我国城市居民绿色出行行为调查问卷,并依据东
部地区城市的大样本调查数据,统计分析了我国东部地区城市居民的出行方式选择、绿色出行行为现状及特征差异,深入研究了城市居民绿色出行行为影响因素的作用机制。最后梳理了国内外促进城市居民绿色出行的政策和措施,结合质化和量化分析结果,提出了促进我国 城市居民绿色出行的政策建议。主要研究内容和创新性工作总结如下:(1)城市居民绿色出行行为概念和种类的界定。在文献研究基础上,本文将城市居民绿色出行行为界定为,在综合考虑人、社会、环境和谐发展的前提下,城市居民有意识的选用低能耗、高能效、低污染、兼顾效率与公平、有益于城市与居民健康发展的出行方式的行为。并借鉴环境行为的分类方式,首次将城市居民绿色出行行为划分为调整型绿色出行行为和促进型绿色出行行为。其中,调整型绿色出行行为是指个体身体力行的日常实践行动,主要是指个体主动实施地、调整现有出行方式为绿色出行方式的行为;促进型绿色出行行为是指个体对其他特定个体的游说行为,具体指积极参与或游说、建议他人参与绿色出行相关组织或活动的行为。(2)城市居民绿色出行行为驱动机理的质化研究。本文采用扎根分析这一质性研究方法对我国东部地区32位代表性城市居民的深度访谈资料进行开放式编码、主轴编码和选择性编码等逐级编码,厘清了城市居民绿色出行行为的主要影响因素及作用机制,构建了包含出行者心理认知、行为意愿、出行特性、出行偏好、社会参照规范、制度技术情境和出行者属性等7类主范畴的城市居民绿色出行行为驱动机理理论模型,提出了出行者心理认知通过行为意愿作用于绿色出行行为、出行特性和出行偏好、社会参照
参考： 韦东山视频第10课第一节内核启动流程分析之编译体验 第11课第三节构建根文件系统之busybox 第11课第四节构建根文件系统之构建根文件系统韦东山书籍《嵌入式linux应用开发完全手册》 其他《linux设备驱动程序》第三版 平台： JZ2440、mini2440或TQ2440 交叉网线和miniUSB PC机（windows系统和Vmware下的ubuntu12.04） 一、交叉编译环境的选型 具体的安装交叉编译工具，网上很多资料都有，我的那篇《arm-linux- gcc交叉环境相关知识》也有介绍，这里我只是想提示大家：构建跟文件系统中所用到的lib库一定要是本系统Ubuntu中的交叉编译环境arm-linux- gcc中的。即如果电脑ubuntu中的交叉编译环境为arm-linux-
二、主机、开发板和虚拟机要三者互通 w IP v2.0》一文中有详细的操作步骤，不再赘述。 linux 2.6.22.6_jz2440.patch组合而来，具体操作： 1. 解压缩内核和其补丁包 tar xjvf linux-2.6.22.6.tar.bz2 # 解压内核 tar xjvf linux-2.6.22.6_jz2440.tar.bz2 # 解压补丁
cd linux_2.6.22.6 patch –p1 < ../linux-2.6.22.6_jz2440.patch 3. 配置 在内核目录下执行make 2410_defconfig生成配置菜单，至于怎么配置，《嵌入式linux应用开发完全手册》有详细介绍。 4. 生成uImage make uImage 四、移植busybox 在我们的根文件系统中的/bin和/sbin目录下有各种命令的应用程序，而这些程序在嵌入式系统中都是通过busybox来构建的，每一个命令实际上都是一个指向bu sybox的链接,busybox通过传入的参数来决定进行何种命令操作。 1）配置busybox 解压busybox-1.7.0,然后进入该目录，使用make menuconfig进行配置。这里我们这配置两项 一是在编译选项选择动态库编译，当然你也可以选择静态，不过那样构建的根文件系统会比动态编译的的大。 ->Busybox Settings ->Build Options
《驱动程序开发技术》大作业 ——过滤键盘驱动 姓名：梁海杰 学号：2009441624 班级：计科普0902
摘要 Kbdclass.sys是键盘的类驱动，无论是USB键盘，还是PS/2键盘都要经过它的处理；在键盘类驱动之下，和实际硬件打交道的驱动叫做“端口驱动”，比如：i8042prt.sys是ps/2键盘的端口驱动，Kbdhid.sys是USB键盘的端口驱动。键盘中断导致键盘中断服务例程被执行，导致最终i8042prt的I8042KeyboardInterruptService被执行。在I8042KeyboardInterruptService中，从端口读取扫描码，放到一个KEYBOARD_INPUT_DATA 结构中。并把这个结构放到i8042prt的输入队列中。最后会调用内核api函数KeInsertQueueDpc。在这个调用中会调用上层KbdClass.sys中处理输入的回调函数KeyboardClassServiceCallback，取走i8042prt的输入数据队列里的数据。利用驱动分层机制，使用过滤驱动捕获键盘的扫描码并保存下来；应用程序定时访问驱动程序取回扫描码，转换成相应的按键名称并显示；通过应用程序设定按键映射，应用程序将指令传送给驱动程序，以实现将指定的按键消息转换成其他按键。 关键词：过滤键盘；驱动分层；映射；扫描码
过滤键盘驱动 一、主要设计思路 利用驱动分层机制，使用过滤驱动捕获键盘的扫描码并保存下来；应用程序定时访问驱动程序取回扫描码，转换成相应的按键名称并显示；通过应用程序设定按键映射，应用程序将指令传送给驱动程序，以实现将指定的按键消息转换成其他按键。 键盘过滤驱动是工作在异步模式下的。系统为了得到一个按键操作，首先要发送一个IRP_MJ_READ消息到驱动的设备栈，驱动收到这个IRP后，会一直保持这个IRP为未确定（pending）态，因为当时并没有按键操作。直到一个键被真正的按下，驱动此时就会立刻完成这个IRP，并将刚按下的键的相关数据做为该IRP的返回值。在该IRP带着对应的数据返回后，操作系统将这些值传递给对应的事件系统来处理，然后系统紧接着又会立刻发送一个IRP_MJ_READ请求，等待下次的按键操作，重复以上的步骤。 为了实现截获键盘消息，需要在过滤驱动程序中创建一个挂接到物理键盘设备上层的过滤驱动设备。系统发送的IRP_MJ_READ消息会首先到达过滤驱动设备，这样就可以有机会给IRP_MJ_READ设置指定的完成例程，然后将消息下传给物理键盘设备。当有按键动作发生时，IRP_MJ_READ消息在完成后就会调用指定的完成例程，这时就可以在完成例程中读出键盘动作的内容，或者修改这些信息，以实现按键的映射。
BDD实践-easyb应用简述 行为驱动开发（Behaviour-Driven Development）（简写BDD）是一种设计方法。是测试驱动开发的进化，关注于设计。行为驱动开发中，定义系统的行为是主要工作，而对系统行为的描述则变成了测试标准。在实现中，BDD让客户和开发者使用同一种“语言”（DSL）来描述同一个系统，可以最大程度避免表达不一致带来的问题。同时结合测试，用系统行为的定义来验证实现代码。 在项目应用中，我们采用BDD众多框架的一种，Easyb来完成设计和测试工作。开发环境为Eclipse3.6版本，以下插件安装也选则和此版本对应的版本，不再说明。Easyb需要Groovy 环境支持，这里需要在Eclipse安装对应的插件，Groovy Eclipse Plugin（插件）是script语言Groovy的开发辅助工具，它提供编辑，编译，以及执行groovy脚本的功能。Groovy-Eclipse 2.5.0是最新版本。 Groovy-Eclipse 2.5.0 插件的更新地址，在线安装地址: https://www.doczj.com/doc/35660056.html,/release/GRECLIPSE/e3.6/ 安装包下载地址: https://www.doczj.com/doc/35660056.html,/release/GRECLIPSE/e3.6/archive-2.5.0.xx-20110511-1600-e36-R ELEASE.zip 安装完成Groovy插件后，需要安装Easyb插件。在线安装地址: https://www.doczj.com/doc/35660056.html,/svn/trunk/eclipse-plugins/org.easyb.eclipse.updatesite/ 安装包下载地址: https://www.doczj.com/doc/35660056.html,/files/easyb-0.9.8.tar.gz 配置完成上述环境就可以进行开发和测试工作了。 以下举例说明一个简单的应用。 首先说明需求情况。需求为在网络环境下，客户端需要远程调用一个应用服务，调用时只需要关心业务应用，指明需要的服务即可，不需要了解具体的路由过程。路由功能将由被设计的路由系统完成。 在这样的需求下，我们设计场景，即测试用例如下： 覆盖需求：客户端获取服务端地址。 用例名称：获取正确的应用服务发布端地址。 前置条件：1. 路由服务器启动。2. 应用服务发布端启动并注册到路由服务器。3. 应用服务请求端启动并注册到路由服务器。 操作步骤：应用服务请求端获取发布端地址。 预期结果：应用服务请求端获取正确的服务端地址。 我们把这个场景体现在Easyb中，首先建立一个story文件，文件命名为requester.story，作为服务请求方，从需求角度建立此文件。然后在该文件中建立一个场景，实现上述用例步骤。在Easyb中场景关键字是scenario。代码如下： 文件requester.story scenario"获取正确的应用服务发布端地址", { given"路由服务器启动" and given"应用服务发布端启动并注册到路由服务器" and given"应用服务请求端启动并注册到路由服务器" when"应用服务请求端获取发布端地址"
行为驱动开发 行为驱动开发（简称BDD）是测试驱动开发的升级版。它是一套软件工程实践方法，能帮助研发团队更快地构建和交付更有价值和更高质量的软件产品。采用BDD思想编写的测试读起来更像规格说明书而不是单元测试，所以它是使用测试作为表达和验证行为的一种手段。基于这个特性，BDD也非常适合应用在需求分析中。 一、行为驱动开发的原则 1．聚焦交付业务价值。使用验收标准作为目标，帮助业务实现更实际的可交付的功能。 2．团队共同确定交付标准。业务分析人员，开发人员，测试人员与最终用户一起定义和指定功能。 3．拥抱变化。项目开始时不锁定需求，而是假设需求，从用户那里得到早期的反馈，对需求的理解将在项目的整个生命周期中演进和变更。 4．不仅仅编写自动化测试，而是编写可执行规范和底层规范。团队将验收标准转换为自动化的验收测试，更准确地说是转换为可执行规范。在编写任何代码之前，开发人员将考虑代码实际上应该做什么，并将其表示为底层的可执行规范。可执行规范是一种自动化测试，它演示和验证应用程序如何交付特定的业务需求。自动化测试作为构建过程的一部分运行，并在对应用程序进行更改时运行，进行验收测试和回归测试。 5．交付活文档，并使用活文档来支持后续维护工作。在项目结束后持续维护项目可执行规范。 二、行为驱动开发的优势 1．专注业务目标，避免工程师把工作量浪费在不提供业务价值的功能上，能够降低成本，减少浪费。
2．完整的可执行规范，可充当开发人员的辅助技术文档，更容易理解现有的代码库并进行更改。 3．全面的自动化验收测试和回归测试，不仅可以提升执行效率，也能降低手工测试的出错率，使得迭代速度更快更可靠。 三、行为驱动开发的缺陷 1. 需要多个角色高度参与和协作，涉众如果不愿意或不能参与对话和协作，或者等到项目结束后才给出反馈，就很难充分利用BDD的优点。 2．比较适用于敏捷开发，但不太适用于瀑布式开发。 3．对参与角色能力要求很高，尤其是测试团队，不仅需要精通业务，对业务目标清晰，而且对测试技术能力要求更高，如果编写的自动化测试很烂，会导致更高的测试维护成本。
基于测试驱动开发的高校突发事件辅助决策系统 基于测试驱动开发的高校突发事件辅助决策系统 摘耍：由于高校的特殊性，导致突发事件的机会更多、危害更大，因此如何利用历史数据对高校突发事件进行预警和辅助决策显得十分重要。在探讨高校突发事件辅助决策系统的基础上，将测试驱动开发的方法应用于系统开发，实验证明可以明确高校突发事件辅助决策系统的开发需求，加速开发进程，改进软件的质量。 关键词：高校突发事件；辅助决策系统；测试驱动开发 目前，对于高校突发事件危机管理方面的应用研究比较欠缺，很多研究只是基于初步调查的经验总结和感性判断。因此将相关的前沿理论应用到突发事件管理的研究中，建立完善的突发事件辅助决策系统，为高校的管理者提供理论和实践依据是众多专家探讨的关键问题。将测试驱动开发TDD (Test-Dri VenDevel opment)的方法应用于系统开发，实验证明可以明确高校突发事件辅助决策系统的开发需求，加速幵发进程，改进软件的质量。 一、系统功能分析 高校突发事件辅助决策系统主耍具有突发事件预警和突发事件辅助处理两大功能。突发事件预警是指从根本上防止突发事件的形成、爆发，是一种超前的管理。预警系统是对预警对象、预警指标进行分析，从而获取预警信息，以便评佔信息、评价突发事件严重程度、决定是否发出突发事件警报。突发事件辅助处理是根据预警系统对突发事件的早期预测结果作决策，实施处理计划，把已经发生和未发生而将耍发生的事件的影响，控制在最小范围。 二、系统模块设计
根据上述分析，高校突发事件辅助决策系统可以划分为以下模块: 1、预警指标体系设定子模块。由于传统的事件跟踪的预警方法有着诸多弊端，高校突发事件辅助决策系统采用预警指标的方法。预警指标是依据对预警对象（事件、个人）的情况建立一套有监测功能的预警指标体系，通过预警指标收集信息，分析判断突发事件的成因、规模、类型、发生频率、强度、影响后果及发展和变化规律，进行突发事件的预测。 2、预警信息分析子模块。突发事件预警分析子模块主要工作是收集预警征兆信息，进行分析，根据分析结果，发布警报信息和对策信息。通过对学生所在的外部环境的分析研究，掌握客观环境的发展趋势和动态，了解与突发事件发纶有关的微观动向，从而敏锐地察觉环境的各种变化，保证当环境出现不利的因素时，能及吋有效地采取措施，趋利避害。 3、突发事件辅助处理子模块。突发事件管理既强调突发事件出现和发生之后的及时干预，乂重视对突发事件的处理，突发事件管理的偶然和突发性使得处理突发事件的应急计划的制定显得十分重要。在突发事件的应急计划屮，包括应对突发事件的策略、干预突发事件的规则、解决突发事件的程度和方法等。 4、数据查询功能子模块。系统具备全面简便的查询功能，可以按照所填的信息进行查询，快速生成处理报告。系统自带统计分析功能，可以为部分大量表的结果提供描述性统计量，能够实现对不同年份、性质、程度等基本统计量进行比较，大大方便了辅助决策及报告工作。 5、数据导出功能。系统具备全面轻松的数据导出功能，方便深入的科学研究。可以将全部量表的数据导出，从而很方便地实现深入的研究及完成辅助决策功能。 三、TDD在高校突发事件辅助决策系统的应用 1、TDD的概念 测试驱动开发TDD是敏捷开发中的一项核心实践和技术，也是一种设计方法论。TDD的原理是在开发功能代码之前，先编写单元测试用例代码。测试代码确定要编写产品的具体需求。TDD的基本思想是通过测试来推动整个开发的进行，但是测试驭动开发不是单纯的测试工作，而是把需求分析、设计、质量控制量化的过程。
Jbehave 学习 JBehave行为驱动开发（BDD）是一个框架。 BDD是测试驱动开发（TDD）和验收测试驱动开发（ATDD）的一种演进，目的是使新手和专家开发实践起来更加方便和直观。它改变了从被测试为基础到以行为为基础的词汇，将自己定位为一个设计理念。 一、BDD课题研究之测试思想和方法总结 此次研究的课题是BDD，主要涉及两个方面：测试的思想和方法、技术框架。这里做测试思想和方法的总结。 BDD是什么 全称： Behaviour Driven Development（行为驱动开发）。 BDD改变了我们对软件测试的认识。先前我对测试的认识是：从大的角度来讲，软件测试就是对一个软件系统从功能上进行确认测试和验证测试，从性能上进行压力测试和负载测试，以及对系统的配置测试和兼容性测试等，从类别上又有单元测试，集成测试，回归测试，所有的这些测试工作都有一个目的：交付一套高质量的软件系统。我们软件测试人员的工作就是：尽可能早的找出软件缺陷，并确保其得以修复。顺理成章的，在我们的思维中是：我们先拿到系统的既成品，然后开展测试工作，而BDD恰好颠覆了我们的思维。 回到BDD正题，BDD中有两个大的概念：测试先行和系统设计。 测试先行：BDD提倡我们在开发者的编码工作开展之前，先写测试用例，然后由测试来推动着开发的工作，具体解释为：在设计如何实现一个功能前，先考虑如何测试这个功能，测试的代码完成后，再编写功能实现代码，并且使得该测试用例通过，即完成了系统的一个功能模块。 系统设计：在系统功能实现代码编写之前，我们需要先编写测试代码，在我们的测试代码中实现对系统行为的描述，这个描述其实就是用一种接近自然语言的方式对系统进行详细的设计，并且使项目相关人员，即使是非技术人员也能很容易看懂。关于系统行为，举例说明：用户在一个特定的条件下对系统做请求，系统在该条件下做什么样的处理，这就是系统的一个行为。 总结一下BDD的概念：在项目之初，由客户、开发人员、测试人员一起通过充分的沟通对系统的行为进行设计，由测试人员以接近自然语言的方式编写可以描述系统行为的测试用例，然后由开发人员编写相关的实现代码，并确保该测试用例通过。循环这个过程实现整个系统的功能。
浅谈测试驱动开发（TDD） 李群https://www.doczj.com/doc/35660056.html, 测试驱动开发(TDD)是极限编程的重要特点，它以不断的测试推动代码的开发，既简化了 代码，又保证了软件质量。本文从开发人员使用的角度，介绍了TDD 优势、原理、过程、 原则、测试技术、Tips 等方面。 背景 一个高效的软件开发过程对软件开发人员来说是至关重要的，决定着开发是痛苦的挣扎，还是不断进步的喜悦。国人对软件蓝领的不屑，对繁琐冗长的传统开发过程的不耐，使大多数开发人员无所适从。最近兴起的一些软件开发过程相关的技术，提供一些比较高效、实用的软件过程开发方法。其中比较基础、关键的一个技术就是测试驱动开发（Test-Driven Development）。虽然TDD光大于极限编程，但测试驱动开发完全可以单独应用。下面就从开发人员使用的角度进行介绍，使开发人员用最少的代价尽快理解、掌握、应用这种技术。下面分优势，原理，过程，原则，测试技术，Tips等方面进行讨论。 1. 优势 TDD的基本思路就是通过测试来推动整个开发的进行。而测试驱动开发技术并不只是单纯的测试工作。 需求向来就是软件开发过程中感觉最不好明确描述、易变的东西。这里说的需求不只是指用户的需求，还包括对代码的使用需求。很多开发人员最害怕的就是后期还要修改某个类或者函数的接口进行修改或者扩展，为什么会发生这样的事情就是因为这部分代码的使用需求没有很好的描述。测试驱动开发就是通过编写测试用例，先考虑代码的使用需求（包括功能、过程、接口等），而且这个描述是无二义的，可执行验证的。 通过编写这部分代码的测试用例，对其功能的分解、使用过程、接口都进行了设计。而且这种从使用角度对代码的设计通常更符合后期开发的需求。可测试的要求，对代码的内聚性的提高和复用都非常有益。因此测试驱动开发也是一种代码设计的过程。 开发人员通常对编写文档非常厌烦，但要使用、理解别人的代码时通常又希望能有文档进行指导。而测试驱动开发过程中产生的测试用例代码就是对代码的最好的解释。 快乐工作的基础就是对自己有信心，对自己的工作成果有信心。当前很多开发人员却经常在担心：“代码是否正确？”“辛苦编写的代码还有没有严重bug？”“修改的新代码对其他部分有没有影响？”。这种担心甚至导致某些代码应该修改却不敢修改的地步。测试驱动开发提供的测试集就可以作为你信心的来源。 当然测试驱动开发最重要的功能还在于保障代码的正确性，能够迅速发现、定位bug。而迅速发现、定位bug是很多开发人员的梦想。针对关键代码的测试集，以及不断完善的测试用例，为迅速发现、定位bug提供了条件。 我的一段功能非常复杂的代码使用TDD开发完成，真实环境应用中只发现几个bug，而且很
敏捷测试的思考和新发展 2010年为《程序员》杂志写了一篇《敏捷测试的方法和实践》，我们可以回过头来，看看过去的一年，敏捷测试发生了哪些变化。首先，我做了一个实验，分别打开2010年和2011年的“STAREAST Conference at-a-Glance”，输入Agile，2010年显示10个结果，而2011年显示17个结果，有一个很大的增长，说明敏捷测试越来越引起大家的关注。这只是一个表面的现象，我们还需要真正了解发生了哪些实质性的变化。 举一个例子，《敏捷测试：测试人员和测试团队的实践指南》的作者Lisa Crispin在StarEast 2011上有一个演讲——Agile Testing: After the First Year, What’s Next? 其中提到，我们从传统开发方法转向敏捷方法，由于开发人员掌握了测试驱动开发（TDD，Test Driven Development），而测试人员部分地实现了验收测试和回归测试的自动化，所以我们活下来了，但我们在接下来深入实施敏捷测试时，还会面临新的挑战，甚至要克服更大的困难。当测试人员有了一年的经验，并拥有了敏捷方法的价值观、原则和实践之后，我们还不得不考虑如何不断改进持续的发布、如何有效地管理技术债务、如何对客户的需求有更好的理解，这就要求我们掌握更深的敏捷测试技术，例如将“精益（Lean）方法”用于改进敏捷测试的绩效，以及重构自动化测试的设计或脚本以提高投入产出比。 TDD 向ATDD、BDD转化？ 以前人们谈到敏捷方法，就会谈到TDD或UTDD（Unit TDD），但是究竟有多少个公司在采用TDD方法来写代码？而在采用TDD开发方法的公司中，又有多少程序员在全面使用TDD方法呢？TDD是一个纠结的问题。一方面，TDD的确是一个好东西，先写测试用例、后写代码，保证程序员第一次就把代码写对，也彻底解决了代码的可测试性问题，在代码层次上把缺陷的预防做到淋漓尽致。另一方面，多数项目很紧张，不可能给程序员足够时间去实施TDD，程序员对实现有极大兴趣，而对测试缺乏兴趣，多数程序员也不愿意或不会主动去做TDD。这样，TDD实践还存在较大困难，有比较多的争议。我看到一位作者写道：组里头TDD 说了3年，据我所知，看完两本TDD名著，并坚持写单元测试的人只有我一个（我组里有开发人员15名）。 为了解决TDD实施不力，在过去一年，越来越多的人关注ATDD，即验收测试驱动开发（Acceptance Test Driven Development）。从2003年开始，人们逐渐实践TDD，而ATDD 是在2007年Lasse Koskela写了一本书《测试驱动：Java 开发人员的TDD和ATDD》，才开始引起大家的更多关注。从那时算起也有四年了，但在国内，则是最近一两年的事。当然，我们可以将TDD和ATDD结合起来使用，形成一种混合的方法模型。TDD和ATDD之间的关系，可以用图1来描述。
练习题 1.软件调试的目的是？ A A. 找出错误所在并改正之 B. 排除存在错误的可能性 C. 对错误性质进行分类 D. 统计出错的次数 2.下列叙述中,哪一项是正确的 ．．．？ D A.用黑盒法测试时，测试用例是根据程序内部逻辑设计的; B.测试是为了验证该软件已正确地实现了用户的要求; C.对面向对象程序来说,单元测试的最小单元是每条程序语句,即以分号结尾的程序; D.发现错误多的程序模块，残留在模块中的错误也多。 3.创建一个基于JUNIT的单元测试类，该类必须扩展? C A．TestSuite B. Assert C. TestCase D. JFCTestCase 4.以下对单元测试，不正确 ．．．的说法是? C A．单元测试的主要目的是针对编码过程中可能存在的各种错误； B．单元测试一般是由程序开发人员完成的 C．单元测试是一种不需要关注程序结构的测试； D．单元测试属于白盒测试的一种。 5.测试驱动开发的含义是? B A．先写程序后写测试的开发方法 B. 先写测试后写程序，即“测试先行” C. 用单元测试的方法写测试 D. 不需要测试的开发 6.用JUNIT断言一个方法输出的是指定字符串，应当用的断言方法是? C A．assertNotNull( ) B. assertSame() C. assertEquals() D. assertNotEquals() 7.TestCase是junit.framework中的一个? C A．方法 B. 接口 C. 类 D. 抽象类
8.TestSuite是JUNIT中用来? A A．集成多个测试用例 B. 做系统测试用的 C. 做自动化测试用的 D. 方法断言 9.对于测试程序的一些命名规则，以下说法正确 ．．的一项是? C A．测试类的命名只要符合Java类的命名规则就可以了； B．测试类的命名一般要求以Test打头，后接类名称，如：TestPerson； C．测试类的命名一般要求以Test结尾，前接类名称，如：PersonTest； D．测试类中的方法都是以testXxx（）形式出现。 10.以下不属于单元测试优点的一项是? D A．它是一种验证行为 B. 它是一种设计行为 C．它是一种编写文档的行为 D. 它是一种评估行为 数据驱动测试也称? C A．单元测试 B. 白盒测试 C. 黑盒测试 D. 确认测试 11.逻辑驱动测试也称? C A．单元测试 B. 灰盒测试 C. 白盒测试 D. 用户测试 12.以下不属于白盒测试的优点是? B A．增大代码的覆盖率 B.与软件的内部实现无关 C．提高代码的质量 D.发现代码中隐藏的问题 13.组装测试又称为? A A．集成测试 B. 系统测试 C. 回归测试 D. 确认测试 14.对于单元测试框架，除了用于Java的JUnit还有CppUnit、NUnit等，它们是? A A．C++单元测试框架、.NET单元测试框架 B. C语言单元测试框架、通用单元测试框架 C．C++单元测试框架、自动化单元测试框架 D. 自动化单元测试框架、.NET单元测试框架 15.对于JFCUnit，以下说法不正确 ．．．的是? D A. 它是JAVA GUI的测试框架 B. 它是JUnit的扩展，用于GUI的测试 C．编写JFCUnit的测试用例需要扩展JFCTestCase