時間：2023-02-03 16:58:47
導語：在軟件測試項目總結的撰寫旅程中，學習并吸收他人佳作的精髓是一條寶貴的路徑，好期刊匯集了九篇優秀范文，愿這些內容能夠啟發您的創作靈感，引領您探索更多的創作可能。
關鍵字：軟件；測試過程；管理
軟件開發過程的質量決定軟件的質量，軟件測試過程的質量直接影響測試結果的準確性和有效性。
1 軟件測試過程常用的模型
1、V模型
V模型反映出測試活動與分析設計活動的關系，指出單元測試和集成測試應檢測程序的執行是否滿足軟件設計的要求。系統測試應檢測系統功能、性能的質量特性是否達到系統要求的指標。驗收測試確定軟件的實現是否滿足用戶需求或合同的要求。
2、W模型
W模型指出軟件各開發階段中應同步進行的驗證和確認活動，即測試與開發也應是同步進行的。W模型有利于盡早和全面的發現問題。
3、H模型
V模型與W模型有不妥，即它們都把軟件的開發視為需求、設計和編碼等一系列串行的活動，而事實上，這些活動可以交叉進行的。H模型揭示這一點：軟件測試是一個獨立的流程，貫穿于產品的整個生命周期中，與其他流程并發進行。
除了上面的幾種常見模型外，還有X模型、前置測試模型等。在實踐中，建議以W模型作為框架，及早全面地開展測試，同時靈活運用H模型獨立測試的思想，在達到恰當的就緒點時就應該開展獨立的測試工作，同時將測試工作進行迭代，最終保證完成測試目標。
2 測試階段中的測試活動
軟件測試過程主要包括以下四項基本活動：
1、測試策劃
在測試策劃中的活動有：制定測試計劃，以確定測試范圍、測試策略和測試方法，規劃測試任務日程表，對測試資源進行安排，并提前評估測試風險，制定風險控制策略。
2、測試設計與實現
在測試設計與實現中的活動有：制定測試的技術方案，選擇測試工具，并根據測試技術方案設計測試用例。
3、測試執行
在測試執行中的活動有：建立相關測試環境、配置測試數據、按日程安排執行測試用例并記錄測試執行結果，對發現的軟件缺陷進行報告，并配合開發人員進行軟件缺陷的分析、處理和追蹤。
4、測試總結
在測試總結中的活動有：對測試結果進行綜合分析，以確定軟件產品質量的當前狀態，為產品的改進和提供數據和依據，同時編制測試報告，提交相關的測試文檔。
3 軟件測試過程管理的特點
軟件測試過程管理的基本內容包括計劃、組織和監控；測試過程中存在的問題有：
1.軟件質量標準定義不準確、任務邊界模糊。
2.軟件測試項目的變化控制和預警分析要求高。
3.軟件測試項目具有智力密集，勞動密集的特點，受人力資源的影響最大。
4.測試任務的分配比較困難。
5.測試要求的人力資源十分穩定。
6.軟件測試人員在待遇、地位上可能會受到一些不公平的待遇。
軟件測試項目的過程管理能否成功，通常受到三方面的影響：項目組內的環境，項目所處的組織環境，整個開發流程所控制的全局環境。
4 軟件測試過程管理的原則
1、有關測試需求，應當有一個經各方同意的、完整的、清楚的、詳細的、整體的、可實現的和可測試性的需求并文檔化，盡可能堅持最初的需求。
2、測試計劃先行。軟件項目管理過程從項目的計劃活動開始，軟件測試項目也不例外，也是從測試計劃開始。
3、建立任務優先級。在測試任務較多的情況下，應該為各項任務建立測試優先級，這樣也可以根據優先級來先后處理各項任務。
4、建立客觀的評估標準。這樣使得整個項目過程具有良好的可測性和可跟蹤性，強調以數據說話。
5、盡早測試。這是從W模型中抽象出來的理念。一方面指測試人員盡早參與測試項目，另一方面指盡早開展測試執行任務。
6、全面測試。這也是W模型的重要思想，其含義一方面只要對軟件所有產品進行全面的測試；另一方面指軟件開發人員與測試人員全面參與到測試工作中。
7、全過程測試。這是從W模型中抽象出來的另一理念。其含義一方面指測試人員要充分關注開發過程；另一方面指測試人員要對測試的全過程進行全程的跟蹤。
8、獨立的、迭代的測試。這是H模型的重要思想，強調只要達到測試就緒點，即測試條件成熟，測試準備活動完成，測試執行活動就可以開展。
5 軟件測試過程的人員組織
測試團隊的組織直接關系到測試團隊的工作效率和生產力，其組織方式由測試團隊的規模、具體任務和技術來決定。
一個測試團隊的基本角色有：測試經理、實驗室管理人員、內審員、測試組長、測試設計人員、資深測試工程師、一般測試工程師。
若測試團隊規模較大，則測試工程師分為三個層次：初級測試工程師、測試工程師和資深測試工程師，同時設置自動化測試工程師、系統測試工程師和架構工程師。
測試過程人員組織的一個方面是考慮測試團隊的規模，測試團隊的規模可以考慮在整個開發部門所占的比重，或相對開發人員所占的比例。從經驗看，不同的應用，軟件測試和軟件開發人員的比例也是不同的，大致可分為三類。
1、操作系統類型的產品，對測試要求最高，測試人員和開發人員的比例為2：1。
2、應用平臺、支持系統類型的產品，對測試要求比較高，通常測試人員和開發人員的比例為1：1。
3、對于特定應用系統一類產品，由于以后對象清楚、范圍小，甚至可對應用平臺或應用環境加以限制，所以測試人員可以再減少，但測試人員和開發人員的比例至少保證在1：2的水平以上。
6 結束語
相比之下，目前中國軟件企業在軟件測試方面與國際水準仍存在較大差距。首先，在認識上重開發、輕測試，沒有認識到軟件項目的如期完成不僅取決于開發人員，更取決于測試人員；其次，在管理上隨意、簡單，沒有建立有效、規范的軟件測試管理體系；另外，缺少自動化工具的支持，大多數企業在軟件測試時并沒有采用軟件測試管理系統。所以對國內軟件企業來說，不僅要提高對軟件測試過程管理的認識，同時要建立起完善的軟件測試過程管理體系，確保軟件測試管理在軟件質量保證中發揮應有的關鍵作用。
參考文獻
[1]朱少民. 軟件測試方法和技術 [M].北京：清華大學出版社， 2005年
[2]鄭文強，馬均長. 軟件測試管理[M].北京：電子工業出版社， 2010年
[3]布萊克（美）.軟件測試過車管理[M].北京：機械工業出版社，2003年
關鍵詞：軟件測試管理；測試團隊；測試過程；事件管理；配置管理
中圖分類號：TP311 文獻標識碼：A 文章編號：1674-7712 （2013） 04-0075-01
一、引言
現在，軟件測試已經成為一個很有潛力的專業，軟件測試可以提高質量，降低維護成本。
對于大型相對復雜的軟件項目，做好軟件測試就會相對困難，因此，為了盡可能提高軟件質量，減少錯誤，必須有效對測試工作進行計劃和管理。
要想對測試工作進行有效策劃和管理，需要采取系統的方法建立軟件測試管理體系，對測試活動進行監管和控制，以確保軟件測試在軟件質量保證中發揮應有的關鍵作用。
二、建立測試管理體系
軟件測試的過程及應用即測試規劃，設計，執行，配置與資源管理，缺陷管理等。從項目管理的角度來說，這些過程里，前一過程的輸出是后一過程的輸入。其中，配置與資源管理是這些過程的支持，測試管理對其他測試過程進行監視、測試和管理
三、測試管理過程和基本內容
（一）測試團隊管理
做好軟件測試需要一個獨立的團隊，測試團隊獨立于開發團隊之外去做測試工作，可以更加公正的進行測試。雖然測試人員可能需要花時間去熟悉被測對象然后才能設計出測試用例，但是測試人員具備了專業的測試理念和設計技術，而這些測試技術是一個開發人員所沒有的或測試前必須花時間去學習掌握的。
測試團隊管理的主要任務：確定測試隊伍的組織模式，確定測試需求和組織測試設計，估計測試工作量，安排測試任務，確定應交付的測試文檔，管理測試工具。
（二）測試過程管理
軟件測試貫穿于軟件開發整個生命周期，在軟件開發的每一個階段，都有相對應的測試任務，從計劃、設計、執行到缺陷管理、總結等步驟，構成了一個測試過程。（如圖1）
因此，軟件測試過程管理主要集中在測試準備、測試計劃、測試用例設計、測試執行、測試結果分析，以及如何開發和使用測試過程管理工具上。
（三）資源和配置管理
1.資源管理包括人力資源和環境資源
人力資源：測試人員的數量及其測試技能，在測試的各個階段中對人員和技能要求不同。
環境資源：建立測試環境所需要的計算機軟件資源和硬件資源。硬件提供了一個支持操作系統、應用系統和測試工具等運行的基本平臺，軟件資源則包括操作系統、第三方軟件產品、測試工具等。
2.配置管理
配置管理是是指通過執行版本控制、變更控制等規程，以及使用合適的配置管理軟件，來保證所有配置項的完整性和可跟蹤性。配置管理是對工作成果的一種有效保護。
（四）事件（缺陷）管理
事件即缺陷管理，為了有效地管理缺陷（事件），在項目內應該引入規范、高效的缺陷（事件）管理系統。
軟件測試的任務就是尋找缺陷，缺陷從被發現、分析、修改，到修改的確認形成了一個缺陷的生命周期（lifecycle）。在缺陷周期內要對缺陷進行跟蹤。缺陷可能會在開發過程中被發現，也可能在評審和測試過程中發現，甚至在系統最后使用過程還會發現缺陷。缺陷可能在代碼內、在運行的系統中、也可能在各種文檔內。缺陷與軟件的版本、運行的環境有關。缺陷與人員有關：測試員、開發人員、管理者和客戶等
四、總結與展望
測試管理涉及的范圍非常廣泛，如測試組織管理、測試過程管理、事件管理、人力資源與配置管理、風險管理、進度管理等。軟件測試貫穿于軟件開發整個生命周期，軟件開發周期模型為我們提供了軟件測試的流程和方法，為測試過程管理提供了依據。但實際的測試工作是復雜而煩瑣的，不會有哪種模型完全適用于某項測試工作。因此，在實際工作中，我們要考慮實際情況靈活地運用測試過程管理理念，依據這些理念來策劃測試過程，以不變應萬變。
參考文獻：
[1]楊小平，王勝開.面向對象軟件測試探討[J].計算機科學，2009，36（11）.
[2]王文東，耿國華，張根耀.軟件可靠性保證與評測技術[J].微機發展，2004（11）.
[3]葉言苓，崔彥軍.軟件測試管理的研究與應用[J].計算機應用與軟件，2003（09）.
關鍵詞：軟件測試；企業需求；教學方法
中圖分類號：TP311.53—4 文獻標識碼：A 文章編號：1007—9599 （2012） 14—0000—02
隨著軟件產業迅速發展，軟件產品的質量成為人們共同關注的焦點，軟件測試的作用和地位越來越顯得突出，它是軟件產品質量控制的具體實現環節及其根本保證[1]，社會對軟件測試人才的需求量劇增，對軟件測試人員的綜合素質要求也越來越高。
但由于我國的軟件測試技術起步比較晚，并由于主客觀方面的種種原因，在大學計算機教育中，軟件測試教育存在很多問題，無法達到《軟件測試》課程教學的目的和要求，也無法滿足業界對軟件測試人才的需求。
一、教學現狀
在目前的教學環境中，雖然《軟件測試》是一門理論性和實踐性都很強的專業課，但大多數院校在教學過程中，仍會忽視強調測試理論和相關基礎的重要性。在理論教學過程中，不重視測試的基礎教學，在培養過程中更多地停留在知識傳授，忽視軟件測試職業素質的培養，實際上，一個合格的測試人員除了具備測試專業知識外，嚴謹的工作習慣、良好的溝通能力和團隊合作精神也是軟件測試人員所必需的[2]。在實驗教學過程中，一味依賴教材的理論內容，忽略思考的智力技能培養，所設計的實驗內容不符合現實需求，軟件測試的實踐教學存在同社會脫節。在教學方法方面，傳統教學方法形式單一，學生學習興趣很低，自主學習能力較低。本文針對教學過程中理論教學、實踐教學、教學方法三個方面，對軟件測試人才的培養總結一些思考和心得。
二、思考和實踐
（一）重視并滲透理論教學
重視軟件測試課程的理論教學，基礎的扎實與否直接影響了能力的可持續發展性。在制定課程大綱時，加大理論課時的分配，使學生從根本上認識到理論在課程學習中的重要性，不再簡單的認為軟件測試只是簡單的“點擊”等操作，而是一門對思考和邏輯要求很高的課程。好的軟件測試人員擁有高敏感能力，高發散能力，高分析能力，而這些都是以扎實的理論基礎為前提的。并在教學過程中，不僅僅以教材為理論傳授基準，應結合項目中的實際測試場景和案例，加深對各個理論點的理解和運用，以樹型結構串聯零散的知識點，注重知識的內部體系結構，使學生系統的掌握測試的理論知識，鍛煉思維發散和思考能力，從而引導學生對知識和技能進行舉一反三、觸類旁通的遷移。
將軟件測試的思想深入廣泛地滲透到所有的專業課程中。例如在各類程序設計語言基礎課程中引入單元測試的思想，在軟件工程課程中，強調軟件測試的重要性，增強軟件質量管理意識，在面向對象的分析和設計課程中，強調測試和開發并行并重的思想[3]。
（二）以企業需求作為實驗教學的目標
1.以企業項目為教學內容
在傳統教學中，軟件測試實驗的內容通常只單純的利用教材上介紹的不同測試方法來“設計”實驗，所設計的實驗內容泛泛化，不僅不符合企業的需求，而且不符合項目測試中的完整性和規范化。在實際工作中，一個項目中所涉及到的測試技術和方法，以及這些技術的重難點，都很難在現有的實驗教材中得以體現。而以項目為實驗教學的方法，是以企業的需求和實踐流程為出發點，在實驗的教學過程中以項目為主線展開，以測試的流程由淺入深，把相關知識點融入到項目的各個環節中去，將項目完整的進行剖析，循序漸進[3]。
2.重視文檔和流程
在企業的實際測試工作中，文檔是非常重要的。我們以一個符合現實性的完整B/S模式的“圖書管理系統”作為測試案例，該項目涵蓋課程的主要知識要點和基本技能，項目大小和難易適中，提供給學生系統的代碼、需求分析、概要設計書、詳細設計書等必須文檔[4]，只有具備以上資料，才可真實的模擬實際工作模式。通過文檔，使得學生明白所測軟件提供什么功能？是否符合用戶的需求，設計是否合理，結果與設計是否一致，通過文檔，使得學生一邊熟悉系統一邊思考軟件研發者在設計過程中的遺漏點。文檔，不僅是測試人員與開發人員之間溝通的直接橋梁，而且這種彼此的不斷溝通以及思考，直接影響了軟件測試的最終質量。同時，除了以項目為教學的基本單位，并強調文檔在項目中的重要性，還要嚴格按照工作中的實際情況，將學生分成若干個項目組。項目組分別設置測試經理、測試負責人、測試組員等角色，各盡其責。這種強調文檔，各盡其責的項目教學方式，更加符合企業的實際需求，并有效鍛煉了學生的團隊合作能力。
關鍵詞：CDIO；軟件測試；教學改革；分組教學
中圖分類號：TP393 文獻標識碼：A 文章編號：1009-3044（2014）03-0670-03
1 概述
軟件測試技術是高職軟件技術專業的一門必修的專業核心課程。該課程是針對軟件測試員/程序員崗位的任職要求所設置的具有綜合性質的課程，主要任務是通過對軟件測試基礎理論、技術方法、流程管理和使用自動化工具實施項目測試的學習，使學生了解完整的軟件測試的工作過程，能對完整的項目進行測試的實施工作，從而實現與測試技能要求的無縫對接。但是筆者通過幾年的教學發現，很多同學學完這門課程后只是了解了軟件測試方面的相關知識，根本就不能夠綜合運用這些知識進行實際項目的測試工作。筆者通過分析總結認為最主要的原因是我們教學的過程中沒有采用工程的思想，使得學生不能有效地把這些知識碎片整合到一起，當然就不能談不上實際應用能力。
CDIO模式作為近年來國際工程教育改革的最新成果，它是“做中學”和“基于項目教育和學習”的集中概括和抽象表達，它以工程項目從研發到運行的生命周期為載體，讓學生以主動的、實踐的、課程之間有機聯系的方式學習工程[1-2]。無錫商業職業技術學院軟件技術專業結合自身的實際情況，對基于CDIO模式的高職軟件技術人才培養方案進行了初步探索。軟件測試技術作為軟件技術專業的專業核心課程之一，在CDIO工程教育模式的指導下進行一系列的教學實踐應用，取得了很好的效果。
2 傳統教學模式存在的問題
現代IT企業需要具有較高專業技能、職業素質和團隊協作能力的實用復合型人才[3]，但
高職院校軟件專業培養出來的人才普遍只是掌握了相關的知識，而不能有效的利用這些知識進行實踐應用。為了解決這個問題，各個院校的軟件技術專業都一直在嘗試探索更好的人才培養方案[4]，主要的專業課程也在進行各種各樣的教學改革[5]。因此，幾年來，“實踐教學”、“案例教學”、“情景教學法”等等教學模式進行了進一步的應用，但是在這些傳統的教學模式下，還是存在一些問題。軟件測試技術課程也是如此，存在的問題主要有以下幾個方面：
（1） 實踐教學死板化。各個院校的軟件技術專業在人才培養方案的制定中，都明確規定了課程的實踐教學環節，體現了對實踐教學的重視。以作者所在專業為例，規定專業課程的實踐課時比例至少達到50%。但是在實際教學中，實踐教學一般都是教師通過案例先講解演示，學生再模仿訓練，總體還是采用填鴨式的教學方式，因此造成學生一開始還表現強烈的新奇感，對課程學習充滿著動力和信心，但是由于無法真正調動學生的主觀能動性，隨著教學的推進，學生逐漸失去學習興趣，后面的實踐訓練只能是敷衍了事。并且，由于課堂教學課時的限制，實訓機制死板、不健全，使得學生的真正動手機會還是很少。
（2） 項目教學虛擬化。教學過程中，案例教學法得到了普遍的應用。以軟件測試技術課程為例，包括一些具有軟件測試精品課程的院校，無非都是采用了比如三角形測試、NextDate案例測試、飛機票訂票系統等作為教學案例，雖然使學生對相關知識和技術有了更深入地認識，但是這些項目大多都是虛擬項目，這些虛擬項目主要存在兩方面的弊端：一是功能過于單一，內容陳舊，只能起到說明相關測試技術的作用，卻與實際應用脫節，缺乏實戰性，使得學生在真正面對一個綜合項目的時候卻感覺無從下手。二是由于每個項目功能單一，不能把一個完整的項目貫穿于整個課程的教學，通過這些虛擬項目，不利于培養學生形成從測試計劃、測試執行、測試用例設計到測試報告的整個測試過程的工程思想，也不利于發掘學生自身的潛能。
（3） 知識內容缺乏系統化。教學過程中，授課教師只關注學生知識點的掌握，而忽略了知
識點之間的系統聯系和實際應用，使得學生一知半解，不知道學習這些知識點的用處，也不知道如何把所學內容運用到實際項目當中。在這種情況下，學生的工程管理、項目規范、項目文檔編制、團隊協作和溝通能力沒有得到有效提升，因此難以滿足企業對綜合素質人才的要求。
3 CDIO模式在軟件測試技術課程中的應用
在CDIO模式指導下，我院軟件技術專業課程體系圍繞軟件產品開發為主線，以每位同學都要參與幾個項目開發為目的進行課程安排。在整個課程體系中，將CDIO項目按規模和范圍劃分為三級，一級為包含軟件專業主要核心課程和能力要求的項目。我們選取了與企業合作開發的實際案例：洗衣管理系統和校外實訓系統；二級為包含一組相關核心課程、能力要求的項目。主要是階段實訓和綜合項目實訓項目；三級為單門課程內為增強該門課程能力與理解而設的項目，其中三級項目的設立與否及形式由各門課程大綱根據需要確定。
在軟件測試技術課程中，我們把CDIO模式貫穿于教學過程的每個環節，從如下幾個方面對課程進行了教學改革和實踐應用：
3.1 教學目標和內容
在CDIO模式下，軟件測試技術的教學目標為“掌握軟件測試的理論知識，掌握主流的測試技術和方法；具備測試計劃的制定能力、測試用例的設計能力、測試代碼及文檔的編寫能力；具有良好的分析問題和解決問題的能力以及溝通和團隊協作能力；具備自主學習和可持續發展能力”。
在課程內容方面，我們基于CDIO的構思、設計、實現、運作的思想，貫穿“做中學”和“基于項目教育和學習”的方式，以工程項目從研發到運行的生命周期為載體，把軟件測試技術課程的內容分成五個項目任務。并且在課程中，選取校外實訓系統和洗衣管理系統的測試作為貫穿于整個課程的任務。在這兩個項目的引領下，實施課程教學。課程的五個項目任務如下表所示：
3.2 教學組織
在CDIO模式下，為了使學生由接受者轉變為主動參與者和積極探索者，在發揮教師主導作用的同時，充分發揮學生的主體作用。在教學組織方面，我們采用行動導向的教學模式，以小組模式為基礎組織教學。在具體教學過程中，我們對學生進行分組，讓每個學生充當企業中的真實角色，以一個職業人的身份，在真實的工作環境中，模擬軟件企業工作模式，每位同學承擔工作崗位相應的責任和任務[6]。課堂教學也不再采用“教師演示講解、學生模仿練習”的模式，每一次課堂教學，教師先演示項目，提出任務需求，進行必要的知識講解，然后教師為學生發放項目任務書，再由組長帶領小組成員分析項目任務，探討實施方案，撰寫任務計劃，完成項目任務，并提交相關文檔。在整個任務完成過程中，授課教師不斷和學生交流，對于學生在完全任務過程中存在的問題，指導學生解決。這樣，不僅能夠調用學生的主觀能動性，引導學生思考問題，解決問題，并在解決問題的過程中研究新的實現方法，而且突破了傳統的以學校和課堂為中心的封閉式教學組織形式，將實際生產與學習真正融合為一體，在掌握業務知識、培養技能的同時，培養敬業精神、團隊意識和職業道德等綜合素質，使師生在職業崗位中學習，在學習環境中工作。
3.3 教學手段
在教學手段應用上，充分利用現代教育技術，采取密切的產學結合方式，聘請企業兼職教師進行實踐指導，并充分利用網絡平臺和網絡教學資源。授課教師在課堂上通過多媒體教學的方式講解重點難點問題，相關的項目任務探討和知識擴展通過網絡化平臺進行。對于網絡化平臺，我們主要采用兩種方式：一是建立課程QQ群，為學生提供一個資料共享和課程討論和交流的平臺，二是要求學生訪問中國測試網，通過論壇和專業測試人員和其他測試學習者進行溝通交流。在網絡教學資源方面，要求每一位同學使用高等職業教育軟件教學資源庫網站，訪問網站的課程資源和培訓資源，其中軟件測試的課程資源包括：學習指南、授課錄像、實訓指導、課程案例、參考和素材資源等方面。通過這樣的方式，能夠解決課堂教學課時的限制，使得課程的教學從課堂延伸到課后，對學生可持續學習的能力具有很大的促進作用。此外，利用與江蘇微軟技術中心的合作優勢，邀請他們在期末來校進行項目實訓指導。
3.4 考核方式
根據CDIO培養大綱，將學生的能力分為工程基礎知識、個人能力、人際團隊能力和工程系統能力四個層面[7]，再使用傳統的考核方式已經不能滿足要求。軟件測試技術課程打破了單一的考核方式，從學生的專業能力、社會能力培養的要求出發，建立基于教學全過程、以學生能力提升為導向的學習評價體系。具體包括過程性考核、綜合素質評價和終結性考核。其中過程性考核占30%，綜合素質評價占20%，終結性考核占50% 。
過程性考核：對學生完成實踐類項目的情況進行綜合評定，考查項目包括課堂學習、小組學習、創新能力、課堂實踐和實踐報告等方面，每一個項目的考核都制定嚴格的評分標準。
綜合素質評價：對學生在平時學習和實踐中表現出來的職業素養進行綜合評定，主要包括團隊協作能力、溝通交流能力、分析和解決問題的能力、自學能力、工作態度等方面，并對這些方面制定出嚴格的評分標準。
終結性考核：建立試題庫，實施考教分，在期末對學生進行包括筆試和上機考試的綜合測試。其中筆試考查學生軟件測試的基礎理論知識以及對測試理論的應用能力，該部分占終結性考核的60%；上機考試通過對實際測試項目的工作過程進行檢查和考核，對任務完成情況進行考核，還包括對測試工具運用的考核，該部分占終結性考核的40%。
4 結束語
通過在CDIO模式指導下進行軟件測試技術課程的教學，解決了傳統教學模式存在的主要問題，為達到學生的知識能力與測試技能要求之間的無縫對接奠定了良好的基礎。下一步的工作是進一步完善CDIO模式在軟件測試技術課程中的應用，并把這些經驗總結應用到軟件專業其它課程的教學過程當中。
參考文獻：
[1] 顧配華.以設計為導向的EIP-CDIO創新型工程人才培養模式[J].中國高等教育，2009（3）.
[2] 查建中.論“做中學”戰略下的CDIO模式[J].高等工程教育研究，2008（3）.
[3] 單光磊，韋良福.高職教育教學改革借鑒CDIO模式解析[J].山東水利職業學院院刊，2011（1）.
[4] 唐寶燕，馮娜.CDIO模式在高職軟件技術專業教學改革中的應用[J].電腦知識與技術，2012（2）.
[5] 陳翔，鞠小林.卓越計劃驅動下的軟件測試技術課程教學改革[J].計算機教育，2013（13）.
案例教學是軟件測試教學中的常用手段，對學生理解測試方法有著很重要的作用，但是目前高校教學普遍存在著教學案例陳舊過時，大部分教學都沿用了傳統的教學案例。這些案例大都沒有介紹軟件測試的工程方法和實現過程，并且沒有進行難度的區分，很難達到好的教學效果。
本專業的教師經過多年的實踐，總結了大量的教學經驗，按照實際工作中典型的工程師團隊所需的各種技能知識為導向，按照復雜度漸增、螺旋遞進的原則設置卓越軟件工程師課程體系與內容，把傳統的以學科知識的系統性為導向的橫向課程體系改造為以個人職業角色發現和能力提升為導向的、適應團隊教育培養的新型縱向課程體系。軟件測試課程是軟件工程卓越工程師培養課程體系的重要組成部分，課程總體跟隨整體培養課程體系的大方向，并結合自身的特點進行建設。
1復雜度漸增式開設課程
在傳統的以面向開發為主的培養模式下，測試課程設置單一，知識針對性連貫性不強。為了解決這些問題，在專業課程開設過程中將軟件測試課程課程拆分，穿插到整個培養過程中，緊密聯系軟件工程其他階段的課程，并且使用案例貫穿所有階段，復雜度逐漸遞增，讓學生在學習過程中循序漸進，逐步建立學習的興趣和信心。在第5學期分成兩個階段分別開設《單元測試與軟件質量》和《軟件驗證與確認》。在第一階段旨在培養學生小規模程序測試的能力不涉及復雜系統，以提高個人開發測試的基本能力為目標，學生可以運用測試課程中學習的方法在開發過程中使用，針對性強。第二階段旨在培養學生對系統整體測試的能力，此時學生以完成基本開發能力的訓練，其他相關課程的培養中也進入了系統級別。在該階段以上一階段培養的能力為基礎，提高復雜度，跟軟件開發其他階段緊密結合。完成第5學期的測試基礎課程開設之后，在第6學期還開設了《web軟件測試》、《測試案例分析》、《數據庫測試》等專業選修課，給有興趣的學生提供更多的學習選擇。
2基礎與實踐并重，充分利用虛擬實踐平臺課程
的開設充分考慮到測試重實踐，并且與軟件開發其他階段聯系緊密等特點；同時也考慮到了此時學生正處于學習階段，直接參與實際項目對學生的學習并不能起到很好的作用，因此在課程學習階段充分利用了校內軟件實訓基地，創建網上“虛擬企業”，引入企業管理模式，在這種虛擬平臺下，針對基礎的知識點開設虛擬項目[3]，模擬軟件測試的真實工程環境。學生在自己組合團隊中有各自的工程任務，針對性實用性很強，學生能夠在完成自己任務的同時感性的認識測試崗位工作，體會到軟件測試在整個軟件開發過程中的作用，將單項知識技能之間關聯在一起，系統的運用專業知識和技能。
3采用螺旋式的案例教學，案例與其他軟件開發階段貫穿
0引言
如今，軟件產品被廣泛應用于各個領域，如航空、機械、電子產品等，軟件產品質量成為軟件開發中重點關注的方向。在一些對于安全性要求較高的領域，對軟件產品的質量要求更高。例如，在2011年溫州發生的7.23動車追尾事故，導致212人傷亡;1996年阿里亞娜5型火箭發射39秒后爆炸，直接經濟損失3.7億美元;2002年首都機場電腦系統出現故障，導致6000多人滯留機場等。軟件中存在的缺陷是造成這些嚴重后果的根源。因此，軟件測試的重要性不言而喻。
傳統的軟件開發流程越來越無法滿足當下軟件需求的頻繁變動，如傳統的瀑布模型，測試人員在一定的控制點之前不能測試，所以在此之前無法找到缺陷。等到所有開發完成，即過了該控制點后再進行測試，缺陷數量會急劇增加，同時任何缺陷的修復都需要對一連串代碼進行變動，修復時間難以確定，軟件遲遲不能，損失將難以估量。
敏捷軟件開發是基于一種更接近人類活動現實情況的方法論，采用以人為本、迭代、增量的開發過程，逐步滿足軟件不斷變更的需求[1]。敏捷主要提倡個人為團隊所作的貢獻，注重各個職位的權利下發，發揮個人的主觀能動性，保證隨時都有可供交付的軟件產品。敏捷開發更容易在項目早期控制缺陷數目。軟件測試是保證軟件質量與可靠性的重要手段，敏捷開發能充分發揮軟件測試的重要作用。
1敏捷開發思想
敏捷開發是以用戶的需求進化為核心，采用逐步迭代、循序漸進的方式進行軟件開發。在敏捷開發模式中，軟件項目在開發前，先將整體項目切分成多個子項目，迭代過程中根據需要可以對子項目進行拆分或同時進行多個子項目，每一個子項目都要經過測試，保證項目能運行成功。換言之，就是把一個大的軟件項目分成許多小項目，每個項目獨立完成，但相互之間又有聯系，在該過程中軟件始終處于可用狀態。
敏捷開發本身更多的是一種概念，它是一種循序漸進的迭代開發方式，強調團隊成員間的溝通。2001年，敏捷開發創始人了敏捷宣言：個體和交互勝過流程和工具，可用的軟件勝過完備的文檔，客戶協作勝過合同談判，響應變化勝過遵循計劃[2]。也即，雖然后半部分的條目也具有價值，但是更看重前半部分的條目。他們希望這將成為成功的軟件開發的基礎。敏捷開發的方法很多，主要包括快速應用開發(RAD)[3]、極限編程(XP)[4]、動態系統開發方法(DSDM)[5]與Scrum[6]。本文構建的測試模型借鑒敏捷開發過程中的迭代思想，以漸進的方式完成測試工作，不僅可使測試工作具有更好的靈活性，同時也能更好地適用于現有的敏捷開發過程。
軟件是一種非常特殊的產品，開發出的軟件通常會存在一些缺陷，而有些缺陷會造成非常嚴重的損失。軟件測試則成為保障軟件質量的一種重要手段[7]。根據不同標準有多種測試方式，如集成測試、單元測試、系統測試、驗收測試和回歸測試。傳統的V測試模型和W測試模型成為指導人們進行測試的方法，而不同于這兩種測試模型的H模型，則強調測試的獨立性。另外目前很多開發團隊已經開始使用敏捷開發方式，敏捷開發方式非常注重客戶的交互以及團隊中的溝通，同時開發過程中會有許多迭代過程。本文提出的測試模型借鑒敏捷開發中的迭代思想，測試流程是一個漸進的過程。然而，即使有成功的敏捷開發方法，開發人員和測試人員依然要尋求最適合的敏捷方法，并將相關技術融入到自己的敏捷方法中。
2敏捷開發中的軟件測試
2.1敏捷測試
敏捷測試沒有已經確定的唯一定義，原有的測試定義“通過在規定條件下對程序進行操作，發現錯誤，衡量軟件質量”仍然適用，核心思想可以理解為“遵循敏捷開發的宣言，接納敏捷核心價值觀，基于敏捷開發的軟件測試”。敏捷開發宣言中提到敏捷開發的4個核心價值觀：簡明(Simplicity)、溝通(Communication)、反饋(Feedback)、勇氣/決斷(Courage)。符合敏捷核心價值觀的測試實踐活動都可以稱為敏捷測試，敏捷不僅是一種過程，更多的是一種理念[8]。
2.2敏捷測試方法
圖1為敏捷開發測試流程，此流程是一個結合了Scrum和XP方法，并加上一些基于計劃性流程原則后的產物。虛線箭頭兩端是開發過程中與軟件測試相關的部分，敏捷開發的測試人員全程參與完整的迭代開發。
(1)需求分析：測試工程師可以根據測試經驗以及需求的測試難度對需求列表提出問題或意見，以期團隊能共同提供建議或方案，在之后的實際測試過程中有助于提高測試效率。
(2)迭代計劃：包括對需求的詳細分析以及任務表等，軟件工程師和測試工程師對需求進行討論。
(3)迭代啟動會議：項目經理、產品經理、軟件工程師、測試工程師對此代計劃進行討論、完善。
(4)測試計劃：測試工程師根據需求以及測試經驗完成詳細的測試計劃書，團隊對測試計劃進行研討并確認驗收測試。
(5)測試驅動開發：測試工程師相當于軟件的第一批用戶，測試過程中要重視反饋，這也是敏捷開發的原則之一。
(6)驗收測試：測試工程師對此次迭代的所有功能進行演示，測試產品功能是否合格。如果產品合格，則此次驗收通過，可以進入下一環;如果產品不合格，則此次驗收失敗，重新返回開發階段，找出失敗的原因及bug并解決，并確認下一次驗收測試。
(7)提交與驗證：由測試工程師為產品負責人與參與項目的人進行演示，包括此次迭代的主要功能、產生的未解決bug，然后由產品負責人核準迭代成功。
(8)迭代后的研討：對此次迭代過程中產生的問題進行討論，對于亮點可以進行表揚，錯誤要分析原因。
從流程圖和測試人員參與項目的簡單描述中，可以總結出敏捷測試的方法主要有兩種：與傳統軟件測試相似的測試和測試驅動開發(TDD，Test-DrivenDevelopment)。
圖2展示的是測試驅動開發流程，開發人員在編寫產品代碼之前，要先編寫單元測試代碼，在進行單元測試后才能進行產品代碼的編寫，以保證產品代碼能完全符合要求。產品代碼編寫完成后進行單元測試和集成測試，測試代碼和產品代碼都要進行代碼審查，保證代碼的簡潔、統一，方便以后維護。在敏捷測試中，測試驅動開發的重要目的不僅僅是測試軟件，同時在開發過程中幫助客戶和程序員確定需求。測試驅動開發應該運用于每一個迭代中，逐步開發完成所有軟件功能。
傳統軟件測試的種類非常多，在敏捷測試中應當根據當前迭代的需求進行測試[9]。某車削軟件有這樣一個需求，能支持直徑40mm的刀具路徑生成。該需求一定配備了相應的刀具路徑生成方法，然后只需確定刀路生成中的一些參數，然后設計數量足夠的不同表面形態的圓面即可。由于TestPart數量過多，可能會用到自動化測試，也有可能會用到一些特殊的TestPart，如圓面面型變化大，甚至不是圓面等。迭代最后一定有整體的性能測試，在整個項目進行過程中，傳統的軟件測試方法同樣適用于敏捷開發。
2.3敏捷測試特點
在瀑布開發模式中，要求流程規范、文檔齊全，測試進行時再根據軟件需求總結、測試所有功能點，直到軟件中沒有明顯bug。在傳統的軟件測試開始時，軟件的缺陷會達到頂點，同時如果有需求變化，則需要重新編寫文檔，可能必須將之前的工作推翻重來，費時費力。而在敏捷測試中，一切都發生了改變。
敏捷開發模式中測試不是一個單獨階段，它和編碼一樣是軟件開發的重要組成部分。敏捷開發使用一個“完整團隊”的方法來保證軟件產品質量。敏捷團隊中的測試人員從客戶需求中提煉要求，然后與開發團隊合作，把這些要求變成可執行的規范，用于指導代碼編寫。隨著測試和編碼的逐漸進行與交互，將建立一些產品特性，直到提供足夠的產品價值。
敏捷測試包括以下幾個主要特點：①周期性的迭代開發方式。不同于傳統測試的一次性集成或功能測試，敏捷測試在迭代進行過程中要通過及時響應客戶反饋來修正軟件測試策略，以此修正軟件的質量指標;②每日立會，密切溝通。傳統測試提供了大量文檔描述產品需求，并通過文檔進行測試。敏捷測試則需要團隊每天進行交流，測試人員與客戶持續溝通，以保證產品質量符合客戶預期，并與開發人員溝通來確定需求認識的統一;③測試方法多樣，貫穿整個項目開發過程。敏捷測試包括測試人員對軟件的自動化測試、集成測試、功能測試等，還包括開發人員對代碼的單元測試、代碼評審等工作，從最底層和基礎的測試來保證軟件整體質量;④確保客戶需求圓滿實現。客戶需求是敏捷開發中最核心的內容，敏捷測試同樣需圍繞客戶需求實現。
2.4敏捷測試優勢
目前大多數軟件項目的共同特點是用戶需求變化快、風險高，同時還能快速搶占市場，這剛好是敏捷開發能夠解決的。
(1)良好的持續溝通可減少缺陷產生，降低風險。在敏捷開發模式下，測試人員的溝通尤為重要。一個迭代從開始到結束，測試人員都需要參與。迭代開始時，所有人都要對該階段軟件的成型有統一認識，滿足用戶需求的同時還要符合一次迭代的時間要求;迭代進行中，測試對開發人員的反饋非常重要，軟件開發初期，測試工具十分缺乏，對測試工作的進行造成很大阻礙，這時需要和開發人員持續溝通，必要時可共同開發一些輔助測試工具，在此期間要把握好迭代進行的時間;迭代后期，也可以作為bug反饋期，測試人員不但要站在用戶角度考慮需求，同時能和開發人員站在技術角度討論問題，達到溝通的目的。
(2)合理的測試用例。敏捷最直接的特點就是快速，如果涉及的用例粒度太細，很難開展敏捷測試。一個合理的測試用例不僅能包含所有可能產生缺陷的地方，同時還能快速地響應需求變化。
(3)更多人參與測試。敏捷測試中的測試人員不再是一個獨立的測試個體，研發人員、產品負責人、用戶都可以參與測試。研發人員的測試可以減少編程中的bug，產品負責人的測試可以更好、更全面地把握產品現狀，用戶的測試則可以提供來自真正用戶的反饋，以更好地促進軟件開發。
3敏捷開發中的軟件測試實例
本章結合一個具體的軟件項目，詳細介紹項目中的敏捷測試。
3.1項目介紹
針對3軸超精密加工車床，提供針對光學自由曲面進行加工的刀路軌跡計算的CAM(ComputerAidedManufacturing，計算機輔助制造)軟件。該軟件的目標是比UGNX中的相同功能有更快的計算速度和更高的精度。
3.2需求分析和項目規劃階段
項目經理和產品經理根據客戶給定的需求進行分類，包括框架、加工方式、加工質量、刀具選擇、仿真等需求，并對項目可能產生的需求進行判斷和規劃，形成項目計劃書。項目計劃書包括項目背景、、需求以及預期完成時間。項目計劃書完成之后即可開始進行第一個迭代，并以第一個迭代為基礎不斷進行下去，直到完成所有需求。由于整體項目過于龐大，這里只對第一個迭代進行介紹。
項目實例：第一個迭代中有2個需求，同時根據工作量分配任務天數以及每個需求的參與人員，如表1所示。
3.3迭代進行階段
迭代開始時，項目經理制定迭代的具體開發任務和測試任務。在迭代啟動會議中，每個人都要對此次迭代任務有統一認識，并且能夠承載相應的任務量，在需求確定完畢后進行任務分配。
.
開發人員進行編碼時，測試人員的工作重點包括：編寫測試計劃、測試用例、驗收測試以及提交和驗證。測試計劃和測試用例的編寫同時完成，且在迭代初期完成。驗收測試一般是在迭代后期進行集成測試，迭代過程中也可以協助開發人員進行單獨的功能測試。
3.3.1編寫測試計劃和測試用例
測試計劃需要具體的操作步驟以及相對完善的測試用例來涵蓋需求，因此需要測試人員有比較豐富的測試經驗。
項目實例如下：
表2和表3中的TestParts需要填寫測試工件名稱。測試計劃編寫完成后要經過開發人員和項目經理確認，保證開發人員認同并能夠達到計劃的目標。敏捷開發是不斷迭代的過程，對于一些比較簡單的功能，盡量設計簡潔的測試用例。如果TestParts比較多，可以采用自動化測試，而對于一些比較復雜的功能，可以先采用手動測試，在功能更加完善后再考慮自動化測試。
3.3.2驗收測試
驗收測試要嚴格按照迭代前期寫好的測試計劃進行，在開發人員開發完此次迭代所有功能后，測試人員對所有功能進行集成測試、功能測試、自動化測試等，完成所有測試工作后形成測試報告。報告內容包括此次迭代基本功能完成情況、缺陷產生情況以及測試過程中的一些詳細數據。
3.3.3提交和驗證
團隊全體成員參加驗收會議，由測試工程師對迭代成果進行演示，產品經理和項目經理進行驗收，項目需求全部完成則此次迭代成功，然后再對此次迭代中的不足之處進行討論和改進，或者提出創新之處。如果項目需求未達標，或產生了過多缺陷，則此次迭代不予通過，全員討論延后驗收或將缺陷完善延后到下一個迭代。
項目實例：針對需求R1、R2的基本功能測試達到了計劃的標準，框架的視圖操作和顯示功能以及CAD模型輸入功能均正常運行且無缺陷。雖然框架本身存在一些缺陷，仍能滿足迭代的基本需求。經過討論此次迭代成功，產生的bug在下一個迭代進行完善。
3.4迭代后研討和下一次迭代討論
迭代完成后要對迭代過程進行回顧，測試人員需要對bug進行總結，包括測試過程中產生的問題，以及需要改進的地方，然后對下一次迭代的需求進行初步討論，決定下一個周期的工作內容。
4結語
敏捷開發中的軟件測試應當遵循敏捷開發的基本原則，面對不同的開發方法和應用環境，軟件測試方法也不同。敏捷測試作為從敏捷開發中成長起來的測試方法，與敏捷過程密不可分，本文對敏捷開發中的軟件測試特點和方法進行了詳細描述。然而，真正在面對軟件測試時，測試用例的生成與覆蓋標準、測試的充分性和有效性、不同階段的測試關系等，以及如何將傳統測試中的一些方法應用到敏捷測試中，需要探討的問題及方法仍然很多。
摘要：通過校企合作能夠有效支撐應用性本科和高職高專教育人才培養的校外實踐教學基地、學生實習基地和教師職場體驗基地，建立畢業生質量追蹤調查機制、用人單位對學校和學院教學質量評價和反饋機制。本文介紹了我院在校企合作構建特色專業課程方面的探索。
關鍵詞：特色專業；軟件測試；校企合作；高職高專
中圖分類號：G642
文獻標識碼：B
1引言
計算機應用技術是一個應用范圍很廣的專業，可以從事計算機行業的幾乎所有工作。因此，計算機應用技術專業學生應學習的內容很多，內容涵蓋很廣。對于高職學生來說，三年學習內容不可能涵蓋所有的計算機應用領域。因此，必須對該專業定向。而專門化方向須根據市場需求方能確定。為此，我們在北京及周邊等地進行專業調研，了解社會對計算機應用技術專業學生的就業崗位、能力與素質需求。并由此確定計算機應用技術的專業化方向為軟件測試。
旺盛的社會需求是人才培養面臨的最大機遇，教育發展的最大動力是社會需求。軟件測試專業就是一個朝陽專業，社會需求較大，以就業為導向構建高職計算機應用特色專業人才培養模式及課程教學改革研究，將按照“就業導向明確、層次定位準確，培養模式先進，專業特色鮮明，人才質量優良”的要求，推進人才培養模式、課程體系和人才培養質量。
以計算機軟件測試方向作為高職計算機應用特色專業的研究與建設是新的探索。一個正規的軟件開發項目應該包括軟件開發和軟件測試兩大部分，而且旨在提供質量保證的測試部分應該占更大的比重，國際上標準的軟件開發和測試人才的比例應該為1:1或1:2，而目前國內這個比例則為5:1。計算機軟件測試專業在國內尚屬待開發專業，就業前景非常看好。但由于是新專業，現有的中青年教師在授課之前基本沒有系統的軟件測試理論和工程實踐、更無教學經驗。基于這種情況，就更加應該盡快開展專業研究和建設，并借助于各方力量，以提高教師的理論水平和實踐能力，使他們能盡快掌握理論和具備實踐能力，承擔起教學與實踐任務。
2計算機應用特色專業建設思路
由于國內軟件開發和軟件測試人員比例的嚴重失調，行業急需軟件測試人才。而該專業正在創建和開發時期，沒有教學經驗。基于這種情況，開展特色專業人才培養模式及課程教學改革研究，是很有必要的。為了使軟件測試專業教學更加貼近教學，使教學更具針對性，教學素材、案例更符合實際需要，必須引進實際項目，聘請校外專家，及時與實力雄厚的教育集團及企業合作進行專業共建。
特色專業建設的目的是：尋找促進人才培養與市場需求緊密結合的路子，突出軟件測試專業方向應用性人才培養特色，加強學校與社會企業的合作與交流，構建適應社會發展需求的產、學、研合作教育平臺。提高教師教學科研能力和技術實踐水平，帶動學校學科專業結構調整和人才培養模式創新。建設能夠有效支撐高職高專教育人才培養的實踐教學平臺，建立畢業生質量追蹤調查機制，為學校摸索出一條構建特色專業課程的新路。
改革創新軟件測試專業人才培養模式，深入研究校企專業建設內容，真正將行業所需人才應具備的知識、技能引進到專業人才培養過程中，確保專業建設內容的先進性與實用性。
人才培養模式以培養學生的全面職業化素質、技術應用能力和就業競爭能力為主線，充分利用學校和企業兩種不同的教育環境和教育資源，通過企業與學校的長期合作和雙向互動，將在學校的理論學習、基本訓練與在企業的實際工作經歷有機結合起來實現高素質高技能人才培養。
在開展本課題研究時，我們將本著“面向實際、站在前沿、重在應用、加強合作”的指導思想，努力創造一種團結民主、互幫互學、求實創新的科研氛圍，力求做到邊學習培訓，邊研究應用，邊推出成果，邊總結推廣，力求通過三年的研究，在課程體系設置、實訓基地建設、師資隊伍建設、畢業生就業引導等方面，探索出一套“高職計算機應用――軟件測試專業人才培養”的新模式。
3課程體系的建設
課程體系從原來的以學科為體系的課程設置轉變為以能力為主線的課程體系設置，即先按各專業方向對崗位能力的要求，及每崗位能力從入門、基礎、應用到綜合的過程來設置課程。根據軟件測試的特點設計了個性化的課程體系，確保學生們能夠學成上崗。課程體系按以下幾個模塊來實施：
3.1基礎課程階段教學計劃
3.2集中實訓階段教學計劃
3.3職業素質培養教學計劃
4專業建設研究目標
4.1技術路線和實施步驟
軟件測試特色專業的研究，主要是以就業為導向構建高職計算機應用特色專業人才培養模式及課程教學改革研究，研究計算機應用特色專業如何與社會需求密切結合的專業發展模式，培養學生的軟件測試的實際應用能力，加強專業建設和人才培養，讓教師與學生的培養一起成長，培養學生具有較強的實踐能力、崗位適應能力、創新能力的從事軟件測試的高等技術應用性專門人才。主要從以下幾個階段實施：
第一階段(2008年9月~2009年8月)
該階段是基礎課和專業基礎課程的改革和建設，主要由教研室負責這部分課程的建設與授課、課程資料及輔助科學軟件的開發。把開發小型應用系統作為教學的主線，鼓勵和引導學生參加項目建設。為后續課程的學習奠定基礎。
第二階段(2009年9月~2010年8月)
該階段通過構建軟件測試的基本概念框架，掌握使用軟件測試系統中軟件測試的基本方法、基本技能等。從軟件測試的基本概念到單元測試、集成測試、性能測試的實踐活動，設計與課程密切相關的單元測試。
第三階段(2010年9月~2011年8月)
該階段是軟件工程與測試實驗室搭建、軟件測試平臺搭建及綜合實訓基地建設搭建。該階段需要借助多方力量進行專業課程的構建、進行軟件工程與測試實驗室搭建、軟件測試平臺搭建等實訓課程的實施階段。
第四階段(2011年9月~2011年12月)
該階段是結題階段。收集、整理子課題結題實驗報告，舉辦課題成果評獎活動；撰寫課題結題報告，發表相關論文，上交申請成果評估驗收；課題組結題大會，成果出版與展示等。
4.2研究假設和擬創新點
(1) 結合所學課程，讓學生直接參與公司項目開發，有利于學生職業能力的培養。通過校企合作探索軟件測試人才培養模式，涉及到的合作機制、教學機制、運行機制的改革與創新。
(2) 通過課題研究，促進校企合作，以及人才培養與市場需求緊密結合，突出軟件測試專業方向應用性人才培養特色，構建適應社會發展需求的產學研合作教育平臺。
(3) 以就業為導向，圍繞專業核心能力，構建課程體系；通過產學結合，建設優質核心課程，制定課程標準，編寫適用教材；建設雙師結構的教學團隊和校內外實訓基地。
(4) 將傳統的課程進行整合，理論夠用為度，以講座、學術報告等形式增加現實社會所急需內容。課程模塊化教學，采用“事件驅動”式的培養方式，根據就業崗位確定課程設置，培養學生的基本技能。根據社會的需求大力實施訂單教育。
(5) 從課程學習到課程設計、畢業設計各階段，貫穿實施項目教學法，在項目教學中，學習過程成為一個人人參與的創造實踐活動，注重的不是最終的結果，而是完成項目的過程。
4.3專業建設的預期目標
學院與企業合作，實施實訓人才培養模式，共同致力于軟件測試應用人才的培養，開啟我院計算機應用人才培養與企業需求零距離對接的先河。注重人才培養的針對性和實用性，可以有力地促進我院教育教學的改革，提高辦學效益，實現學校、企業、學生“三贏”，產生良好的社會影響。使學生掌握必需的科學文化基礎知識和軟件測試等方面的專業知識，具有較強的實踐能力、崗位適應能力、創新能力的從事軟件測試的計算機技術應用性專門人才。特色專業預期培養目標如下。
5結束語
計算機軟件測試專業正在創建和開發時期，以就業為導向構建高職計算機應用特色專業人才培養模式及課程教學改革研究是新的探索。總之，高職計算機應用特色專業教學改革是培養數以億計高素質勞動者和數以千萬計高技能專門人才的需要，且大有文章可做。只要我們在教學實踐中不斷探索，不斷總結，高職計算機應用特色專業的教學改革就一定能結出豐碩果實，高職計算機教育就一定能為社會培養出“適銷對路”的計算機應用人才。
參考文獻：
[1] 朱鴻,金凌紫. 軟件質量保障與測試[M]. 北京:科學出版社,1997.
【關鍵詞】軟件測試 教學改革 軟件測試工程師
【基金項目】2015年中央高校基本科研業務費專項資金項目“C程序代碼級內存缺陷的充分性檢測技術研究”（15CX02050A）。
【中圖分類號】G64 【文獻標識碼】A 【文章編號】2095-3089（2015）09-0229-01
一、引言
隨著軟件產業的迅猛發展，軟件的復雜性也日益增加，導致對軟件的質量提出了更高的要求，這也使得軟件測試工程師成為每個軟件企業都不可或缺的技術人才。“軟件測試”就是一門培養軟件測試工程師的專業課[1]，本課程較為系統的介紹了軟件測試的基本理論、測試方法、測試過程以及常用測試工具等內容。本課程知識的掌握將為學生系統的掌握軟件工程知識體系以及畢業后從事軟件測試、軟件開發等職位打下良好的基礎。
如何扎實有效的培養軟件工程學生在軟件測試領域既具有理論基礎、又具有工程實戰能力，目前許多軟件工程專業教育者進行了積極的探索 [2-4]。我校軟件工程專業已入選山東省卓越工程師培養計劃[5]，為了執行國家對軟件工程專業卓越工程師培養的精神，融合學校的“三三三”培養體系[6]的頂層設計，以貫徹培養理論扎實、具備工程實踐能力、創新能力強、適應經濟社會發展需要的高質量軟件工程師為目標，我們也在軟件測試課程的培養方案、課程結構、教學方法和考評體系等方面進行了一系列的改革和探索[7，8]。其中最為重要的改革是借鑒CDIO（Conceive-Design-Implement-Operate）工程教育理念，落實了“基于項目的教學”方法，增開了大量的課程設計和綜合實踐環節，在理論教學的同時注重了工程實踐能力得培養。
二、“軟件測試”教學面臨的問題
“軟件測試”課程的已有的教學改革改善了教學效果，但是由于傳統的教學方法依然影響著教學，所以目前的軟件測試課程教學過程中依然面臨一系列問題。
（一）教學內容抽象，學生學習興趣不高
軟件測試是軟件工程知識體系的九個知識域中理論性最強的一個知識域，必然造成軟件測試教材與教學內容較抽象。目前，軟件測試課程教學中普遍存在著理論教學偏重的特點，扎實的理論素養是卓越工程師的必備基礎，但是即便對于軟件工程專業的本科學生，也欠缺軟件項目的實際開發經驗，所以課程內容的抽象性增加了學生對課程內容的理解難度。為促進學生對理論知識的理解與應用，必須結合軟件測試的課程特點，將抽象的內容分化到軟件測試過程的不同階段中，并采用相應的測試工具體現測試的方法，再應用于教學案例，才能促進學生對抽象的測試理論知識的理解與應用。
（二）教學內容碎片化，學生沒有完善的測試知識體系
按照軟件開發過程的要求，軟件測試是貫穿于整個開發過程的一項活動。而在教學中，軟件測試的理論出現了割裂，各知識點呈現碎片化，理論內容與實際的軟件測試流程不同步。將不同的測試理論與方法進行了分割，這樣利于教材內容的安排以及教學內容的組織，但這也必然造成教學內容碎片化，學生形成不了一個統一的測試理論框架，難以把握所學的理論與方法在軟件開發與測試的過程中如何應用。為促進教學效果，有必要基于軟件測試過程，定位軟件測試的介入點，在不同的介入點進行理論知識的分配，形成一個以軟件測試過程為主線、各理論知識在介入點進行分配的魚骨圖式的軟件測試理論知識體系。
（三）輕視測試工具應用，培養的學生與企業需求難以銜接
因為軟件測試方法眾多，這也造成有大量可選的軟件測試工具。雖然工具的培訓是培養卓越工程師的一個必備環節，然而卓越工程師的培養畢竟不等同于職業教育，不能只是簡單的掌握一個測試工具，而應該了解測試工具所體現的測試理論、所適用的測試階段以及所應用的場景。在進行測試工具培訓鍛煉的同時，必須結合所講授的測試理論，以及該工具適用的測試過程與測試場景。為了全面的掌握各種具有代表性的測試工具，需要搭建一個測試工具箱。
（四）教學案例簡單，學生沒有完整的測試思路
因為理論知識碎片化的講授，也造成目前教學中只能采用簡單的案例，簡單的案例雖然有助于學生對具體測試方法的理解，但是難以融會貫通的掌握對一個完整項目的測試。為此，需要基于魚骨圖的軟件測試理論知識體系，精心設計能夠貫穿整個測試流程的案例，并有必要設計不同類型的案例，形成一個分層次、分類別的測試案例庫，以保證對各種測試方法的掌握。
（五）學生對軟件測試存在認識偏差，缺乏從事軟件測試職業的意愿
目前國內軟件行業依然蔓延著“重開發、輕測試”的觀點，這種觀點也延伸到軟件工程專業的教學中，導致部分學生對軟件測試這個職業存在認識偏差。這就要求軟件測試課程需要從原來偏重理論講解、學生欠缺軟件測試訓練的教學中擺脫出來，應該與軟件測試工程師要求的能力培養集合起來，注重理論培養的同時，加強與軟件測試職業的銜接，增設對軟件測試工具的訓練，加大基于案例與項目的實戰訓練，通過工程能力的培養以加深學生對軟件測試的正確認識。
三、總結
為了執行我校軟件工程專業的卓越工程師培養計劃，解決“軟件測試”教學中存在的上述問題，我們計劃在已有的教學改革基礎上，提出“方法為基、過程引導、工具跟進、案例貫穿”的“方法-過程-工具-案例”四位一體的教學方法，以解決目前“軟件測試”課程中存在的諸多問題。
本文分析了“軟件測試”這門課程隨著卓越工程師培養、研究型教學的要求下在理論培養與工程能力訓練等方面逐漸顯露出的各種亟待解決問題，只有充分認識到這些問題，才有可能針對問題進行教學改革，進而培養理論與功能能力具備的軟件測試人才。
參考文獻：
[1]吳春雷， 剛旭， 張俊三. 基于“卓越計劃”的軟件測試類課程改革[J]. 計算機教育， 2014，11：88-91.
[2]李月龍. 高校軟件測試課程教學改革研究[J]. 計算機教育， 2014，7：16-18.
[3]鄧松. 遞進式軟件測試創新人才培養模式研究[J]. 計算機教育， 2014，7：5-7.
[4]周雪妍， 林澤鴻， 羅秋濱， 路雯靖， 劉玉利. 軟件測試技術四面體培養模式的探索與研究[J]. 教學研究， 2013，5：56-58.
[5]張國平等. 軟件工程卓越培養計劃的研究與設計[C].軟件工程2011年會，2011，10.
[6]劉華東. 構建“三三三”培養體系 推進本科教育邁向更高目標[J]. 中國高等教育， 2012，18：34-36.
[7]吳春雷. 面向應用型軟件人才教學模式的探索與實踐[J].中國成人教育， 2014.04：124-126.
[8]張國平，吳春雷. 軟件工程專業核心課程案例化教材的規劃與設計[J].高等理科教育，2013.10：85-87.
關鍵詞： 探索性軟件測試； 嵌入式系統軟件測試； 基于會話的測試管理； 敏捷測試
中圖分類號： TN911?34； TP311.5 文獻標識碼： A 文章編號： 1004?373X（2014）20?0074?06
Exploratory software testing approaches and their application in embedded systems
LIU Xi
（Nanjing Research Institute of Electronics Technology， Nanjing 210039， China）
Abstract： To apply the exploratory testing technology to the software testing of embedded systems is one of the promising ways to solve the problems including tight schedule， heavy tasks and incomplete software documentations. Rigorous testing management process and documentation are usually required for testing embedded systems， which is however weakened in exploratory testing. In order to guide proper application of exploratory testing in embedded system software testing， it is necessary to survey and review exploratory testing technology， analyze the correlation and conflict between exploratory testing technology and software testing system of embedded systems. Based on the survey， some suggestions are given on the application model in software testing of embedded systems. The problems andfollow?up study concerning the application are also discussed.
Keywords： exploratory software testing； embedded system software testing； session?based testing management； agile testing
0 引 言
軟件在嵌入式系統中的作用越來越大。軟件的質量不僅直接影響任務的成敗，也關系著設備甚至人員的安全。隨著用戶對嵌入式系統軟件質量要求的提升，軟件測試已成為嵌入式系統交付前必不可少的環節[1]。
經典的測試方法要求依據軟件需求和設計文檔，遵循既定的測試流程，嚴格按照預先設計的“腳本”開展。因此經典測試方法也稱為腳本測試（Script Testing）。隨著嵌入式軟件迭代的加速，給軟件測試留出時間逐漸減少。嵌入式系統軟件測試呈現出一些新特點，包括軟件需求變化快、軟件文檔缺乏、軟件測試周期短、測試時間不足等。
探索性測試（Exploratory Testing）具有在時間短和文檔不完善的情況下，充分發揮測試人員的經驗和能力，快速、高質量完成軟件測試等優點。已形成了一套管理方法和應用模型[2?3]，并在微軟等多個企業開展了成功的實踐[3?5]。探索性測試方法關注于實用，對它的研究也多數集中在實際應用方法而不是理論研究上[3，6?8]。
探索性測試是解決嵌入式系統軟件測試需求變化快、軟件文檔缺乏、測試周期短等現實問題的可行手段之一。為了恰當運用，需要總結探索性測試的一般性應用方法體系，并探討其與嵌入式系統軟件測試體系的聯系和沖突。在此基礎上提出適用于嵌入式系統軟件測試的探索性測試應用模型。
1 探索性軟件測試的基本原理
探索性測試的概念形成較早，經過隨后的發展已形成了一定的應用體系。
1.1 探索性軟件測試的概念
傳統的軟件測試分為測試需求分析、測試策劃、測試用例設計、測試執行和測試總結等主要階段，依次開展[1]。傳統軟件測試流程依賴于完整、詳實的軟件需求和設計文檔作為輸入。而在現實的測試任務中，軟件需求和設計文檔往往有誤或不完備，這導致腳本測試活動無法正常有效開展。
“探索性測試是同時進行學習、測試設計和測試執行的一種測試方法；也就是說，測試沒有事先通過確定的測試計劃定義，而是動態地被設計、執行和修改”[9]。探索性測試（也稱為探索式測試）最早于1983年提出，并在實踐中發展 [10?11]。與傳統腳本測試相比，探索性測試具有以下技術特點：
（1） 測試活動的同時性。鼓勵在測試執行的過程中，同時進行對被測軟件的學習和測試設計。
（2） 關注測試任務。更關注于被測軟件本身和需要測試的問題。
（3） 測試中的演繹推理。通過前一個測試活動的結果來指導后期測試的開展。
（4） 利用人的優勢。關注于人本身的優勢，如判斷、分析、應變和協作的能力。
作為一種敏捷軟件測試方法，探索性測試弱化了對測試的預先設計和測試流程的嚴格要求，而強調測試的同時性以及人的經驗和創造性，關注于發現軟件缺陷，持續優化測試工作[12?13]。測試人員在測試?理解?再細化測試的迭代中，通過測試活動本身不斷深入學習被測軟件，從而能夠縮減測試準備時間，發現更多缺陷，并使得軟件測試可以在被測軟件說明或文檔不齊全的情況下開展[14]。
1.2 探索性軟件測試的主要方法
探索性測試的概念提出后，經過工業界和學術界人士的工作，已初步形成包含經驗運用、執行策略、管理模型的體系。
1.2.1 探索方法
探索性測試強調對測試人員的知識和經驗的運用。這些經驗和知識可分為領域知識、系統知識和一般的軟件工程知識[15]。領域知識指領域規則、客戶流程和操作場景等，包括用戶使用和具體應用領域知識。系統知識是關于待測軟件的特性和技術細節的具體知識，包括系統級的交互以及個體功能細節。一般的軟件工程知識即不需要對被測軟件系統和應用領域的具體知識。
豐富的知識和經驗是對探索性測試人員的基本要求，以此為基礎，探索性測試的發揮人的創造性，并由此增強了測試過程的適用性。從工程應用的實踐中，已總結出了一些有用的啟發式方法。運用這些策略和啟發式方法，可以幫助軟件測試人員在具備了基本的知識和經驗的情況下，盡快熟悉被測系統，并在測試過程中充分運用經驗和創造性。
在開展具體的測試活動時，測試人員則可以借助一些啟發式方法在測試活動中“探索”被測軟件。這些啟發式的方法是測試中為了發現可能的缺陷，測試人員常用的一些技巧 [16]。這其中典型的有Hendrickson的檢查單[17]以及Whittaker的漫游方法[3]。這些方法的共同特性是提醒測試人員：
（1） 應關注軟件最主要的功能，并在測試的過程中對軟件的行為進行聯想、質疑并發散，充分利用逆向輸入、邊界情況、近似值、錯誤輸入和特殊值（如0），通過軟件行為的原因、表現等舉一反三；
（2） 應刻意構造一些特殊的行為，如嘗試遍歷所有輸出、嘗試最長操作路徑、嘗試關注關鍵數據的演化、打散或集中事物、長時間運行軟件等；
（3） 應構造測試檢查軟件主要功能往往不關注的情景，例如啟動和退出、全選、空值、資源過量和緊張、取消操作、重復、同時運行等。
傳統方法假設軟件文檔中說明了軟件的各種預期行為，因而可以通過分析文檔來提取測試預期（Test Oracles）。然而，在軟件信息不完備的情況下，測試預期則無法提前預知。HICCUPPS的啟發式方法，從歷史（History）信息、顧客形象（Image）在軟件中的恰當映射、類似軟件的對照（Comparable Products）、與軟件和商業聲明（Claims）、用戶預期（User’s Expectations）、同類產品本身（the Product itself）、明顯的意圖（Purpose）和法律規章（Statutes）等角度，幫助測試人員在判定測試是否通過[14]。
1.2.2 管理模型
良好的測試管理模型是保證測試質量、提高測試效率的必要保障。基于會話的測試管理（SBTM）是探索性測試領域中最常用的管理實踐。SBTM將軟件測試活動分解為若干會話（Session）[2]。會話特征如下：
會話圍繞主旨（Charter）開展：即待測試的任務和目標；會話時間較短：時間長度在90 min左右；會話需要記錄：借助會話記錄單；每輪會話需要計劃和總結：一輪會話執行通常是一天，其中包含若干個會話測試。
基于會話的測試過程如圖1所示。當接到測試任務時，測試小組通過對測試任務進行分析討論，確定各會話的主旨。會話主旨包含被測軟件的主題、測試人員的角色、目的、條件、優先級、參考文檔、數據、思路、預期等信息[18]。測試項目負責人分配各會話測試人員，隨后開展首輪會話執行。一輪會話執行通常為一天。每輪會話執行結束后，需組織會話總結，主要借助以下維度進行：會話執行情況、筆記、缺陷、問題、數據、時間分解、人員安排等。通過總結確定下一輪會話、資源分配。下一輪會話執行按照相似的方式開展。在測試達到預期時間和充分度要求后，測試結束，并根據每輪會話報告單整理測試報告。
圖1 基于會話的測試管理示意圖
會話還可以根據需要進行擴展，例如可以包含對會話的風險評估和資源統計[4]，也可以將會話延伸為對特定問題的關注，形成測試的線索[19]。
1.3 探索性測試工具
探索性測試的有效開展同時依賴于工具的輔助。已有一些探索性測試的工具可供參考，例如Microsoft Test Manager（與Visual Studio組件），BBTestAssistant、TestExplorer，Session Tester，Rapid Reporter，Wink。這些工具通過基于錄制回放、截屏和輔助文字信息的方式幫助測試人員記錄探索性測試的執行過程，其中Session Tester、Rapid Reporter和Wink是免費的，Session Tester和Rapid Reporter則專門針對會話機制進行了設計和優化。
雖然這些基于錄制回放原理的工具能夠輔助測試人員整理測試報告，但是卻缺少對測試人員運用其知識和經驗的指導，對探索性測試的執行也缺少引導作用。目前沒有專門的探索性測試流程管理工具，不能起到控制測試流程的作用。有必要針對具體應用研發相應的輔助工具。
2 探索性測試的應用及其效果
經過發展，探索性測試已在多個企業運用。人們對探索性測試方法的優缺點也有了更加明確的認識。
2.1 探索性測試在工業界的應用
微軟是較早實踐探索性測試方法的軟件企業。微軟在Windows 2000系統徽標認證、必應搜索引擎和地圖、Visual Studio、Windows Media Player等系統、網絡和桌面應用中廣泛使用了探索性測試的技巧和方法，尤其是漫游探索法[3，7，20?21]。在其他公司，探索性測試也成功的運用于互聯網應用行業以及信息系統的軟件測試中。這些測試任務往往在軟件文檔不全、測試時間緊、企業對采用傳統的腳本測試流程不滿意的背景下開展，通過運用基于會話的方法，測試團隊都能夠高效的完成測試任務，甚至發現了采用傳統方法在類似項目中遺漏的缺陷，在系統上線后也沒有發生重大問題，軟件項目組對測試團隊的滿意度有提升[22?24]。
雖然可能沒有直接說明采用探索性測試，開源軟件的測試往往具有探索性測試的特點。這些測試往往在沒有詳細的軟件文檔和測試用例設計的基礎上，利用志愿測試人員的經驗和興趣開展 [25]。在敏捷軟件研發團隊中，探索性測試的方法也多有運用[26]。成功案例包括與XP和Scrum敏捷軟件開發的結合[5，27]。
除了在工業界的運用，也有學者對敏捷軟件測試的應用進行了系統的研究和討論。Itkonen等人在芬蘭多個軟件公司中研究了測試人員對探索性測試的使用方法、效果和評價[28]，對探索性測試的優缺點、應用條件合場景以及推薦的方法進行了總結[29]；通過研究和實驗，發現了探索性測試在缺陷檢測能力上能達到甚至超過傳統腳本測試的水平[6]。Naseer，史亮和高翔也總結了探索性軟件測試在瑞典軟件公司、國內的微軟和淘寶等企業運用的經驗，對探索性測試的活動進行了總結[8，10]。Bach等人還成立了公司專門從事測試方面的研究和推廣。另外，也有一些研究將探索性測試思想與測試自動化方法結合[30]，或利用探索性測試的思想提高測試效率和質量的工作[5]。
從目前的應用情況來看，探索性測試技術多數是在桌面應用、B/S架構信息系統等領域的應用，在嵌入式系統軟件測試中的應用較少。
2.2 探索性測試的優缺點
經過實踐，總結上述對探索性測試的應用，能夠發現，探索性測試尤其適用于要求在短時間內發現被測軟件一些重要缺陷或事先沒有能夠進行詳細測試設計的情況；但也具有測試過程不易控制、測試文檔不全等問題。因此，在具體領域中運用探索性測試技術時，有必要根據領域特性，設計適合的測試流程，揚長避短。
一般認為探索性測試的主要優點和缺點如下：
優點：便于利用人員經驗；適合于從用戶角度的測試；適用于缺少軟件文檔、測試時間緊情況；靈活且適應性強；對測試人員和開發人員的反饋較快；能夠為測試帶來新內容，降低“殺蟲劑”效應。
缺點：缺少足夠的文檔，不易度量覆蓋率；測試統計數據不足，不利于決策；對測試人員經驗要求較高；在測試人員經驗不足、管理不嚴格的情況下，可能會影響測試質量；如缺少恰當工具，則不利于缺陷復現。
3 探索性測試在嵌入式系統中的應用
探索性測試技術卻是能夠應對嵌入式系統軟件測試中軟件需求變化快、測試周期短、軟件文檔不全等現實問題的可行方法之一。本文首先分析探索性測試在嵌入式軟件測試中應用的需求和困難，然后探討探索性測試技術與嵌入式系統軟件測試體系的結合方法，對應用模型提出建議，并對應用中可能的問題和后續研究進行討論和展望。
3.1 探索性測試一般性方法的適用性
隨著IT技術的發展和各國在國防、智能電網、物聯網、智能手機等行業投入的加大，嵌入式軟件產品越來越多，測試任務越來越重，往往難以保證充裕的測試時間。軟件需求和開發文檔存在不準確、不完備的情況。而同時，嵌入式軟件的測試具有較強的領域特性，領域內測試人員對被測系統的經驗比較豐富。因此，需要也有條件在嵌入式系統軟件中開展探索性測試，以降低對軟件需求和設計規約的依賴、發揮探索性測試對軟件變化的適應性和充分利用測試人員經驗的優勢。
然而，探索性測試技術在嵌入式領域中的應用卻較少。探索性測試的通用方法沒有直接用于嵌入式系統軟件測試的原因主要是 [1，31?33]：
（1） 軟件測試文檔：探索性測試不鼓勵測試花費精力在策劃和準備上，而測試執行記錄風格隨意性較大，不利于形成統一、完備的測試文檔；這與按照國標和軍標中對完整的軟件測試文檔的要求沖突。
（2） 軟件測試充分性度量：不易度量測試覆蓋率，不易評價測試質量。
（3） 軟件測試過程控制：缺少對配置和測試流程的系統性管理，可能造成測試過程失控。
3.2 探索性測試應用模型探討
為了解決嵌入式系統測試中軟件需求變化快、測試周期短、軟件文檔不完備等現實問題，有必借鑒探索性測試技術在信息系統、網絡應用、操作系統等方面的成功經驗，將其融入嵌入式系統軟件測試體系中來[24，34]。為了與相應的軟件測評體系和標準匹配，必須對探索性測試通用方法進行調整，設計探索性測試在嵌入式系統軟件測試的應用模型。
一種可參考的“腳本會話模型”如圖2所示，是以探索性測試一般性理論、探索性測試各特性在各型產品軟件的適用性研究為基礎，將探索性測試與傳統腳本測試相結合的軟件測試模型。為充分利用兩者的優勢，腳本會話模型的整體仍以傳統腳本方法為基礎，從而利用腳本測試管理中測試文檔完備和過程管理控制完善等優點，而在測試執行過程中充分發揮探索性測試的靈活、高效優點，引入會話、漫游測試法等探索性測試等方法，同時借助嵌入式系統軟件測試典型數據復用庫來實現對測試人員經驗的固化和復用。
圖2 嵌入式系統軟件腳本會話測試模型
如圖3所示，腳本會話模型整體流程遵循經典的腳本測試流程，但發揮了探索性測試對經驗的利用和靈活性的特點。
圖3 腳本會話測試模型流程框架
包含以下步驟：
（1） 測試策劃和設計階段；借助領域軟件測試典型數據復用庫（測試人員經驗的固化體現）形成測試項、構造測試用例，降低對軟件需求和設計文檔的依賴，初步完成測試需求的提取和測試用例的設計。
（2） 測試執行階段：測試執行以基于會話的方式開展，并對一般會話進行擴展。根據測試設計和計劃，確定每個會話的主旨、用例和測試方法。在每一次會話中，測試人員可以結對開展測試執行，根據預先指定的漫游策略和啟發式方法，針對一個測試項進行探索，并補充測試用例。測試人員在會話結束后整理會話記錄單。根據本輪會話執行情況，記錄缺陷、改善測試設計，并準備下一輪會話。如此迭代直到測試結束條件滿足，測試執行結束[35]。
（3） 測試總結階段：借助測試執行中各個會話報告單，總結和報告缺陷。
3.3 討論和展望
探索性測試在互聯網和桌面應用已經成功實踐[34]，而在嵌入式領域應用仍然較少。在嵌入式系統軟件測試中運用諸如腳本會話模型的探索性測試技術時，應注意以下三點問題：
（1） 測試過程管理和文檔。必須重視探索性測試的過程管理以保證測試過程受控。同時在適當的階段應編寫相應文檔作為測試階段性成果，并在測試執行完成后更新相應文檔。
（2） 結合具體領域。具體領域的軟件測試典型數據復用庫可以看作是對該領域軟件測試人員測試經驗的固化，是軟件測試團隊的組織資產，有助于團隊新成員快速熟悉被測系統，提高探索性測試的效率。
（3） 針對測試團隊和項目制定具體策略。制定探索性測試中的典型方法的應用策略，并注意收集反饋，在實踐中持續改進。
探索性測試作為一種在互聯網、操作系統等領域成功運用多年的測試技術和理念，可以與其他軟件測試技術結合，共同推進嵌入式軟件測試質量的提升。可能的結合方向包括（但不限于）：
（1） 基于模型的測試和驗證。借助軟件模型可發現隱藏在軟件界面和正常使用流程下的交互，其中可能隱藏了大量的缺陷；借助模型檢驗工具提供的反例[36]，測試人員還可以對軟件進行更加深入的探索；
（2） 測試自動化。嵌入式系統軟件需要處理傳感器送來的大量數據，采用自動化方法能夠有效減少測試人員的工作量；結合探索性測試的技術，也能夠為測試用例約簡和測試預期問題提供解決途徑[34，37?39]；
基于剖面的測試：構造嵌入式系統的操作剖面和用戶剖面，輔助測試人員能有選擇性地對系統進行探索[40??41]。
4 結 語
探索性測試技術經過研究和發展，已形成了一套可行的體系。探索性測試在嵌入式系統軟件測試中的應用還較少。經過對探索性測試體系的全面研究，能夠更好的理解這種方法在嵌入式系統軟件測試中的適用性，并為融合探索性測試與傳統嵌入式軟件測試方法，形成適用于嵌入式系統軟件測試的探索性測試應用模型提供思路和方向。
參考文獻
[1] 康一梅，張永革，李志軍，等.嵌入式軟件測試[M].北京：機械工業出版社，2008.
[2] BACH J. Session?based test management [J]. Software Testing and Quality Engineering， 2000， 2（6）： 1?4.
[3] WHITTAKER J A.探索式軟件測試[M].北京：清華大學出版社，2010.
[4] LYNDSAY J， VAN EEDEN N. Adventures in session?based testing [EB/OL]. [2002?08?02]. http：///articl.
[5] TUOMIKOSKI J， TERVONEN I. Absorbing software testing into the scrum method [J]. Lecture Notes in Business Information Processing， 2009， 32： 199?215.
[6] ITKONEN J， MANTYLA M V， LASSENIUS C. Defect detection efficiency： Test case based vs. exploratory testing [C]// Proceedings of International Symposium on Empirical Software Engineering and Measurement （ESEM）. [S.l.]： [s.n.]， 2007： 61?70.
[7] BACH J. General functionality and stability test procedure for certified for Microsoft Windows logo [R/OL]. [1999?08?22]. http：///tools/procedure.pdf.
[8] NASEER A， ZULFIQAR M. Investigating exploratory testing in industrial practice [D]. Ronneby： Blekinge Institute of Technology， 2010.
[9] BOURQUE P， FAIRLEY R E. Guide to the software engineering body of knowledge， version 3.0 [R/OL]. [2013?03?13].. http：// /p?1714.
[10] KANER C， FALK J， NGUYEN H Q. Testing computer software， second edition [M]. New York： John Wiley & Sons， Inc.， 1999.
[11] KANER C， BACH J， PETTICHORD B. Lessons learned in software testing[M]. New York： John Wiley & Sons， Inc.， 2002.
[12] FOWLER M， HIGHSMITH J. The agile manifesto [J]. Software Development， 2001， 9（8）： 28?32.
[13] COCKBURN A. Agile software development [M]. [S.l.]： Addison?Wesley， 2002.
[14] BOLTON M. Testing without a map [J/OL]. [2011?07?18]. http：// /1137978.
[15] ITKONEN J， MANTYLA M V， LASSENIUS C. The role of the tester's knowledge in exploratory software testing [J]. IEEE Transactions on Software Engineering， 2013， 39（5）： 707?724.
[16] KANER C. A Tutorial in exploratory testing [R]. Chicago： QAI QUEST Conference， 2008.
[17] HENDRICKSON E. Explore It！： Reduce risk and increase confidence with exploratory testing [M]. [S.l.]： The Pragmatic Programmers， 2013.
[18] CLAESSON A. How to perform exploratory testing by using test charters [R]. Swedish： Swedish Association for Software Testing （SAST）， 2007.
[19] BACH J. Introducing thread?based test management [R/OL]. [2010?11?26]. http：///blog/archives/503.
[20] ROBINSON H. Explorer test automation [C]// Proceedings of the Conference for the Advancement of Science Teaching （CAST）. [S.l.]： [s.n.]， 2010： 11?21.
[21] ROBINSON H. Using simple automation to test complex software [C]// Proceedings of Annual Pacific NW Software Quality Conference. [S.l.]： PNSQC， 2010： 123?132.
[22] V?GA J， AMLAND S. Managing high?speed web testing [C]// Software Quality and Software Testing in Internet Times. [S.l.]： Springer?Verlag， 2002： 23?30.
[23] WOOD B， JAMES D. Applying session?based testing to medical software [J]. Medical Device & Diagnostic Industry， 2003， 25（5）： 90?96.
[24] 柳溪，馬康，劉智.融合探索性與腳本方法的第三方軟件測試模型及其應用[J].信息化研究，2013，39（6）：43?48.
[25] ABERDOUR M. Achieving quality in open source software [J]. IEEE Software， 2007， 24（1）： 58?64.
[26] KASURINEN J， TAIPALE O， SMOLANDER K. Test case selection and prioritization： risk?based or design?based？ [C]// Proceedings of the International Symposium on Empirical Software Engineering and Measurement. [S.l.]： [s.n.]， 2010： 234?242.
[27] MARTIN D， ROOKSBY J， ROUNCEFIELD M， et al. Good' organisational reasons for 'bad' software testing： an ethnographic study of testing in a small software company [C]// Proceedings of International Conference on Software Engineering. [S.l.]： ICSE）， 2007： 602?611.
[28] ITKONEN J， RAUTIAINEN K. Exploratory testing： a multiple case study [C]// Proceedings of International Symposium on Empirical Software Engineering. [S.l.]： [s.n.]， 2005： 1?8.
[29] ITKONEN J， MANTYLA M V， LASSENIUS C. How do testers do it？ An exploratory study on manual testing practices [C]// Proceedings of the International Symposium on Empirical Software Engineering and Measurement. [S.l.]： ESEM， 2009： 494?497.
[30] HELLMANN T D， MAURER F. Rule?based exploratory testing of graphical user interfaces [C]// Proceedings of Agile Conference. [S.l.]： AGILE， 2011： 107?116.
[31] 中華人民共和國國家質量監督檢驗檢疫總局.GB/T 25000.51?2010軟件工程 軟件產品質量要求與評價（SQuaRE）SQuaRE指南[S].北京：中國標準出版社，2010.
[32] 中華人民共和國國家質量監督檢驗檢疫總局.GB/T 8567?2006計算機軟件文檔編制規范[S].北京：中國標準出版社， 2006.
[33] 中華人民共和國國家質量監督檢驗檢疫總局.GB/T 9386?2008 計算機軟件測試文檔編制規范[S].北京：中國標準出版社，2006.
[34] 史亮，高翔.探索式測試實踐之路[M].北京：電子工業出版社，2012.
[35] KANER C， BACH J. Exploratory testing in pairs [R/OL]. [2001?08?22]. http：///a/pairs.pdf.
[36] CLARKE E M， GRUMBERG O， PELED D A. Model checking [M]. [S.l.]： The MIT Press， 2000.
[37] DUSTIN E， RASHKA J， PAUL J. Automated software testing [M]. [S.l.]： Addison?Wesley Professional， 1999.
[38] FEWSTER M， GRAHAM D. Software test automation [M]. [S.l.]： Addison?Wesley Professional， 1999.
[39] KANER C. Architectures of test automation [R/OL]. [2000?09?28]. http：///pdfs/testarch.pdf.
[40] BUWALDA H. Soap opera testing [J/OL]. [2011?04?11]. http：///link？u...