第六章：内核编程介绍
一、内核开发入门
（一）内核编程的环境准备
从现在开始如何编写内核程序和一些注意事项，内核程序运行在R0层，拥有最高权限，在这里我假设你有足够的VC开发上层应用程序的经验。
开发内核程序需要准备的开发环境：Visual Studio 6/2005/2010均可，微软的驱动程序开发包DDK（Driver Development Kit），随着Vista版本的发布这个开发包升级为WDK （Windows Driver Kit）
开发内核程序需要准备的调试环境：虚拟机系统，Windbg调试程序, Dbgview.exe 查看日志程序。
（二）编写第一个驱动程序
与普通的应用程序相比，在一个内核程序工程中，需要增加如下两个文件：
其他更详细的信息，请到网上查阅相关资料。
没有仔细研究过，写成这样就可以编译通过。更多细节请查阅相关资料。
以查看到本程序打印出来的日志。
二、驱动开发基础
（一）浅谈驱动对象、设备对象与请求
首先，谈谈驱动对象（DRIVER_OBJECT），可以说驱动对象代表的是一个驱动程序（或者叫内核模块）。在写内核程序时，必须要填写这样一种结构，来告诉Windows 程序提供的功能。内核程序并不生成进程，它们有系统的System进程加载，可以存在于任何的进程。
设备对象（DEVICE_OBJECT）可以是一个具体的物理设备，如：键盘、硬盘等；
也可以是一个虚拟的“设备”，如：用于进程间通信的管道。设备对象由驱动对象创建，一个驱动对象可以创建很多个设备对象。这些设备对象储存在一个设备栈中，这些设备对象是用链表连接在一起的，当新的设备对象产生时应该是用的尾插入（和人理解）。
对于请求，我们可以理解为Windows SDK程序设计里的消息。一般都是以IRP方式传递的。而设备对象是唯一可以接受请求的实体。然而一个驱动对象中可能会有很多个设备对象，那么是由哪一个设备对象来处理呢？
我的理解是：就像MFC中的消息传递机制一样，会有一个消息的接收顺序；IRP 请求也是这样，它先发送到设备栈中最上面的一个设备（最新加入），没有被处理就继续向下发送，如果到最后都还是没有被处理，我认为会有一个默认的处理。
（二）IoCallDriver函数与PoCallDriver函数
除了函数名不同之外，其他都一样。参数都是两个，一个是设备对象的指针，另一个是IRP请求对象的指针。返回值也是一样。那么区别到底是什么呢？
我们来看WDK Documentation上的解释：
The IoCallDriver routine sends an IRP to the driver associated with a specified device object.
The PoCallDriver routine passes a power IRP to the next-lower driver in the device stack. (Windows Server 2003, Windows XP, and Windows 2000 only.)
从上面的这两句话中可以看出：IoCallDriver这个函数向DeviceObject设备对象的驱动对象发送一个IRP请求；而PoCallDriver函数向设备栈中的下层设备传递一个主功能号为IRP_MJ_POWER的请求，且限于特定的OS。
而且，调用IoCallDriver之前，主调驱动程序必须要为目标驱动程序建立IRP里的I/O stack location；同时，调用时，IoCallDriver函数还会帮助驱动程序将输入参数的DeviceObject值赋给IO_STACK_LOCA TION结构里的DeviceObject成员。
（三）IRP请求处理及完成机制
近来学习Windows 内核方面的东西，觉得对I/O 处理过程没有一个总体的概念。
于是，就花了很长的时间搜集了很多这方面的知识总结了一下。
在Windows 内核中的请求基本上是通过I/O Request Packet 完成的。前面说过，设备对象是唯一可以接受请求的实体。下面，我就来详细地说下IRP 请求是怎么样一步一步完成的。
首先，我们就需要知道IRP 是怎么产生。IRP 是由I/O 管理器发出的，I/O 管理器是用户态与内核态之间的桥梁，当用户态进程发出I/O 请求时，I/O 管理器就捕获这些请求，将其转换为IRP 请求，发送给驱动程序。I/O 管理器无疑是非常重要的，具有核心地位。它负责所有I/O 请求的调度和管理工作，根据请求的不同内容，选择相应的驱动程序对象，设备对象，并生成、发送、释放各种不同的IRP 。整个I/O 处理流程是在它的指挥下完成的。
一个IRP 是从非分页内存中分配的可变大小的结构，它包括两部分：IRP 首部和辅助请求参数数组，如图1 所示。这两部分都是由I/O 管理器建立的。
图 1 IRP 简单结构图
IRP 首部中包含了指向IRP 输入输出缓冲区指针、当前拥有IRP 的驱动指针等。
紧接着首部的是一个IO_STACK_LOCATION 结构的数组。它的大小由设备栈中的设备数确定（设备栈的概念会在下文中阐述）。IO_STACK_LOCATION 结构中保存了一个I/O 请求的参数及代码、请求当前对应的设备指针、完成函数指针（IoCompletion ）等。
那么，由I/O 管理器产生的IRP 请求发送到哪去了呢？这里我们就要来说说设备栈的概念了，操作系统用设备对象（device object ）表示物理设备，每一个物理设备都有一个或多个设备对象与之相关联，设备对象提供了在设备上的所有操作。也有一些设备对象并不表示物理设备。一个唯软件驱动程序（software-only driver ，处理I/O 请求，但是不把这些请求传递给硬件）也必须创建表示它的操作的设备对象。设备常常由多个设备对象所表示，每一个设备对象在驱动程序栈（driver stack ）中对应一个驱动程序来管理设备的I/O 请求。一个设备的所有设备对象被组织成一个设备栈（device stack ）。而且，IO_STACK_LOCATION 数组中的每个元素和设备栈中的每个设备是一一对应的，一般情况下，只允许层次结构中的每个设备对象访问它自己对应的IO_STACK_LOCATION 。无论何时，一个请求操作都在一个设备上被完成，I/O 管理器把IRP 请求传递给设备栈中顶部设备的驱动程序（IRP 是传递给设备对象的，通过设备对象的DriverObject 成员找到驱动程序）。驱动程序访问它对应的设备对象在IRP 中IO_STACK_LOCATION 数组中的元素检查参数，以决定要进行什么操作（通过检查结构中的MajorFunction 字段，确定执行什么操作及如何解释Parameters 共用体字段的内容）。驱动程序可以根据IO_STACK_LOCA TION 结构中的MajorFunction 字段进行处理。每一个驱动或者处理IRP ，或者把它传递给设备栈中下一个设备对象的驱动程序。
传递IRP 请求到底层设备的驱动程序需要经过下面几个步骤：
1.为下一个IO_STACK_LOCATION 结构设置参数。可以有以下两种方式：
·调用IoGetNextIrpStackLocation 函数获得下个结构的指针，再对参数进行赋值；
·调用IoCopyCurrentIrpStackLocationToNext 函数（如果第 2 步中驱动设置了IoCompletion 函数），或者调用IoSkipCurrentIrpStackLocation 函数（如果第2 步中驱动没有设置IoCompletion 函数）把当前的参数传递给下一个。
2.如果需要的话，调用IoSetCompletionRoutine 函数设置IoCompletion 函数进行后续处理。
3.调用IoCallDriver 函数将IRP 请求传递给下一层驱动。这个函数会自动调整IRP 栈指针，并且执行下一层驱动的派遣函数。
当驱动程序把IRP 请求传递给下一层驱动之后，它就不再拥有对该请求的访问权，强行访问会导致系统崩溃。如果驱动程序在传递完之后还想再访问该请求，就必须要设置IoCompletion 函数。IRP 请求可以再其他驱动程序或者其他线程中完成或取消。
当某一驱动程序调用IoCompleteRequest 函数时，I/O 操作就完成了。这个函数使得IRP 的堆栈指针向上移动一个位置，如图2 所示：
图 2 IRP 完成时栈指针的移动
图 2 所示的当 C 驱动程序调用完IoCompleteRequest 函数后I/O 栈的情况。左边的实线箭头表明栈指针现在指向驱动 B 的参数和回调函数；虚线箭头是之前的情况。右边的空心箭头指明了IoCompletion 函数被调用的顺序。
如果驱动程序把IRP 请求传递给设备栈中的下层设备之前设置了IoCompletion 函数，当I/O 栈指针再次指回到该驱动程序时，I/O 管理器就将调用该IoCompletion 函数。
IoCompletion 函数的返回值有两种：
（ 1 ）STATUS_CONTINUE_COMPLETION ：告诉I/O 管理器继续执行上层驱动程序的IoCompletion 函数。
（ 2 ）STA TUS_MORE_PROCESSING_REQUIRED ：告诉I/O 管理器停止执行上层驱动程序，并将栈指针停在当前位置。在当前驱动程序调用IoCompleteRequest 函数后再继续执行上层驱动的IoCompletion 函数。
当所有驱动都完成了它们相应的子请求时，I/O 请求就结束了。I/O 管理器从Irp ?>IoStatus.Status 成员更新状态信息，从Irp?>https://www.doczj.com/doc/4814178177.html,rmation 成员更新传送字节数。
（四）编写程序手动加载驱动程序
（五）创建IRP的四种不同方式
在驱动程序中，经常会调用其他的驱动程序；其中，手动构造IRP ，然后将IRP 传递到相应驱动程序的派遣函数中是一种比较简单的方法，下面就来介绍下手动创建IRP 的几种不同的方法及其特点。
创建IRP 总共有 4 种方法。分别通过调用：IoBuildSynchronousFsdRequest 、IoBuildAsynchronousFsdRequest 、IoBuildDeviceIoControl 和IoAllocateIrp 这4 个内核函数来完成。这其中，IoAllocateIrp 是比较底层的内核函数，其余的三个内核函数是属于靠近上层的内核函数，而且这三个函数都是通过调用IoAllocateIrp 实现的。
这几个函数都是文档化的函数，原型都可以在DDK Documentation 中查到，这里就不多说了，下面主要来说说它们的不同点：
1.可创建的IRP 类型
这四个函数可以创建的IRP 的类型是不同的。IoBuildSynchronousFsdRequest 用于创建同步的IRP 请求，但是只可以创建以下类型的IRP ：IRP_MJ_PNP ,IRP_MJ_READ,IRP_MJ_WRITE,IRP_MJ_FLUSH_BUFFERS 和IRP_MJ_SHUTDOWN ；IoBuildAsynchronousFsdRequest 可创建的IRP 类型和IoBuildSynchronousFsdRequest 一样（从名字就可以看出来），只是它是用来创建异步的IRP 请求。IoBuildDeviceIoControl 可以创建的IRP 类型为：IRP_MJ_DEVICE_CONTROL 和IRP_MJ_INTERNAL_DEVICE_CONTROL 。而且IoBuildDeviceIoControl 只能创建同步的IRP 。在这三个函数中，都有一个ULONG 的输入参数指定创建的IRP 类型。IoAllocateIrp 函数的使用比较灵活，他可以创建任意类型的IRP ，但不是由参数指定，而是创建后自行填写，要求用户对IRP 的结构有比较熟悉的理解。
2.创建后IRP 对象的删除
IoBuildSynchronousFsdRequest、IoBuildAsynchronousFsdRequest 和IoBuildDeviceIoControl 内核函数在创建完IRP 后，不需要程序员负责删除IRP ，操作系统会自动删除。而用IoAllocateIrp 内核函数创建IRP 时，需要程序员自己调用IoFreeIrp 内核函数删除IRP 对象。
3.关联的事件
IoBuildSynchronousFsdRequest 和IoBuildDeviceIoControl 在创建IRP 时，需要为它们准备好一个事件，这个事件会和IRP 请求相关联，当IRP 请求被结束时该事件触发。程序中要用KeWaitForSingleObject 函数等待。IoBuildAsynchronousFsdRequest 函数创建IRP 时则不需要准备事件，不过可以通过IRP 的UserEvent 子域来通知IRP 请求的结束。
当执行IoCompleteRequest 内核函数时，操作系统会检查IRP 的UserEvent 子域是否为空。如果该子域为空，则它代表一个事件指针，这时IoCompleteRequest 会设置这个事件。
（六）驱动和应用层的三种通信方式
驱动程序和客户应用程序经常需要进行数据交换，但我们知道驱动程序和客户应用程序可能不在同一个地址空间，因此操作系统必须解决两者之间的数据交换。
驱动层和应用层通信，主要是靠DeviceIoControl函数，下面是该函数的原型：
BOOL DeviceIoControl (
HANDLE hDevice, // 设备句柄
DWORD dwIoControlCode, // IOCTL请求操作代码
LPVOID lpInBuffer, // 输入缓冲区地址
DWORD nInBufferSize, // 输入缓冲区大小
LPVOID lpOutBuffer, // 输出缓冲区地址
DWORD nOutBufferSize, // 输出缓冲区大小
LPDWORD lpBytesReturned, // 存放返回字节数的指针
LPOVERLAPPED lpOverlapped // 用于同步操作的Overlapped结构体指针
);
dwIoControlCode
要进行操作的控制码。驱动程序可以通过CTL_CODE宏来组合定义一个控制码，并在IRP_MJ_DEVICE_CONTROL的实现中进行控制码的操作。在驱动层，irpStack->Parameters.DeviceIoControl.IoControlCode表示了这个控制码。
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////
IoBuildDeviceIoControl 可以创建的IRP 类型为：IRP_MJ_DEVICE_CONTROL和IRP_MJ_INTERNAL_DEVICE_CONTROL 。而且IoBuildDeviceIoControl 只能创建同步的IRP
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////
IOCTL请求有四种缓冲策略，下面一一介绍。
1、输入输出缓冲I/O(METHOD_BUFFERED)
2、直接输入缓冲输出I/O(METHOD_IN_DIRECT)
3、缓冲输入直接输出I/O(METHOD_OUT_DIRECT)
4、上面三种方法都不是(METHOD_NEITHER)
为了对这些类型更详细的描述，请看msdn上的解释，我抄录如下：
"缓冲"方法(METHOD_BUFFERED)
备注：在下面的讨论中，"输入"表示数据从用户模式的应用程序到驱动程序，"输出"表示数据从驱动程序到应用程序。
对于读取请求，I/O 管理器分配一个与用户模式的缓冲区大小相同的系统缓冲区。
IRP 中的SystemBuffer 字段包含系统地址。UserBuffer 字段包含初始的用户缓冲区地址。当完成请求时，I/O 管理器将驱动程序已经提供的数据从系统缓冲区复制到用户缓冲区。对于写入请求，会分配一个系统缓冲区并将SystemBuffer 设置为地址。用户缓冲区的内容会被复制到系统缓冲区，但是不设置UserBuffer。对于IOCTL 请求，会分配一个容量大小足以包含输入缓冲区或输出缓冲区的系统缓冲区，并将SystemBuffer 设置为分配的缓冲区地址。输入缓冲区中的数据复制到系统缓冲区。UserBuffer 字段设置为用户模式输出缓冲区地址。内核模式驱动程序应当只使用系统缓冲区，且不应使用UserBuffer 中存储的地址。
对于IOCTL，驱动程序应当从系统缓冲区获取输入并将输出写入到系统缓冲区。当完成请求时，I/O 系统将输出数据从系统缓冲区复制到用户缓冲区。
"直接"方法(METHOD_IN/OUT_DIRECT)
对于读取和写入请求，用户模式缓冲区会被锁定，并且会创建一个内存描述符列表(MDL)。MDL 地址会存储在IRP 的MdlAddress 字段中。SystemBuffer 和UserBuffer 均没有任何含义。但是，驱动程序不应当更改这些字段的值。
对于IOCTL 请求，如果在METHOD_IN_DIRECT 和METHOD_OUT_DIRECT 中同时有一个输出缓冲区，则分配一个系统缓冲区（SystemBuffer 又有了地址）并将输入数据复制到其中。如果有一个输出缓冲区，且它被锁定，则会创建MDL 并设置MdlAddress。UserBuffer 字段没有任何含义。
"两者都不"方法(METHOD_NEITHER)
对于读取和写入请求，UserBuffer 字段被设置为指向初始的用户缓冲区。不执行任何其他操作。SystemAddress 和MdlAddress 没有任何含义。对于IOCTL 请求，I/O 管理器将UserBuffer 设置为初始的用户输出缓冲区，而且，它将当前I/O 栈位置的Parameters.DeviceIoControl.Type3InputBuffer 设置为用户输入缓冲区。利用该I/O 方法，由驱动程序来确定如何处理缓冲区：分配系统缓冲区或创建MDL。
通常，驱动程序在访问用户数据时不应当将UserBuffer 字段用作地址，即使当用户缓冲区被锁定时也是如此。这是由于在调用驱动程序时，在系统中可能看不到调用用户的地址空间。（对于该规则的一个例外是，在最高层驱动程序将IRP 向下传递到较低层的驱动程序之前，它可能需要使用UserBuffer 来复制数据。）如果使用"直接"或"两者都不"方法，在创建MDL 之后，驱动程序可以使用MmGetSystemAddressForMdl 函数来获取有效的系统地址以访问用户缓冲区。
在驱动层，依传输类型的不同，输入缓冲区的位置亦不同，见下表。
传输类型位置
METHOD_IN_DIRECT irp->AssociatedIrp.SystemBuffer
METHOD_OUT_DIRECT irp->AssociatedIrp.SystemBuffer
METHOD_BUFFERED irp->AssociatedIrp.SystemBuffer
METHOD_NEITHER
irpStack->Parameters.DeviceIoControl.Type3InputBuffer
在驱动层，依传输类型的不同，输出缓冲区的位置亦不同，见下表。
传输类型位置
METHOD_IN_DIRECT irp->MdlAddress
METHOD_OUT_DIRECT irp->MdlAddress
METHOD_BUFFERED irp->AssociatedIrp.SystemBuffer
METHOD_NEITHER irp->UserBuffer
所以只要确定了传输方式后，就可以根据各自的位置来读取和写入数据，从而实现应用层和驱动的通信。
下面看驱动层对ioctl控制码的处理代码：
代码：
码比较简单，我就不多说了，还是看代码吧，很好明白。
（七）SSDT详解
1．什么是SSDT
自然，这个是我必须回答的问题。不过在此之前，请你打开命令行（cmd.exe）窗口，并输入“dir”并回车——好了，列出了当前目录下的所有文件和子目录。
那么，以程序员的视角来看，整个过程应该是这样的：
由用户输入dir命令。
cmd.exe获取用户输入的dir命令，在内部调用对应的Win32 API函数FindFirstFile、FindNextFile和FindClose，获取当前目录下的文件和子目录。
cmd.exe将文件名和子目录输出至控制台窗口，也就是返回给用户。
到此为止我们可以看到，cmd.exe扮演了一个非常至关重要的角色，也就是用户与Win32 API的交互。——你大概已经可以猜到，我下面要说到的SSDT亦必将扮演这个角色，这实在是一点新意都没有。
没错，你猜对了。SSDT的全称是System Services Descriptor Table，系统服务描述符表。这个表就是一个把ring3的Win32 API和ring0的内核API联系起来的角色，下面我将以API函数OpenProcess为例说明这个联系的过程。
你可以用任何反汇编工具来打开你的kernel32.dll，然后你会发现在OpenProcess中
这就是说，OpenProcess调用了ntdll.dll的NtOpenProcess函数。那么继续反汇编之，
上面是我的XP Professional sp2中ntdll.dll的反汇编结果，如果你用的是2000系统，
虽然它们存在着些许不同，但都可以这么来概括：
把一个数放入eax（XP是0x7A，2000是0x6A），这个数值称作系统的服务号。
把参数堆栈指针（esp+4）放入edx。
sysenter或int 2Eh。
好了，你在ring3能看到的东西就到此为止了。事实上，在ntdll.dll中的这些函数可以称作真正的NT系统服务的存根（Stub）函数。分隔ring3与ring0城里城外的这一道叹息之墙，也正是由它们打通的。接下来SSDT就要出场了，come some music。
2．SSDT有何用
插一句先，貌似到现在为止我仍然没有讲出来SSDT是个什么东西，真正可以算是“犹抱琵琶半遮面”了。——书接上文，在你调用sysenter或int 2Eh之后，Windows 系统将会捕获你的这个调用，然后进入ring0层，并调用内核服务函数NtOpenProcess，这个过程如下图所示。
SSDT在这个过程中所扮演的角色是至关重要的。让我们先看一看它的结构，如下图。
当程序的处理流程进入ring0之后，系统会根据服务号（eax）在SSDT这个系统服务描述符表中查找对应的表项，这个找到的表项就是系统服务函数NtOpenProcess的真正地址。之后，系统会根据这个地址调用相应的系统服务函数，并把结果返回给ntdll.dll 中的NtOpenProcess。图中的“SSDT”所示即为系统服务描述符表的各个表项；右侧的“ntoskrnl.exe”则为Windows系统内核服务进程（ntoskrnl即为NT OS KerneL的缩写），它提供了相对应的各个系统服务函数。ntoskrnl.exe这个文件位于Windows的system32目录下，有兴趣的朋友可以反汇编一下。
附带说两点。根据你处理器的不同，系统内核服务进程可能也是不一样的。真正运行于系统上的内核服务进程可能还有ntkrnlmp.exe、ntkrnlpa.exe这样的情况——不过为了统一起见，下文仍统称这个进程为ntoskrnl.exe。另外，SSDT中的各个表项也未必会全部指向ntoskrnl.exe中的服务函数，因为你机器上的杀毒监控或其它驱动程序可能会改写SSDT中的某些表项——这也就是所谓的“挂钩SSDT”——以达到它们的“主动防御”式杀毒方式或其它的特定目的。
KeServiceDescriptorTable
事实上，SSDT并不仅仅只包含一个庞大的地址索引表，它还包含着一些其它有用的信息，诸如地址索引的基地址、服务函数个数等等。ntoskrnl.exe中的一个导出项KeServiceDescriptorTable即是SSDT的真身，亦即它在内核中的数据实体。SSDT的数据结构定义如下：
pvServiceCounterTable则指向另一个索引表，该表包含了每个服务表项被调用的次数；不过这个值只在Checkd Build的内核中有效，在Free Build的内核中，这个值总为NULL （注：Check/Free是DDK的Build模式，如果你只使用SDK，可以简单地把它们理解为Debug/Release）。ulNumberOfServices表示当前系统所支持的服务个数。pvParamTableBase指向SSPT（System Service Parameter Table，即系统服务参数表），该表格包含了每个服务所需的参数字节数。
下面，让我们开看看这个结构里边到底有什么。打开内核调试器（以kd为例），输
接下来，亦可根据基地址与服务总数来查看整个服务表的各项：
为我的SSDT被System Safety Monitor接管了，没留下几个原生的ntoskrnl.exe表项。
现在是写些代码的时候了。KeServiceDescriptorTable及SSDT各个表项的读取只能在ring0层完成，于是这里我使用了内核驱动并借助DeviceIoControl来完成。其中
浅谈验收测试驱动开发 【摘要】软件行业已经发展了很多年，尽管新技术不断涌现，但是软件质量问题依然存在，最突出的两点就是较高的缺陷率和较差的可维护性。为了应对此类问题，驱动测试开发技术（ADD）应运而生，但是随着ADD技术的普及，它所隐藏的问题也浮出水面，最为人诟病的就是“不能满足客户需求”，因为测试人员只注重代码缺陷率而忽视了系统具体功能。本文阐述如何在ADD开发模式的基础上，结合验收测试驱动开发（ATDD）探讨如何开发适应于用户的系统。 【关键词】敏捷开发；验收测试驱动开发；软件工程 一、引言 极限编程方法理论中“测试驱动开发”是其一个重要组成部分，最早是由Kent Beck提出，并积极推广的一种软件开发方法。Kent Beck在他所著的《测试驱动开发》一书中指出“测试驱动开发”遵循“为明天编码，为今天设计”的观点。相比传统遵循“需求-设计-开发-测试”的软件开发流程而言，更强调测试优先，再通过编码和重构反复迭代最终构筑一个完整的软件系统。“测试驱动开发”在相当程度上了的确提高了开发人员的代码质量，而且在应对系统的可靠性也教之传统软件开发有着更大的优势，主要体现在客户需求变更时能灵活应对。然而软件问题中另一项“是否满足客户需求”确没有很好地解决。验收测试驱动开发（ATDD）针对这个问题，提出让客户参与到测试标准的制定，让软件满足客户需求。用ATDD 方法开发软件，开发人员更注重的是系统行为测试，而不是软件中每个模块，甚至每行代码的测试。构筑一个满足客户需求的软件系统，不仅仅是软件设计开发人员和测试人员靠个人能力能解决的，在此过程中需要客户参与进来，为打造可靠的软件提供有力的保障。 二、什么是ATDD 测试驱动开发（ADD）能够帮助开发人员开发出高质量的代码，保证开发人员所开发出的代码执行正确，但是这些执行正确的代码在很大程度上是针对的具体模块而不是整体的系统功能。在一定程度上不一定能够满足客户的需求。验收测试驱动开发（ATDD）是建立在TDD的基础上，TDD和ATDD既可以分开使用也可以配合使用，在帮助开发人员在提高软件质量的同时，也帮助开发人员开发出用户真正需要的软件系统。软件测试是软件工程的重要组成部分，在传统的软件开发当中，软件测试大概包括软件执行过程中是否存在BUG、系统中是否还存在其它缺陷以及系统是否与系统设计书保持一致几项内容，ATDD则在此基础上赋予了软件软件测试新的任务，即利用验收测试从系统功能的角度上驱动软件开发，解决软件不能满足客户需求或者是与客户设想相背离的问题。 总体而言验收测试驱动开发是包括客户在内的一个团体组织的活动，围绕着客户需求引入“用户故事”（user story）这种灵活的客户需求管理方式。客户和技术人员（包括设计、开发和测试）通过紧密的写作、有效的交流和沟通构筑可靠
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为单的数据块，但不知道文件怎样表示。举个更具体的生活例子。主人(最高层驱动)知道（并且需要）笔计本电脑，但不知道具体放在什么位置；而仆人(最底层驱动)却知道它放在具体什么地方，但
浅谈测试驱动开发（TDD） 李群https://www.doczj.com/doc/4814178177.html, 测试驱动开发(TDD)是极限编程的重要特点，它以不断的测试推动代码的开发，既简化了 代码，又保证了软件质量。本文从开发人员使用的角度，介绍了TDD 优势、原理、过程、 原则、测试技术、Tips 等方面。 背景 一个高效的软件开发过程对软件开发人员来说是至关重要的，决定着开发是痛苦的挣扎，还是不断进步的喜悦。国人对软件蓝领的不屑，对繁琐冗长的传统开发过程的不耐，使大多数开发人员无所适从。最近兴起的一些软件开发过程相关的技术，提供一些比较高效、实用的软件过程开发方法。其中比较基础、关键的一个技术就是测试驱动开发（Test-Driven Development）。虽然TDD光大于极限编程，但测试驱动开发完全可以单独应用。下面就从开发人员使用的角度进行介绍，使开发人员用最少的代价尽快理解、掌握、应用这种技术。下面分优势，原理，过程，原则，测试技术，Tips等方面进行讨论。 1. 优势 TDD的基本思路就是通过测试来推动整个开发的进行。而测试驱动开发技术并不只是单纯的测试工作。 需求向来就是软件开发过程中感觉最不好明确描述、易变的东西。这里说的需求不只是指用户的需求，还包括对代码的使用需求。很多开发人员最害怕的就是后期还要修改某个类或者函数的接口进行修改或者扩展，为什么会发生这样的事情就是因为这部分代码的使用需求没有很好的描述。测试驱动开发就是通过编写测试用例，先考虑代码的使用需求（包括功能、过程、接口等），而且这个描述是无二义的，可执行验证的。 通过编写这部分代码的测试用例，对其功能的分解、使用过程、接口都进行了设计。而且这种从使用角度对代码的设计通常更符合后期开发的需求。可测试的要求，对代码的内聚性的提高和复用都非常有益。因此测试驱动开发也是一种代码设计的过程。 开发人员通常对编写文档非常厌烦，但要使用、理解别人的代码时通常又希望能有文档进行指导。而测试驱动开发过程中产生的测试用例代码就是对代码的最好的解释。 快乐工作的基础就是对自己有信心，对自己的工作成果有信心。当前很多开发人员却经常在担心：“代码是否正确？”“辛苦编写的代码还有没有严重bug？”“修改的新代码对其他部分有没有影响？”。这种担心甚至导致某些代码应该修改却不敢修改的地步。测试驱动开发提供的测试集就可以作为你信心的来源。 当然测试驱动开发最重要的功能还在于保障代码的正确性，能够迅速发现、定位bug。而迅速发现、定位bug是很多开发人员的梦想。针对关键代码的测试集，以及不断完善的测试用例，为迅速发现、定位bug提供了条件。 我的一段功能非常复杂的代码使用TDD开发完成，真实环境应用中只发现几个bug，而且很
linux驱动开发的经典书籍 结构、操作系统、体系结构、编译原理、计算机网络你全修过 我想大概可以分为4个阶段，水平从低到高 从安装使用=>linux常用命令=>linux系统编程=>内核开发阅读内核源码 其中学习linux常用命令时就要学会自己编译内核，优化系统，调整参数 安装和常用命令书太多了，找本稍微详细点的就ok，其间需要学会正则表达式 系统编程推荐《高级unix环境编程》，黑话叫APUE 还有《unix网络编程》 这时候大概还需要看资料理解elf文件格式，连接器和加载器，cmu的一本教材中文名为《深入理解计算机系统》比较好 内核开发阅读内核源码阶段，从写驱动入手逐渐深入linux内核开发 参考书如下《linux device drivers》，黑话叫ldd 《linux kernel development》，黑话叫lkd 《understading the linux kernel》，黑话叫utlk 《linux源码情景分析》 这四本书为搞内核的必读书籍 最后，第三阶段和第四阶段最重动手，空言无益，光看书也不罩，不动手那些东西理解不了 学习linux/unix编程方法的建议 建议学习路径： 首先先学学编辑器，vim, emacs什么的都行。 然后学make file文件，只要知道一点就行，这样就可以准备编程序了。 然后看看《C程序设计语言》K&R，这样呢，基本上就可以进行一般的编程了，顺便找本数据结构的书来看。 如果想学习UNIX/LINUX的编程，《APUE》绝对经典的教材，加深一下功底，学习《UNP》的第二卷。这样基本上系统方面的就可以掌握了。 然后再看Douglus E. Comer的《用TCP/IP进行网际互连》第一卷，学习一下网络的知识，再看《UNP》的第一卷，不仅学习网络编程，而且对系统编程的一些常用的技巧就很熟悉了，如果继续网络编程，建议看《TCP/IP进行网际互连》的第三卷，里面有很多关于应用
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架构简图
linux驱动程序的编写 一、实验目的 1.掌握linux驱动程序的编写方法 2.掌握驱动程序动态模块的调试方法 3.掌握驱动程序填加到内核的方法 二、实验内容 1. 学习linux驱动程序的编写流程 2. 学习驱动程序动态模块的调试方法 3. 学习驱动程序填加到内核的流程 三、实验设备 PentiumII以上的PC机，LINUX操作系统，EL-ARM860实验箱 四、linux的驱动程序的编写 嵌入式应用对成本和实时性比较敏感，而对linux的应用主要体现在对硬件的驱动程序的编写和上层应用程序的开发上。 嵌入式linux驱动程序的基本结构和标准Linux的结构基本一致，也支持模块化模式，所以，大部分驱动程序编成模块化形式，而且，要求可以在不同的体系结构上安装。linux是可以支持模块化模式的，但由于嵌入式应用是针对具体的应用，所以，一般不采用该模式，而是把驱动程序直接编译进内核之中。但是这种模式是调试驱动模块的极佳方法。 系统调用是操作系统内核和应用程序之间的接口，设备驱动程序是操作系统内核和机器硬件之间的接口。设备驱动程序为应用程序屏蔽了硬件的细节,这样在应用程序看来,硬件设备只是一个设备文件,应用程序可以像操作普通文件一样对硬件设备进行操作。同时,设备驱动程序是内核的一部分,它完成以下的功能:对设备初始化和释放;把数据从内核传送到硬件和从硬件读取数据;读取应用程序传送给设备文件的数据和回送应用程序请求的数据;检测和处理设备出现的错误。在linux操作系统下有字符设备和块设备，网络设备三类主要的设备文件类型。 字符设备和块设备的主要区别是:在对字符设备发出读写请求时,实际的硬件I/O一般就紧接着发生了;块设备利用一块系统内存作为缓冲区,当用户进程对设备请求满足用户要求时,就返回请求的数据。块设备是主要针对磁盘等慢速设备设计的,以免耗费过多的CPU时间来等待。 1 字符设备驱动结构 Linux字符设备驱动的关键数据结构是cdev和file_operations结构体。
参考： 韦东山视频第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消息在完成后就会调用指定的完成例程，这时就可以在完成例程中读出键盘动作的内容，或者修改这些信息，以实现按键的映射。
浅析测试驱动开发 测试驱动开发是一种用于敏捷软件开发的开发过程，可以快速应对需求变化。它要求先设计和编写测试代码，然后编写功能代码通过所有测试，再重构以提高代码质量。文章将先介绍测试驱动开发的优点、使用环境，然后介绍开发过程，最后介绍相关工具。 标签：测试；TDD；敏捷开发 1 概述 1.1 定义 测试驱动开发（Test Driven Development，TDD）是由极限编程之父Kent Beck提出的一种面向对象的开发方法[1]。区别于传统的软件开发模式，测试先行将更重视测试在整个软件开发过程中的作用并促进项目的进行。它要求先完成测试代码，然后编写功能代码，并且功能代码要以通过测试代码为标准，然后对功能代码重构，重构之后再运行测试并要通过测试[2]。它的一个开发周期比较短，整个项目是多个周期的迭代。这种开发方式有效的提高了软件质量和开发效率[3]。目前，TDD已经被很多公司和开发团队接受并用于实践。 1.2 优点 由于测试先行，因此写代码前就应该有明确的需求，并体现在测试用例中。在交付前，测试用例可以用来描述功能需求并替代部分文档。并且以测试用例描述的需求不容易出现模糊不清的概念，因为测试结果只会是True或False。这解决了开发人员在开发时误解或由于沟通问题不完全理解需求文档而造成开发到一定程度后才发现代码与需求有偏差。但这还没有解决对客户的误解或与客户沟通不畅导致需求分析错误的问题。 功能代码编写完成后必须通过所有测试，这就保证了这部分代码是满足其功能要求的。通过确保每小部分代码的质量，可以较快的叠加成更复杂的功能且保证最后交付的软件与设计的要求是一致的。在对功能代码进行优化时，因为也要通过测试用例，所以能保证这部分代码的改动不会对调用它的其他模块有影响。 1.3 适用环境 尽管从理论上讲TDD可以在各种软件开发项目中使用，但是在某些项目上可能感觉不到比较明显的效率提升或质量提高。 TDD是面向对象的开发方式，如果项目不使用面向对象的设计和开发，则不适合使用TDD。
Jbehave 学习 JBehave行为驱动开发（BDD）是一个框架。 BDD是测试驱动开发（TDD）和验收测试驱动开发（ATDD）的一种演进，目的是使新手和专家开发实践起来更加方便和直观。它改变了从被测试为基础到以行为为基础的词汇，将自己定位为一个设计理念。 一、BDD课题研究之测试思想和方法总结 此次研究的课题是BDD，主要涉及两个方面：测试的思想和方法、技术框架。这里做测试思想和方法的总结。 BDD是什么 全称： Behaviour Driven Development（行为驱动开发）。 BDD改变了我们对软件测试的认识。先前我对测试的认识是：从大的角度来讲，软件测试就是对一个软件系统从功能上进行确认测试和验证测试，从性能上进行压力测试和负载测试，以及对系统的配置测试和兼容性测试等，从类别上又有单元测试，集成测试，回归测试，所有的这些测试工作都有一个目的：交付一套高质量的软件系统。我们软件测试人员的工作就是：尽可能早的找出软件缺陷，并确保其得以修复。顺理成章的，在我们的思维中是：我们先拿到系统的既成品，然后开展测试工作，而BDD恰好颠覆了我们的思维。 回到BDD正题，BDD中有两个大的概念：测试先行和系统设计。 测试先行：BDD提倡我们在开发者的编码工作开展之前，先写测试用例，然后由测试来推动着开发的工作，具体解释为：在设计如何实现一个功能前，先考虑如何测试这个功能，测试的代码完成后，再编写功能实现代码，并且使得该测试用例通过，即完成了系统的一个功能模块。 系统设计：在系统功能实现代码编写之前，我们需要先编写测试代码，在我们的测试代码中实现对系统行为的描述，这个描述其实就是用一种接近自然语言的方式对系统进行详细的设计，并且使项目相关人员，即使是非技术人员也能很容易看懂。关于系统行为，举例说明：用户在一个特定的条件下对系统做请求，系统在该条件下做什么样的处理，这就是系统的一个行为。 总结一下BDD的概念：在项目之初，由客户、开发人员、测试人员一起通过充分的沟通对系统的行为进行设计，由测试人员以接近自然语言的方式编写可以描述系统行为的测试用例，然后由开发人员编写相关的实现代码，并确保该测试用例通过。循环这个过程实现整个系统的功能。
本人此刻还不是什么驱动工程师，连入门都谈不上，但我坚信在未来的3-5年我肯定能成为我想像中的人，因为我马上就要进入这一行工作了。写下这个日志来记录我是怎么最后成为我想像中的人才的，呵呵。 《Linux驱动工程师》这个东西是我在大二的时候看到有一篇讲如何学习嵌入式的，点击这里下载PDF，里面讲到嵌入式分为四层：硬件，驱动，系统，应用程序;还说linux驱动最难然后工资也最高就冲着他这句话我就决定我大学毕业的时候要去做这个linux驱动工程师，随后我就先后买了51单片机，ARM7,ARM9还有一大堆的视频教程准备来进行学习。我还跟我旁边那个哈工大哥们说：“我们学校像我这样的人很少，你们学校呢？”他说：“太少了，不过我们学校都是做这种板子卖的人比较多！”。行，你们牛！即使是买了这些东西，从大二到现在都快毕业了但感觉还是没有入门。回想一下我都学过什么啊：1：自己在ARM9上写bootloader(主要锻炼了三方面的知识：C语言应该写了有近万行的代码，ARM9的外设的基本操作方法如UART,LCD,TOUCH,SD,USB,ETHERNET...，makefile);2:移植和学习linux驱动。下面我说一下我学习Linux驱动的一个思路这也是我在面试的时候自我介绍中最重要的部分；1：硬件知识学习Linux驱动首先得了解这个驱动对应的硬件的一些基本原理和操作方法比如LCD你得了解它的场同步，行同步，像素时钟，一个像素的表示模式，还有就是这个LCD是怎么把图像显示在屏幕上的。如果是USB,SD卡就得了解相关协议。可以通过spec（协议）、datasheet来了解，这就是传说中的Linux驱动开发三件宝之二，还有一个就是linux相关源码。2：了解linux驱动框架linux下的每一类驱动差不多都是一个比较完善的子系统，比如FLASH的驱动它就属于MTD子系统从上到下分为四层：设备节点层，设备层，原始设备层，最下面的与具体硬件相关的硬件驱动层，通常要我们自己来实现就是最下面这个与具体硬件相关那部分代码。3：了解这个驱动的数据流。这个过程与第二个过程紧密相关，如果了解了驱动的框架差不多这个过程也算了解了。比如flash.在/dev/目录下有对应flash的字符设备文件和块设备文件，用户对这些文件进行读、写、ioctl操作，其间通过层层的函数调用最终将调用到最下面的硬件驱动层对硬件进行操作。了解这个过程我相信在调试驱动的时候是很有帮助。3：分析与硬件相关通常需要我们实现的那部分源代码。4：三板子上将驱动调试出来。每次调试都会出问题，但我买的板子提供的资料比较全调试过程中遇到的问题都比较浅显，即使是浅显的问题也要把它记录下来。(这个是我上次在华为面试的时候，那个人问我你调试驱动遇到过什么问题吗？你是如何解决的。当时我学习还没有到调试驱动这一步，所以那次面试也惨败收场)。 好像说了这么多，还没有进入正题《工作的选择》。在年前去了龙芯，实习2.8K，转正3.5k，环境还是不错，经理很好，头儿也很帅都是中科院的硕士。不过去了两周我就没去了身边的人都不太理解，我也一度有过后悔的时候，从龙芯出来应该是1月6号，也就是从那个时候开始我就没有再找工作，转而学习linux驱动。一直到上周日。上周日的晚上我就开始投简历一开始要找linux驱动，在智联里面输入linux驱动出来500来个职位，点开一看没有一个自己符合要求的，差不多都要3-5年经验本科，有时候好不容易有个实习的关键字在里面，一看要求硕士，严重打击了我的信心，哎不管了随便投，最后又投了一下嵌入式关键字的职位。最后就瞎申请，看看职位要求差不多就申请。周一来了，这周一共来了6个面试，创下了我求职以来的历史新高。周一下午面了一家感觉还不错不过到现在也没有给我一个通知，估计当时我要了4500把他给要跑了，这家是做测量的不是Linux驱动，差不多是把ARM当单片机用。周二上午一家也是要招linux驱动面了估计不到二分钟，他
行为驱动开发 行为驱动开发（简称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的基本思想是通过测试来推动整个开发的进行，但是测试驭动开发不是单纯的测试工作，而是把需求分析、设计、质量控制量化的过程。
Intro: 简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。敏捷开发是由一些业界专家针对一些企业现状提出了一些让软件开发团队具有快速工作、响应变化能力的价值观和原则，并于2001初成立了敏捷联盟。他们 正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。 敏捷开发(agile development)概念从2004年初开始广为流行。Bailar非常支持这一理论，他采取了"敏捷方式"组建团队：Capital One的"敏捷团队" 包括3名业务人员、两名操作人员和5?7名IT人员，其中包括1个业务信息指导(实际上是业务部门和IT部门之间的"翻译者");另夕卜，还有一个由项目经理和至少80名开发人员组成的团队。这些开发人员都曾被Bailar送去参加过" 敏捷开发"的培训，具备相关的技能。 每个团队都有自己的敏捷指导(Bailar聘用了20个敏捷指导)，他的工作是关注流程并提供建议和支持。最初提出的需求被归纳成一个目标、一堆记 录详细需要的卡片及一些供参考的原型和模板。在整个项目阶段，团队人员密切合作，开发有规律地停顿--在9周开发过程中停顿3?4次，以评估过程及决定需求变更是否必要。在Capital One大的IT项目会被拆分成多个子项目，安排给各"敏捷团队"，这种方式在"敏捷开发"中叫"蜂巢式(swarming)"，所有过程由一名项目经理控制。 为了检验这个系统的效果，Bailar将项目拆分，从旧的"瀑布式"开发转变为"并列式"开发，形成了"敏捷开发"所倡导的精干而灵活的开发团队，并将开发阶段分成30天一个周期，进行"冲刺"--每个冲刺始于一个启动会议，到下个冲刺前结束。 在Bailar将其与传统的开发方式做了对比后，他感到非常兴奋--"敏捷开发"使开发时间减少了30%-40%有时甚至接近50%提高了交付产品的质量"不过，有些需求不能用敏捷开发来处理。"Bailar承认，"敏捷开发"也有局限性，比如对那些不明确、优先权不清楚的需求或处于"较快、较便宜、较优" 的三角架构中却不能排列出三者优先级的需 求。此外，他觉得大型项目或有特 殊规则的需求的项目，更适宜采用传统的开发方式。尽管描述需求一直是件困难的事，但经过阵痛之后，需求处理流程会让CIO受益匪浅。 敏捷开发是由一些业界专家针对一些企业现状提出了一些让软件开发团队具有快速工作、响应变化能力的价值观和原则，并于2001初成立了敏捷联盟 他们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。通过这项工作，他们认为： 个体和交互胜过过程和工具 ?可以工作的软件胜过面面俱到的文档 客户合作胜过合同谈判
练习题 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
第17章USB设备驱动 USB设备驱动和PCI设备驱动是PC中最主要的两种设备驱动程序。与PCI协议相比，USB协议更复杂，涉及面较多。本章将介绍USB设备驱动开发。首先介绍USB协议，使读者对USB协议有个整体认识。然后介绍USB设备在WDM中的开发框架。由于操作系统的USB总线驱动程序提供了丰富的功能调用，因此开发USB驱动开发变得相对简单，只需要调用USB总线驱动接口。 17.1 USB总线协议 USB总线协议比PCI协议复杂的多，涉及USB物理层协议，又涉及USB传输层协议等。对于USB驱动程序开发者来说，不需要对USB协议的每个细节都很清楚。本节概要地介绍USB总线协议，并对驱动开发者需要了解的地方进行详细介绍。 17.1.1 USB设备简介 USB即通用串行总线（Universal Serial Bus），是一种支持即插即用的新型串行接口。也有人称之为“菊链（daisy－chaining）”，是因为在一条“线缆”上有链接127 个设备的能力。USB要比标准串行口快得多，其数据传输率可达每秒4Mb~12Mb（而老式的串行口最多是每秒115Kb）。除了具有较高的传输率外，它还能给外围设备提供支持。 需要注意的是，这不是一种新的总线标准，而是计算机系统连接外围设备（如键盘、鼠标、打印机等）的输入/输出接口标准。到现在为止，计算机系统连接外围设备的接口还没有统一的标准，例如，键盘的插口是圆的、连接打印机要用9针或25针的并行接口、鼠标则要用9针或25针的串行接口。USB能把这些不同的接口统一起来，仅用一个4针插头作为标准插头，如图17-1所示。通过这个标准插头，采用菊花链形式可以把所有的外设连接起来，并且不会损失带宽。USB正在取代当前PC上的串口和并口。