第一篇：經驗交流：測試驅動開發感悟

最近聽到了很多關于軟件質量的話題，自己前段時間也參加個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.我們的學生在變化

通過校本課程的使用，我們欣喜地看到：學生的個性得到了充分張揚和發展，興趣愛好廣泛了，動手能力強了；關注生活，主動學習的人多了；主動合作、探究的意識增強了；知識面拓寬了，且運用知識的能力也有了進一步的提高；在接受傳統文化中提升了情感，懂得了做人的道理等。

校本課程的開發與實施對于我們來說可能才剛剛起步，還有許多困難和問題擺在我們面前，我們有信心把這項工作做的更好，同時也希望通過這此交流能從兄弟單位學到更多的方法和經驗。

中心小學