精华内容
下载资源
问答
  • 前面我们学习I2C、USB、SD驱动时,有没有发现一个共性,就是在驱动开发时,每个驱动都分层三部分,由上到下分别是: 1、XXX 设备驱动 2、XXX 核心层 3、XXX 主机控制器驱动  而需要我们编写的主要是设备驱动...

          前面我们学习I2C、USB、SD驱动时,有没有发现一个共性,就是在驱动开发时,每个驱动都分层三部分,由上到下分别是:

    1、XXX 设备驱动

    2、XXX 核心层

    3、XXX 主机控制器驱动

          而需要我们编写的主要是设备驱动部分,主机控制器驱动部分也有少量编写,二者进行交互主要时由核心层提供的接口来实现;这样结构清晰,大大地有利于我们的驱动开发,这其中就是利用了Linux设备驱动开发中两个重要思想,下面来一一解析


    一、设备驱动的分层思想

           在面向对象的程序设计中,可以为某一类相似的事物定义一个基类,而具体的事物可以继承这个基类中的函数。如果对于继承的这个事物而言,其某函数的实现与基类一致,那它就可以直接继承基类的函数;相反,它可以重载之。这种面向对象的设计思想极大地提高了代码的可重用能力,是对现实世界事物间关系的一种良好呈现。

          Linux内核完全由C语言和汇编语言写成,但是却频繁用到了面向对象的设计思想。在设备驱动方面,往往为同类的设备设计了一个框架,而框架中的核心层则实现了该设备通用的一些功能。同样的,如果具体的设备不想使用核心层的函数,它可以重载之。举个例子:

    return_type core_funca(xxx_device * bottom_dev, param1_type param1, param1_type param2)
    {
    	if (bottom_dev->funca)
    	return bottom_dev->funca(param1, param2);
    	/* 核心层通用的funca代码 */
    	...
    }

         上述core_funca的实现中,会检查底层设备是否重载了funca(),如果重载了,就调用底层的代码,否则,直接使用通用层的。这样做的好处是,核心层的代码可以处理绝大多数该类设备的funca()对应的功能,只有少数特殊设备需要重新实现funca()

    再看一个例子:

    return_type core_funca(xxx_device * bottom_dev, param1_type param1, param1_type param2)
    {
    	/*通用的步骤代码A */
    	...
    	bottom_dev->funca_ops1();
    	/*通用的步骤代码B */
    	...
    	bottom_dev->funca_ops2();
    	/*通用的步骤代码C */
    	...
    	bottom_dev->funca_ops3();
    }

        上述代码假定为了实现funca(),对于同类设备而言,操作流程一致,都要经过“通用代码A、底层ops1、通用代码B、底层ops2、通用代码C、底层ops3”这几步,分层设计明显带来的好处是,对于通用代码A、B、C,具体的底层驱动不需要再实现,而仅仅只关心其底层的操作ops1、ops2、ops3。图1明确反映了设备驱动的核心层与具体设备驱动的关系,实际上,这种分层可能只有2层(图1的a),也可能是多层的(图1的b)。


           这样的分层化设计在Linux的input、RTC、MTD、I2 C、SPI、TTY、USB等诸多设备驱动类型中屡见不鲜。


    二、主机驱动和外设驱动分离思想

    主机、外设驱动分离的意义

           在Linux设备驱动框架的设计中,除了有分层设计实现以外,还有分隔的思想。举一个简单的例子,假设我们要通过SPI总线访问某外设,在这个访问过程中,要通过操作CPU XXX上的SPI控制器的寄存器来达到访问SPI外设YYY的目的,最简单的方法是:

    return_type xxx_write_spi_yyy(...)
    {
    	xxx_write_spi_host_ctrl_reg(ctrl);
    	xxx_ write_spi_host_data_reg(buf);
    	while(!(xxx_spi_host_status_reg()&SPI_DATA_TRANSFER_DONE));
    	...
    }

         如果按照这种方式来设计驱动,结果是对于任何一个SPI外设来讲,它的驱动代码都是CPU相关的。也就是说,当然用在CPU XXX上的时候,它访问XXX的SPI主机控制寄存器,当用在XXX1的时候,它访问XXX1的SPI主机控制寄存器:

    return_type xxx1_write_spi_yyy(...)
    {
    	xxx1_write_spi_host_ctrl_reg(ctrl);
    	xxx1_ write_spi_host_data_reg(buf);
    	while(!(xxx1_spi_host_status_reg()&SPI_DATA_TRANSFER_DONE));
    	...
    }
          这显然是不能接受的,因为这意味着外设YYY用在不同的CPU XXX和XXX1上的时候需要不同的驱动。那么,我们可以用如图的思想对主机控制器驱动和外设驱动进行分离。这样的结构是,外设a、b、c的驱动与主机控制器A、B、C的驱动不相关,主机控制器驱动不关心外设,而外设驱动也不关心主机,外设只是访问核心层的通用的API进行数据传输,主机和外设之间可以进行任意的组合


          如果我们不进行上图的主机和外设分离,外设a、b、c和主机A、B、C进行组合的时候,需要9个不同的驱动。设想一共有m个主机控制器,n个外设,分离的结果是需要m+n个驱动,不分离则需要m*n个驱动。

          Linux SPI、I2C、USB、ASoC(ALSA SoC)等子系统都典型地利用了这种分离的设计思想。


    展开全文
  • 谈谈对测试驱动开发思想的体会

    千次阅读 2017-11-11 13:44:05
    最近学习了一本书《Python Web开发:测试驱动方法》,贯穿全书的便是测试驱动开发的编程思想。有点儿兵马未动,粮草先行的兵家思想。先简单总结一下这本书带给我的收获:1.学习了测试驱动开发的一种编程思想,与传统...

    最近学习了一本书《Python Web开发:测试驱动方法》,贯穿全书的便是测试驱动开发的编程思想。有点儿兵马未动,粮草先行的兵家思想。先简单总结一下这本书带给我的收获:1.学习了测试驱动开发的一种编程思想,与传统的瀑布开发流程又很大的出入。2.学习了如何写好功能测试,如何写好单元测试。3.先通过测试,再谈重构。

    好,下面简单聊聊我对这种编程思想的体会。

    何为测试驱动开发

    维基百科中队测试驱动开发又一个比较正式的介绍:测试驱动开发(英语:Test-driven development,缩写为TDD)是一种软件开发过程中的应用方法,由极限编程中倡导,以其倡导先写测试程序,然后编码实现其功能得名。测试驱动开发始于20世纪90年代。测试驱动开发的目的是取得快速反馈并使用“illustrate the main line”方法来构建程序。

    测试驱动开发是戴两顶帽子思考的开发方式:先戴上实现功能的帽子,在测试的辅助下,快速实现其功能;再戴上重构的帽子,在测试的保护下,通过去除冗余的代码,提高代码质量。测试驱动着整个开发过程:首先,驱动代码的设计和功能的实现;其后,驱动代码的再设计和重构。

    按照我个人的理解:将业务需求转化为功能测试及单元测试,业务代码则为了通过测试而不断的迭代。

    测试驱动开发利弊权衡(由于未实战过tdd,看法可能略显稚嫩)

    • 通过测试驱动开发,能保证业务代码能满足需求,不断的重构,能保证系统功能的正常运行。但是对于代码质量的把控,貌似很难做到。
    • 测试驱动开发思想其实并不难理解,流程无非也是在测试开发重构过程中不断流转,但是个人感觉在工程实践上其实难度挺大
    • 就个人工作经验来看,目前多数企业对于项目代码质量把控很差,项目周期紧,领导总是抱着先上线,遇到bug再解决,故TDD的开发模式在很多公司,尤其是创业公司中很难推广开,由于前期测试覆盖度不够,开发急促,导致后期上线维护异常困难
    • TDD的开发模式也应该分业务场景而看,但具体是哪些场景合适目前没有资格谈

    TDD这种方式,还是得实践。然而以目前公司的平台,基本属于不可能。不过,就算不能在公司实践TDD的开发模式,它其中最重要的核心部分–测试,会让我在今后的开发过程中更加重视这部分。

    展开全文
  • 敏捷中出现各种”XX驱动开发“的实践。起源主要是来自Kent在极限编程中提出的测试优先编程(Test-First Programming)。现在出现了(除了行为驱动开发以为,相关的还有像实例驱动开发(EDD-Example Driven ...

    敏捷中出现各种”XX驱动开发“的实践。起源主要是来自Kent在极限编程中提出的测试优先编程(Test-First Programming)。现在出现了(除了行为驱动开发以为,相关的还有像实例驱动开发(EDD-Example Driven Development),特性驱动开发(FDD-Feature Driven Development)等。

    各种驱动开发之间的关系众说纷纭这里我们来聊一聊测试驱动开发(TDD)、验收测试驱动开发(ATDD)和行为驱动开发(BDD)。

    测试驱动开发

    Kent Beck最早在其极限编程(XP)方法论中,向大家推荐“测试驱动”这一最佳实践,还专门撰写了《测试驱动开发》一书,详细说明如何实现。

    测试驱动开发(TDD)使用自动化测试用例来指导开发代码。TDD 过程包含下列活动:

    • 新增一个测试(成生测试用例并自动化),用于描述在代码内的某一小片段所期望的功能(程序设计的思路);
    • 此时因为相应的业务代码还没有编写,测试无法通过;
    • 编写业务代码并运行测试直到测试通过;
    • 在测试通过后,如果代码又有变更,例如对业务代码进行重构,则需再次运行测试以确保变更后的代码仍然可以通过测试;
    • 对代码内的下一小片段继续执行上述过程,需要运行之前的测试(回归测试)以及新加入的测试。

    行为驱动开发和测试驱动开发介绍: https://www.itsource.cn/web/news/1933.html

    虽然“测试驱动开发”里面有测试的字眼,但是这个其实还是个开发活动,通常都不是由测试人员负责的,即使其中的驱动开发的测试的代码也不是测试人员编写的,至于里面涉及到的代码的重构这些内容,就更是开发人员而不是测试人员编写的。

    狭义的测试驱动开发一般指的就是单元测试级别的测试驱动开发。但是广义的测试驱动开发不仅仅可以用于单元测试级别,还可以用于集成测试或者系统测试级别。当然也可以用于验收测试级别,此时就是后面要讲的验收测试驱动开发。

    敏捷中很多思想都是建立在个人或者团队能力成熟度很高的基础上的。很多团队在实施测试驱动开发的时候无法顺利的进行下去,有很大一方面是实施的团队的技能还没有跟上。你很难想象一个开发团队,在单元测试都无法高质量的完成的情况下,转型采用TDD能够成功。

    验收测试驱动开发

    验收测试驱动开发(ATDD),在用户故事的创建阶段就定义验收准则及其相关的测试。ATDD 强调协作,各个利益相关者(开发、测试、业务代表等)不仅要理解软件组件应该有何种行为,还要理解如何做才能确保可以通过验收。

    验收测试驱动开发是一种测试优先的方法。

    首先需要再实施用户故事之前创建测试用例。测试用例由包括开发人员、测试人员和业务代表在内的敏捷团队创建,可以是手工测试用例也可以是自动化测试用例。第一步是开展一个由开发人员、测试人员和业务代表一起参与分析、讨论和撰写的规格说明研讨会。任何在用户故事中不完整、不清楚或者错误的地方都会在这个过程中得到修复。

    下一步是创建测试。这一活动可以由团队一起完成或者由测试人员单独完成。在任何情况下,测试都应该由一个独立的个人(如业务代表)来确认。这里的测试是描述用户故事中特性的例子。这些例子会帮助团队正确地实施用户故事。由于例子和测试是相同的,二者经常可以互换使用。这项工作从基本的例子和开放的问题开始。

    一般而言第一次测试都是正向测试,在没有意外或错误条件下确认正确的行为,比较执行的活动的顺序,判断是否如期望的那样进行。在正向路径测试完成后,团队应该撰写逆向测试并且覆盖非功能属性(如性能,易用性)。测试须以利益相关者都能理解的方式表述,包含以自然语言表达的语句,这些语句应该包括必要的前提条件以及任何可能的输入和相关输出。

    例子必须覆盖所有用户故事的特性,并且不应该添加新内容到用户故事中。这意味,不应存在那些描述没有被写在用户故事中的例子。另外,不应该有两个例子描述用户故事中的相同特性。

    行为驱动开发

    行为驱动开发(BDD)使开发人员聚焦于测试软件行为是否符合预期。由于测试是以软件行为的形式展示出来的,测试对于团队成员和其他利益相关者来说更容易。单从BDD的概念来说,它不仅仅是针对测试,它使得在业务团队和开发之间达成共识。在软件项目中涉及多人紧密协作,由产品业务讲解功能需求,开发负责代码实现,测试保证软件质量,高质量的沟通对项目成功至关重要。如果在一个项目中业务人员用自己行话,开发人员用技术语言、技术思维去理解业务,在沟通过程难免出现分歧,开发人员就可能按自己的理解去实现了一个错误的功能。

    BDD用通用自然语言描述实例(系统行为)。团队成员使用统一、易读的语言明确实例,作为验收测试标准。一方面可以消除理解上的歧义,一方面可以激发思考没有考虑到的场景。这里的实例是可以随时运行,反馈系统运行真实结果,如果运行失败,要么文档过时需要更新,要么系统出现问题需要修复。

    在讨论BDD和TDD、ATDD的关系时,有些地方把BDD看成一个新的完整的开发流程,也有些地方把BDD看成是TDD的延伸,ATDD的一种落地的实例。这只是从不同的角度来看待BDD,并不影响BDD的本质。

    典型的 BDD 框架将验收准则用 given/when/then 的格式表示:

    Given(给定)某些初始上下文,

    When(当)一个事件发生,

    Then(则)确保某些输出。

     

     

    行为驱动开发,让开发做正确的事: https://yq.aliyun.com/articles/594347
    行为驱动开发(BDD) - 一个快速的描述和示例: https://www.cnblogs.com/Javi/p/7158573.html
    五分钟让你彻底了解TDD、ATDD、BDD&RBE:https://mp.weixin.qq.com/s/KCrkL4NeuZeZvTu5Sc6B_g

    小结

    TDD、ATDD和BDD通过在开发之前清晰的描述系统行为和开发详细的测试用例来帮助开发人员更好的开发出高质量的代码。 测试从以前的破坏性的方法转换到建设性的方法中来。 给整个开发带来的新的思想上的变化。但是这些新的思想在实践过程中的具体能够带来多大的好处,也受到使用的组织和人的各方面条件的限制。没有一劳永逸的技术,只有持续不断的改进。这才是敏捷思想的内涵。

    展开全文
  • 测试驱动开发基本思想是,开发人员先编写测试用例,再编写能通过用例的代码。就像砌砖师傅先用桩子拉上线再砌墙一样。 思想: • Test Driven Development测试驱动开发 • Acceptance TestDriven Development...

    测试驱动开发

    测试驱动开发基本思想是,开发人员先编写测试用例,再编写能通过用例的代码。就像砌砖师傅先用桩子拉上线再砌墙一样。

    思想:

    •       Test Driven Development测试驱动开发

    •       Acceptance TestDriven Development验收测试驱动开发

    •       测试驱动设计,测试也是一项设计活动,编写用例的同时已在思考设计

    •       持续集成,用例必须能自动化,且集成到CI环境中

    优点:

    •       提高代码行测试覆盖率

    •       100%通过率,处理不通过的问题是优先级最高任务

    •       快速变更的能力,变更后快速通过持续集成自动化测试

    •       有信心重构,重构后的代码能快速测试

    •       减少技术债,减少BUG泄露

    敏捷转型过程中,测试驱动开发通常是最重要也最艰难的一个,只有实现快速自动化测试,才可能快速交付。前景非常诱人,但是在这个过程中我们的付出可能也是最多的。

    按照敏捷思想,大部分的测试工作应该是开发来完成的,测试人员重点是保证开发测试的正确性,比如:测试方案、测试计划等。测试驱动开发的推广过程中,首要的问题是将开发人员长期以来形成的思维观念和意识形态转变过来,大部分开发人员只喜欢编码,不喜欢测试,更无法理解为什么没有产品代码的时候就先写单元测试;其次是相关的技术支持,测试驱动开发对开发人员提出了更高的要求,不仅要掌握测试和重构,还要懂得设计模式等设计方面的知识。

    那么测试驱动开发跟持续集成如何关联到一起哪?简单总结一下:

    •     Add atest

    •     Addcode to pass the test

    •     Passall existing tests

    •     Cleanup the code

    •     Checkin

    •     ContinuousIntegration                        =

    (   Auto Compile                                      +

    Auto Build                                            +

    Auto Deploy                                         +

    Auto fullregression testing                 +    

    Check in codefrequently                      )

     

     

    展开全文
  • 我们刚刚实现了完全用测试驱动开发(注:Test Driven Development,下文简称“TDD”)方法制作完成首款游戏。我将在下文中分享我的经验,现在我们已经彻底完成了项目的首个版本。我之前讨论过测试驱动游戏开发方法(注...
  • 神话的破灭但是随着软件规模的扩大和软件复杂度的提高,无序的开发过程开始显示出它的弱点,首先,开发质量没有保证。软件错误随着软件复杂度的增加而增加。几次恶性的软件错误导致的巨大损失导致软件危机的出现,...
  • 测试驱动开发

    千次阅读 2018-11-24 14:14:00
    测试驱动开发 概述 极限编程是一个轻量级的、灵巧的软件开发方法,同时它也是一个非常严 谨和周密的方法,它从 4 个基本方面对软件项目进行改善:交流、简易、反馈 和勇气。测试驱动开发则是极限编程的最佳...
  • C语言虽然是面向过程的语言,但是在linux的内核中到处都可以看到其采用面向对象的思想,最典型的就是文件系统,llinux把各种文件系统都可以转换成一种标准的文件系统,提供统一的接口给用户。  另一个例子就是...
  • 当然,这次驱动开发过程中不仅在技术上有所收获,更重要的收获是,懂得了在驱动开发中遇到问题后怎样有效的处理。下面将从开发流程、配置SPI控制器相关须知、用户空间SPI驱动、Linux设备模型与platform总线(虚拟...
  • 测试驱动开发与极限编程思想浅析

    千次阅读 2005-12-14 10:43:00
    随着全球经济的发展与计算机技术的普及,各行业...传统的软件工程方法已经遭到人们的质疑,很多改进的软件开发方法便应运而生。极限编程(eXtreme Programming, XP)便是在这样一种环境下出现的新型的适用于中小型系统
  • 测试是如何驱动开发过程

    千次阅读 2005-02-21 13:38:00
    测试是如何驱动开发过程的测试驱动开发起源于XP法中提倡的测试优先实践。测试优先实践重视单元测试,强调程序员除了编写代码,还应该编写单元测试代码。在开发的顺序上,它改变了以往先编写代码,再编写测试的过程...
  • 如何学习linux驱动开发

    千次阅读 2014-11-30 12:23:00
    linux设备驱动开发,看起来是一份很高大上的职业,毕竟从事上层应用开发人员太多,而且门槛又不是特别高,而内核级开发从业人员要少得多,而且资料又较少。有许多刚刚接触到linux设备驱动开发的同仁会感觉非常困惑,...
  • 敏捷开发思想

    千次阅读 2019-04-12 22:52:55
    敏捷开发的模式分类(摘抄至互联网):SCRUM 的工作流程(摘抄至互联网)流程: SCRUM 是什么? Scrum是敏捷开发中的名词。 敏捷开发是什么? 敏捷开发(Agile Development) 是一种以人为核心、迭代、循序渐进的开发方法...
  • 本博实时更新《Linux设备驱动开发详解(第3版)》(即《Linux设备驱动开发详解:基于最新的Linux 4.0内核》)的最新进展。 目前已经完成稿件。 2015年8月9日,china-pub开始上线预售: ... 2015年8月20日,各路朋友报喜...
  • 基于树莓派驱动开发详解

    千次阅读 2020-08-09 20:15:49
    1、驱动开发思想 要想进行驱动开发首先我们应该知道,上层到底层是如何进行的,上层调用c库的open函数,首先会发生一次软中断,从用户空间进入内核空间,触发系统调用接口函数sys_call,然后通过open函数的设备名...
  • Python测试驱动开发(TDD)

    千次阅读 2018-07-27 10:27:31
    Python测试驱动开发(TDD) 前言:TDD是一种敏捷开发模式,而不是测试方法。 目录 Python测试驱动开发(TDD) 目录 单元测试与功能测试的区别 “单元测试/编写代码“循环 遵守不测试常量规则 有用的TDD概念 ...
  • 【学习笔记】C#测试驱动开发

    千次阅读 2014-05-06 16:28:52
    个人与互动 重于 流程与工具可用的软件 重于 详尽的文件与客户合作 重于 合约协商响应变化 重于 遵循计划 敏捷注重交流沟通,应对变化。 著名的敏捷开发方法: Scrum极限编程(XP)功能驱动开发Clear...
  • 《Linux设备驱动开发详解:基于最新的Linux 4.0内核》
  • 最近兴起的一些软件开发过程相关的技术,提供一些比较高效、实用的软件过程开发方法。其中比较基础、关键的一个技术就是测试驱动开发(Test-Driven Development)。虽然TDD光大于极限编程,但测试驱
  • 敏捷开发 —— TDD(测试驱动开发

    千次阅读 2017-07-18 22:58:30
    测试驱动开发 TDD(Test-Driven Development)是敏捷开发的一项核心实践,同时也是一种设计技术和方法。1. 基本思想在开发功能代码之前,先编写单元测试用例代码,测试代码确定需要编写什么产品代码。TDD虽是敏捷...
  • 感悟测试驱动开发

    千次阅读 2014-04-08 21:30:15
     软件开发方法学的泰斗Kent Beck先生最为推崇"模式、极限编程和测试驱动开发"。在他所创造的极限编程(XP)方法论中,就向大家推荐"测试先行"这一最佳实践,并且还专门撰写了《测试驱动开发》一书,详细说明如何...
  • 测试驱动开发学习

    千次阅读 2012-11-27 18:00:21
    测试驱动开发,英文全称Test-Driven Development,简称TDD,是一种不同于传统软件开发流程的新型的开发方法。它要求在编写某个功能的代码之前先编写测试代码,然后只编写使测试通过的功能代码,通过测试来推动整个...
  • 这几天学习了一下测试驱动开发(tdd) 实用指南,感觉相见恨晚,... Test-Driven Development A Practical Guide 测试驱动开发,实用指南,作者David Astels 测试驱动开发的主要思想是 测试先行,在写一个类的具体
  •  由此,衍生出《Linux设备驱动开发详解》新版的第一个出发点,那就是带给读者更多关于Linux开发背后思想的讲解,奠定根基。《Linux设备驱动开发详解(基于4.0内核)》呈现给读者的,更多的是一种思考,而不是知识点...
  • TDD-测试驱动开发

    2012-11-23 17:19:55
    测试驱动开发,英文全称Test-Driven Development,简称TDD,是一种不同于传统软件开发流程的新型的开发方法。它要求在编写某个功能的代码之前先编写测试代码,然后只编写使测试通过的功能代码,通过测试来推动整个...
  • TDD(测试驱动开发)死了吗?

    千次阅读 2019-06-26 15:04:26
    很早之前,曾在网络上见到过 TDD 这 3 个大写的英文字母,它是 Test Driven Development 这三个单词的缩写,也就是“测试驱动开发”的意思——听起来很不错的一种理念。 其理念主要是确保两件事: 确保所有的需求都...
  • 模型驱动开发新体验

    千次阅读 2019-07-15 09:24:07
    为了解决这些问题,就出现了很多新的方法,其中最突出的一个就是模型驱动开发 MDD (Model Driven Development)。  基于高度业务模型驱动开发MDD,通过使用高度抽象的领域业务模型作为构件,完成代码转换实现或...
  • linux驱动开发1之什么是驱动?

    千次阅读 2018-07-17 21:14:48
    驱动的本质是电力驱动,而驱动代码只是给出了操作方法。 3.linux体系架构 分层思想 驱动的上面是系统调用API 驱动的下面是硬件 驱动自己本身也是分层的 4.linux的模块化设计 4.1微内核和宏内核(也说明了...
  • Windows驱动开发:用C还是C++

    千次阅读 2016-03-28 11:46:45
    在做windows驱动程序开发之前,首先要确定开发的语言...使用C语言,是比较容易上手,因为很多人都是从学习C语言而学习程序开发的,而在驱动开发的时候,用C语言写相对比较简单,不需要考虑太多的限制。 用C++的话,在

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 103,089
精华内容 41,235
关键字:

计划驱动的开发过程的思想的方法