经验交流：测试驱动开发感悟★

第一篇：经验交流：测试驱动开发感悟

最近听到了很多关于软件质量的话题，自己前段时间也参加个PMP(项目管理)的培训，所以一时对于质量控制特别感兴趣，在这里想和大家共同讨论下！

软件质量，是所有人都很关心的东西。我们在开发过程中为了保证质量，从中引进了软件测试。它在整个的过程中起到的作用不言而预，但是它也存在一些问题:

1、在软件测试中要保证软件的高质量就必须增加项目的成本，从而需要增加测试人员，延长项目时间，购买或学习测试工具的成本。

2、因为这种测试是依赖与开发完后才提交给测试人员的，所以如果测试中出现BUG，就会出现BUG打回，再次提交测试...，这中间还需要测试人员和开发人员的沟通，这也是一个成本的增加

3、这种方式会使得开发人员对测试人员产生依赖，从而降低代码的质量，减少自己的测试.....我们为什么不能把测试前移呢！让开发人员自己对软件的业务就做个完整的测试，然后把代码提交给测试人员，这样就可以减少BUG的数量，同时可以让测试人员不只关注与功能性的问题，可以关注更深层次的问题(性能，用户体验...)，这种方式就是做单元测试。其实这个东西很早就有了，每个人都知道它，只是如何做的问题，我相信其实很多公司都做到，有些做的很好，但也有些是失败的！我自己经历过失败，体会过它的麻烦和迷惑，也经历了成功，体会到了它的好处。所以把这些写出来分享下！

软件就是由代码组成的，所以软件的质量就是代码的质量，我们出了BUG就从代码开始入手找问题，然后修改代码。但是当你的软件从小慢慢变大时候，代码越来越多，彼此之间的关联越来越紧密，这样就带来了一个问题“修改一部分代码后会影响多少？”，如果你拿这个问题去问那些项目中没有单元测试的开发人员，他们给出的答案都是通过“拍脑袋”来的，这样绝对会给你的项目带来风险。为了降低风险，项目开始要求开发人员做单元测试，但是做过后得出，这真的可以降低成本吗！花了太多的时间去写测试代码(甚至比开发时间还要多)，对于质量的保证也没有达到预期的效果...，项目做完后，发现做单元测试的和没有做成本多很多，所以接着就放弃了！.....这种现象我想是我们都想做它但又不做它的最大因素。

其实我想大家对它的理解有点误差，我认为他最大的用处不是用来测试代码，而是测试设计！代码从是设计来的，保证了设计的正确性不也保证了代码嘛！软件中的未知风险太多了，其实很多出于设计，对于设计很难去评价好，还是坏，很难找到一个衡量的标准，但是我想TDD，给了我们一个标准，虽然不能去完整的评价，但至少可以是一部分，可以降低它的风险。

这里慢慢开始引入了本文的主题，测试驱动开发(TDD)。我的理解上，单元测试如果不是TDD这种模式，就没有太多的必要去做，因为那样投入做单元测试的成本和收益之间找不到平衡点。

“测试驱动开发”的经历

测试驱动开发简称TTD，全名Test-Driven Developmentd。它是敏捷开发的一个重要组成部分，来源与“极限编程”。我接触它是从一年前的那天(具体时间不记得了~ 呵呵！)开始的.....接触

记得两年前的某天，我正在公司偷偷地看电视剧“奋斗”，这时看到邮箱中的一封邮件: 部门下了一个确定“要求每个项目开发过程中加入单元测试”。当我听到“单元测试”的时候，满头的问号，“它是什么东西，做什么用的....?”（当时还很菜，居然还听过单元测试...!），接着不停的开始找资料，足足花了一个星期才把它了解，然后做了一个简单的DEMO，写些简单的测试代码，把它放到 Nunit上，看着都是通过的提示，兴奋呀！

这时就和项目中的一个“大牛”开始讨论它了，忽然“大牛”的口中蹦出了三个英文单词“TDD”，然后和我讲了一大堆，我根本就不知道他说什么（水平有限，当时理解不了），只是重复着三个字“明白了”。接着他说，项目的这个版本你设计的时候，加入单元测试吧，如果可以的话，也试下TDD.....我是一个喜欢挑战的人，所以一开始就玩先写测试代码，结果呢！大家都明白，菜鸟嘛！一定失败咯，其中的原因是：根本就没有“测试驱动开发”的思想，完全不知道如何开始先写测试代码，而且还没有理解MOCK！下面只有乖乖地和别人一样，等代码写完后再写测试代码。

就在代码写完，开始写测试代码的时候，我们项目组内的人都遇到了相同的问题：

1、系统中程序之间的偶合度太强，业务层，UI，数据层依赖了太多的环境因素，很难分开，所以写测试代码前，还需要去虚拟很多东西

2、花了一天把需要虚拟的东西都做完后，又出现了一个最重要的问题，测试代码太多了，实在写不下去了，一个测试方法(业务比较复杂的)花了半天的时间，这比我写代码时间还多

之后为了完成任务只写了几个简单的测试代码提交。不久，其他项目组也遇到了这些问题，所以公司最后停止了这个过程。我当时听到这个消息的时候，心里有点不好受，因为从那时起我就觉得这是很好的过程，出现的这些问题只因为我们的实力还不够，同时它对于开发人员来说也是一个挑战，一个提高。

可现在停止了，意味着失去了一个很好的锻炼平台。

出于不甘心失败，自己暗暗下决心，一定要提高自己的实力，一定要在设计前就写好测试代码！.....迷茫

在之后的一两个月的时间内是很迷茫的，虽然自己下了决心，却不知道从何开始，盲目地在网上找资料，发现有意义的资料太少，身边虽然有牛人在，但是这个东西是只能意会不能言传的。去公司的图书馆找了些关于敏捷开发和极限编程的书，看完后体会还真是挺深的，加强了对“测试驱动开发”的认识，可自己还是不会.......！

那时的自己连设计模式都不会几个，好象连接口interface都不太会用，至于抽象还是刚刚理解的阶段，对于单元测试，还没有学会MOCK。

不过我的运气还真好，就在这个时候，有个朋友找到我说，有个小项目需要帮忙，问我是否参与呢，由我来负责架构和设计(现在想想，他还真有魄力，敢让我这个菜鸟来架构)，我那时也很闲，而且正想找个实验的项目呢！于是就答应下来了。

项目其实很简单，外贸公司用于发布产品和网上销售的网站。用户数也没有要求，小公司要求可以用就可以了。花了一段时间接触客户，做出了简单的项目计划，基本完成了用户需求，然后就开始做基本架构了，架构还是用经典的三层模式，数据库选的是MYSQL，没有用O/R Mapping....这些第三方的框架。因为出于实践和学习，所以希望都通过自己手写来完成。接下来开始做具体的设计了，花了几天的时间做完了大概的设计，画完了UML图.....，就剩下代码了！

“单元测试”，任然加入了我的开发过程，在这里我总结了一开始失败的原因，加上自己这段时间的学习，知道了要减少程序之间的偶合度，减少依赖。可是真到写的时候，又迷茫了.....成熟

经过了一段时间的迷茫和设计的不断返工，计划的不断延误。终于开始认清了真相，也真的理解了一句话，“质量是设计出来!”，同时明白了“抽象”的必要性，并且还是会使用MOCK了！

哎~，这些收获付出了很多的代价呀！项目的合伙人因为计划不断厌恶，想杀我心都有，每次去用户那里，用户总语气很怪强调“专家”这两个字(我朋友为了接项目，忽悠客户说我是很牛的专家...)，我顶着这些压力，还在不停的重构，不停的写着测试代码。

不过，单元测试的过程并没有很大的改善，主要还是一个复杂的方法里面的业务规则很多，而且代码也多，方法内部依赖的环境因素和依赖对象也很多，当出现这种情况的时候，去写它的测试代码简直是一个十分痛苦的事情，而且这种应付不了以后的变化。这种代码代码本来就多，当需要变化的时候，看代码就需要N久时间，更别说还有心情在去理会测试代码了！我对于这种问题并没有太多的解决办法，只是用时间去填补。

其实经过了这些，我知道自己欠缺什么？！那就是设计，由于设计的不够抽象，对于复杂事物分解的不够简单...，接着跑出去书城，拿着刚发的工资买了N多的关于设计的书籍。把它们抱回家，当看着这些书的时候，看着正在进行的项目，和那一大堆比代码还复杂的测

试代码，觉得值了！

飞跃

“单一职责”

“依赖倒置”

“开放封闭”

“Liskov替换原则”

“迪米特法则”

这些设计的基本原则，大家是否是已经看过了太多次了，但是这些你真的每个都理解了吗？23种设计模式，每种模式都会了吗！会使用吗！你做设计的时候，是否会去思考我应该用何种模式呢？！......这是我花了N久时间才慢慢理解和学会的东西。时间大概过了半年多，我的小项目已经开始运行，看着它正常的运行和VS2005上测试项目中的一排“测试通过”的标志，无限的喜悦。我学会了设计，理解了测试驱动开发，并且写测试代码不在烦恼，而是如此的简单，“设计完后就马上去构思测试代码，如果觉得测试代码复杂，又回来修改设计，直到交互都简单为止”，这成为我现在的一种习惯。学会这些的同时我又拿到了项目Money，真是爽呀！

经历过这些，我的领会是：在做单元测试之前，你必须要学会设计。设计原则和设计模式是你需要要去掌握和理解的，要让自己在做设计的时候，不会去想“我是否应该用哪种模式”，而已灵活运用，根据具体的情况去做，因为你要做到“无剑胜有胜”!

只有简单的东西才容易写，容易测试。代码变的简单，单元测试同样会变的简单。所以其中最关键的就是你如何将复杂的东西简化。虽然谁都知道这个道理，但是要真正做到还是很不容易的。

需要理解，需要实践，需要时间去积累...这是我做单元测试，并学会测试驱动开发的一个过程，现在虽然自己还是一只“小鸟”，但是我可以让代码看上去简单，有了一大堆测试代码的保证，降低了变更的风险。

工作还在继续，还向着新的目标前进......

第二篇：农业项目开发经验交流材料

农业项目开发经验交流材料

一、坚持选项原则，做好项目前期工作

20xx项目区确定后，根据项目区的土地资源条件、水利条件、产业特点等，对项目的开发建设内容、投资估算、资金筹措、综合效益和拟采取的主要措施等进行了分析论证，优化建设方案，编制了可行性研究报告和实施方案，把工作任务、目标进行了详细分解，拟定了严格的技术标准和操作规程，提出了工作保障措施，为开发工作的具体实施做好了充分准备。

二、搞好宣传发动，充分调动各方面的积极性

为全面做好20xx的农业综合开发工作，我们组织人员深入项目村，召开“两委”会和村民代表大会，宣传实施农业综合开发的目的和意义，做到了家喻户晓，人人明白。同时组织有关部门和项目镇、村及企业负责人到兄弟县（区）参观考察，学习先进经验，提高思想认识，调动广大干部群众参与开发的积极性，为全面搞好农业综合开发工作奠定了坚实的基础。

三、严格“六制”管理，确保工程建设质量

在项目实施过程中，我们认真总结经验教训，积极探索新路子，研究新办法，健全各项制度，加强项目管理。成立了项目乡镇镇长挂帅的工程指挥部，做到了组织领导到位，管理措施到位。严格落实了工程项目法人制、工程招投标制、项目工程监理制、项目公示制、建设工程物料政府采购制和建设工程报账提款制。在项目工程建设中，始终把工程建设质量放在首位，一是积极配合工程监理单位对工程进行全方位监理，严格按照国家要求加强监管，使工程质量达到设计标准。二是从项目镇、村聘请有协调能力和有专业技术的人员为监督员，对工程施工过程中的每个细节进行监督。

四、注重项目效益，促进产业开发

我们立足当地金银花生产优势，把农业综合开发项目与建设优势农产品生产基地有机结合起来，积极扶持金银花种植大户，建设金银花精品示范园，开展金银花高产技术培训。积极培育壮大产业规模，提升产品质量，大力发展优质、高产、高效金银花生产，使项目区成为县金银花最集中、最有特色的生产区域。

五、积极扶持果品加工龙头企业，提高农业产业化水平

把产业化经营项目向果品加工这一优势产业倾斜，对等重点企业进行连续扶持，精心打造具有国内外市场竞争力的生产企业和名牌产品。真正起到了围绕产业扶龙头，龙头带基地，基地联农户，扶持一个龙头振兴一方经济，富裕一方农民的作用。

我们将以这次农业综合开发检查验收为契机，学习借鉴兄弟县区的好经验、好做法,进一步加强领导，强化措施，抓好存在问题的整改，对进度慢的施工企业安排专人，专段管理，加快工程建设，确保按时完成。对建设完成的工程，及时验收移交，健全工程管理运行机制，切实把项目工程建设好、管理好、使用好，长期发挥效益。让农业综合开发工程真正成为富民工程、连心工程、奔小康工程。

第三篇：文物开发和利用经验交流材料

××省××市××区是文物大区，文物资源十分丰富，尤其是以*南古民居为代表的地面文物，以其分布广、品位高、特色显而受中外游客的青睐。该区享有“××古建长廊之美誉”，明代古民居数以百计，清代古民居数以千计。其中全国重点文物保护单位4处（罗东舒祠、潜口民宅、老屋阁及绿绕亭、呈坎村古建筑群），省保单位3处，市保单位2处，区保单位4处，另外，还有呈坎村、唐模村两处历史文化保护区。为此，××区文化部门积极做好古建筑维修、保护工作，深入发掘文物景点的文化内涵，大力发展具有地方特色的文物景区旅游和民俗风情旅游，在文物的开发和利用上取得卓有成效的成绩：

古建筑保护成绩喜人。古建筑是徽文化的重要载体,也是开展文化旅游活动的主要场所。该区古建筑门类丰富，数量众多，如古牌坊、古祠堂、古民居、古村落，但经过几百年风雨的侵袭，古村落的风貌已遭明显破坏，正从这个意义上该区把古建筑保护工作当作重中之重之事来抓。建区以来，在区委、区政府和上级文物部门的大力支持下，采取原地保护和易地拆迁集中保护相结合的方法，筹集古民居抢救保护资金1000余万元，抢救维修古建筑50余处，建筑面积近XX0平方米。使该区最有代表性的古民居建筑精品恢复原貌，得以妥善保护。

——在潜口，按照“原拆原建、修旧如旧”的文物保护原则，以易地拆迁集中复原的保护方法，搬迁了13处明代建筑至潜口紫霞山峰，被誉为古民居文物保护的“潜口模式”。1998年，经国家文物局批准继续在潜口民宅观音山建设清园，集中保护十幢清代古建筑。1999年底潜口民宅清代古建筑群搬迁工程动工建设，该工程总投资500万元，占地20余亩。潜口民宅将以山庄的形式再现××跨明、清五百余年的古建筑艺术风采。

——在呈坎，重点维修了国保单位罗东舒祠、长春社，征购维修了“两罗”宅，三层明居燕翼堂，抢修了罗光荣宅，形成具有广泛影响的重点征购，原地维修，成片保护的“呈坎模式”。其中罗东舒祠二期修复工程及长春社修复工程还得到美国安思远等友人的赞助，在海内外产生一定影响。“呈坎古建筑群”于1998年被列为全国重点文物保护单位。

——在西溪南，争取了美国安思远等友人的赞助，维修了国保单位绿绕亭和老屋阁前、中进，复原了老屋阁后进。

——在岩寺，多种渠道筹集资金，修复了岩寺新四军军部址。

做大做强文物旅游文章。建区以来，区文物部门着力做大做强文物旅游文章，依靠以古建筑载体为代表的丰富文物资源，调整文物保护思路，由静态保护拓展到动态保护，加大了文物资源的保护和开发开放力度，使文物资源的潜在优势转化为旅游经济优势。区政府因势利导，并相继推出以文物旅游为特色的“岩寺新四军军部—唐模景区—呈坎景区—潜口民宅”黄金旅游线。潜口民宅先后接待了三十多个国家和地区游客50多万人次，1994年黄山市文物古迹首游式在潜口民宅开幕。先后举办了《古建筑构件展》、《古钱币展》、《新安书画展》、《古建筑白蚁防治研究展》、《毛泽东诞辰100周年大型图片展》等专题展览，还组织了××民俗婚礼表演活动。中央电视台、安徽电视台等国内外新闻单位先后在此拍摄制作电影、电视剧50多部，被誉为“天然影视基地”。

××区文化部门以“二次创业”的精神，大力推进文物旅游景点宣传促销和开放利用工作，派员到市各大旅行社、宾馆进行联系，发放宣传材料，突出个性化、特色化宣传；赴各大城市进行宣传促销，并组织浙江、南京等地的旅行社来踩线定路。在黄山大门附近和近一些主要路段设置大幅宣传画，宣传文物景区、景点。同潜口老年协会合作、常年为游客表演丰富多彩的民俗节目，增加了景点的吸引力。该民俗节目被中国新闻网采用，并被美国、新加坡、日本、港澳台等多家报刊选用。此外，还加大对景区导游人员素质培训，提高导游水平，该区文化部门正积极在文物景点开辟游客休息场所，加快对景点的配套设施建设力度，如加快清园工程建设，争取早日完工与明园自然连接，实现对外开放。

如今，××区充分利用文物资源和人文景观为旅游服务，做大做强文化旅游文章，为促进旅游经济跳跃式发展作贡献。

第四篇：测试工程师和开发工程师的博弈

测试工程师与开发工程师的搏奕 作为测试工程师，在日常工作中接触最多的当然是团队中的开发工程师，如何和开发工程师进行有效的交流是测试工程师面对的重要问题。一般来说，在一个团队中，总是有开发人员喜欢和不喜欢的测试工程师，这两者之间的工作效率和效果都有很大的差异。当然，不能武断地说测试人员不喜欢的测试工程师就一定是效率低下的测试工程师，或者说是不合格的测试工程师，但一般来说，那些容易得到开发人员认可的工程师在测试时总能够更好地发现缺陷和敦促开发人员解决缺陷。

测试工程师和开发工程师承担的是开发工作的两个不同方面，说得极端一点，一个是创建，一个是破坏，虽然两者的最终目的都是一样的，但在达成目标的方式上却有很大的差异。因此，在为同一个目标奋斗的过程中，发生冲突也是难免的，但通过下面的一些建议，换个视角看看开发人员的生活和工作，可能很多的冲突就能化解于无形了。

Cem Kaner在《Testing Computer Software》书中有一段话: “The best tester is not the one who finds the most bugs or who embarrasses the most developers.The best tester is the one who gets the most bugs fixed.”（最好的测试人员不是发现最多BUG或是使得最多开发人员不自在的人，而是能够[说服开发人员]修正最多BUG的人），建议大家好好理解这句话。

至于我个人，是从开发工程师转为测试工程师的，对于开发工程

师的处境和想法也曾有过切身的体会，或许是这个原因，让我在和开发工程师交流的过程中还算是比较顺利，和他们相处得也还不错。在我的测试经历中，也接触过相当多的开发工程师，这里我把和开发人员交流的经验归结为“五要四不要”：

【五要】

1、要耐心和细心

细心是测试工程师的一个基本素质，测试工程师是对质量负责的人，涉及到质量问题，就不能含糊，因此一定要细心，细心对待每一个可能的BUG、细心对待每一段 被你检查的代码，细心对待每一个你撰写的BUG报告，细心对待你发出的每一封邮件。细心是一种态度，你的态度迟早会感染和你合作的开发人员，而这往往是合作愉快的基础。

至于说到耐心，在我的工作经历中，不厌其烦地向开发人员解释一个BUG，让他认识到BUG的重要性是经常的事情，其实想想也很正常，对任何人来说，被人指出自己的缺点和不足都不是让人舒服的事情，因此，一点不耐烦的情绪就可能引起对方很大的反感，给自己的工作带来不必要的麻烦。

2、要懂得尊重对方

开发是一件需要全面和综合考虑的工作，开发工作中，由于各种原因导致程序中出现问题是很正常的现象，作为测试工程师，发现了这些问题并不值得你夸耀，也不能 说明你比开发工程师聪明。一个好的测试工程师一定是懂得尊重开发工程师的人，尊重对方的技术水

平，尊重对方的代码。我接触过的开发人员都是挺和善的，一般来说，对他们最大的尊重就是承认他的专业水平，承认他的代码。对他们来说，代码就像是自己的孩子一样：）因此，记得在合适的时候表达你对他的尊重，赞扬一下他代码的精妙之处。

3、要能设身处地为对方着想

开发工程师一般都处在较大的工作压力下，他的上司直接考核他们的指标很大程度上是已完成的代码，所以在工作任务紧张的时候，对于测试工程师报上来的BUG会 拖延解决甚至是推脱，给测试工程师的感觉就是很不合作。那么在这个时候，就需要设身处地的为对方着想了，每个人都会为自己的工作在内心排定优先级，如果他 认为解决你发现的BUG不是重要的事情，那么最大的可能就是你并没有向他解释清楚这个BUG的严重程度。

发现BUG是我们的责任，敦促BUG得到解决是我们更重要的责任，因此，我们可以心平气和地和开发人员坐下来讨论一下BUG的严重程度，和他一起排定BUG的优先级别并确定解决的时间。

4、要有原则

不要忘记，测试工程师需要对产品的质量负责，在这一点上一定要有原则。测试工程师可以和开发工程师建立良好的个人关系，但在具体的事情上，一定要按照公司的相关流程来处理。当然，在坚持原则的同时，可以采用一些委婉的表达方式，可以在允许的情况下尽量体谅开发工程师，但请记住，一个有原则的测试工程师才能真 正帮助开发工程师，才能赢得开发工程师的尊重。

5、要主动承担

如果开发工程师要求你承担部分不属于你的责任，比如，定位你发现的BUG到代码一级，或者是帮助他编写部分文档和代码（不要不相信，真的有这样的事情），那么你会怎么做呢？在我的测试经历中，这些事情都遇到过，我的原则是在可能的情况下尽量多承担。其实都是工作上的事情，有能力的话，多做一点也无妨。

在我的测试经历中，我会根据自己的进度和时间安排尽可能地提供更多的关于BUG的参考意见，甚至是定位到代码一级，这种方式不是正规的方式，但对于提高自己被信任的程度是非常有益的。但在主动承担时，一定要明确是在自己确有余力的情况下才能去承担，否则，婉拒是最好的对策。

【四不要】

1、不要嘲笑

不要嘲笑你所发现的BUG，即使是非常愚蠢的错误也绝对不要嘲笑，说不定那个错误是因为开发工程师联系加班24小时犯下的，对别人的工作始终应该尊重。如果 你觉得有必要提醒他不再犯一些经常犯的错误，可以采用这样的方式：编写一份测试过程中发现的开发人员常犯错误的文档（记住，千万不要写上谁犯了这些错 误），用轻松的口气调侃一下，发送给开发人员。这种方法我采用过，开发人员都能很快接受。

2、不要在背后评论开发工程师

永远不要在背后评论开发工程师的技术能力，这个绝对是非常忌讳的事情，一时的口舌之快或许会使你永远不再能同他良好地合作，要知道，开发工程师最在意地就是别人对他的技术能力的评价。其实这个不仅仅是作为测试工程师的准则，也应该是做人的准则。

3、不要动辄用上层来压制对方

在出现和对方的意见分歧的时候，应该采用什么方式说服对方呢？直接向上层求助当然是一个办法，但这种办法带来的负面左右也是很明显的，首先是作为上层的处理 结果可能不一定符合你的愿望（在很多公司，开发工程师的地位高于测试工程师的地位，这种地位的不平等导致上层在处理分歧时会有一定的偏向性）；其次是动辄 拿出上层来压制对方只能给他人留下无用的印象。所以在出现分歧时，尽量尝试通过沟通解决吧，实在不行，再动用最后的手段。

4、和开发人员的沟通不要只有BUG

除了在BUG记录单上，在其他的地方也让和你合作的开发工程师接触到你吧：），午餐或是集体活动的时候多和对方聊聊天，一方面可以增进彼此的感情，混个脸熟，打交道的时候也方便；另一方面，从他那里了解业务的知识和他负责模块的方方面面，对自己也是提升。我个人就很喜欢和开发工程师沟通，开发工程师其实一 般都是比较健谈的，尤其是对自己程序的精妙之处，多了解一些，多接触一些，对自己总是有益的。

写了这么多，其实关键的就是两点：多从别人的角度去想想，所谓“换位思考”，多尊重对方就一定能得到对方的尊重与配合；其次

是加强和开发工程师的沟通，让他清楚地认识到你的工作对他的价值，你发现的每一个BUG的重要性。

我一直认为，一个好的测试工程师一定是在公司里被所有人尊重的快乐分子，而不应该是一个“铁面判官”：）当然，作为我个人来说，绝对不敢说自己做的已经很好了，不过，我经常都记得提醒自己：尊重对方。

第五篇：小学校本课程开发经验交流

提升办学特色

提高学生素质

―――小学校本课程开发经验交流

一、我们的基本认识

在新课程改革实施的第5个年头，我校与新课程同行，本着立足素质教育，从实际出发，坚持“以人为本、促学生全面发展”的主旨，积极着手校本课程开发和建设工作。我们认为校本课程是提升办学品位、创建教育特色的重要途径。目的就是为了开发教师潜能，发展学生个性，最终更好地满足学生的实际发展需要。基于此，我校校本课程开发和实施是以学校多年来实施的活动课和兴趣小组为基础，以学校和教师为主体，进行了点滴的探索。

二、我们的主要做法

1、健全机构，完善措施，制度保障，确保校本课程有序进行 根据省课程评价标准，我校相继出台了《课程管理实施方案》、《校本课程开发与实施方案》，成立了相关的领导小组和实施小组，就学校课程的指导思想、总体目标、各年级的课程结构与门类、课时分配、课程资源的开发、课程的组织实施与管理、课程评价以及保障机制等进行科学的全面的构想。在实际操作中加强了学校课程开发、管理和研究队伍的建设，充分发挥全体教师尤其是管理人员在课程决策、开发等方面的重要作用，提高课程管理的科学化、规范化和民主化的水平。引导和鼓励教师对课程的实施和操作进行创造性的设计，增强课程资源开发的意识，通过多种渠道，开发、优化和整合各种课程资源，实现优质课程资源共享，满足师生需求。建立和完善学校课程建设与管理的评价机制，建立和强化课程管理的保障机制，确保学校课程建设健康、有序、持续深入地开展。

2、挖掘资源，优化师资

（1）、把校内课程资源转化为校本课程

把校内课程资源转化为校本课程是我们开发校本课程的重要途径。我们结合学校实际，积极引导学校把校内优势资源转化为课程资源，尤其把教师资源的转化当作校本课程开发的根本。校本开发要求我们的教师做到一专多能。“专”指专业课，“能”指除专业课之外能指导学生活动的能力，如：唱歌、跳舞、编织、绘画等，因为只有教师有了知识的源头活水，学生才会有取之不尽，用之不竭的甘泉。在调查全校教师的特长后，我们发现教师有许多精彩的一面：有技术特长型的（音、体、美）；有生活技艺型的（编织、家政）；有学科知识延伸型的（阅读指导）……根据教师的实际情况，结合学生的兴趣爱好，我们下设校本课程的选修课（10余门），然后让每一位任课教师自由申报，承担一门活动课程，经学校审核后，方可确定。同时，我们利用学校图书室、实验室、微机室、校园电视台、宣传橱窗、文化长廊和音乐、体育、及美术课等各学科的课程资源开发了校本课程书法与乡土美术、剪纸、各种有趣的小制作、网页赏析与设计等。

（2）、把学校的传统优势与特色转化为校本课程

把学校的传统优势与特色转化为校本课程是我们开发校本课程的长远规划。学校的传统优势及学校文化积淀是学校长期办学取得的成果。在我校的多功能楼建设完成后，学校挖掘学校校史、校友资源以及校园文化，建立了校史馆，以此形成自己独具特色的校本课程，并随着学校的发展不断补充和完善，使这一资源成为对学生实施教育的活教材。

（3）、把活动课提升为校本课程

把活动课提升为校本课程是我们开发校本课程的进一步延伸。尽管活动课与目前课程改革所倡导的校本课程开发理念是相同的，但它并不等同于校本课程。因此，我们在原有活动课的基础上，用课程开发的程序及理念去审视原有的活动课，对其进一步进行全面筛选，进行重新开发与规范，把活动课转化为校本课程，将教育的手臂更加延伸。现在由活动提升、开发的校本课程达10多种，如趣味数学、唐诗鉴赏、美文赏析、古诗词诵读、英语口语、快乐体育等。这些活动与课程的相互渗透、相互交织，达到了既发展个性又综合发展的目的。活动教材也已成为我们今后课程设置的主要方向。

3、及时评估、交流，促进校本课程开发均衡发展

为推进学校校本课程建设的进程，提升课程开发的质量，按照《校本课程开发与实施方案》进一步规范校本课程开发工作，由教研室及学校课程开发负责人组成的调研小组进行阶段性评估，以评估促规范，以评估促交流。并在此基础上，每年组织一次处级优秀校本课程的展示和教研活动。通过展示，对共性的问题进行充分探讨与沟通，帮助课程实施相对薄弱的学校、科目找到有针对性的解决方法；通过开展教研活动，以降低教研重心，丰富教研形式，为校本课程的开展服务。

三、我们的主要收获 1.我们的学校在变化

通过校本课程的开发和实施，我们的学校教育教学也不断在走向内涵发展的道路，提升了各自的办学特色，学校文化氛围更

加浓厚，学生的综合素养得到提升，并在今年10月份争创省艺术教育学校。

2.我们的教师在变化

校本课程的开发，充分地调动了我处大部分教师的积极性和自我实现的欲望，在主动地开发、实施校本课程的过程中，教师有了更多的机会进行教育科研，有效地促进了教师的专业发展，并由此进行的各种教科研课题取得了丰硕成果。

3.我们的学生在变化

通过校本课程的使用，我们欣喜地看到：学生的个性得到了充分张扬和发展，兴趣爱好广泛了，动手能力强了；关注生活，主动学习的人多了；主动合作、探究的意识增强了；知识面拓宽了，且运用知识的能力也有了进一步的提高；在接受传统文化中提升了情感，懂得了做人的道理等。

校本课程的开发与实施对于我们来说可能才刚刚起步，还有许多困难和问题摆在我们面前，我们有信心把这项工作做的更好，同时也希望通过这此交流能从兄弟单位学到更多的方法和经验。

中心小学