時間：2023-02-03 16:58:47
導(dǎo)語：在軟件測試項目總結(jié)的撰寫旅程中，學(xué)習(xí)并吸收他人佳作的精髓是一條寶貴的路徑，好期刊匯集了九篇優(yōu)秀范文，愿這些內(nèi)容能夠啟發(fā)您的創(chuàng)作靈感，引領(lǐng)您探索更多的創(chuàng)作可能。
關(guān)鍵字：軟件；測試過程；管理
軟件開發(fā)過程的質(zhì)量決定軟件的質(zhì)量，軟件測試過程的質(zhì)量直接影響測試結(jié)果的準(zhǔn)確性和有效性。
1 軟件測試過程常用的模型
1、V模型
V模型反映出測試活動與分析設(shè)計活動的關(guān)系，指出單元測試和集成測試應(yīng)檢測程序的執(zhí)行是否滿足軟件設(shè)計的要求。系統(tǒng)測試應(yīng)檢測系統(tǒng)功能、性能的質(zhì)量特性是否達(dá)到系統(tǒng)要求的指標(biāo)。驗收測試確定軟件的實現(xiàn)是否滿足用戶需求或合同的要求。
2、W模型
W模型指出軟件各開發(fā)階段中應(yīng)同步進(jìn)行的驗證和確認(rèn)活動，即測試與開發(fā)也應(yīng)是同步進(jìn)行的。W模型有利于盡早和全面的發(fā)現(xiàn)問題。
3、H模型
V模型與W模型有不妥，即它們都把軟件的開發(fā)視為需求、設(shè)計和編碼等一系列串行的活動，而事實上，這些活動可以交叉進(jìn)行的。H模型揭示這一點：軟件測試是一個獨立的流程，貫穿于產(chǎn)品的整個生命周期中，與其他流程并發(fā)進(jìn)行。
除了上面的幾種常見模型外，還有X模型、前置測試模型等。在實踐中，建議以W模型作為框架，及早全面地開展測試，同時靈活運用H模型獨立測試的思想，在達(dá)到恰當(dāng)?shù)木途w點時就應(yīng)該開展獨立的測試工作，同時將測試工作進(jìn)行迭代，最終保證完成測試目標(biāo)。
2 測試階段中的測試活動
軟件測試過程主要包括以下四項基本活動：
1、測試策劃
在測試策劃中的活動有：制定測試計劃，以確定測試范圍、測試策略和測試方法，規(guī)劃測試任務(wù)日程表，對測試資源進(jìn)行安排，并提前評估測試風(fēng)險，制定風(fēng)險控制策略。
2、測試設(shè)計與實現(xiàn)
在測試設(shè)計與實現(xiàn)中的活動有：制定測試的技術(shù)方案，選擇測試工具，并根據(jù)測試技術(shù)方案設(shè)計測試用例。
3、測試執(zhí)行
在測試執(zhí)行中的活動有：建立相關(guān)測試環(huán)境、配置測試數(shù)據(jù)、按日程安排執(zhí)行測試用例并記錄測試執(zhí)行結(jié)果，對發(fā)現(xiàn)的軟件缺陷進(jìn)行報告，并配合開發(fā)人員進(jìn)行軟件缺陷的分析、處理和追蹤。
4、測試總結(jié)
在測試總結(jié)中的活動有：對測試結(jié)果進(jìn)行綜合分析，以確定軟件產(chǎn)品質(zhì)量的當(dāng)前狀態(tài)，為產(chǎn)品的改進(jìn)和提供數(shù)據(jù)和依據(jù)，同時編制測試報告，提交相關(guān)的測試文檔。
3 軟件測試過程管理的特點
軟件測試過程管理的基本內(nèi)容包括計劃、組織和監(jiān)控；測試過程中存在的問題有：
1.軟件質(zhì)量標(biāo)準(zhǔn)定義不準(zhǔn)確、任務(wù)邊界模糊。
2.軟件測試項目的變化控制和預(yù)警分析要求高。
3.軟件測試項目具有智力密集，勞動密集的特點，受人力資源的影響最大。
4.測試任務(wù)的分配比較困難。
5.測試要求的人力資源十分穩(wěn)定。
6.軟件測試人員在待遇、地位上可能會受到一些不公平的待遇。
軟件測試項目的過程管理能否成功，通常受到三方面的影響：項目組內(nèi)的環(huán)境，項目所處的組織環(huán)境，整個開發(fā)流程所控制的全局環(huán)境。
4 軟件測試過程管理的原則
1、有關(guān)測試需求，應(yīng)當(dāng)有一個經(jīng)各方同意的、完整的、清楚的、詳細(xì)的、整體的、可實現(xiàn)的和可測試性的需求并文檔化，盡可能堅持最初的需求。
2、測試計劃先行。軟件項目管理過程從項目的計劃活動開始，軟件測試項目也不例外，也是從測試計劃開始。
3、建立任務(wù)優(yōu)先級。在測試任務(wù)較多的情況下，應(yīng)該為各項任務(wù)建立測試優(yōu)先級，這樣也可以根據(jù)優(yōu)先級來先后處理各項任務(wù)。
4、建立客觀的評估標(biāo)準(zhǔn)。這樣使得整個項目過程具有良好的可測性和可跟蹤性，強(qiáng)調(diào)以數(shù)據(jù)說話。
5、盡早測試。這是從W模型中抽象出來的理念。一方面指測試人員盡早參與測試項目，另一方面指盡早開展測試執(zhí)行任務(wù)。
6、全面測試。這也是W模型的重要思想，其含義一方面只要對軟件所有產(chǎn)品進(jìn)行全面的測試；另一方面指軟件開發(fā)人員與測試人員全面參與到測試工作中。
7、全過程測試。這是從W模型中抽象出來的另一理念。其含義一方面指測試人員要充分關(guān)注開發(fā)過程；另一方面指測試人員要對測試的全過程進(jìn)行全程的跟蹤。
8、獨立的、迭代的測試。這是H模型的重要思想，強(qiáng)調(diào)只要達(dá)到測試就緒點，即測試條件成熟，測試準(zhǔn)備活動完成，測試執(zhí)行活動就可以開展。
5 軟件測試過程的人員組織
測試團(tuán)隊的組織直接關(guān)系到測試團(tuán)隊的工作效率和生產(chǎn)力，其組織方式由測試團(tuán)隊的規(guī)模、具體任務(wù)和技術(shù)來決定。
一個測試團(tuán)隊的基本角色有：測試經(jīng)理、實驗室管理人員、內(nèi)審員、測試組長、測試設(shè)計人員、資深測試工程師、一般測試工程師。
若測試團(tuán)隊規(guī)模較大，則測試工程師分為三個層次：初級測試工程師、測試工程師和資深測試工程師，同時設(shè)置自動化測試工程師、系統(tǒng)測試工程師和架構(gòu)工程師。
測試過程人員組織的一個方面是考慮測試團(tuán)隊的規(guī)模，測試團(tuán)隊的規(guī)?？梢钥紤]在整個開發(fā)部門所占的比重，或相對開發(fā)人員所占的比例。從經(jīng)驗看，不同的應(yīng)用，軟件測試和軟件開發(fā)人員的比例也是不同的，大致可分為三類。
1、操作系統(tǒng)類型的產(chǎn)品，對測試要求最高，測試人員和開發(fā)人員的比例為2：1。
2、應(yīng)用平臺、支持系統(tǒng)類型的產(chǎn)品，對測試要求比較高，通常測試人員和開發(fā)人員的比例為1：1。
3、對于特定應(yīng)用系統(tǒng)一類產(chǎn)品，由于以后對象清楚、范圍小，甚至可對應(yīng)用平臺或應(yīng)用環(huán)境加以限制，所以測試人員可以再減少，但測試人員和開發(fā)人員的比例至少保證在1：2的水平以上。
6 結(jié)束語
相比之下，目前中國軟件企業(yè)在軟件測試方面與國際水準(zhǔn)仍存在較大差距。首先，在認(rèn)識上重開發(fā)、輕測試，沒有認(rèn)識到軟件項目的如期完成不僅取決于開發(fā)人員，更取決于測試人員；其次，在管理上隨意、簡單，沒有建立有效、規(guī)范的軟件測試管理體系；另外，缺少自動化工具的支持，大多數(shù)企業(yè)在軟件測試時并沒有采用軟件測試管理系統(tǒng)。所以對國內(nèi)軟件企業(yè)來說，不僅要提高對軟件測試過程管理的認(rèn)識，同時要建立起完善的軟件測試過程管理體系，確保軟件測試管理在軟件質(zhì)量保證中發(fā)揮應(yīng)有的關(guān)鍵作用。
參考文獻(xiàn)
[1]朱少民. 軟件測試方法和技術(shù) [M].北京：清華大學(xué)出版社， 2005年
[2]鄭文強(qiáng)，馬均長. 軟件測試管理[M].北京：電子工業(yè)出版社， 2010年
[3]布萊克（美）.軟件測試過車管理[M].北京：機(jī)械工業(yè)出版社，2003年
關(guān)鍵詞：軟件測試管理；測試團(tuán)隊；測試過程；事件管理；配置管理
中圖分類號：TP311 文獻(xiàn)標(biāo)識碼：A 文章編號：1674-7712 （2013） 04-0075-01
一、引言
現(xiàn)在，軟件測試已經(jīng)成為一個很有潛力的專業(yè)，軟件測試可以提高質(zhì)量，降低維護(hù)成本。
對于大型相對復(fù)雜的軟件項目，做好軟件測試就會相對困難，因此，為了盡可能提高軟件質(zhì)量，減少錯誤，必須有效對測試工作進(jìn)行計劃和管理。
要想對測試工作進(jìn)行有效策劃和管理，需要采取系統(tǒng)的方法建立軟件測試管理體系，對測試活動進(jìn)行監(jiān)管和控制，以確保軟件測試在軟件質(zhì)量保證中發(fā)揮應(yīng)有的關(guān)鍵作用。
二、建立測試管理體系
軟件測試的過程及應(yīng)用即測試規(guī)劃，設(shè)計，執(zhí)行，配置與資源管理，缺陷管理等。從項目管理的角度來說，這些過程里，前一過程的輸出是后一過程的輸入。其中，配置與資源管理是這些過程的支持，測試管理對其他測試過程進(jìn)行監(jiān)視、測試和管理
三、測試管理過程和基本內(nèi)容
（一）測試團(tuán)隊管理
做好軟件測試需要一個獨立的團(tuán)隊，測試團(tuán)隊獨立于開發(fā)團(tuán)隊之外去做測試工作，可以更加公正的進(jìn)行測試。雖然測試人員可能需要花時間去熟悉被測對象然后才能設(shè)計出測試用例，但是測試人員具備了專業(yè)的測試?yán)砟詈驮O(shè)計技術(shù)，而這些測試技術(shù)是一個開發(fā)人員所沒有的或測試前必須花時間去學(xué)習(xí)掌握的。
測試團(tuán)隊管理的主要任務(wù)：確定測試隊伍的組織模式，確定測試需求和組織測試設(shè)計，估計測試工作量，安排測試任務(wù)，確定應(yīng)交付的測試文檔，管理測試工具。
（二）測試過程管理
軟件測試貫穿于軟件開發(fā)整個生命周期，在軟件開發(fā)的每一個階段，都有相對應(yīng)的測試任務(wù)，從計劃、設(shè)計、執(zhí)行到缺陷管理、總結(jié)等步驟，構(gòu)成了一個測試過程。（如圖1）
因此，軟件測試過程管理主要集中在測試準(zhǔn)備、測試計劃、測試用例設(shè)計、測試執(zhí)行、測試結(jié)果分析，以及如何開發(fā)和使用測試過程管理工具上。
（三）資源和配置管理
1.資源管理包括人力資源和環(huán)境資源
人力資源：測試人員的數(shù)量及其測試技能，在測試的各個階段中對人員和技能要求不同。
環(huán)境資源：建立測試環(huán)境所需要的計算機(jī)軟件資源和硬件資源。硬件提供了一個支持操作系統(tǒng)、應(yīng)用系統(tǒng)和測試工具等運行的基本平臺，軟件資源則包括操作系統(tǒng)、第三方軟件產(chǎn)品、測試工具等。
2.配置管理
配置管理是是指通過執(zhí)行版本控制、變更控制等規(guī)程，以及使用合適的配置管理軟件，來保證所有配置項的完整性和可跟蹤性。配置管理是對工作成果的一種有效保護(hù)。
（四）事件（缺陷）管理
事件即缺陷管理，為了有效地管理缺陷（事件），在項目內(nèi)應(yīng)該引入規(guī)范、高效的缺陷（事件）管理系統(tǒng)。
軟件測試的任務(wù)就是尋找缺陷，缺陷從被發(fā)現(xiàn)、分析、修改，到修改的確認(rèn)形成了一個缺陷的生命周期（lifecycle）。在缺陷周期內(nèi)要對缺陷進(jìn)行跟蹤。缺陷可能會在開發(fā)過程中被發(fā)現(xiàn)，也可能在評審和測試過程中發(fā)現(xiàn)，甚至在系統(tǒng)最后使用過程還會發(fā)現(xiàn)缺陷。缺陷可能在代碼內(nèi)、在運行的系統(tǒng)中、也可能在各種文檔內(nèi)。缺陷與軟件的版本、運行的環(huán)境有關(guān)。缺陷與人員有關(guān)：測試員、開發(fā)人員、管理者和客戶等
四、總結(jié)與展望
測試管理涉及的范圍非常廣泛，如測試組織管理、測試過程管理、事件管理、人力資源與配置管理、風(fēng)險管理、進(jìn)度管理等。軟件測試貫穿于軟件開發(fā)整個生命周期，軟件開發(fā)周期模型為我們提供了軟件測試的流程和方法，為測試過程管理提供了依據(jù)。但實際的測試工作是復(fù)雜而煩瑣的，不會有哪種模型完全適用于某項測試工作。因此，在實際工作中，我們要考慮實際情況靈活地運用測試過程管理理念，依據(jù)這些理念來策劃測試過程，以不變應(yīng)萬變。
參考文獻(xiàn)：
[1]楊小平，王勝開.面向?qū)ο筌浖y試探討[J].計算機(jī)科學(xué)，2009，36（11）.
[2]王文東，耿國華，張根耀.軟件可靠性保證與評測技術(shù)[J].微機(jī)發(fā)展，2004（11）.
[3]葉言苓，崔彥軍.軟件測試管理的研究與應(yīng)用[J].計算機(jī)應(yīng)用與軟件，2003（09）.
關(guān)鍵詞：軟件測試；企業(yè)需求；教學(xué)方法
中圖分類號：TP311.53—4 文獻(xiàn)標(biāo)識碼：A 文章編號：1007—9599 （2012） 14—0000—02
隨著軟件產(chǎn)業(yè)迅速發(fā)展，軟件產(chǎn)品的質(zhì)量成為人們共同關(guān)注的焦點，軟件測試的作用和地位越來越顯得突出，它是軟件產(chǎn)品質(zhì)量控制的具體實現(xiàn)環(huán)節(jié)及其根本保證[1]，社會對軟件測試人才的需求量劇增，對軟件測試人員的綜合素質(zhì)要求也越來越高。
但由于我國的軟件測試技術(shù)起步比較晚，并由于主客觀方面的種種原因，在大學(xué)計算機(jī)教育中，軟件測試教育存在很多問題，無法達(dá)到《軟件測試》課程教學(xué)的目的和要求，也無法滿足業(yè)界對軟件測試人才的需求。
一、教學(xué)現(xiàn)狀
在目前的教學(xué)環(huán)境中，雖然《軟件測試》是一門理論性和實踐性都很強(qiáng)的專業(yè)課，但大多數(shù)院校在教學(xué)過程中，仍會忽視強(qiáng)調(diào)測試?yán)碚摵拖嚓P(guān)基礎(chǔ)的重要性。在理論教學(xué)過程中，不重視測試的基礎(chǔ)教學(xué)，在培養(yǎng)過程中更多地停留在知識傳授，忽視軟件測試職業(yè)素質(zhì)的培養(yǎng)，實際上，一個合格的測試人員除了具備測試專業(yè)知識外，嚴(yán)謹(jǐn)?shù)墓ぷ髁?xí)慣、良好的溝通能力和團(tuán)隊合作精神也是軟件測試人員所必需的[2]。在實驗教學(xué)過程中，一味依賴教材的理論內(nèi)容，忽略思考的智力技能培養(yǎng)，所設(shè)計的實驗內(nèi)容不符合現(xiàn)實需求，軟件測試的實踐教學(xué)存在同社會脫節(jié)。在教學(xué)方法方面，傳統(tǒng)教學(xué)方法形式單一，學(xué)生學(xué)習(xí)興趣很低，自主學(xué)習(xí)能力較低。本文針對教學(xué)過程中理論教學(xué)、實踐教學(xué)、教學(xué)方法三個方面，對軟件測試人才的培養(yǎng)總結(jié)一些思考和心得。
二、思考和實踐
（一）重視并滲透理論教學(xué)
重視軟件測試課程的理論教學(xué)，基礎(chǔ)的扎實與否直接影響了能力的可持續(xù)發(fā)展性。在制定課程大綱時，加大理論課時的分配，使學(xué)生從根本上認(rèn)識到理論在課程學(xué)習(xí)中的重要性，不再簡單的認(rèn)為軟件測試只是簡單的“點擊”等操作，而是一門對思考和邏輯要求很高的課程。好的軟件測試人員擁有高敏感能力，高發(fā)散能力，高分析能力，而這些都是以扎實的理論基礎(chǔ)為前提的。并在教學(xué)過程中，不僅僅以教材為理論傳授基準(zhǔn)，應(yīng)結(jié)合項目中的實際測試場景和案例，加深對各個理論點的理解和運用，以樹型結(jié)構(gòu)串聯(lián)零散的知識點，注重知識的內(nèi)部體系結(jié)構(gòu)，使學(xué)生系統(tǒng)的掌握測試的理論知識，鍛煉思維發(fā)散和思考能力，從而引導(dǎo)學(xué)生對知識和技能進(jìn)行舉一反三、觸類旁通的遷移。
將軟件測試的思想深入廣泛地滲透到所有的專業(yè)課程中。例如在各類程序設(shè)計語言基礎(chǔ)課程中引入單元測試的思想，在軟件工程課程中，強(qiáng)調(diào)軟件測試的重要性，增強(qiáng)軟件質(zhì)量管理意識，在面向?qū)ο蟮姆治龊驮O(shè)計課程中，強(qiáng)調(diào)測試和開發(fā)并行并重的思想[3]。
（二）以企業(yè)需求作為實驗教學(xué)的目標(biāo)
1.以企業(yè)項目為教學(xué)內(nèi)容
在傳統(tǒng)教學(xué)中，軟件測試實驗的內(nèi)容通常只單純的利用教材上介紹的不同測試方法來“設(shè)計”實驗，所設(shè)計的實驗內(nèi)容泛泛化，不僅不符合企業(yè)的需求，而且不符合項目測試中的完整性和規(guī)范化。在實際工作中，一個項目中所涉及到的測試技術(shù)和方法，以及這些技術(shù)的重難點，都很難在現(xiàn)有的實驗教材中得以體現(xiàn)。而以項目為實驗教學(xué)的方法，是以企業(yè)的需求和實踐流程為出發(fā)點，在實驗的教學(xué)過程中以項目為主線展開，以測試的流程由淺入深，把相關(guān)知識點融入到項目的各個環(huán)節(jié)中去，將項目完整的進(jìn)行剖析，循序漸進(jìn)[3]。
2.重視文檔和流程
在企業(yè)的實際測試工作中，文檔是非常重要的。我們以一個符合現(xiàn)實性的完整B/S模式的“圖書管理系統(tǒng)”作為測試案例，該項目涵蓋課程的主要知識要點和基本技能，項目大小和難易適中，提供給學(xué)生系統(tǒng)的代碼、需求分析、概要設(shè)計書、詳細(xì)設(shè)計書等必須文檔[4]，只有具備以上資料，才可真實的模擬實際工作模式。通過文檔，使得學(xué)生明白所測軟件提供什么功能？是否符合用戶的需求，設(shè)計是否合理，結(jié)果與設(shè)計是否一致，通過文檔，使得學(xué)生一邊熟悉系統(tǒng)一邊思考軟件研發(fā)者在設(shè)計過程中的遺漏點。文檔，不僅是測試人員與開發(fā)人員之間溝通的直接橋梁，而且這種彼此的不斷溝通以及思考，直接影響了軟件測試的最終質(zhì)量。同時，除了以項目為教學(xué)的基本單位，并強(qiáng)調(diào)文檔在項目中的重要性，還要嚴(yán)格按照工作中的實際情況，將學(xué)生分成若干個項目組。項目組分別設(shè)置測試經(jīng)理、測試負(fù)責(zé)人、測試組員等角色，各盡其責(zé)。這種強(qiáng)調(diào)文檔，各盡其責(zé)的項目教學(xué)方式，更加符合企業(yè)的實際需求，并有效鍛煉了學(xué)生的團(tuán)隊合作能力。
關(guān)鍵詞：CDIO；軟件測試；教學(xué)改革；分組教學(xué)
中圖分類號：TP393 文獻(xiàn)標(biāo)識碼：A 文章編號：1009-3044（2014）03-0670-03
1 概述
軟件測試技術(shù)是高職軟件技術(shù)專業(yè)的一門必修的專業(yè)核心課程。該課程是針對軟件測試員/程序員崗位的任職要求所設(shè)置的具有綜合性質(zhì)的課程，主要任務(wù)是通過對軟件測試基礎(chǔ)理論、技術(shù)方法、流程管理和使用自動化工具實施項目測試的學(xué)習(xí)，使學(xué)生了解完整的軟件測試的工作過程，能對完整的項目進(jìn)行測試的實施工作，從而實現(xiàn)與測試技能要求的無縫對接。但是筆者通過幾年的教學(xué)發(fā)現(xiàn)，很多同學(xué)學(xué)完這門課程后只是了解了軟件測試方面的相關(guān)知識，根本就不能夠綜合運用這些知識進(jìn)行實際項目的測試工作。筆者通過分析總結(jié)認(rèn)為最主要的原因是我們教學(xué)的過程中沒有采用工程的思想，使得學(xué)生不能有效地把這些知識碎片整合到一起，當(dāng)然就不能談不上實際應(yīng)用能力。
CDIO模式作為近年來國際工程教育改革的最新成果，它是“做中學(xué)”和“基于項目教育和學(xué)習(xí)”的集中概括和抽象表達(dá)，它以工程項目從研發(fā)到運行的生命周期為載體，讓學(xué)生以主動的、實踐的、課程之間有機(jī)聯(lián)系的方式學(xué)習(xí)工程[1-2]。無錫商業(yè)職業(yè)技術(shù)學(xué)院軟件技術(shù)專業(yè)結(jié)合自身的實際情況，對基于CDIO模式的高職軟件技術(shù)人才培養(yǎng)方案進(jìn)行了初步探索。軟件測試技術(shù)作為軟件技術(shù)專業(yè)的專業(yè)核心課程之一，在CDIO工程教育模式的指導(dǎo)下進(jìn)行一系列的教學(xué)實踐應(yīng)用，取得了很好的效果。
2 傳統(tǒng)教學(xué)模式存在的問題
現(xiàn)代IT企業(yè)需要具有較高專業(yè)技能、職業(yè)素質(zhì)和團(tuán)隊協(xié)作能力的實用復(fù)合型人才[3]，但
高職院校軟件專業(yè)培養(yǎng)出來的人才普遍只是掌握了相關(guān)的知識，而不能有效的利用這些知識進(jìn)行實踐應(yīng)用。為了解決這個問題，各個院校的軟件技術(shù)專業(yè)都一直在嘗試探索更好的人才培養(yǎng)方案[4]，主要的專業(yè)課程也在進(jìn)行各種各樣的教學(xué)改革[5]。因此，幾年來，“實踐教學(xué)”、“案例教學(xué)”、“情景教學(xué)法”等等教學(xué)模式進(jìn)行了進(jìn)一步的應(yīng)用，但是在這些傳統(tǒng)的教學(xué)模式下，還是存在一些問題。軟件測試技術(shù)課程也是如此，存在的問題主要有以下幾個方面：
（1） 實踐教學(xué)死板化。各個院校的軟件技術(shù)專業(yè)在人才培養(yǎng)方案的制定中，都明確規(guī)定了課程的實踐教學(xué)環(huán)節(jié)，體現(xiàn)了對實踐教學(xué)的重視。以作者所在專業(yè)為例，規(guī)定專業(yè)課程的實踐課時比例至少達(dá)到50%。但是在實際教學(xué)中，實踐教學(xué)一般都是教師通過案例先講解演示，學(xué)生再模仿訓(xùn)練，總體還是采用填鴨式的教學(xué)方式，因此造成學(xué)生一開始還表現(xiàn)強(qiáng)烈的新奇感，對課程學(xué)習(xí)充滿著動力和信心，但是由于無法真正調(diào)動學(xué)生的主觀能動性，隨著教學(xué)的推進(jìn)，學(xué)生逐漸失去學(xué)習(xí)興趣，后面的實踐訓(xùn)練只能是敷衍了事。并且，由于課堂教學(xué)課時的限制，實訓(xùn)機(jī)制死板、不健全，使得學(xué)生的真正動手機(jī)會還是很少。
（2） 項目教學(xué)虛擬化。教學(xué)過程中，案例教學(xué)法得到了普遍的應(yīng)用。以軟件測試技術(shù)課程為例，包括一些具有軟件測試精品課程的院校，無非都是采用了比如三角形測試、NextDate案例測試、飛機(jī)票訂票系統(tǒng)等作為教學(xué)案例，雖然使學(xué)生對相關(guān)知識和技術(shù)有了更深入地認(rèn)識，但是這些項目大多都是虛擬項目，這些虛擬項目主要存在兩方面的弊端：一是功能過于單一，內(nèi)容陳舊，只能起到說明相關(guān)測試技術(shù)的作用，卻與實際應(yīng)用脫節(jié)，缺乏實戰(zhàn)性，使得學(xué)生在真正面對一個綜合項目的時候卻感覺無從下手。二是由于每個項目功能單一，不能把一個完整的項目貫穿于整個課程的教學(xué)，通過這些虛擬項目，不利于培養(yǎng)學(xué)生形成從測試計劃、測試執(zhí)行、測試用例設(shè)計到測試報告的整個測試過程的工程思想，也不利于發(fā)掘?qū)W生自身的潛能。
（3） 知識內(nèi)容缺乏系統(tǒng)化。教學(xué)過程中，授課教師只關(guān)注學(xué)生知識點的掌握，而忽略了知
識點之間的系統(tǒng)聯(lián)系和實際應(yīng)用，使得學(xué)生一知半解，不知道學(xué)習(xí)這些知識點的用處，也不知道如何把所學(xué)內(nèi)容運用到實際項目當(dāng)中。在這種情況下，學(xué)生的工程管理、項目規(guī)范、項目文檔編制、團(tuán)隊協(xié)作和溝通能力沒有得到有效提升，因此難以滿足企業(yè)對綜合素質(zhì)人才的要求。
3 CDIO模式在軟件測試技術(shù)課程中的應(yīng)用
在CDIO模式指導(dǎo)下，我院軟件技術(shù)專業(yè)課程體系圍繞軟件產(chǎn)品開發(fā)為主線，以每位同學(xué)都要參與幾個項目開發(fā)為目的進(jìn)行課程安排。在整個課程體系中，將CDIO項目按規(guī)模和范圍劃分為三級，一級為包含軟件專業(yè)主要核心課程和能力要求的項目。我們選取了與企業(yè)合作開發(fā)的實際案例：洗衣管理系統(tǒng)和校外實訓(xùn)系統(tǒng)；二級為包含一組相關(guān)核心課程、能力要求的項目。主要是階段實訓(xùn)和綜合項目實訓(xùn)項目；三級為單門課程內(nèi)為增強(qiáng)該門課程能力與理解而設(shè)的項目，其中三級項目的設(shè)立與否及形式由各門課程大綱根據(jù)需要確定。
在軟件測試技術(shù)課程中，我們把CDIO模式貫穿于教學(xué)過程的每個環(huán)節(jié)，從如下幾個方面對課程進(jìn)行了教學(xué)改革和實踐應(yīng)用：
3.1 教學(xué)目標(biāo)和內(nèi)容
在CDIO模式下，軟件測試技術(shù)的教學(xué)目標(biāo)為“掌握軟件測試的理論知識，掌握主流的測試技術(shù)和方法；具備測試計劃的制定能力、測試用例的設(shè)計能力、測試代碼及文檔的編寫能力；具有良好的分析問題和解決問題的能力以及溝通和團(tuán)隊協(xié)作能力；具備自主學(xué)習(xí)和可持續(xù)發(fā)展能力”。
在課程內(nèi)容方面，我們基于CDIO的構(gòu)思、設(shè)計、實現(xiàn)、運作的思想，貫穿“做中學(xué)”和“基于項目教育和學(xué)習(xí)”的方式，以工程項目從研發(fā)到運行的生命周期為載體，把軟件測試技術(shù)課程的內(nèi)容分成五個項目任務(wù)。并且在課程中，選取校外實訓(xùn)系統(tǒng)和洗衣管理系統(tǒng)的測試作為貫穿于整個課程的任務(wù)。在這兩個項目的引領(lǐng)下，實施課程教學(xué)。課程的五個項目任務(wù)如下表所示：
3.2 教學(xué)組織
在CDIO模式下，為了使學(xué)生由接受者轉(zhuǎn)變?yōu)橹鲃訁⑴c者和積極探索者，在發(fā)揮教師主導(dǎo)作用的同時，充分發(fā)揮學(xué)生的主體作用。在教學(xué)組織方面，我們采用行動導(dǎo)向的教學(xué)模式，以小組模式為基礎(chǔ)組織教學(xué)。在具體教學(xué)過程中，我們對學(xué)生進(jìn)行分組，讓每個學(xué)生充當(dāng)企業(yè)中的真實角色，以一個職業(yè)人的身份，在真實的工作環(huán)境中，模擬軟件企業(yè)工作模式，每位同學(xué)承擔(dān)工作崗位相應(yīng)的責(zé)任和任務(wù)[6]。課堂教學(xué)也不再采用“教師演示講解、學(xué)生模仿練習(xí)”的模式，每一次課堂教學(xué)，教師先演示項目，提出任務(wù)需求，進(jìn)行必要的知識講解，然后教師為學(xué)生發(fā)放項目任務(wù)書，再由組長帶領(lǐng)小組成員分析項目任務(wù)，探討實施方案，撰寫任務(wù)計劃，完成項目任務(wù)，并提交相關(guān)文檔。在整個任務(wù)完成過程中，授課教師不斷和學(xué)生交流，對于學(xué)生在完全任務(wù)過程中存在的問題，指導(dǎo)學(xué)生解決。這樣，不僅能夠調(diào)用學(xué)生的主觀能動性，引導(dǎo)學(xué)生思考問題，解決問題，并在解決問題的過程中研究新的實現(xiàn)方法，而且突破了傳統(tǒng)的以學(xué)校和課堂為中心的封閉式教學(xué)組織形式，將實際生產(chǎn)與學(xué)習(xí)真正融合為一體，在掌握業(yè)務(wù)知識、培養(yǎng)技能的同時，培養(yǎng)敬業(yè)精神、團(tuán)隊意識和職業(yè)道德等綜合素質(zhì)，使師生在職業(yè)崗位中學(xué)習(xí)，在學(xué)習(xí)環(huán)境中工作。
3.3 教學(xué)手段
在教學(xué)手段應(yīng)用上，充分利用現(xiàn)代教育技術(shù)，采取密切的產(chǎn)學(xué)結(jié)合方式，聘請企業(yè)兼職教師進(jìn)行實踐指導(dǎo)，并充分利用網(wǎng)絡(luò)平臺和網(wǎng)絡(luò)教學(xué)資源。授課教師在課堂上通過多媒體教學(xué)的方式講解重點難點問題，相關(guān)的項目任務(wù)探討和知識擴(kuò)展通過網(wǎng)絡(luò)化平臺進(jìn)行。對于網(wǎng)絡(luò)化平臺，我們主要采用兩種方式：一是建立課程QQ群，為學(xué)生提供一個資料共享和課程討論和交流的平臺，二是要求學(xué)生訪問中國測試網(wǎng)，通過論壇和專業(yè)測試人員和其他測試學(xué)習(xí)者進(jìn)行溝通交流。在網(wǎng)絡(luò)教學(xué)資源方面，要求每一位同學(xué)使用高等職業(yè)教育軟件教學(xué)資源庫網(wǎng)站，訪問網(wǎng)站的課程資源和培訓(xùn)資源，其中軟件測試的課程資源包括：學(xué)習(xí)指南、授課錄像、實訓(xùn)指導(dǎo)、課程案例、參考和素材資源等方面。通過這樣的方式，能夠解決課堂教學(xué)課時的限制，使得課程的教學(xué)從課堂延伸到課后，對學(xué)生可持續(xù)學(xué)習(xí)的能力具有很大的促進(jìn)作用。此外，利用與江蘇微軟技術(shù)中心的合作優(yōu)勢，邀請他們在期末來校進(jìn)行項目實訓(xùn)指導(dǎo)。
3.4 考核方式
根據(jù)CDIO培養(yǎng)大綱，將學(xué)生的能力分為工程基礎(chǔ)知識、個人能力、人際團(tuán)隊能力和工程系統(tǒng)能力四個層面[7]，再使用傳統(tǒng)的考核方式已經(jīng)不能滿足要求。軟件測試技術(shù)課程打破了單一的考核方式，從學(xué)生的專業(yè)能力、社會能力培養(yǎng)的要求出發(fā)，建立基于教學(xué)全過程、以學(xué)生能力提升為導(dǎo)向的學(xué)習(xí)評價體系。具體包括過程性考核、綜合素質(zhì)評價和終結(jié)性考核。其中過程性考核占30%，綜合素質(zhì)評價占20%，終結(jié)性考核占50% 。
過程性考核：對學(xué)生完成實踐類項目的情況進(jìn)行綜合評定，考查項目包括課堂學(xué)習(xí)、小組學(xué)習(xí)、創(chuàng)新能力、課堂實踐和實踐報告等方面，每一個項目的考核都制定嚴(yán)格的評分標(biāo)準(zhǔn)。
綜合素質(zhì)評價：對學(xué)生在平時學(xué)習(xí)和實踐中表現(xiàn)出來的職業(yè)素養(yǎng)進(jìn)行綜合評定，主要包括團(tuán)隊協(xié)作能力、溝通交流能力、分析和解決問題的能力、自學(xué)能力、工作態(tài)度等方面，并對這些方面制定出嚴(yán)格的評分標(biāo)準(zhǔn)。
終結(jié)性考核：建立試題庫，實施考教分，在期末對學(xué)生進(jìn)行包括筆試和上機(jī)考試的綜合測試。其中筆試考查學(xué)生軟件測試的基礎(chǔ)理論知識以及對測試?yán)碚摰膽?yīng)用能力，該部分占終結(jié)性考核的60%；上機(jī)考試通過對實際測試項目的工作過程進(jìn)行檢查和考核，對任務(wù)完成情況進(jìn)行考核，還包括對測試工具運用的考核，該部分占終結(jié)性考核的40%。
4 結(jié)束語
通過在CDIO模式指導(dǎo)下進(jìn)行軟件測試技術(shù)課程的教學(xué)，解決了傳統(tǒng)教學(xué)模式存在的主要問題，為達(dá)到學(xué)生的知識能力與測試技能要求之間的無縫對接奠定了良好的基礎(chǔ)。下一步的工作是進(jìn)一步完善CDIO模式在軟件測試技術(shù)課程中的應(yīng)用，并把這些經(jīng)驗總結(jié)應(yīng)用到軟件專業(yè)其它課程的教學(xué)過程當(dāng)中。
參考文獻(xiàn)：
[1] 顧配華.以設(shè)計為導(dǎo)向的EIP-CDIO創(chuàng)新型工程人才培養(yǎng)模式[J].中國高等教育，2009（3）.
[2] 查建中.論“做中學(xué)”戰(zhàn)略下的CDIO模式[J].高等工程教育研究，2008（3）.
[3] 單光磊，韋良福.高職教育教學(xué)改革借鑒CDIO模式解析[J].山東水利職業(yè)學(xué)院院刊，2011（1）.
[4] 唐寶燕，馮娜.CDIO模式在高職軟件技術(shù)專業(yè)教學(xué)改革中的應(yīng)用[J].電腦知識與技術(shù)，2012（2）.
[5] 陳翔，鞠小林.卓越計劃驅(qū)動下的軟件測試技術(shù)課程教學(xué)改革[J].計算機(jī)教育，2013（13）.
案例教學(xué)是軟件測試教學(xué)中的常用手段，對學(xué)生理解測試方法有著很重要的作用，但是目前高校教學(xué)普遍存在著教學(xué)案例陳舊過時，大部分教學(xué)都沿用了傳統(tǒng)的教學(xué)案例。這些案例大都沒有介紹軟件測試的工程方法和實現(xiàn)過程，并且沒有進(jìn)行難度的區(qū)分，很難達(dá)到好的教學(xué)效果。
本專業(yè)的教師經(jīng)過多年的實踐，總結(jié)了大量的教學(xué)經(jīng)驗，按照實際工作中典型的工程師團(tuán)隊所需的各種技能知識為導(dǎo)向，按照復(fù)雜度漸增、螺旋遞進(jìn)的原則設(shè)置卓越軟件工程師課程體系與內(nèi)容，把傳統(tǒng)的以學(xué)科知識的系統(tǒng)性為導(dǎo)向的橫向課程體系改造為以個人職業(yè)角色發(fā)現(xiàn)和能力提升為導(dǎo)向的、適應(yīng)團(tuán)隊教育培養(yǎng)的新型縱向課程體系。軟件測試課程是軟件工程卓越工程師培養(yǎng)課程體系的重要組成部分，課程總體跟隨整體培養(yǎng)課程體系的大方向，并結(jié)合自身的特點進(jìn)行建設(shè)。
1復(fù)雜度漸增式開設(shè)課程
在傳統(tǒng)的以面向開發(fā)為主的培養(yǎng)模式下，測試課程設(shè)置單一，知識針對性連貫性不強(qiáng)。為了解決這些問題，在專業(yè)課程開設(shè)過程中將軟件測試課程課程拆分，穿插到整個培養(yǎng)過程中，緊密聯(lián)系軟件工程其他階段的課程，并且使用案例貫穿所有階段，復(fù)雜度逐漸遞增，讓學(xué)生在學(xué)習(xí)過程中循序漸進(jìn)，逐步建立學(xué)習(xí)的興趣和信心。在第5學(xué)期分成兩個階段分別開設(shè)《單元測試與軟件質(zhì)量》和《軟件驗證與確認(rèn)》。在第一階段旨在培養(yǎng)學(xué)生小規(guī)模程序測試的能力不涉及復(fù)雜系統(tǒng)，以提高個人開發(fā)測試的基本能力為目標(biāo)，學(xué)生可以運用測試課程中學(xué)習(xí)的方法在開發(fā)過程中使用，針對性強(qiáng)。第二階段旨在培養(yǎng)學(xué)生對系統(tǒng)整體測試的能力，此時學(xué)生以完成基本開發(fā)能力的訓(xùn)練，其他相關(guān)課程的培養(yǎng)中也進(jìn)入了系統(tǒng)級別。在該階段以上一階段培養(yǎng)的能力為基礎(chǔ)，提高復(fù)雜度，跟軟件開發(fā)其他階段緊密結(jié)合。完成第5學(xué)期的測試基礎(chǔ)課程開設(shè)之后，在第6學(xué)期還開設(shè)了《web軟件測試》、《測試案例分析》、《數(shù)據(jù)庫測試》等專業(yè)選修課，給有興趣的學(xué)生提供更多的學(xué)習(xí)選擇。
2基礎(chǔ)與實踐并重，充分利用虛擬實踐平臺課程
的開設(shè)充分考慮到測試重實踐，并且與軟件開發(fā)其他階段聯(lián)系緊密等特點；同時也考慮到了此時學(xué)生正處于學(xué)習(xí)階段，直接參與實際項目對學(xué)生的學(xué)習(xí)并不能起到很好的作用，因此在課程學(xué)習(xí)階段充分利用了校內(nèi)軟件實訓(xùn)基地，創(chuàng)建網(wǎng)上“虛擬企業(yè)”，引入企業(yè)管理模式，在這種虛擬平臺下，針對基礎(chǔ)的知識點開設(shè)虛擬項目[3]，模擬軟件測試的真實工程環(huán)境。學(xué)生在自己組合團(tuán)隊中有各自的工程任務(wù)，針對性實用性很強(qiáng)，學(xué)生能夠在完成自己任務(wù)的同時感性的認(rèn)識測試崗位工作，體會到軟件測試在整個軟件開發(fā)過程中的作用，將單項知識技能之間關(guān)聯(lián)在一起，系統(tǒng)的運用專業(yè)知識和技能。
3采用螺旋式的案例教學(xué)，案例與其他軟件開發(fā)階段貫穿
0引言
如今，軟件產(chǎn)品被廣泛應(yīng)用于各個領(lǐng)域，如航空、機(jī)械、電子產(chǎn)品等，軟件產(chǎn)品質(zhì)量成為軟件開發(fā)中重點關(guān)注的方向。在一些對于安全性要求較高的領(lǐng)域，對軟件產(chǎn)品的質(zhì)量要求更高。例如，在2011年溫州發(fā)生的7.23動車追尾事故，導(dǎo)致212人傷亡;1996年阿里亞娜5型火箭發(fā)射39秒后爆炸，直接經(jīng)濟(jì)損失3.7億美元;2002年首都機(jī)場電腦系統(tǒng)出現(xiàn)故障，導(dǎo)致6000多人滯留機(jī)場等。軟件中存在的缺陷是造成這些嚴(yán)重后果的根源。因此，軟件測試的重要性不言而喻。
傳統(tǒng)的軟件開發(fā)流程越來越無法滿足當(dāng)下軟件需求的頻繁變動，如傳統(tǒng)的瀑布模型，測試人員在一定的控制點之前不能測試，所以在此之前無法找到缺陷。等到所有開發(fā)完成，即過了該控制點后再進(jìn)行測試，缺陷數(shù)量會急劇增加，同時任何缺陷的修復(fù)都需要對一連串代碼進(jìn)行變動，修復(fù)時間難以確定，軟件遲遲不能，損失將難以估量。
敏捷軟件開發(fā)是基于一種更接近人類活動現(xiàn)實情況的方法論，采用以人為本、迭代、增量的開發(fā)過程，逐步滿足軟件不斷變更的需求[1]。敏捷主要提倡個人為團(tuán)隊所作的貢獻(xiàn)，注重各個職位的權(quán)利下發(fā)，發(fā)揮個人的主觀能動性，保證隨時都有可供交付的軟件產(chǎn)品。敏捷開發(fā)更容易在項目早期控制缺陷數(shù)目。軟件測試是保證軟件質(zhì)量與可靠性的重要手段，敏捷開發(fā)能充分發(fā)揮軟件測試的重要作用。
1敏捷開發(fā)思想
敏捷開發(fā)是以用戶的需求進(jìn)化為核心，采用逐步迭代、循序漸進(jìn)的方式進(jìn)行軟件開發(fā)。在敏捷開發(fā)模式中，軟件項目在開發(fā)前，先將整體項目切分成多個子項目，迭代過程中根據(jù)需要可以對子項目進(jìn)行拆分或同時進(jìn)行多個子項目，每一個子項目都要經(jīng)過測試，保證項目能運行成功。換言之，就是把一個大的軟件項目分成許多小項目，每個項目獨立完成，但相互之間又有聯(lián)系，在該過程中軟件始終處于可用狀態(tài)。
敏捷開發(fā)本身更多的是一種概念，它是一種循序漸進(jìn)的迭代開發(fā)方式，強(qiáng)調(diào)團(tuán)隊成員間的溝通。2001年，敏捷開發(fā)創(chuàng)始人了敏捷宣言：個體和交互勝過流程和工具，可用的軟件勝過完備的文檔，客戶協(xié)作勝過合同談判，響應(yīng)變化勝過遵循計劃[2]。也即，雖然后半部分的條目也具有價值，但是更看重前半部分的條目。他們希望這將成為成功的軟件開發(fā)的基礎(chǔ)。敏捷開發(fā)的方法很多，主要包括快速應(yīng)用開發(fā)(RAD)[3]、極限編程(XP)[4]、動態(tài)系統(tǒng)開發(fā)方法(DSDM)[5]與Scrum[6]。本文構(gòu)建的測試模型借鑒敏捷開發(fā)過程中的迭代思想，以漸進(jìn)的方式完成測試工作，不僅可使測試工作具有更好的靈活性，同時也能更好地適用于現(xiàn)有的敏捷開發(fā)過程。
軟件是一種非常特殊的產(chǎn)品，開發(fā)出的軟件通常會存在一些缺陷，而有些缺陷會造成非常嚴(yán)重的損失。軟件測試則成為保障軟件質(zhì)量的一種重要手段[7]。根據(jù)不同標(biāo)準(zhǔn)有多種測試方式，如集成測試、單元測試、系統(tǒng)測試、驗收測試和回歸測試。傳統(tǒng)的V測試模型和W測試模型成為指導(dǎo)人們進(jìn)行測試的方法，而不同于這兩種測試模型的H模型，則強(qiáng)調(diào)測試的獨立性。另外目前很多開發(fā)團(tuán)隊已經(jīng)開始使用敏捷開發(fā)方式，敏捷開發(fā)方式非常注重客戶的交互以及團(tuán)隊中的溝通，同時開發(fā)過程中會有許多迭代過程。本文提出的測試模型借鑒敏捷開發(fā)中的迭代思想，測試流程是一個漸進(jìn)的過程。然而，即使有成功的敏捷開發(fā)方法，開發(fā)人員和測試人員依然要尋求最適合的敏捷方法，并將相關(guān)技術(shù)融入到自己的敏捷方法中。
2敏捷開發(fā)中的軟件測試
2.1敏捷測試
敏捷測試沒有已經(jīng)確定的唯一定義，原有的測試定義“通過在規(guī)定條件下對程序進(jìn)行操作，發(fā)現(xiàn)錯誤，衡量軟件質(zhì)量”仍然適用，核心思想可以理解為“遵循敏捷開發(fā)的宣言，接納敏捷核心價值觀，基于敏捷開發(fā)的軟件測試”。敏捷開發(fā)宣言中提到敏捷開發(fā)的4個核心價值觀：簡明(Simplicity)、溝通(Communication)、反饋(Feedback)、勇氣/決斷(Courage)。符合敏捷核心價值觀的測試實踐活動都可以稱為敏捷測試，敏捷不僅是一種過程，更多的是一種理念[8]。
2.2敏捷測試方法
圖1為敏捷開發(fā)測試流程，此流程是一個結(jié)合了Scrum和XP方法，并加上一些基于計劃性流程原則后的產(chǎn)物。虛線箭頭兩端是開發(fā)過程中與軟件測試相關(guān)的部分，敏捷開發(fā)的測試人員全程參與完整的迭代開發(fā)。
(1)需求分析：測試工程師可以根據(jù)測試經(jīng)驗以及需求的測試難度對需求列表提出問題或意見，以期團(tuán)隊能共同提供建議或方案，在之后的實際測試過程中有助于提高測試效率。
(2)迭代計劃：包括對需求的詳細(xì)分析以及任務(wù)表等，軟件工程師和測試工程師對需求進(jìn)行討論。
(3)迭代啟動會議：項目經(jīng)理、產(chǎn)品經(jīng)理、軟件工程師、測試工程師對此代計劃進(jìn)行討論、完善。
(4)測試計劃：測試工程師根據(jù)需求以及測試經(jīng)驗完成詳細(xì)的測試計劃書，團(tuán)隊對測試計劃進(jìn)行研討并確認(rèn)驗收測試。
(5)測試驅(qū)動開發(fā)：測試工程師相當(dāng)于軟件的第一批用戶，測試過程中要重視反饋，這也是敏捷開發(fā)的原則之一。
(6)驗收測試：測試工程師對此次迭代的所有功能進(jìn)行演示，測試產(chǎn)品功能是否合格。如果產(chǎn)品合格，則此次驗收通過，可以進(jìn)入下一環(huán);如果產(chǎn)品不合格，則此次驗收失敗，重新返回開發(fā)階段，找出失敗的原因及bug并解決，并確認(rèn)下一次驗收測試。
(7)提交與驗證：由測試工程師為產(chǎn)品負(fù)責(zé)人與參與項目的人進(jìn)行演示，包括此次迭代的主要功能、產(chǎn)生的未解決bug，然后由產(chǎn)品負(fù)責(zé)人核準(zhǔn)迭代成功。
(8)迭代后的研討：對此次迭代過程中產(chǎn)生的問題進(jìn)行討論，對于亮點可以進(jìn)行表揚(yáng)，錯誤要分析原因。
從流程圖和測試人員參與項目的簡單描述中，可以總結(jié)出敏捷測試的方法主要有兩種：與傳統(tǒng)軟件測試相似的測試和測試驅(qū)動開發(fā)(TDD，Test-DrivenDevelopment)。
圖2展示的是測試驅(qū)動開發(fā)流程，開發(fā)人員在編寫產(chǎn)品代碼之前，要先編寫單元測試代碼，在進(jìn)行單元測試后才能進(jìn)行產(chǎn)品代碼的編寫，以保證產(chǎn)品代碼能完全符合要求。產(chǎn)品代碼編寫完成后進(jìn)行單元測試和集成測試，測試代碼和產(chǎn)品代碼都要進(jìn)行代碼審查，保證代碼的簡潔、統(tǒng)一，方便以后維護(hù)。在敏捷測試中，測試驅(qū)動開發(fā)的重要目的不僅僅是測試軟件，同時在開發(fā)過程中幫助客戶和程序員確定需求。測試驅(qū)動開發(fā)應(yīng)該運用于每一個迭代中，逐步開發(fā)完成所有軟件功能。
傳統(tǒng)軟件測試的種類非常多，在敏捷測試中應(yīng)當(dāng)根據(jù)當(dāng)前迭代的需求進(jìn)行測試[9]。某車削軟件有這樣一個需求，能支持直徑40mm的刀具路徑生成。該需求一定配備了相應(yīng)的刀具路徑生成方法，然后只需確定刀路生成中的一些參數(shù)，然后設(shè)計數(shù)量足夠的不同表面形態(tài)的圓面即可。由于TestPart數(shù)量過多，可能會用到自動化測試，也有可能會用到一些特殊的TestPart，如圓面面型變化大，甚至不是圓面等。迭代最后一定有整體的性能測試，在整個項目進(jìn)行過程中，傳統(tǒng)的軟件測試方法同樣適用于敏捷開發(fā)。
2.3敏捷測試特點
在瀑布開發(fā)模式中，要求流程規(guī)范、文檔齊全，測試進(jìn)行時再根據(jù)軟件需求總結(jié)、測試所有功能點，直到軟件中沒有明顯bug。在傳統(tǒng)的軟件測試開始時，軟件的缺陷會達(dá)到頂點，同時如果有需求變化，則需要重新編寫文檔，可能必須將之前的工作推翻重來，費時費力。而在敏捷測試中，一切都發(fā)生了改變。
敏捷開發(fā)模式中測試不是一個單獨階段，它和編碼一樣是軟件開發(fā)的重要組成部分。敏捷開發(fā)使用一個“完整團(tuán)隊”的方法來保證軟件產(chǎn)品質(zhì)量。敏捷團(tuán)隊中的測試人員從客戶需求中提煉要求，然后與開發(fā)團(tuán)隊合作，把這些要求變成可執(zhí)行的規(guī)范，用于指導(dǎo)代碼編寫。隨著測試和編碼的逐漸進(jìn)行與交互，將建立一些產(chǎn)品特性，直到提供足夠的產(chǎn)品價值。
敏捷測試包括以下幾個主要特點：①周期性的迭代開發(fā)方式。不同于傳統(tǒng)測試的一次性集成或功能測試，敏捷測試在迭代進(jìn)行過程中要通過及時響應(yīng)客戶反饋來修正軟件測試策略，以此修正軟件的質(zhì)量指標(biāo);②每日立會，密切溝通。傳統(tǒng)測試提供了大量文檔描述產(chǎn)品需求，并通過文檔進(jìn)行測試。敏捷測試則需要團(tuán)隊每天進(jìn)行交流，測試人員與客戶持續(xù)溝通，以保證產(chǎn)品質(zhì)量符合客戶預(yù)期，并與開發(fā)人員溝通來確定需求認(rèn)識的統(tǒng)一;③測試方法多樣，貫穿整個項目開發(fā)過程。敏捷測試包括測試人員對軟件的自動化測試、集成測試、功能測試等，還包括開發(fā)人員對代碼的單元測試、代碼評審等工作，從最底層和基礎(chǔ)的測試來保證軟件整體質(zhì)量;④確保客戶需求圓滿實現(xiàn)。客戶需求是敏捷開發(fā)中最核心的內(nèi)容，敏捷測試同樣需圍繞客戶需求實現(xiàn)。
2.4敏捷測試優(yōu)勢
目前大多數(shù)軟件項目的共同特點是用戶需求變化快、風(fēng)險高，同時還能快速搶占市場，這剛好是敏捷開發(fā)能夠解決的。
(1)良好的持續(xù)溝通可減少缺陷產(chǎn)生，降低風(fēng)險。在敏捷開發(fā)模式下，測試人員的溝通尤為重要。一個迭代從開始到結(jié)束，測試人員都需要參與。迭代開始時，所有人都要對該階段軟件的成型有統(tǒng)一認(rèn)識，滿足用戶需求的同時還要符合一次迭代的時間要求;迭代進(jìn)行中，測試對開發(fā)人員的反饋非常重要，軟件開發(fā)初期，測試工具十分缺乏，對測試工作的進(jìn)行造成很大阻礙，這時需要和開發(fā)人員持續(xù)溝通，必要時可共同開發(fā)一些輔助測試工具，在此期間要把握好迭代進(jìn)行的時間;迭代后期，也可以作為bug反饋期，測試人員不但要站在用戶角度考慮需求，同時能和開發(fā)人員站在技術(shù)角度討論問題，達(dá)到溝通的目的。
(2)合理的測試用例。敏捷最直接的特點就是快速，如果涉及的用例粒度太細(xì)，很難開展敏捷測試。一個合理的測試用例不僅能包含所有可能產(chǎn)生缺陷的地方，同時還能快速地響應(yīng)需求變化。
(3)更多人參與測試。敏捷測試中的測試人員不再是一個獨立的測試個體，研發(fā)人員、產(chǎn)品負(fù)責(zé)人、用戶都可以參與測試。研發(fā)人員的測試可以減少編程中的bug，產(chǎn)品負(fù)責(zé)人的測試可以更好、更全面地把握產(chǎn)品現(xiàn)狀，用戶的測試則可以提供來自真正用戶的反饋，以更好地促進(jìn)軟件開發(fā)。
3敏捷開發(fā)中的軟件測試實例
本章結(jié)合一個具體的軟件項目，詳細(xì)介紹項目中的敏捷測試。
3.1項目介紹
針對3軸超精密加工車床，提供針對光學(xué)自由曲面進(jìn)行加工的刀路軌跡計算的CAM(ComputerAidedManufacturing，計算機(jī)輔助制造)軟件。該軟件的目標(biāo)是比UGNX中的相同功能有更快的計算速度和更高的精度。
3.2需求分析和項目規(guī)劃階段
項目經(jīng)理和產(chǎn)品經(jīng)理根據(jù)客戶給定的需求進(jìn)行分類，包括框架、加工方式、加工質(zhì)量、刀具選擇、仿真等需求，并對項目可能產(chǎn)生的需求進(jìn)行判斷和規(guī)劃，形成項目計劃書。項目計劃書包括項目背景、、需求以及預(yù)期完成時間。項目計劃書完成之后即可開始進(jìn)行第一個迭代，并以第一個迭代為基礎(chǔ)不斷進(jìn)行下去，直到完成所有需求。由于整體項目過于龐大，這里只對第一個迭代進(jìn)行介紹。
項目實例：第一個迭代中有2個需求，同時根據(jù)工作量分配任務(wù)天數(shù)以及每個需求的參與人員，如表1所示。
3.3迭代進(jìn)行階段
迭代開始時，項目經(jīng)理制定迭代的具體開發(fā)任務(wù)和測試任務(wù)。在迭代啟動會議中，每個人都要對此次迭代任務(wù)有統(tǒng)一認(rèn)識，并且能夠承載相應(yīng)的任務(wù)量，在需求確定完畢后進(jìn)行任務(wù)分配。
.
開發(fā)人員進(jìn)行編碼時，測試人員的工作重點包括：編寫測試計劃、測試用例、驗收測試以及提交和驗證。測試計劃和測試用例的編寫同時完成，且在迭代初期完成。驗收測試一般是在迭代后期進(jìn)行集成測試，迭代過程中也可以協(xié)助開發(fā)人員進(jìn)行單獨的功能測試。
3.3.1編寫測試計劃和測試用例
測試計劃需要具體的操作步驟以及相對完善的測試用例來涵蓋需求，因此需要測試人員有比較豐富的測試經(jīng)驗。
項目實例如下：
表2和表3中的TestParts需要填寫測試工件名稱。測試計劃編寫完成后要經(jīng)過開發(fā)人員和項目經(jīng)理確認(rèn)，保證開發(fā)人員認(rèn)同并能夠達(dá)到計劃的目標(biāo)。敏捷開發(fā)是不斷迭代的過程，對于一些比較簡單的功能，盡量設(shè)計簡潔的測試用例。如果TestParts比較多，可以采用自動化測試，而對于一些比較復(fù)雜的功能，可以先采用手動測試，在功能更加完善后再考慮自動化測試。
3.3.2驗收測試
驗收測試要嚴(yán)格按照迭代前期寫好的測試計劃進(jìn)行，在開發(fā)人員開發(fā)完此次迭代所有功能后，測試人員對所有功能進(jìn)行集成測試、功能測試、自動化測試等，完成所有測試工作后形成測試報告。報告內(nèi)容包括此次迭代基本功能完成情況、缺陷產(chǎn)生情況以及測試過程中的一些詳細(xì)數(shù)據(jù)。
3.3.3提交和驗證
團(tuán)隊全體成員參加驗收會議，由測試工程師對迭代成果進(jìn)行演示，產(chǎn)品經(jīng)理和項目經(jīng)理進(jìn)行驗收，項目需求全部完成則此次迭代成功，然后再對此次迭代中的不足之處進(jìn)行討論和改進(jìn)，或者提出創(chuàng)新之處。如果項目需求未達(dá)標(biāo)，或產(chǎn)生了過多缺陷，則此次迭代不予通過，全員討論延后驗收或?qū)⑷毕萃晟蒲雍蟮较乱粋€迭代。
項目實例：針對需求R1、R2的基本功能測試達(dá)到了計劃的標(biāo)準(zhǔn)，框架的視圖操作和顯示功能以及CAD模型輸入功能均正常運行且無缺陷。雖然框架本身存在一些缺陷，仍能滿足迭代的基本需求。經(jīng)過討論此次迭代成功，產(chǎn)生的bug在下一個迭代進(jìn)行完善。
3.4迭代后研討和下一次迭代討論
迭代完成后要對迭代過程進(jìn)行回顧，測試人員需要對bug進(jìn)行總結(jié)，包括測試過程中產(chǎn)生的問題，以及需要改進(jìn)的地方，然后對下一次迭代的需求進(jìn)行初步討論，決定下一個周期的工作內(nèi)容。
4結(jié)語
敏捷開發(fā)中的軟件測試應(yīng)當(dāng)遵循敏捷開發(fā)的基本原則，面對不同的開發(fā)方法和應(yīng)用環(huán)境，軟件測試方法也不同。敏捷測試作為從敏捷開發(fā)中成長起來的測試方法，與敏捷過程密不可分，本文對敏捷開發(fā)中的軟件測試特點和方法進(jìn)行了詳細(xì)描述。然而，真正在面對軟件測試時，測試用例的生成與覆蓋標(biāo)準(zhǔn)、測試的充分性和有效性、不同階段的測試關(guān)系等，以及如何將傳統(tǒng)測試中的一些方法應(yīng)用到敏捷測試中，需要探討的問題及方法仍然很多。
摘要：通過校企合作能夠有效支撐應(yīng)用性本科和高職高專教育人才培養(yǎng)的校外實踐教學(xué)基地、學(xué)生實習(xí)基地和教師職場體驗基地，建立畢業(yè)生質(zhì)量追蹤調(diào)查機(jī)制、用人單位對學(xué)校和學(xué)院教學(xué)質(zhì)量評價和反饋機(jī)制。本文介紹了我院在校企合作構(gòu)建特色專業(yè)課程方面的探索。
關(guān)鍵詞：特色專業(yè)；軟件測試；校企合作；高職高專
中圖分類號：G642
文獻(xiàn)標(biāo)識碼：B
1引言
計算機(jī)應(yīng)用技術(shù)是一個應(yīng)用范圍很廣的專業(yè)，可以從事計算機(jī)行業(yè)的幾乎所有工作。因此，計算機(jī)應(yīng)用技術(shù)專業(yè)學(xué)生應(yīng)學(xué)習(xí)的內(nèi)容很多，內(nèi)容涵蓋很廣。對于高職學(xué)生來說，三年學(xué)習(xí)內(nèi)容不可能涵蓋所有的計算機(jī)應(yīng)用領(lǐng)域。因此，必須對該專業(yè)定向。而專門化方向須根據(jù)市場需求方能確定。為此，我們在北京及周邊等地進(jìn)行專業(yè)調(diào)研，了解社會對計算機(jī)應(yīng)用技術(shù)專業(yè)學(xué)生的就業(yè)崗位、能力與素質(zhì)需求。并由此確定計算機(jī)應(yīng)用技術(shù)的專業(yè)化方向為軟件測試。
旺盛的社會需求是人才培養(yǎng)面臨的最大機(jī)遇，教育發(fā)展的最大動力是社會需求。軟件測試專業(yè)就是一個朝陽專業(yè)，社會需求較大，以就業(yè)為導(dǎo)向構(gòu)建高職計算機(jī)應(yīng)用特色專業(yè)人才培養(yǎng)模式及課程教學(xué)改革研究，將按照“就業(yè)導(dǎo)向明確、層次定位準(zhǔn)確，培養(yǎng)模式先進(jìn)，專業(yè)特色鮮明，人才質(zhì)量優(yōu)良”的要求，推進(jìn)人才培養(yǎng)模式、課程體系和人才培養(yǎng)質(zhì)量。
以計算機(jī)軟件測試方向作為高職計算機(jī)應(yīng)用特色專業(yè)的研究與建設(shè)是新的探索。一個正規(guī)的軟件開發(fā)項目應(yīng)該包括軟件開發(fā)和軟件測試兩大部分，而且旨在提供質(zhì)量保證的測試部分應(yīng)該占更大的比重，國際上標(biāo)準(zhǔn)的軟件開發(fā)和測試人才的比例應(yīng)該為1:1或1:2，而目前國內(nèi)這個比例則為5:1。計算機(jī)軟件測試專業(yè)在國內(nèi)尚屬待開發(fā)專業(yè)，就業(yè)前景非?？春谩５捎谑切聦I(yè)，現(xiàn)有的中青年教師在授課之前基本沒有系統(tǒng)的軟件測試?yán)碚摵凸こ虒嵺`、更無教學(xué)經(jīng)驗?；谶@種情況，就更加應(yīng)該盡快開展專業(yè)研究和建設(shè)，并借助于各方力量，以提高教師的理論水平和實踐能力，使他們能盡快掌握理論和具備實踐能力，承擔(dān)起教學(xué)與實踐任務(wù)。
2計算機(jī)應(yīng)用特色專業(yè)建設(shè)思路
由于國內(nèi)軟件開發(fā)和軟件測試人員比例的嚴(yán)重失調(diào)，行業(yè)急需軟件測試人才。而該專業(yè)正在創(chuàng)建和開發(fā)時期，沒有教學(xué)經(jīng)驗?；谶@種情況，開展特色專業(yè)人才培養(yǎng)模式及課程教學(xué)改革研究，是很有必要的。為了使軟件測試專業(yè)教學(xué)更加貼近教學(xué)，使教學(xué)更具針對性，教學(xué)素材、案例更符合實際需要，必須引進(jìn)實際項目，聘請校外專家，及時與實力雄厚的教育集團(tuán)及企業(yè)合作進(jìn)行專業(yè)共建。
特色專業(yè)建設(shè)的目的是：尋找促進(jìn)人才培養(yǎng)與市場需求緊密結(jié)合的路子，突出軟件測試專業(yè)方向應(yīng)用性人才培養(yǎng)特色，加強(qiáng)學(xué)校與社會企業(yè)的合作與交流，構(gòu)建適應(yīng)社會發(fā)展需求的產(chǎn)、學(xué)、研合作教育平臺。提高教師教學(xué)科研能力和技術(shù)實踐水平，帶動學(xué)校學(xué)科專業(yè)結(jié)構(gòu)調(diào)整和人才培養(yǎng)模式創(chuàng)新。建設(shè)能夠有效支撐高職高專教育人才培養(yǎng)的實踐教學(xué)平臺，建立畢業(yè)生質(zhì)量追蹤調(diào)查機(jī)制，為學(xué)校摸索出一條構(gòu)建特色專業(yè)課程的新路。
改革創(chuàng)新軟件測試專業(yè)人才培養(yǎng)模式，深入研究校企專業(yè)建設(shè)內(nèi)容，真正將行業(yè)所需人才應(yīng)具備的知識、技能引進(jìn)到專業(yè)人才培養(yǎng)過程中，確保專業(yè)建設(shè)內(nèi)容的先進(jìn)性與實用性。
人才培養(yǎng)模式以培養(yǎng)學(xué)生的全面職業(yè)化素質(zhì)、技術(shù)應(yīng)用能力和就業(yè)競爭能力為主線，充分利用學(xué)校和企業(yè)兩種不同的教育環(huán)境和教育資源，通過企業(yè)與學(xué)校的長期合作和雙向互動，將在學(xué)校的理論學(xué)習(xí)、基本訓(xùn)練與在企業(yè)的實際工作經(jīng)歷有機(jī)結(jié)合起來實現(xiàn)高素質(zhì)高技能人才培養(yǎng)。
在開展本課題研究時，我們將本著“面向?qū)嶋H、站在前沿、重在應(yīng)用、加強(qiáng)合作”的指導(dǎo)思想，努力創(chuàng)造一種團(tuán)結(jié)民主、互幫互學(xué)、求實創(chuàng)新的科研氛圍，力求做到邊學(xué)習(xí)培訓(xùn)，邊研究應(yīng)用，邊推出成果，邊總結(jié)推廣，力求通過三年的研究，在課程體系設(shè)置、實訓(xùn)基地建設(shè)、師資隊伍建設(shè)、畢業(yè)生就業(yè)引導(dǎo)等方面，探索出一套“高職計算機(jī)應(yīng)用――軟件測試專業(yè)人才培養(yǎng)”的新模式。
3課程體系的建設(shè)
課程體系從原來的以學(xué)科為體系的課程設(shè)置轉(zhuǎn)變?yōu)橐阅芰橹骶€的課程體系設(shè)置，即先按各專業(yè)方向?qū)徫荒芰Φ囊?，及每崗位能力從入門、基礎(chǔ)、應(yīng)用到綜合的過程來設(shè)置課程。根據(jù)軟件測試的特點設(shè)計了個性化的課程體系，確保學(xué)生們能夠?qū)W成上崗。課程體系按以下幾個模塊來實施：
3.1基礎(chǔ)課程階段教學(xué)計劃
3.2集中實訓(xùn)階段教學(xué)計劃
3.3職業(yè)素質(zhì)培養(yǎng)教學(xué)計劃
4專業(yè)建設(shè)研究目標(biāo)
4.1技術(shù)路線和實施步驟
軟件測試特色專業(yè)的研究，主要是以就業(yè)為導(dǎo)向構(gòu)建高職計算機(jī)應(yīng)用特色專業(yè)人才培養(yǎng)模式及課程教學(xué)改革研究，研究計算機(jī)應(yīng)用特色專業(yè)如何與社會需求密切結(jié)合的專業(yè)發(fā)展模式，培養(yǎng)學(xué)生的軟件測試的實際應(yīng)用能力，加強(qiáng)專業(yè)建設(shè)和人才培養(yǎng)，讓教師與學(xué)生的培養(yǎng)一起成長，培養(yǎng)學(xué)生具有較強(qiáng)的實踐能力、崗位適應(yīng)能力、創(chuàng)新能力的從事軟件測試的高等技術(shù)應(yīng)用性專門人才。主要從以下幾個階段實施：
第一階段(2008年9月~2009年8月)
該階段是基礎(chǔ)課和專業(yè)基礎(chǔ)課程的改革和建設(shè)，主要由教研室負(fù)責(zé)這部分課程的建設(shè)與授課、課程資料及輔助科學(xué)軟件的開發(fā)。把開發(fā)小型應(yīng)用系統(tǒng)作為教學(xué)的主線，鼓勵和引導(dǎo)學(xué)生參加項目建設(shè)。為后續(xù)課程的學(xué)習(xí)奠定基礎(chǔ)。
第二階段(2009年9月~2010年8月)
該階段通過構(gòu)建軟件測試的基本概念框架，掌握使用軟件測試系統(tǒng)中軟件測試的基本方法、基本技能等。從軟件測試的基本概念到單元測試、集成測試、性能測試的實踐活動，設(shè)計與課程密切相關(guān)的單元測試。
第三階段(2010年9月~2011年8月)
該階段是軟件工程與測試實驗室搭建、軟件測試平臺搭建及綜合實訓(xùn)基地建設(shè)搭建。該階段需要借助多方力量進(jìn)行專業(yè)課程的構(gòu)建、進(jìn)行軟件工程與測試實驗室搭建、軟件測試平臺搭建等實訓(xùn)課程的實施階段。
第四階段(2011年9月~2011年12月)
該階段是結(jié)題階段。收集、整理子課題結(jié)題實驗報告，舉辦課題成果評獎活動；撰寫課題結(jié)題報告，發(fā)表相關(guān)論文，上交申請成果評估驗收；課題組結(jié)題大會，成果出版與展示等。
4.2研究假設(shè)和擬創(chuàng)新點
(1) 結(jié)合所學(xué)課程，讓學(xué)生直接參與公司項目開發(fā)，有利于學(xué)生職業(yè)能力的培養(yǎng)。通過校企合作探索軟件測試人才培養(yǎng)模式，涉及到的合作機(jī)制、教學(xué)機(jī)制、運行機(jī)制的改革與創(chuàng)新。
(2) 通過課題研究，促進(jìn)校企合作，以及人才培養(yǎng)與市場需求緊密結(jié)合，突出軟件測試專業(yè)方向應(yīng)用性人才培養(yǎng)特色，構(gòu)建適應(yīng)社會發(fā)展需求的產(chǎn)學(xué)研合作教育平臺。
(3) 以就業(yè)為導(dǎo)向，圍繞專業(yè)核心能力，構(gòu)建課程體系；通過產(chǎn)學(xué)結(jié)合，建設(shè)優(yōu)質(zhì)核心課程，制定課程標(biāo)準(zhǔn)，編寫適用教材；建設(shè)雙師結(jié)構(gòu)的教學(xué)團(tuán)隊和校內(nèi)外實訓(xùn)基地。
(4) 將傳統(tǒng)的課程進(jìn)行整合，理論夠用為度，以講座、學(xué)術(shù)報告等形式增加現(xiàn)實社會所急需內(nèi)容。課程模塊化教學(xué)，采用“事件驅(qū)動”式的培養(yǎng)方式，根據(jù)就業(yè)崗位確定課程設(shè)置，培養(yǎng)學(xué)生的基本技能。根據(jù)社會的需求大力實施訂單教育。
(5) 從課程學(xué)習(xí)到課程設(shè)計、畢業(yè)設(shè)計各階段，貫穿實施項目教學(xué)法，在項目教學(xué)中，學(xué)習(xí)過程成為一個人人參與的創(chuàng)造實踐活動，注重的不是最終的結(jié)果，而是完成項目的過程。
4.3專業(yè)建設(shè)的預(yù)期目標(biāo)
學(xué)院與企業(yè)合作，實施實訓(xùn)人才培養(yǎng)模式，共同致力于軟件測試應(yīng)用人才的培養(yǎng)，開啟我院計算機(jī)應(yīng)用人才培養(yǎng)與企業(yè)需求零距離對接的先河。注重人才培養(yǎng)的針對性和實用性，可以有力地促進(jìn)我院教育教學(xué)的改革，提高辦學(xué)效益，實現(xiàn)學(xué)校、企業(yè)、學(xué)生“三贏”，產(chǎn)生良好的社會影響。使學(xué)生掌握必需的科學(xué)文化基礎(chǔ)知識和軟件測試等方面的專業(yè)知識，具有較強(qiáng)的實踐能力、崗位適應(yīng)能力、創(chuàng)新能力的從事軟件測試的計算機(jī)技術(shù)應(yīng)用性專門人才。特色專業(yè)預(yù)期培養(yǎng)目標(biāo)如下。
5結(jié)束語
計算機(jī)軟件測試專業(yè)正在創(chuàng)建和開發(fā)時期，以就業(yè)為導(dǎo)向構(gòu)建高職計算機(jī)應(yīng)用特色專業(yè)人才培養(yǎng)模式及課程教學(xué)改革研究是新的探索。總之，高職計算機(jī)應(yīng)用特色專業(yè)教學(xué)改革是培養(yǎng)數(shù)以億計高素質(zhì)勞動者和數(shù)以千萬計高技能專門人才的需要，且大有文章可做。只要我們在教學(xué)實踐中不斷探索，不斷總結(jié)，高職計算機(jī)應(yīng)用特色專業(yè)的教學(xué)改革就一定能結(jié)出豐碩果實，高職計算機(jī)教育就一定能為社會培養(yǎng)出“適銷對路”的計算機(jī)應(yīng)用人才。
參考文獻(xiàn)：
[1] 朱鴻,金凌紫. 軟件質(zhì)量保障與測試[M]. 北京:科學(xué)出版社,1997.
【關(guān)鍵詞】軟件測試 教學(xué)改革 軟件測試工程師
【基金項目】2015年中央高?；究蒲袠I(yè)務(wù)費專項資金項目“C程序代碼級內(nèi)存缺陷的充分性檢測技術(shù)研究”（15CX02050A）。
【中圖分類號】G64 【文獻(xiàn)標(biāo)識碼】A 【文章編號】2095-3089（2015）09-0229-01
一、引言
隨著軟件產(chǎn)業(yè)的迅猛發(fā)展，軟件的復(fù)雜性也日益增加，導(dǎo)致對軟件的質(zhì)量提出了更高的要求，這也使得軟件測試工程師成為每個軟件企業(yè)都不可或缺的技術(shù)人才?！败浖y試”就是一門培養(yǎng)軟件測試工程師的專業(yè)課[1]，本課程較為系統(tǒng)的介紹了軟件測試的基本理論、測試方法、測試過程以及常用測試工具等內(nèi)容。本課程知識的掌握將為學(xué)生系統(tǒng)的掌握軟件工程知識體系以及畢業(yè)后從事軟件測試、軟件開發(fā)等職位打下良好的基礎(chǔ)。
如何扎實有效的培養(yǎng)軟件工程學(xué)生在軟件測試領(lǐng)域既具有理論基礎(chǔ)、又具有工程實戰(zhàn)能力，目前許多軟件工程專業(yè)教育者進(jìn)行了積極的探索 [2-4]。我校軟件工程專業(yè)已入選山東省卓越工程師培養(yǎng)計劃[5]，為了執(zhí)行國家對軟件工程專業(yè)卓越工程師培養(yǎng)的精神，融合學(xué)校的“三三三”培養(yǎng)體系[6]的頂層設(shè)計，以貫徹培養(yǎng)理論扎實、具備工程實踐能力、創(chuàng)新能力強(qiáng)、適應(yīng)經(jīng)濟(jì)社會發(fā)展需要的高質(zhì)量軟件工程師為目標(biāo)，我們也在軟件測試課程的培養(yǎng)方案、課程結(jié)構(gòu)、教學(xué)方法和考評體系等方面進(jìn)行了一系列的改革和探索[7，8]。其中最為重要的改革是借鑒CDIO（Conceive-Design-Implement-Operate）工程教育理念，落實了“基于項目的教學(xué)”方法，增開了大量的課程設(shè)計和綜合實踐環(huán)節(jié)，在理論教學(xué)的同時注重了工程實踐能力得培養(yǎng)。
二、“軟件測試”教學(xué)面臨的問題
“軟件測試”課程的已有的教學(xué)改革改善了教學(xué)效果，但是由于傳統(tǒng)的教學(xué)方法依然影響著教學(xué)，所以目前的軟件測試課程教學(xué)過程中依然面臨一系列問題。
（一）教學(xué)內(nèi)容抽象，學(xué)生學(xué)習(xí)興趣不高
軟件測試是軟件工程知識體系的九個知識域中理論性最強(qiáng)的一個知識域，必然造成軟件測試教材與教學(xué)內(nèi)容較抽象。目前，軟件測試課程教學(xué)中普遍存在著理論教學(xué)偏重的特點，扎實的理論素養(yǎng)是卓越工程師的必備基礎(chǔ)，但是即便對于軟件工程專業(yè)的本科學(xué)生，也欠缺軟件項目的實際開發(fā)經(jīng)驗，所以課程內(nèi)容的抽象性增加了學(xué)生對課程內(nèi)容的理解難度。為促進(jìn)學(xué)生對理論知識的理解與應(yīng)用，必須結(jié)合軟件測試的課程特點，將抽象的內(nèi)容分化到軟件測試過程的不同階段中，并采用相應(yīng)的測試工具體現(xiàn)測試的方法，再應(yīng)用于教學(xué)案例，才能促進(jìn)學(xué)生對抽象的測試?yán)碚撝R的理解與應(yīng)用。
（二）教學(xué)內(nèi)容碎片化，學(xué)生沒有完善的測試知識體系
按照軟件開發(fā)過程的要求，軟件測試是貫穿于整個開發(fā)過程的一項活動。而在教學(xué)中，軟件測試的理論出現(xiàn)了割裂，各知識點呈現(xiàn)碎片化，理論內(nèi)容與實際的軟件測試流程不同步。將不同的測試?yán)碚撆c方法進(jìn)行了分割，這樣利于教材內(nèi)容的安排以及教學(xué)內(nèi)容的組織，但這也必然造成教學(xué)內(nèi)容碎片化，學(xué)生形成不了一個統(tǒng)一的測試?yán)碚摽蚣埽y以把握所學(xué)的理論與方法在軟件開發(fā)與測試的過程中如何應(yīng)用。為促進(jìn)教學(xué)效果，有必要基于軟件測試過程，定位軟件測試的介入點，在不同的介入點進(jìn)行理論知識的分配，形成一個以軟件測試過程為主線、各理論知識在介入點進(jìn)行分配的魚骨圖式的軟件測試?yán)碚撝R體系。
（三）輕視測試工具應(yīng)用，培養(yǎng)的學(xué)生與企業(yè)需求難以銜接
因為軟件測試方法眾多，這也造成有大量可選的軟件測試工具。雖然工具的培訓(xùn)是培養(yǎng)卓越工程師的一個必備環(huán)節(jié)，然而卓越工程師的培養(yǎng)畢竟不等同于職業(yè)教育，不能只是簡單的掌握一個測試工具，而應(yīng)該了解測試工具所體現(xiàn)的測試?yán)碚?、所適用的測試階段以及所應(yīng)用的場景。在進(jìn)行測試工具培訓(xùn)鍛煉的同時，必須結(jié)合所講授的測試?yán)碚摚约霸摴ぞ哌m用的測試過程與測試場景。為了全面的掌握各種具有代表性的測試工具，需要搭建一個測試工具箱。
（四）教學(xué)案例簡單，學(xué)生沒有完整的測試思路
因為理論知識碎片化的講授，也造成目前教學(xué)中只能采用簡單的案例，簡單的案例雖然有助于學(xué)生對具體測試方法的理解，但是難以融會貫通的掌握對一個完整項目的測試。為此，需要基于魚骨圖的軟件測試?yán)碚撝R體系，精心設(shè)計能夠貫穿整個測試流程的案例，并有必要設(shè)計不同類型的案例，形成一個分層次、分類別的測試案例庫，以保證對各種測試方法的掌握。
（五）學(xué)生對軟件測試存在認(rèn)識偏差，缺乏從事軟件測試職業(yè)的意愿
目前國內(nèi)軟件行業(yè)依然蔓延著“重開發(fā)、輕測試”的觀點，這種觀點也延伸到軟件工程專業(yè)的教學(xué)中，導(dǎo)致部分學(xué)生對軟件測試這個職業(yè)存在認(rèn)識偏差。這就要求軟件測試課程需要從原來偏重理論講解、學(xué)生欠缺軟件測試訓(xùn)練的教學(xué)中擺脫出來，應(yīng)該與軟件測試工程師要求的能力培養(yǎng)集合起來，注重理論培養(yǎng)的同時，加強(qiáng)與軟件測試職業(yè)的銜接，增設(shè)對軟件測試工具的訓(xùn)練，加大基于案例與項目的實戰(zhàn)訓(xùn)練，通過工程能力的培養(yǎng)以加深學(xué)生對軟件測試的正確認(rèn)識。
三、總結(jié)
為了執(zhí)行我校軟件工程專業(yè)的卓越工程師培養(yǎng)計劃，解決“軟件測試”教學(xué)中存在的上述問題，我們計劃在已有的教學(xué)改革基礎(chǔ)上，提出“方法為基、過程引導(dǎo)、工具跟進(jìn)、案例貫穿”的“方法-過程-工具-案例”四位一體的教學(xué)方法，以解決目前“軟件測試”課程中存在的諸多問題。
本文分析了“軟件測試”這門課程隨著卓越工程師培養(yǎng)、研究型教學(xué)的要求下在理論培養(yǎng)與工程能力訓(xùn)練等方面逐漸顯露出的各種亟待解決問題，只有充分認(rèn)識到這些問題，才有可能針對問題進(jìn)行教學(xué)改革，進(jìn)而培養(yǎng)理論與功能能力具備的軟件測試人才。
參考文獻(xiàn)：
[1]吳春雷， 剛旭， 張俊三. 基于“卓越計劃”的軟件測試類課程改革[J]. 計算機(jī)教育， 2014，11：88-91.
[2]李月龍. 高校軟件測試課程教學(xué)改革研究[J]. 計算機(jī)教育， 2014，7：16-18.
[3]鄧松. 遞進(jìn)式軟件測試創(chuàng)新人才培養(yǎng)模式研究[J]. 計算機(jī)教育， 2014，7：5-7.
[4]周雪妍， 林澤鴻， 羅秋濱， 路雯靖， 劉玉利. 軟件測試技術(shù)四面體培養(yǎng)模式的探索與研究[J]. 教學(xué)研究， 2013，5：56-58.
[5]張國平等. 軟件工程卓越培養(yǎng)計劃的研究與設(shè)計[C].軟件工程2011年會，2011，10.
[6]劉華東. 構(gòu)建“三三三”培養(yǎng)體系 推進(jìn)本科教育邁向更高目標(biāo)[J]. 中國高等教育， 2012，18：34-36.
[7]吳春雷. 面向應(yīng)用型軟件人才教學(xué)模式的探索與實踐[J].中國成人教育， 2014.04：124-126.
[8]張國平，吳春雷. 軟件工程專業(yè)核心課程案例化教材的規(guī)劃與設(shè)計[J].高等理科教育，2013.10：85-87.
關(guān)鍵詞： 探索性軟件測試； 嵌入式系統(tǒng)軟件測試； 基于會話的測試管理； 敏捷測試
中圖分類號： TN911?34； TP311.5 文獻(xiàn)標(biāo)識碼： 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 引 言
軟件在嵌入式系統(tǒng)中的作用越來越大。軟件的質(zhì)量不僅直接影響任務(wù)的成敗，也關(guān)系著設(shè)備甚至人員的安全。隨著用戶對嵌入式系統(tǒng)軟件質(zhì)量要求的提升，軟件測試已成為嵌入式系統(tǒng)交付前必不可少的環(huán)節(jié)[1]。
經(jīng)典的測試方法要求依據(jù)軟件需求和設(shè)計文檔，遵循既定的測試流程，嚴(yán)格按照預(yù)先設(shè)計的“腳本”開展。因此經(jīng)典測試方法也稱為腳本測試（Script Testing）。隨著嵌入式軟件迭代的加速，給軟件測試留出時間逐漸減少。嵌入式系統(tǒng)軟件測試呈現(xiàn)出一些新特點，包括軟件需求變化快、軟件文檔缺乏、軟件測試周期短、測試時間不足等。
探索性測試（Exploratory Testing）具有在時間短和文檔不完善的情況下，充分發(fā)揮測試人員的經(jīng)驗和能力，快速、高質(zhì)量完成軟件測試等優(yōu)點。已形成了一套管理方法和應(yīng)用模型[2?3]，并在微軟等多個企業(yè)開展了成功的實踐[3?5]。探索性測試方法關(guān)注于實用，對它的研究也多數(shù)集中在實際應(yīng)用方法而不是理論研究上[3，6?8]。
探索性測試是解決嵌入式系統(tǒng)軟件測試需求變化快、軟件文檔缺乏、測試周期短等現(xiàn)實問題的可行手段之一。為了恰當(dāng)運用，需要總結(jié)探索性測試的一般性應(yīng)用方法體系，并探討其與嵌入式系統(tǒng)軟件測試體系的聯(lián)系和沖突。在此基礎(chǔ)上提出適用于嵌入式系統(tǒng)軟件測試的探索性測試應(yīng)用模型。
1 探索性軟件測試的基本原理
探索性測試的概念形成較早，經(jīng)過隨后的發(fā)展已形成了一定的應(yīng)用體系。
1.1 探索性軟件測試的概念
傳統(tǒng)的軟件測試分為測試需求分析、測試策劃、測試用例設(shè)計、測試執(zhí)行和測試總結(jié)等主要階段，依次開展[1]。傳統(tǒng)軟件測試流程依賴于完整、詳實的軟件需求和設(shè)計文檔作為輸入。而在現(xiàn)實的測試任務(wù)中，軟件需求和設(shè)計文檔往往有誤或不完備，這導(dǎo)致腳本測試活動無法正常有效開展。
“探索性測試是同時進(jìn)行學(xué)習(xí)、測試設(shè)計和測試執(zhí)行的一種測試方法；也就是說，測試沒有事先通過確定的測試計劃定義，而是動態(tài)地被設(shè)計、執(zhí)行和修改”[9]。探索性測試（也稱為探索式測試）最早于1983年提出，并在實踐中發(fā)展 [10?11]。與傳統(tǒng)腳本測試相比，探索性測試具有以下技術(shù)特點：
（1） 測試活動的同時性。鼓勵在測試執(zhí)行的過程中，同時進(jìn)行對被測軟件的學(xué)習(xí)和測試設(shè)計。
（2） 關(guān)注測試任務(wù)。更關(guān)注于被測軟件本身和需要測試的問題。
（3） 測試中的演繹推理。通過前一個測試活動的結(jié)果來指導(dǎo)后期測試的開展。
（4） 利用人的優(yōu)勢。關(guān)注于人本身的優(yōu)勢，如判斷、分析、應(yīng)變和協(xié)作的能力。
作為一種敏捷軟件測試方法，探索性測試弱化了對測試的預(yù)先設(shè)計和測試流程的嚴(yán)格要求，而強(qiáng)調(diào)測試的同時性以及人的經(jīng)驗和創(chuàng)造性，關(guān)注于發(fā)現(xiàn)軟件缺陷，持續(xù)優(yōu)化測試工作[12?13]。測試人員在測試?理解?再細(xì)化測試的迭代中，通過測試活動本身不斷深入學(xué)習(xí)被測軟件，從而能夠縮減測試準(zhǔn)備時間，發(fā)現(xiàn)更多缺陷，并使得軟件測試可以在被測軟件說明或文檔不齊全的情況下開展[14]。
1.2 探索性軟件測試的主要方法
探索性測試的概念提出后，經(jīng)過工業(yè)界和學(xué)術(shù)界人士的工作，已初步形成包含經(jīng)驗運用、執(zhí)行策略、管理模型的體系。
1.2.1 探索方法
探索性測試強(qiáng)調(diào)對測試人員的知識和經(jīng)驗的運用。這些經(jīng)驗和知識可分為領(lǐng)域知識、系統(tǒng)知識和一般的軟件工程知識[15]。領(lǐng)域知識指領(lǐng)域規(guī)則、客戶流程和操作場景等，包括用戶使用和具體應(yīng)用領(lǐng)域知識。系統(tǒng)知識是關(guān)于待測軟件的特性和技術(shù)細(xì)節(jié)的具體知識，包括系統(tǒng)級的交互以及個體功能細(xì)節(jié)。一般的軟件工程知識即不需要對被測軟件系統(tǒng)和應(yīng)用領(lǐng)域的具體知識。
豐富的知識和經(jīng)驗是對探索性測試人員的基本要求，以此為基礎(chǔ)，探索性測試的發(fā)揮人的創(chuàng)造性，并由此增強(qiáng)了測試過程的適用性。從工程應(yīng)用的實踐中，已總結(jié)出了一些有用的啟發(fā)式方法。運用這些策略和啟發(fā)式方法，可以幫助軟件測試人員在具備了基本的知識和經(jīng)驗的情況下，盡快熟悉被測系統(tǒng)，并在測試過程中充分運用經(jīng)驗和創(chuàng)造性。
在開展具體的測試活動時，測試人員則可以借助一些啟發(fā)式方法在測試活動中“探索”被測軟件。這些啟發(fā)式的方法是測試中為了發(fā)現(xiàn)可能的缺陷，測試人員常用的一些技巧 [16]。這其中典型的有Hendrickson的檢查單[17]以及Whittaker的漫游方法[3]。這些方法的共同特性是提醒測試人員：
（1） 應(yīng)關(guān)注軟件最主要的功能，并在測試的過程中對軟件的行為進(jìn)行聯(lián)想、質(zhì)疑并發(fā)散，充分利用逆向輸入、邊界情況、近似值、錯誤輸入和特殊值（如0），通過軟件行為的原因、表現(xiàn)等舉一反三；
（2） 應(yīng)刻意構(gòu)造一些特殊的行為，如嘗試遍歷所有輸出、嘗試最長操作路徑、嘗試關(guān)注關(guān)鍵數(shù)據(jù)的演化、打散或集中事物、長時間運行軟件等；
（3） 應(yīng)構(gòu)造測試檢查軟件主要功能往往不關(guān)注的情景，例如啟動和退出、全選、空值、資源過量和緊張、取消操作、重復(fù)、同時運行等。
傳統(tǒng)方法假設(shè)軟件文檔中說明了軟件的各種預(yù)期行為，因而可以通過分析文檔來提取測試預(yù)期（Test Oracles）。然而，在軟件信息不完備的情況下，測試預(yù)期則無法提前預(yù)知。HICCUPPS的啟發(fā)式方法，從歷史（History）信息、顧客形象（Image）在軟件中的恰當(dāng)映射、類似軟件的對照（Comparable Products）、與軟件和商業(yè)聲明（Claims）、用戶預(yù)期（User’s Expectations）、同類產(chǎn)品本身（the Product itself）、明顯的意圖（Purpose）和法律規(guī)章（Statutes）等角度，幫助測試人員在判定測試是否通過[14]。
1.2.2 管理模型
良好的測試管理模型是保證測試質(zhì)量、提高測試效率的必要保障?；跁挼臏y試管理（SBTM）是探索性測試領(lǐng)域中最常用的管理實踐。SBTM將軟件測試活動分解為若干會話（Session）[2]。會話特征如下：
會話圍繞主旨（Charter）開展：即待測試的任務(wù)和目標(biāo)；會話時間較短：時間長度在90 min左右；會話需要記錄：借助會話記錄單；每輪會話需要計劃和總結(jié)：一輪會話執(zhí)行通常是一天，其中包含若干個會話測試。
基于會話的測試過程如圖1所示。當(dāng)接到測試任務(wù)時，測試小組通過對測試任務(wù)進(jìn)行分析討論，確定各會話的主旨。會話主旨包含被測軟件的主題、測試人員的角色、目的、條件、優(yōu)先級、參考文檔、數(shù)據(jù)、思路、預(yù)期等信息[18]。測試項目負(fù)責(zé)人分配各會話測試人員，隨后開展首輪會話執(zhí)行。一輪會話執(zhí)行通常為一天。每輪會話執(zhí)行結(jié)束后，需組織會話總結(jié)，主要借助以下維度進(jìn)行：會話執(zhí)行情況、筆記、缺陷、問題、數(shù)據(jù)、時間分解、人員安排等。通過總結(jié)確定下一輪會話、資源分配。下一輪會話執(zhí)行按照相似的方式開展。在測試達(dá)到預(yù)期時間和充分度要求后，測試結(jié)束，并根據(jù)每輪會話報告單整理測試報告。
圖1 基于會話的測試管理示意圖
會話還可以根據(jù)需要進(jìn)行擴(kuò)展，例如可以包含對會話的風(fēng)險評估和資源統(tǒng)計[4]，也可以將會話延伸為對特定問題的關(guān)注，形成測試的線索[19]。
1.3 探索性測試工具
探索性測試的有效開展同時依賴于工具的輔助。已有一些探索性測試的工具可供參考，例如Microsoft Test Manager（與Visual Studio組件），BBTestAssistant、TestExplorer，Session Tester，Rapid Reporter，Wink。這些工具通過基于錄制回放、截屏和輔助文字信息的方式幫助測試人員記錄探索性測試的執(zhí)行過程，其中Session Tester、Rapid Reporter和Wink是免費的，Session Tester和Rapid Reporter則專門針對會話機(jī)制進(jìn)行了設(shè)計和優(yōu)化。
雖然這些基于錄制回放原理的工具能夠輔助測試人員整理測試報告，但是卻缺少對測試人員運用其知識和經(jīng)驗的指導(dǎo)，對探索性測試的執(zhí)行也缺少引導(dǎo)作用。目前沒有專門的探索性測試流程管理工具，不能起到控制測試流程的作用。有必要針對具體應(yīng)用研發(fā)相應(yīng)的輔助工具。
2 探索性測試的應(yīng)用及其效果
經(jīng)過發(fā)展，探索性測試已在多個企業(yè)運用。人們對探索性測試方法的優(yōu)缺點也有了更加明確的認(rèn)識。
2.1 探索性測試在工業(yè)界的應(yīng)用
微軟是較早實踐探索性測試方法的軟件企業(yè)。微軟在Windows 2000系統(tǒng)徽標(biāo)認(rèn)證、必應(yīng)搜索引擎和地圖、Visual Studio、Windows Media Player等系統(tǒng)、網(wǎng)絡(luò)和桌面應(yīng)用中廣泛使用了探索性測試的技巧和方法，尤其是漫游探索法[3，7，20?21]。在其他公司，探索性測試也成功的運用于互聯(lián)網(wǎng)應(yīng)用行業(yè)以及信息系統(tǒng)的軟件測試中。這些測試任務(wù)往往在軟件文檔不全、測試時間緊、企業(yè)對采用傳統(tǒng)的腳本測試流程不滿意的背景下開展，通過運用基于會話的方法，測試團(tuán)隊都能夠高效的完成測試任務(wù)，甚至發(fā)現(xiàn)了采用傳統(tǒng)方法在類似項目中遺漏的缺陷，在系統(tǒng)上線后也沒有發(fā)生重大問題，軟件項目組對測試團(tuán)隊的滿意度有提升[22?24]。
雖然可能沒有直接說明采用探索性測試，開源軟件的測試往往具有探索性測試的特點。這些測試往往在沒有詳細(xì)的軟件文檔和測試用例設(shè)計的基礎(chǔ)上，利用志愿測試人員的經(jīng)驗和興趣開展 [25]。在敏捷軟件研發(fā)團(tuán)隊中，探索性測試的方法也多有運用[26]。成功案例包括與XP和Scrum敏捷軟件開發(fā)的結(jié)合[5，27]。
除了在工業(yè)界的運用，也有學(xué)者對敏捷軟件測試的應(yīng)用進(jìn)行了系統(tǒng)的研究和討論。Itkonen等人在芬蘭多個軟件公司中研究了測試人員對探索性測試的使用方法、效果和評價[28]，對探索性測試的優(yōu)缺點、應(yīng)用條件合場景以及推薦的方法進(jìn)行了總結(jié)[29]；通過研究和實驗，發(fā)現(xiàn)了探索性測試在缺陷檢測能力上能達(dá)到甚至超過傳統(tǒng)腳本測試的水平[6]。Naseer，史亮和高翔也總結(jié)了探索性軟件測試在瑞典軟件公司、國內(nèi)的微軟和淘寶等企業(yè)運用的經(jīng)驗，對探索性測試的活動進(jìn)行了總結(jié)[8，10]。Bach等人還成立了公司專門從事測試方面的研究和推廣。另外，也有一些研究將探索性測試思想與測試自動化方法結(jié)合[30]，或利用探索性測試的思想提高測試效率和質(zhì)量的工作[5]。
從目前的應(yīng)用情況來看，探索性測試技術(shù)多數(shù)是在桌面應(yīng)用、B/S架構(gòu)信息系統(tǒng)等領(lǐng)域的應(yīng)用，在嵌入式系統(tǒng)軟件測試中的應(yīng)用較少。
2.2 探索性測試的優(yōu)缺點
經(jīng)過實踐，總結(jié)上述對探索性測試的應(yīng)用，能夠發(fā)現(xiàn)，探索性測試尤其適用于要求在短時間內(nèi)發(fā)現(xiàn)被測軟件一些重要缺陷或事先沒有能夠進(jìn)行詳細(xì)測試設(shè)計的情況；但也具有測試過程不易控制、測試文檔不全等問題。因此，在具體領(lǐng)域中運用探索性測試技術(shù)時，有必要根據(jù)領(lǐng)域特性，設(shè)計適合的測試流程，揚(yáng)長避短。
一般認(rèn)為探索性測試的主要優(yōu)點和缺點如下：
優(yōu)點：便于利用人員經(jīng)驗；適合于從用戶角度的測試；適用于缺少軟件文檔、測試時間緊情況；靈活且適應(yīng)性強(qiáng)；對測試人員和開發(fā)人員的反饋較快；能夠為測試帶來新內(nèi)容，降低“殺蟲劑”效應(yīng)。
缺點：缺少足夠的文檔，不易度量覆蓋率；測試統(tǒng)計數(shù)據(jù)不足，不利于決策；對測試人員經(jīng)驗要求較高；在測試人員經(jīng)驗不足、管理不嚴(yán)格的情況下，可能會影響測試質(zhì)量；如缺少恰當(dāng)工具，則不利于缺陷復(fù)現(xiàn)。
3 探索性測試在嵌入式系統(tǒng)中的應(yīng)用
探索性測試技術(shù)卻是能夠應(yīng)對嵌入式系統(tǒng)軟件測試中軟件需求變化快、測試周期短、軟件文檔不全等現(xiàn)實問題的可行方法之一。本文首先分析探索性測試在嵌入式軟件測試中應(yīng)用的需求和困難，然后探討探索性測試技術(shù)與嵌入式系統(tǒng)軟件測試體系的結(jié)合方法，對應(yīng)用模型提出建議，并對應(yīng)用中可能的問題和后續(xù)研究進(jìn)行討論和展望。
3.1 探索性測試一般性方法的適用性
隨著IT技術(shù)的發(fā)展和各國在國防、智能電網(wǎng)、物聯(lián)網(wǎng)、智能手機(jī)等行業(yè)投入的加大，嵌入式軟件產(chǎn)品越來越多，測試任務(wù)越來越重，往往難以保證充裕的測試時間。軟件需求和開發(fā)文檔存在不準(zhǔn)確、不完備的情況。而同時，嵌入式軟件的測試具有較強(qiáng)的領(lǐng)域特性，領(lǐng)域內(nèi)測試人員對被測系統(tǒng)的經(jīng)驗比較豐富。因此，需要也有條件在嵌入式系統(tǒng)軟件中開展探索性測試，以降低對軟件需求和設(shè)計規(guī)約的依賴、發(fā)揮探索性測試對軟件變化的適應(yīng)性和充分利用測試人員經(jīng)驗的優(yōu)勢。
然而，探索性測試技術(shù)在嵌入式領(lǐng)域中的應(yīng)用卻較少。探索性測試的通用方法沒有直接用于嵌入式系統(tǒng)軟件測試的原因主要是 [1，31?33]：
（1） 軟件測試文檔：探索性測試不鼓勵測試花費精力在策劃和準(zhǔn)備上，而測試執(zhí)行記錄風(fēng)格隨意性較大，不利于形成統(tǒng)一、完備的測試文檔；這與按照國標(biāo)和軍標(biāo)中對完整的軟件測試文檔的要求沖突。
（2） 軟件測試充分性度量：不易度量測試覆蓋率，不易評價測試質(zhì)量。
（3） 軟件測試過程控制：缺少對配置和測試流程的系統(tǒng)性管理，可能造成測試過程失控。
3.2 探索性測試應(yīng)用模型探討
為了解決嵌入式系統(tǒng)測試中軟件需求變化快、測試周期短、軟件文檔不完備等現(xiàn)實問題，有必借鑒探索性測試技術(shù)在信息系統(tǒng)、網(wǎng)絡(luò)應(yīng)用、操作系統(tǒng)等方面的成功經(jīng)驗，將其融入嵌入式系統(tǒng)軟件測試體系中來[24，34]。為了與相應(yīng)的軟件測評體系和標(biāo)準(zhǔn)匹配，必須對探索性測試通用方法進(jìn)行調(diào)整，設(shè)計探索性測試在嵌入式系統(tǒng)軟件測試的應(yīng)用模型。
一種可參考的“腳本會話模型”如圖2所示，是以探索性測試一般性理論、探索性測試各特性在各型產(chǎn)品軟件的適用性研究為基礎(chǔ)，將探索性測試與傳統(tǒng)腳本測試相結(jié)合的軟件測試模型。為充分利用兩者的優(yōu)勢，腳本會話模型的整體仍以傳統(tǒng)腳本方法為基礎(chǔ)，從而利用腳本測試管理中測試文檔完備和過程管理控制完善等優(yōu)點，而在測試執(zhí)行過程中充分發(fā)揮探索性測試的靈活、高效優(yōu)點，引入會話、漫游測試法等探索性測試等方法，同時借助嵌入式系統(tǒng)軟件測試典型數(shù)據(jù)復(fù)用庫來實現(xiàn)對測試人員經(jīng)驗的固化和復(fù)用。
圖2 嵌入式系統(tǒng)軟件腳本會話測試模型
如圖3所示，腳本會話模型整體流程遵循經(jīng)典的腳本測試流程，但發(fā)揮了探索性測試對經(jīng)驗的利用和靈活性的特點。
圖3 腳本會話測試模型流程框架
包含以下步驟：
（1） 測試策劃和設(shè)計階段；借助領(lǐng)域軟件測試典型數(shù)據(jù)復(fù)用庫（測試人員經(jīng)驗的固化體現(xiàn)）形成測試項、構(gòu)造測試用例，降低對軟件需求和設(shè)計文檔的依賴，初步完成測試需求的提取和測試用例的設(shè)計。
（2） 測試執(zhí)行階段：測試執(zhí)行以基于會話的方式開展，并對一般會話進(jìn)行擴(kuò)展。根據(jù)測試設(shè)計和計劃，確定每個會話的主旨、用例和測試方法。在每一次會話中，測試人員可以結(jié)對開展測試執(zhí)行，根據(jù)預(yù)先指定的漫游策略和啟發(fā)式方法，針對一個測試項進(jìn)行探索，并補(bǔ)充測試用例。測試人員在會話結(jié)束后整理會話記錄單。根據(jù)本輪會話執(zhí)行情況，記錄缺陷、改善測試設(shè)計，并準(zhǔn)備下一輪會話。如此迭代直到測試結(jié)束條件滿足，測試執(zhí)行結(jié)束[35]。
（3） 測試總結(jié)階段：借助測試執(zhí)行中各個會話報告單，總結(jié)和報告缺陷。
3.3 討論和展望
探索性測試在互聯(lián)網(wǎng)和桌面應(yīng)用已經(jīng)成功實踐[34]，而在嵌入式領(lǐng)域應(yīng)用仍然較少。在嵌入式系統(tǒng)軟件測試中運用諸如腳本會話模型的探索性測試技術(shù)時，應(yīng)注意以下三點問題：
（1） 測試過程管理和文檔。必須重視探索性測試的過程管理以保證測試過程受控。同時在適當(dāng)?shù)碾A段應(yīng)編寫相應(yīng)文檔作為測試階段性成果，并在測試執(zhí)行完成后更新相應(yīng)文檔。
（2） 結(jié)合具體領(lǐng)域。具體領(lǐng)域的軟件測試典型數(shù)據(jù)復(fù)用庫可以看作是對該領(lǐng)域軟件測試人員測試經(jīng)驗的固化，是軟件測試團(tuán)隊的組織資產(chǎn)，有助于團(tuán)隊新成員快速熟悉被測系統(tǒng)，提高探索性測試的效率。
（3） 針對測試團(tuán)隊和項目制定具體策略。制定探索性測試中的典型方法的應(yīng)用策略，并注意收集反饋，在實踐中持續(xù)改進(jìn)。
探索性測試作為一種在互聯(lián)網(wǎng)、操作系統(tǒng)等領(lǐng)域成功運用多年的測試技術(shù)和理念，可以與其他軟件測試技術(shù)結(jié)合，共同推進(jìn)嵌入式軟件測試質(zhì)量的提升?？赡艿慕Y(jié)合方向包括（但不限于）：
（1） 基于模型的測試和驗證。借助軟件模型可發(fā)現(xiàn)隱藏在軟件界面和正常使用流程下的交互，其中可能隱藏了大量的缺陷；借助模型檢驗工具提供的反例[36]，測試人員還可以對軟件進(jìn)行更加深入的探索；
（2） 測試自動化。嵌入式系統(tǒng)軟件需要處理傳感器送來的大量數(shù)據(jù)，采用自動化方法能夠有效減少測試人員的工作量；結(jié)合探索性測試的技術(shù)，也能夠為測試用例約簡和測試預(yù)期問題提供解決途徑[34，37?39]；
基于剖面的測試：構(gòu)造嵌入式系統(tǒng)的操作剖面和用戶剖面，輔助測試人員能有選擇性地對系統(tǒng)進(jìn)行探索[40??41]。
4 結(jié) 語
探索性測試技術(shù)經(jīng)過研究和發(fā)展，已形成了一套可行的體系。探索性測試在嵌入式系統(tǒng)軟件測試中的應(yīng)用還較少。經(jīng)過對探索性測試體系的全面研究，能夠更好的理解這種方法在嵌入式系統(tǒng)軟件測試中的適用性，并為融合探索性測試與傳統(tǒng)嵌入式軟件測試方法，形成適用于嵌入式系統(tǒng)軟件測試的探索性測試應(yīng)用模型提供思路和方向。
參考文獻(xiàn)
[1] 康一梅，張永革，李志軍，等.嵌入式軟件測試[M].北京：機(jī)械工業(yè)出版社，2008.
[2] BACH J. Session?based test management [J]. Software Testing and Quality Engineering， 2000， 2（6）： 1?4.
[3] WHITTAKER J A.探索式軟件測試[M].北京：清華大學(xué)出版社，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] 柳溪，馬康，劉智.融合探索性與腳本方法的第三方軟件測試模型及其應(yīng)用[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] 中華人民共和國國家質(zhì)量監(jiān)督檢驗檢疫總局.GB/T 25000.51?2010軟件工程 軟件產(chǎn)品質(zhì)量要求與評價（SQuaRE）SQuaRE指南[S].北京：中國標(biāo)準(zhǔn)出版社，2010.
[32] 中華人民共和國國家質(zhì)量監(jiān)督檢驗檢疫總局.GB/T 8567?2006計算機(jī)軟件文檔編制規(guī)范[S].北京：中國標(biāo)準(zhǔn)出版社， 2006.
[33] 中華人民共和國國家質(zhì)量監(jiān)督檢驗檢疫總局.GB/T 9386?2008 計算機(jī)軟件測試文檔編制規(guī)范[S].北京：中國標(biāo)準(zhǔn)出版社，2006.
[34] 史亮，高翔.探索式測試實踐之路[M].北京：電子工業(yè)出版社，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...