計算機軟體技術基礎教學論文

　　隨著社會經濟的迅猛發展,數字技術、多媒體資訊科技、計算機軟體技術等先進技術不斷優化和完善,有效提高了人們的社會生活質量。下面是小編為大家整理的，供大家參考。

　　篇一

　　《 實時軟體開發方法思考 》

　　摘要：當今是個資訊自動化的時代，軟體已應用於人們生活的環境的各個方面。把面向物件的實現方法引入到實時軟體系統的開發過程中具有重大的作用，可以達到反覆使用，開發週期時間短、軟體質量增強、開發有保障以及開發成本低等效能目的。這樣就確保了實時軟體的良性開發並使這種開發系統化和工程化，更使人們無論在生產方面還是學習方面都會有很大的便利並提升了生產生活的質量

　　關鍵詞：面向物件;實時軟體;開發方法;軟體工程

　　實時系統是計算機系統中特殊的系統，輸出值和系統的消耗的時間決定了這個系統的結果是否精確，即使用者希望以極短的時間獲取最佳最有效的運算結果。在以前實時系統主要服務於國家軍事安全方面，今天隨著這一系統的研發，它廣泛應用我們社會生活的各個方面和各個環節，其應用範圍從洗衣機、烤箱到自動化的生產線、醫學輔助機械、交通運輸控制、天氣預報預測、航天動力工程等等。在軟體開發中實時系統中的軟體部分逐漸成為一個不可缺少的獨立部分，貫穿於軟體開發的始終。

　　1.闡釋實時軟體的內涵

　　實時軟體是實時系統中的軟體。當外部世界發生變化時，相應地實時系統就會對這種變化做出動作進行迴應，並在規定的時間內、依靠嚴格的控制、最大化地獲取資料來實現這一功能。特別要指出的是，這些控制是有嚴格規範的,這便對實時系統的應用進行了限制，只應用於它相對應的方面。另外，實時系統具有高標準的要求,主要可以體現在以下方面：其一、時間方面，必須在規定的時間內處理完突發事物，如果超過時間就會造成不可彌補的損失;其二、正確性方面，在規定的時間內對突發事物做出合理的邏輯判斷和處理，這就確保了結果的正確性。同時，存在著對實時系統的實時性有一個普遍的誤區，他們狹隘地臆斷實時就是速度要快。以第一時間對外部情況做出反應是實時系統的一個優點，快速反應是實時性的一個要求，但是兩者有著本質的區別，不可混淆概念。有時快速反應並不意味著實現了實時性。所謂的實時性是指要求圓滿處理完外部相應的事物和要求必須在規定的時間內。除了具有一般軟體系統的特點外，實時系統軟體還具有:首先，時間限制,即實時性。要求在規定的時間內對於外部的發生的事物系統要做出反應並處理好;其次，穩定性。如果系統重啟和故障恢復系統會很快復原且資料不受損;再次，多工、並行性、分佈性。實時系統可以同時同步對於外部世界或者分佈較廣的多個問題和任務，進行有效的處理並有效地保證處理的結果具有可靠性。而這種處理的有效性和可靠性是由系統的實時性決定的;最後，對於作業系統的底層具有開發性，實時作業系統就是實時軟體應用中所使用的作業系統,要求在優先調配機制和記憶體鎖定機制控制下，實現多工同時同步處理。特別要注意的是，對於系統中的語言開發原則也要堅持實時性原則，選擇實時性語言，以求對多個任務進行並行處理。

　　2.探討實時軟體開發方法

　　與普通的實時軟體相比，複雜性是兩者的共性，實時系統的軟體還具有自己的特殊性要求，那就是時間控制的因素，這就是實時軟體的結構和開發方法的優勢。

　　2.1實時分析技術

　　以面臨解決的事實問題或既定的目標為依託，全面解析實時系統的軟體和硬體部分，而後對硬體和軟體進行拆解，以求對設計實時軟體奠定根基，這就是實時系統在分析階段中所要完成的任務。建模和模擬技術是實時系統進行分析才應用的技術。對實時系統元素進行建模時要求分析人員必須利用好數學輔助工具，另外，把握時間長短和對資源大小進行估量是分析人員在這一過程中特別要注意的問題。根據在對資料流進行分析的基礎上，分析人員要建模實時系統的硬體和軟體元素，控制以概率的形式進行，這就是數學分析方法應該注意的。同時，對系統時間和資源大小如何進行評估，就要求分析人員以網路分析、序列論、圖形論和資料模型等方式來推匯出來。RMS理論為基礎，能夠分析並行的多工的分析技術，是為了輔助RMAM的分析方法而設立的理論。判斷在實時系統中在排程方面利用RMS處理並行任務是否能夠滿足他們的實時性的依據，那就是看有沒有采用採用RMA分析技術。分析系統的效能需要使用模擬和建模工具,利用這兩種工具軟體工程師還能夠構建一個模型，通過這樣的形式，可以有效地理解系統的運作。為建立一個實時系統的概念模型需要通過系統的狀態圖、活動圖和模組圖，這就是系統的建模方法。然後在在建立的模型的基礎上，分析和模擬系統的行為和執行情況,並測試系統是否具有一致性和完整性，最後，彙總在真實系統中的各種資料和特性。

　　2.2實時設計和實現技術

　　在給定的時間控制情況下如何完成系統的目標是實時設計階段中主要面對的任務。處理實時軟體中的優先權的選擇、多工和並行、同步和非同步、時間約束等問題是設計實時軟體所必須考慮的因素。通常都是通過擴充套件一些非實時設計方法是實時軟體的設計方法所採用的手段，而基於過程的模組化的設計方法是傳統的實時軟體的設計方法才採用的手段。不僅可以採用自頂向下和結構化的程式設計,而且可以採用圖形化的語言描述設計,還有一些運用有限狀態機、Petir網、訊息傳遞系統或一某種專門語言等是使用面向資料的設計方面向物件的實時軟體開發方法所研究的基礎性方法。

　　2.3傳統實時軟體開發方法應該注意的問題

　　由於實時軟體的應用於各個領域，這樣就使實時軟體面臨的問題越來越多，最終使實時軟體很複雜了。在過程的設計方法上而建立的傳統實時軟體已不能夠適應變化的新情況了。它主要存在以下問題:首先，分別對過程和資料進行處理，這樣就使真實世界的實際情況失去了本來面目，更加劇了分析和設計實際世界的難度;其次，沒有統一性的劃分原則對採用層次化的功能模組劃分系統，最為嚴重的是，某個別的開發人員的主觀看法完全左右了對組織軟體單元,系統的劃分，這樣就失去了客觀性加劇了實時軟體開發的困難;最後，由於人為的侷限性使得對排程的分析和描述過程也相當的複雜。

　　3.結語

　　隨著電子資訊科技的發展，我們研究實時軟體開發時，要具有勇於突破和敢於創新的鬥志，在對現實情況進行分析和研究的基礎上，要不斷對實時軟體進行改進，以達到它更好地服務於社會的目的。

　　參考文獻:

　　[1]肖亞利.面向物件的實時軟體開發方法研究[D].四川大學,2003.

　　[2]沈芳平.鍋爐熱效率計算方法研究與軟體開發[D].東南大學,2004.

　　篇二

　　《 軟體開發敏捷管理方法研究 》

　　摘要：21世紀是計算機崛起和發展迅速的時代，面對著使用者多樣化、個性化的需求，軟體開發必須積極適應這一變化，從專案、技術等多方面靈活應對，以提高軟體的適應性，降低開發成本。傳統的軟體開發理論已經失去了作用，而敏捷管理方法為這一問題更好地解決提供了有益的指導，它能夠有效地提高軟體的質量，更好地提升使用者的滿意度。

　　關鍵詞：敏捷管理;軟體開發;應用

　　隨著資訊科技的發展，使用者對軟體的需求也逐漸提高，這就對軟體開發者提出了更高的要求。由於傳統軟體開發理論的不足，軟體開發一般耗時較長，使用者從中的收益較小，而敏捷管理方法以實踐為基礎，為軟體開發提供了新的思路，充分提高了軟體的適應性，有效地滿足了使用者的需求。

　　一、敏捷管理方法概述

　　軟體開發的難度隨著使用者的需求在逐步提高，市場競爭的激烈化也刺激著軟體開發者必須使用新的軟體工程管理理論。目前，敏捷管理方法包括極限程式設計、自適應軟體開發等，這些方法都以使用者的需求為中心，減少了所需要的文件，提高了軟體的靈活性。敏捷軟體開發主要有一下幾條原則：要儘早、持續地交付有價值的軟體供使用者使用;即使到了開發後期也能夠滿足客戶的需求，為客戶的利益著想;經常性的交付可工作的軟體;在軟體開發期間，開發人員要和業務人員積極溝通;為軟體開發者提供他們所需要的環境，給予充足的支援;在開發團隊內部，要面對面的交流，以提高資訊傳遞效率;軟體開發必須保證可持續的、恆定的開發速度;積極關注技能的創新;從最簡的工作開設等。這些原則涵蓋了敏捷管理的核心思想，顛覆了傳統的過載軟體的過程，顯示了以人為本、以技術為支援、注重實效的思想，國內外的實踐也證明了敏捷管理方法在軟體開發中的重要作用。與傳統的管理方法比較，敏捷管理主要有以下幾個優點：

　　①較強的靈活性。敏捷管理方法較為靈活，以現有的事物為基本管理職責，由市場驅動競爭力的儲備，能夠有效地滿足使用者需求的變化。

　　②錯誤率低。敏捷管理方法將設計工作與編碼工作融合到了一起，能夠及時發現錯誤。

　　③專案風險較低。敏捷管理方法提高了有價值、可執行軟體的釋出速度，使使用者能夠儘早地使用軟體。

　　④能夠提高人員的能動性。敏捷管理為員工提供了充足的資源，對客戶的個性需求有較強的應對能力。⑤降低了成本。敏捷管理方法降低了文件的維護成本，面對面的資訊交流也較低了交流成本，同時輕快開發過程也降低了時間成本。

　　二、敏捷管理方法在軟體開發中的應用

　　1、團隊管理

　　軟體開發不是由個人單槍匹馬就能夠完成的，它需要團隊的合作，因此，“以人為本”是團隊管理的基本原則。團隊管理需要以專案為中心，為開發人員提供必要的環境和技術支援，同時還要給予積極的鼓勵。一方面，要“恩威並濟”。團隊管理需要融入一定的紀律，保證軟體開發的標準性，同時也要容忍一定的個體變化。在傳統的管理方法中，嚴格的紀律保證了很多行業的高生產力，但在軟體開發中，如果專案負責人單從自身的角度出發制定嚴格的標準，而忽視了員工的獨特思想，則很可能造成很多不利的影響。另一方面，促進團隊合作。敏捷軟體開發需要促進人與和人之間、小組和小組之間的合作，不再以命令的形式調節他們之間的關係，而是以互信為基礎。第三，提高開發人員的榮譽感。團隊管理的困難之一在於提供適應性強的獎勵機制，如果單純以獎金的形式進行獎勵，長時間也會影響團隊的動力，因此，需要以更好的形式激勵團隊。為員工提供一定的榮譽感，能夠讓員工真實感受到自己勞動成果的價值，能夠更加有效地激發員工的主動性、積極性和創造性。第四，提高資訊的反饋效率。敏捷管理方法較為靈活，但評估起來較為困難。國內外的實踐表明，在管理過程中實施積極的、經常性的反饋，並認真分析評估反饋結果能夠及時地、清楚地瞭解團隊的精神狀態和專案進展情況，從而為專案負責人優化管理方法提供了科學的參考。反饋方法較多，如檢測使用者故事的完成數、驗收測試通過率等，另外也包括每週的評估等。啟動團隊是軟體專案開發的重要步驟，每一個團隊的啟動都需要一定的時間和過程，是工作關係的構建，只有做好啟動團隊工作才能夠有效地促進專案開發目標的實現，確定團隊和員工的工作目標。一般的，從組建團隊開始，調查員工的基本情況，如工作能力、人際關係等，然後分配責任，最後在啟動專案前，召開團隊會議，制定團隊目標、做動員等。

　　2、開發管理

　　在敏捷軟體管理中，多以迭代開發為主，但對管理人員的缺乏可操作性的指導，同時也缺少開發方法的闡述，缺少了單元測試、驗收測試。由於專案團隊的規模、人員構成、專案目標等方面的不同，軟體開發專案沒有統一的開發策略，只有結合具體情況制定開發策略才能夠滿足實際的需要。敏捷管理方法指導下的開發策略需要注意以下幾個問題：第一，努力實現軟體的可執行。從階段性設計看，可執行的軟體代表了團隊的開發成果，為團隊帶來了成就感和信心;從使用者的角度出發，只有給使用者展示了可執行的軟體才能夠讓他們真實地看到自己的需求是否得到了滿足。第二，制定周密的開發計劃。傳統的軟體開發在專案進度方面的掌握程度較低，系統正式完成的時間不確定，因此，敏捷開發要求將開發進度可衡量化，將每一個任務制定一定的點數，將所有任務的點數相加就是本次開發所需要的工作量，用所完成的任務點數比上總任務點數就是開發進度百分比。第三，儘量減少文件的數量。在開發時要根據實際需要增減文件的制定，降低專案的風險。第四，加強交流。敏捷開發要求開發成員之間要加強交流，保證資料採集、團隊合作、軟體設計的效率。第五，積極考慮客戶的需要。敏捷開發要積極滿足使用者的需要，讓使用者直接參與軟體開發的過程中，讓客戶親臨現場，與其探討軟體開發中的各種問題，提高軟體的實用性。

　　3、需求管理

　　需求管理以掌握使用者對軟體的需求為目的，是專案啟動的第一步，是一支指揮棒，以靈活的變動將“使用者故事”和“現場客戶”結合起來，表達了使用者真正的、迫切的需求。“使用者故事”是一種較為簡單的蒐集客戶需求的新方式，獨立表達了使用者的需求，使用者可以隨時刪除也可以隨時加入，是一種概述性的描述;“現場客戶”是指讓使用者代表親臨開發現場給予指導。使用者故事與現場客戶兩種方法的結合，讓客戶對團隊開發軟體的細節有更加深入地瞭解，同時也能夠給予必要的指導，節省了交流時間，提高了開發的效率。

　　4、釋出規劃

　　在對使用者故事進行輕重排列後，從業務和技術方面逐一制定實現計劃。在業務方面要積極考慮業務價值加大的使用者故事;在技術方面，技術小組從技術難度及風險的角度出發，劃分功能區，要將所存在的問題說明給客戶，讓客戶做出選擇。

　　5、迭代規劃

　　敏捷開發要求儘可能為客戶提供可工作的軟體，因此，要儘量縮短迭代的週期，一般為1~4周。迭代的優先順序由技術組確定，但其價值又客戶決定。在第一次迭代中，小組要建立基本的開發設施，另外，要避免技術迭代，減少耗時。對團隊開發來說，在歷經幾個月甚至幾年的時間才有所突破，每一次的迭代都是一次成就，是一種較好地員工激勵形式。

　　6、任務分配

　　在客戶將使用者故事提出後，開發團隊商討如何分界為幾個任務，然後分配給開發人員。第一步，客戶提出使用者故事。客戶將使用者故事宣佈告知給開發團隊，團隊成員可以提出問題，以充分理解客戶故事。第二，討論任務。開發團隊在討論過後將使用者故事分成多個任務，做好接受任務的準備。第三，選定任務。團隊成員選定合適的任務，做好估算工作。

　　7、軟體設計管理

　　在敏捷設計中，迭代開發的過程要力求減少文件，另外，敏捷管理要努力實現全域性檢視和軟體原始碼一起演化，從當前的系統需求出發構建所需的基礎結構，保持結構的簡潔、乾淨，病富有表現力，同時還要提高其靈活性。在分配給開發人員任務之後，要測試程式碼，提高原始碼的質量，讓開發人員有更加充足的信心，同時，測試也能夠迫使程式設計師從不同的角度觀察所要編寫的程式。軟體開發都是由結對的程式設計師使用同一臺電腦實現的，由一位出入程式碼，另一外觀察程式碼及其需要改進的地方，兩者可以交換角色，最後所生成的程式碼成果由兩人共享。結對關係每天至少要改變一次，以減少兩者的壓力，提高編碼質量，同時也能夠促進他們編碼技術的提高。

　　8、跟蹤

　　跟蹤能夠讓程式設計師、客戶及管理者明確工作進度、質量等問題，同時也能夠發現潛在的問題等。一方面，要跟蹤資源，即計劃和實際的對比、團隊成員的人數、客戶參與次數、測試人員數量、參與開發的計算機數量等，這些是軟體開發的必要條件。另一方面，跟蹤範圍，即跟蹤故事的變化情況。第三，跟蹤質量，即測試表所顯示的通過測試數及未通過測試數。第四，跟蹤團隊成員，即觀察開發成員的問題、開發成員之間人際關係問題，看其是否全身心地投入等。

　　9、測試驗收管理

　　當一個迭代完成後，使用者會與團隊商議下一步的需求。測試驗收過程中，越早的發現問題，就能夠縮短程式投入執行所需的時間，期間，客戶需要提供驗收測試，所提供的測試越多，專案進展速度就越快，價值也就越高。客戶可以通過制定的形式採集所需要的素材，通過自動的指令碼根據客戶的需求運轉。一旦某項測試通過需求，則決不允許該測試再次失敗，隨著測試的不斷累積會形成一個測試集合，它能夠測試系統的執行，一旦測試失敗，系統的建立也就失敗。因此，要保證需求的實現，避免其遭到破壞。

　　三、結語

　　敏捷管理方法滲透於整個軟體開發過程中，是一個長期的資訊構建原則，而不是某一個獨立的事件它，適應了複雜軟體開發的要求，同時也適應了軟體技術發展的需要。隨著客戶對軟體要求的不斷提高，敏捷開發適應了複雜的環境，並且儘可能地保持軟體開發的簡單化和系統化，適合團隊型的開發專案，它能夠及時反饋資訊，有效提高客戶的滿意度，也能夠保證系統的質量。

　　參考文獻：

　　[1]沈成莉.敏捷專案管理在軟體開發中的實踐應用[D].復旦大學2009

　　[2]唐俐威.軟體開發的敏捷管理方法應用研究[D].哈爾濱工業大學2006

　　[3]向佐龍.敏捷管理方法在軟體開發中的應用研究[D].武漢理工大學2007

　　篇三

　　《 軟體開發中測試驅動開發的運用 》

　　摘要：在極限程式設計中極具特色的一個原則就是測試驅動開發，作為一種新的思潮正在被越來越多的人所接受，它在軟體開發過程中所表現出來的積極作用是不言而喻的。測試驅動開發的方法能夠在保證功能測試的前提下，也能夠成為設計的一部分。整個開發過程的驅動力就是以測試驅動開發為基礎，能夠在很大程度上提高程式碼質量，改善開發設計過程，從而在根本上提高了產品的質量。

　　關鍵詞：測試驅動開發;軟體開發;積極作用

　　隨著時代的發展，計算機軟體的發展變得尤為迅速，與之對應的問題是使用者對軟體的質量要求也越來越高。為了能夠及時交付給使用者一個滿意的軟體，軟體開發人員往往需要投入到高效的軟體開發過程。然而現實情況則是傳統的軟體工程方法已經變得不再適用於當今的軟體開發，而最近剛剛興起的一些軟體開發過程的技術正好值得我們借鑑和學習。其中就包括我們今天要討論的測試驅動開發，它作為一個最基礎的技術能夠提供給我們一些相對高效的軟體過程開發方法。

　　1測試驅動開發的相關環節

　　1.1原理和過程測試

　　驅動開發的原理就是應該在明確要開發某個功能後，進行構思並決定如何設計測試程式碼的過程，從而根據使用者的需求編寫出功能程式碼滿足這些測試用例。接下來可以迴圈的進行新增其他功能，最後能夠完成全部功能的開發。其中的基本過程包括：明確當前需要完成的功能;需要在保證速度的前提下編寫測試用例;編寫對應的功能程式碼;保證測試能夠通過的方法就是重構程式碼。我們通常在運用了測試框架的前提下，進行組織所有的測試用例，從而保證了整個測試過程的高效和便捷。

　　1.2原則要求

　　為了保證能分清需要檢測的各類程式碼，不同程式碼的的測試之間應該相互隔離，為了避免去考慮許多的無關細節而增加複雜度，所以我們在相關程式碼的測試中一般只考慮該程式碼的測試，而不去考慮它的現實細節。在實際情況中，經常出現的功能點需要我們去測試，在任意階段中如果我們想要新增功能需求問題時，我們能夠把相關功能點新增到測試列表的操作方法從而避免不必要的麻煩，從而不斷地完成對應的測試例項、重構和功能程式碼。這是為了避免疏漏，同時也是為了避免干擾當前正在進行的工作。在完成某個功能、某個類別的時候，首先我們需要編寫測試程式碼，考慮具體該如何測試和使用，接下來再進行設計和編碼。在這個過程中，我們需要正確編寫對應功能程式碼判斷用的語句，隨後編寫對應的輔助語句。

　　1.3測試技術

　　如果我們採用傳統的檢測方式，這無疑會在我們的軟體開發中造成開發速度緩慢等缺點，而我們需要認清的一點就是測試驅動開發中的測試並不是作為一種負擔，而是一種為了幫助我們減輕繁重工作量的有效方法。在針對如何選擇一個合適的時間來停止編寫測試用例的問題上，我們應該根據往常的工作經驗來進行，例如說針對一些功能複雜並且具有核心功能的程式碼來說應該編寫更細緻、全面的測試用例。靜態的標準也不適用於測試驅動開發的測試範圍，在實際情況下是能夠隨著時間的改變而改變。

　　2軟體開發為何要應用測試驅動開發

　　2.1提高程式碼質量

　　測試驅動開發區別於之前的先編碼後測試的開發方式，它的操作過程恰恰相反，它推動整個開發的進行是通過測試來實現的。在某些時候，軟體工程開發工程中的需求是極難描述清楚的，當然我們這裡說的需求當然不只是指使用者的需求，程式碼的使用需求才是我們需要考慮的需求範圍。如果我們在軟體開發後期還要對某個類或者函式的介面進行拓展或者修改，顯然這對任何一個開發人員來說都是不能夠接受的。至於為什麼會發生這樣的事情，從本意上來說就是因為沒有精確地對這部分程式碼作出描述。而當我們需要新增某項新功能時，也不應該著急寫程式程式碼，這時候就體現出了先寫好測試用例的重要性。

　　2.2改善設計方式

　　測試驅動開發的優勢則體現在實現軟體設計的過程中，傳統的軟體工程所體現出來的設計思想跟測試驅動開發的思想是不能夠比較的，傳統設計方法中的死板的原則在測試驅動開發面前是不值得一提的，在某些程度還弱化了了全面細緻的設計。在測試驅動開發過程中我們應該對現有的需求做出簡單的設計，而不是對需求做出詳盡的解釋。看上去好像對設計進行了簡化，也削弱了開發的依據，實際上卻是進一步明確了軟體開發的時候應該更注重眼前的問題，只有這樣才能使做出的軟體更符合客戶的需求。因為設計是一個相持以往的過程，需求文件的體現也在測試用例中表現得非常充分。

　　2.3革新傳統的軟體開發

　　以人為本的思想是測試驅動開發的方法。人類活動都秉持著高度的目的性，建立一個心裡的標準並竭盡全力去達成這個標準會具有重要的心理作用。例如在我們平時的測試過程中，有著不同目的的測試軟體開發將會帶來不一樣的操作結果。比如說將證明程式中沒有我們需要查詢的錯誤作為我們的最終目的，那大腦中的潛意識裡就會指導著我們朝這個思路去做，所以在編寫測試的過程中，我們就潛意識地選擇了一些不會使整個軟體程式出錯的實驗資料;相反，如果我們逆向思維去選擇那些容易發現程式錯誤的測試資料去證明程式中的漏洞，那結果一定就會不同了。對比之下，我們在以尋找錯誤為最終目的的前提下做出的程式檢測質量遠遠高過以不找錯誤為最終目的的思維方式。測試驅動開發改變了以往的破壞性思想，測試在先，編碼在後的方法則是從人性的角度出發。

　　3結語

　　總而言之，測試驅動開發的開發方法就是“測試在前，編碼在後”。人性特點作為測試驅動開發側重考慮的因素，在一定程度上極大的提高了軟體的質量和開發速度。這是一種完全的軟體開發革新，也從根本上改變了傳統的開發軟體思想。推廣測試驅動開發思想使得越來越多的軟體企業開始注意到這種獨具一格的軟體測試方法，間接或者是直接採用了這種方法。測試驅動開發正在軟體開發領域發光發熱，我們也相信在不久的將來就能解決使用者對軟體質量不滿的問題。

　　參考文獻

　　[1]嚴國武.淺談驗收測試驅動開發[J].電子世界,2014***08***.

　　[2]林勇.淺談測試驅動開發[J].中國金融電腦,2012***04***.

　　[3]唐金鵬,李玲琳.測試驅動開發應用研究[J].企業技術開發,2012***05***.

　　[4]李瑛,彭軍.測試驅動開發在系統中的設計實現及效能分析[J].計算機與數字工程,2012***01***.

有關推薦：