探索性研究的特點精選(五篇)

序言：作為思想的載體和知識的探索者，寫作是一種獨特的藝術，我們為您準備了不同風格的5篇探索性研究的特點，期待它們能激發您的靈感。

篇1

（一）教育作用的潛隱性。隱性教育是一種受教育者在心理上并未察覺的無意識教育，它與顯性教育的根本區別在于教育過程的隱蔽性。這種潛隱性可以從如下兩方面進行理解和把握: 其一，教育者傳遞信息方式上的隱蔽性。教育者并非滔滔不絕地灌輸大道理，也并非引經據典地直率勸導、而是有意識地將教育的目的和意向滲透到具體的人、事、物及活動行動過程中, 以含而不露的方式，引導大學生自然融于教育者創設的教育情境中。其二,大學生接受教育的隱蔽性，即無意識性。這種隱性教育的發生與大學生的好奇、興趣、尊重、認可等心理需要直接相關，因此，他能夠在不帶有任何逆反性與排斥性的前提下，用一種潛藏于內心深處的攝取機制，在非目的性、無意識狀態中接受熏陶和影響，進而達到受教育的目的，實現教育者的原始教育初衷。

（二）教育途徑的多樣性。隱性教育不似顯性教育那樣主要依靠面對面上課等的形式，以自上而下嚴肅的教學方式對大學生施加直接的影響，而是打破了傳統的固定形式、固定時間、固定地點進行集中育的封閉式教育模式限制，使大學生在所有時空范圍內時時處處接受到教育，所以我們說隱性教育是一種無課堂形式、跨時空的無處不在的教育。

（三）教育內容的豐富性。隱性教育是一種多層次、全方位的教育，美國學者德里本曾指出：“在學生良好道德的形成中，來自他們在學校環境中的經驗的東西，與教給他們的東西一樣多。”隱性教育的內容包羅萬象，不僅包括學校的硬件環境和精神文明軟件建設，還包括大學生參加的各項社會實踐活動和其它文體活動，這些方方面面的隱性教育資源，以不同的方式、不同的角度、不同的途徑、不同的層次對大學生施加全面的、綜合的、潛在的、深遠的影響。可見，隱性教育的內容是豐富多彩的、分散不定的、靈活多變的、隨處可見的。

（四）教育參與者的自主性。關注師生之間的對話與相互理解，這才是充滿人性光輝與人文關懷的教育，傳統顯性教育偏失的根源，在于對現實生活中主體需要的疏離。隱性教育是一種以受教育者為主體的自主性教育，而不是居高臨下的權威式的訓導和灌輸。在教育過程中，大學生不再是被動的教育客體，而是自愿、自主的主體，參與哪種特定的活動、如何參與、怎樣參與都由受教育者自主選擇和自行決定，這就避免了因直接的、明顯的、外部強加的意圖而使大學生產生逆反心理和對抗情緒，從而使教育效果最終嚴重打折現象的發生。

（五）教育目的的激勵性。隱性教育的目的是要喚醒大學生的潛意識進而養成大學生良好的道德素養和行為習慣。人的潛意識，有人把它比喻為海上冰山的水下部分，它難以感知，卻是人行為的一種原動力。隱性教育就是要激活這一原動力。這種教育效果的凸現必定是日常教育量的長年積累與學生潛意識的升華共同作用的結果，如果教育量積累中斷或積累過程中價值觀發生混亂，就容易出現“前功盡棄”的現象。值得關注的是，這種“前功盡棄”的現象并不鮮見。因此在隱性教育過程中，教育工作者一定要耐得住性子、沉得住氣，使教育內容前后相繼，在教育評價中不自欺欺人，用簡單枚舉法和縱橫對比法說明整體教育效果，激活大學生的潛意識，更重要的是讓他們知道不足，讓他們看到與同齡人的差距，向他們展示新的發展藍圖，使他們形成好的性格，養成終生受益的習慣。這需要我們樹立潛移默化的思想，相信隱性教育的強大力量，相信教育對象的美好未來。

（六）教育形式的隨機性。隱性教育的形式可以是多種多樣，多姿多彩的，它既可以是一次輕松愉快的對話或聊天，也可以是共同參加一項活動，如聽一場精彩生動的演講，看一出寓意深刻的話劇，觀一場精彩激烈的比賽等。為此我們可以說隱性教育無時不在，無處不在，我們平時獲得的各種素質教育其實都蘊含在無限的隱性教育之中。

與此同時，隱性教育也為大學生的個性培養和發展提供了無限的可能。由于隱性教育具有個別性、隱含性和隨機性等特點，恰好與當今大學生日趨增長的自尊、自制、自主相吻合，與時下大學生注重個人隱私、推崇自我、崇尚奮斗緊密相聯。

（七）教育機制的綜合性。一所學校如果只有班組里嚴格的紀律，而在操場、食堂、實驗室等其它場合被允許紀律松懈，那么班級的紀律要求很難使學生受到制約，他們在班級的守紀往往只是一種條件反射行為而已。如果學校的基本規章制度、道德規范要求教師可以例外的話，例如在實行禁煙的校園內教師可以毫無顧忌地抽煙，那么這個學校的教育效果必然大打折扣，失去權威性。因此學校在隱性教育中應該十分注重教育資源開發的綜合性。這種綜合性主要體現在基本行為道德素養上，不僅做到師生一致，而且還要求教師成為學生的楷模；在基本的價值觀、世界觀教育中，要做到學科一致、教學、教育思想與辦學思想相統一。

二、開發隱性教育資源的途徑

（一）滲透隱性課程于顯性課程之中。大學生的大部分時間是在課堂中度過的，這使得存在于教學活動中的隱性課程對大學生彌足重要。顯性課程中的隱性課程滲透，應在把握課堂教學的知識性、系統性、嚴謹性、前沿性的基礎上，在教育者的價值觀念、教學態度、授課方式、個性特點與師生關系上下功夫，使整個教學活動在寬松、和諧、自然的氣氛中進行，具有生動性、趣味性、愉悅性，引導學生在理性和感性的交匯中，有機地滲透思想道德、心理素質、創新精神等的教育和培養。課程目標擬分為情意目標、認知目標和行為目標，隱性課程的目標可以重點充實到情意目標和行為目標中。

（二）開展豐富多彩的校園文化活動。精心設計和組織開展內容豐富、形式新穎、吸引力強的活動課程，開發存在于活動課程中的隱性課程，可以使大學生在活動參與中受到潛移默化的影響，思想感情得到熏陶、人文修養得到提升。

通過專題輔導報告會、祭掃革命烈士墓等多種形式開展主題活動，把自然、社會、人文等方面的知識蘊藏在主題活動之中；通過參與“校園文化節”、“文明宿舍”、愛心捐助等活動，一方面可以滿足展示自我、發展興趣、發揮特長的需要，另一方面還可以培養大學生的合作意識、團隊意識、責任感和集體主義精神；通過開展“創建文明校園、文明班級、文明宿舍，做文明大學生”的道德實踐活動，把隱性教育的要求和任務融入大學生的學習生活之中；通過舉辦科技活動、藝術活動、體育活動和開展黨團活動、社團活動、社會實踐活動，不斷提高大學生的綜合素質。

（三）健全美化完善學校物質空間環境。對學校物質空間進行系統規劃，可考慮以下幾點因素：1.學校的自然環境要適應學生的心理特點，盡力揚長避短，做到凈化、綠化和美化；2.建筑設計要美觀實用，更要適合學生的心理與審美需求；3.室內設計要考慮光線、擺設以及學生的座位排列等因素；4.設施設計，圖書資料、文體器材、實驗儀器等方面物質設施的安排也應能對學生的心理產生積極影響；5.色彩匹配，即校園內外建筑、花草樹木等色彩的協調匹配；6.人物形態。正面積極的師生服飾樣式，容貌特征，行為表現等人物形態也能潛在地促進學生良好的心態和心理素質的構成。

（四）重視校園精神建設。校園精神是學校師生員工共同習得、信守的基本信念、價值標準、道德風尚及精神風貌。重視校園精神建設，開發存在于校園精神中的隱性課程，有利于大學生強化知識、文化、道德方面的修養，培養良好的教育與自我教育意識，推進成才與自我成才的統一。

高校教師要不斷追求人格的自我完善，以德修身、嚴謹自律、率先垂范、言傳身教，以良好的道德品質和崇高的人格魅力給大學生以潛移默化的影響。良好的校風、學風和班風是無形而強大的精神力量，也是培養大學生思想品德、提高大學生思想道德素質和開展隱性教育的有效途徑和方法。注重對校風、學風和班風的建設，形成健康、向上、積極、進步、文明、和諧的良好風氣是實施隱性教育的最佳途徑之一。

篇2

摘 要 本文通過對岷山中學游泳為主的體育特色模式建立的依據、背景，以及2010年至2011年間游泳特色項目開展的情況、組織形式以及取得的成果、目前所遇到的困難，為以后更好的建設及發展提供依據。

關鍵詞 體育特色 游泳 開展 訓練點

中國的素質教育已推行了多年，國家大力推行體育與藝術2+1，逐步形成了以某項體育或藝術為特色的學校，為提升學校的核心發展力必須走特色發展之路，岷山中學從游泳這一體育特色建設入手，帶動學校全面發展，并最終成為以游泳為特色學校，為把游泳這一特色項目做好，做強，岷山中學選擇與市級游泳運動隊訓練點相結合的游泳特色模式，這一模式開展為發展學校體育特色創造了新的方法。

一、什么是學校體育特色與市級游泳訓練點相結合開展學校體育特色模式

與游泳訓練點相結合的學校體育特色模式是體育局與學校共同管理、聯合出資，學校游泳普及與體校訓練點相結合的模式。這一模式達到學校每位學生學會游泳，開展特色游泳項目，體育局培養游泳人才、向市、省、國家輸送游泳人才的雙贏的效果。

二、體育局與學校共建學校游泳特色的優勢分析

（一）學校需要體育局的支持來實現的學校游泳特色項目開展的高質量，游泳項目不像其它的如籃球，田徑、等體育項目，校內本身就有場地，游泳特色的開展需要游泳池，而學校本身沒有游泳池，體育局管轄內的體育游泳訓練中心正在學校的對面，所以從游泳特色實施的場地上說，學校需要與體育局的合作才能很好地開展游泳為特色的項目。從經費上來說，以游泳為特色的項目，該項目在實施過程中的各個方面會產生的費用，其中有場地，專業教師聘任，接送學生汽車費用，取得運動成績后的教練獎勵費用，以及器材的費用。這些費用80%來自于體育局，20%從學校的辦學經費中支取。這很好地解決了，學校辦學經費的不足的問題。游泳這一項目是一個技術性較強的體育項目，需要專業的游泳老師，普通的體育老師勝任不了專業化的教學，體育局有這方面的專業人才。解決了學校辦特色需要的專業游泳教練。

（二）體育局需要以學校游泳特色為基礎來培養北侖區的游泳方面的人才，為北侖區的體育健兒在浙江，全國，乃至世界上取得名次打下基礎，提高北侖區的知名度。中國的人才選拔的制度，使家長們更加重視學生的文化學習成績；獨生子女的吃苦耐勞精神的缺乏；成功的運動健將只是鳳毛麟角，更多的學生要從體校退下來，退下來后很難再考上大學，工作難找；這些因素的影響使很多家長不會輕易把學生送到少體校。體育局立足于學校來發現、培養游泳人才，能讓有先天優勢的學生既能在家的附近接受專業化的訓練，培養自身的專業技能，又能在正規的學校完成國家所要求的基本課程，使學習與訓練兩不誤。在學生的游泳有一定水平時再向上輸送，把握更大，退回的現象更少。這樣才能充分得到家長與社會的支持，從而解決了體校人才難招，招了難留的現象。岷山中學游泳訓練開展兩年多，以下的數據充分說明這一情況。

（三）體育局給學校提供了專業的游泳教師使學生學習游泳更加專業化，學校有游泳專業教師共三位，其中一位是學校體育教師，其他二位是寧波市運動訓練學校派下來的專業游泳教師，受寧波運動訓練學校的直接指導與培訓，他們不僅有專業的訓練知識也有豐富的教學經驗，并定期利用業余時間在上海進行專業教學培訓，學習最新的教學與訓練理念。

三、學校游泳特色開展

（一）學校特色教育，游泳課目標

相對于游泳資源的緊缺，我們學校只能對小學一年級的小朋友進行上課，讓每位學生能基本掌握各種游泳技能，參照目前世界游泳發展的新動向與趨勢，游泳基本動作的規范化和多樣化已被廣泛應用。很多成功的教練都提出，對低年級教學要安排大量的打腿和分解練習，過多的配合只是叫快，不叫好。這是我們普訓所遵循的運動規律。第一學期目標：在12節游泳課中，讓90%的學生熟悉水性，并能連續換氣，60%的學生能完成自由泳打腿的基本動作。20%的學生能完成25米自由泳打腿。第二學期是提高自由泳打腿的技術動作，讓學生能更熟練，更規范地去完成此項練習，從而進一步提高其速度。

（二）學生游泳上課時間

每周每個班級上一次課，上課時間為下午2：35—3：15。

上課地點：北侖區游泳訓練中心，中心良好的運作方式，保證了水質與環境的安全，讓學生家長放心。

上課接送：由北侖區客運中心車輛接送，學生路上的保證安全。

上課與路上的學生管理：由班主任與二位游泳老師帶隊。

上課時的安全管理：北侖區游泳訓練中心的救生員負責安全。

（三）學生游泳課教學學期計劃示例：

表1

課次 內容 目標

1—2 1.游泳基本安全知識介紹和解說。

2.下水熟悉水中環境。 1.讓孩子了解游泳的好處以及如何做好安全防范措施。

2.加強對水的了解，克服心理恐懼。

3.培養孩子在水中自由翱翔的興趣。

3—4 讓學生了解并掌握水中呼吸技術。

在培養興趣的基礎上逐漸掌握接觸水的第一本領：水中呼吸。

5—6 1.水中呼吸+漂浮技術。

2.一學期游泳總結及評定。

1.增加難度，由在陸地站立的轉變到水中漂浮。

2.通過考試和評定，了解成績情況，為下學期的工作做鋪墊。

7—8 1.帶背漂的仰泳漂浮。

2.仰漂和俯漂的結合練習。 兩種漂浮技術結合練習建立游泳基本身置：流線型姿勢。

9—10 1.嘗試一部分基礎好的學生拿掉背漂仰泳打腿，基礎差的繼續鞏固。

2.仰泳打腿的考核和評定。 讓大多數學生掌握游泳的基本技能，并能加以運用。

篇3

【關鍵詞】箱線圖；冪變換；展布水平圖；降水量

一、研究背景及發展

數據分析分為兩大階段，探索階段和實證階段。探索性數據分析可以分離出數據的模式和特點，把它們有力地給分析者。探索性數據分析（exploratory data analysis，簡稱EDA）于上世紀六十年代被提出，并逐步發展，現今已經應用非常廣泛。具體來說，是對調查者觀察得到的原始數據直接進行預處理凈化，做出箱線圖、莖葉圖等等，直觀展現出數據的結構等。并沒有先做出相關的假定或者在部分假定條件下進行分析。即在對數據的基本特點還沒有認識的情況下，無法選取相應的統計方法進行相關分析，此時可以應用探索性數據分析，挖掘數據之間的相關特征，給出之后實證分析的大致方向，此時再運用統計方法則會顯得更加合理，更科學有效。為后來的數據實證分析做鋪墊。

二、實例研究

如下，選取數據為中國16個大城市三月到10月的降水量，數據顯示如下，可知，若直接運用統計方法，如大海撈針，不知何種假定下，選取何種統計方法較為合理。則先運用探索性數據分析中的相關方法。為使結果直觀顯示，運用箱線圖作圖，結合R軟件編寫代碼。

（一）未作冪變換前的箱線圖

箱線圖是一批數據的五數總括的圖示，展現了這個批的數據結構要點。從箱線圖我們可以發掘出一個批的某些特性：位置、展布、偏度、尾長、邊遠數據點（離群點）。

但是初始箱線圖也有缺點，如遠離原點的批可能比靠近原點的批，有更大的展布，體現在圖形上則會出現有些箱線圖擠在一起，較為扁平，不利于數據分析。因此，若用同一尺度來繪圖，將難以看出靠近遠點的批的細節。

為了改善箱線圖的這個缺點，我們可以做一些適當的變換，使得這些批的變異性更加一致。我們要從數據本身得到關于數據變換的一些指導，一個比較適合的標準就是“展布對水平圖”，它能夠建議一個冪變換，有助于把跨越這些批的不同水平的展布變成相等。

用箱線圖比較幾個批的數據，三搜集中國16大城市3月到10月的降水量數據，單位為毫米，由于數據龐大，不在此列出。數據來源于2012年統計年鑒。

構造出的箱線圖可以看出位置，展布，尾長和離群值截斷點。圖中四分數相對于中位數的位置，可以看出偏度，若中位數離下四分數，比離上四分數近得多，則表明這個批是正偏的，反之則為負偏。由以上箱線圖可知，效果不是很好，有較多的離群值截斷點，不便于我們對數據的分析。

由上圖可知，第13個箱線圖（廣州），距離遠點較遠，其降水量不僅有較大的展布，且分布較均勻。第16個箱線圖（烏魯木齊），其降水量展布較小，距離遠點較近。由此可見，箱線圖的局限性，為了解決展布對水平的依賴，以及離群值對數據分析的干擾，下面將對其進行改進。做相應的冪變換。

（二）冪變換（改善箱線圖）

用R對所有數據進行平方根變換，得到新的展布對水平圖。

則與前一個展布對水平圖比較得知，此圖沒有明顯的趨勢，展布對水平不再有依賴性，則說明變換有效，達到了目的。

改善之后的展布水平圖與箱線圖如下。

可知，這個變換確實在幾個重要方面改善了數據。我們可以知道，第13個箱線圖（廣州）的降水量普遍較高，其最小值都高于第2個箱線圖（天津），我們得出，即使是在雨季，天津降水量都比廣州要小，地域差異使得降水量有如此大的差異。第11個箱線圖（武漢）的降水量有一個離群點，是在7月，降水量為389.7，可見武漢的雨水集中在7月，在夏天是一個降水量較大的城市。

三、結論分析

通過運用探索性數據分析和R軟件結合的方法，數據被有效地處理與改善了。可見，探索性數據分析技術能幫助我們正確的處理數據，與R軟件結合以后，擁有更加強大的功能，通過冪變換，箱線圖得到了明顯的改善，減少了離群值，展布也不再依賴于水平。總之，探索性數據分析在當今軟件計算機如此發達的時代，其作用得到了越來越充分的體現，沒有探索性分析，證實性分析往往是盲目的， 缺乏根據的； 沒有證實性分析， 探索性分析則永遠是一次不完整的的統計分析。正確運用探索性數據分析與R軟件結合的方法，對數據進行處理與分析，可以帶來很大的便利。

參考文獻：

[1] David C Hoaglin Frederick Monsteller.John W.Tukey著，鏈、郭德媛、楊振海翻譯校訂.探索性數據分析[M].中國統計出版社，1983.

[2]李世勇，胡建軍，熊 燕，歐陽虹.2004年我國卷煙焦油量的探索性數據分析[J].2005年第7期.

篇4

關鍵詞： 探索性軟件測試； 嵌入式系統軟件測試； 基于會話的測試管理； 敏捷測試

中圖分類號： 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...

篇5

關鍵詞：軟件測試；測試方法；探索性測試

中圖分類號：TP311.52 文獻標識碼：A 文章編號：1007-9599　（2012）　19-0000-02

1 引言

面對當今信息化水平的不斷提高，軟件測試技術也取得了不斷的發展，探索性測試逐漸登上舞臺，受到了軟件測試人員的重視。探索性測試是一種新的測試思維方式，應該是測試人員必須掌握的。探索性測試是軟件測試領域比較前沿的理論，特別適用于那些事先沒有能夠進行詳細測試設計或者要求在短時間內發現被測軟件一些重要缺陷的情況，使用探索性測試能顯著提高軟件測試的效率[1，5]。

探索性軟件測試具有強大的缺陷發現能力，而這一能力是其得到眾多青睞的重要原因，如微軟就建立了專門的探索性測試團隊，探索性測試也是微軟官方的驗證測試方法之一，部分第三方軟件如果需要取得微軟的兼容證書，必須通過微軟的探索性測試[2]。

2 探索性測試的概念和基本思想

2.1 探索性測試的概念

探索性測試的定義很多，探索性測試的創始人James　Bach　對探索性測試的定義為[2]：了解被測軟件，設計測試用例，執行測試同時進行的軟件測試技術。簡單點說就是事先不進行計劃和設計的一種特殊類型的測試，由有經驗的測試人員根據實際情況，憑借自身的測試經驗和對系統的認識來進行測試，而正是因為這一特點，往往能幫助測試人員在測試設計之外發現更多的軟件缺陷。

2.2 探索性測試的基本思想

探索性測試強調系統軟件學習、測試設計和測試執行的同時進行，這樣對傳統測試方法中要求測試文檔（計劃、設計）必須非常詳細和明確、測試用例的設計和執行必須依賴開發文檔、測試執行的過程必須依照測試用例的設計等都是一個很好的補充。

探索性測試強調的同時性是相對于傳統軟件測試過程中的“先設計，后執行”來說的，測試人員通過測試來不斷學習被測系統，同時把學習到的關于被測軟件的更多信息通過綜合的整理和分析創造出更多的關于測試的注意。傳統測試方式強調設計完善的測試用例，測試人員嚴格按照測試用例執行測試，而探索性測試是一種新的測試思維，強調的是測試過程中要有更多的發散思維，這也是與傳統測試方式的最大區別。探索性測試并不是孤立的測試方法，我們在實際的測試過程中都會不自覺的使用它，比如當開發人員修改完一個缺陷后，我們在進行確認時，一些有經驗的測試人員不僅僅是對該缺陷進行確認，他們會進行一些額外的測試來探索修復該缺陷是否對某些功能產生影響，這就是典型的探索性測試，我們只有不斷的豐富自身測試經驗、提高敏銳性，才能夠在合適的測試項目、適當的時機引入探索性測試，達到測試目的。

3 探索性測試的特征及優缺點

探索性測試事先沒有明確的測試計劃，也沒有詳細的測試說明，要根據測試的實際情況來及時的設計出測試用例，它是測試人員依據測試任務進行主動的、探索式的測試。這意味著探索性測試的開展要比傳統測試具備更多的測試經驗和主觀能動性，而且要具備更強的測試用例設計能力，此外，還需要很強的觀察能力，思維能力。

3.1 探索性測試的特征[4]：

探索性測試強調軟件系統學習、測試設計和測試執行同時進行；測試人員在測試的過程中不斷學習被測試系統，然后再根據學習的內容來指導測試，是一循環過程；探索性測試的重點是創新和主觀能動性。

3.2 探索性測試的優點：

比傳統的測試方法靈活；測試文檔可以不充分；能夠發現測試設計以外的缺陷；增強了發現難以發現的缺陷的能力；可以激發測試人員的創造性和主觀能動性。

3.3 探索性測試的缺點：

事先對測試工作沒有一個整體規劃，不利于測試的標準化；測試可能存在重復性，不能確定哪些測試已經被執行過；難于駕馭，測試結果難以評估，難以在軟件測試工作中大量普及應用。

4 探索性測試方法與傳統測試方法的比較

4.1 傳統測試方法

以V模型和W模型為代表的傳統理論的軟件測試，要求在軟件設計開發的同時就引入軟件測試。例如在V模型中，如圖1所示[3]，在軟件開發的系統需求分析、軟件需求分析、軟件概要設計、軟件詳細設計階段分別需要引入系統測試、配置項測試、部件測試、單元測試。這些測試都要求事先設計好測試用例，寫好測試腳本。在實際的測試過程中往往會出現這樣的情況，測試工程師花在測試設計和報告填寫上的時間遠遠超過了真正的執行測試時間。

4.2 探索性測試方法

如圖2模型所示，使用探索性方法進行軟件測試，首先在了解軟件需求和開發文檔，了解測試任務、軟件運行環境、測試環境制定測試計劃的同時，根據已經掌握的情況，對被測試軟件進行初次的測試用例設計，利用設計出來的測試用例，進行探索性軟件測試執行。將測試的執行結果，一方面反饋到設計好的測試用例中去，對已有的測試用例進行修改；另一方面又可以進一步利用對測試過程及測試結果中的信息，加強對軟件系統的學習了解，設計出新的測試用例，執行測試。如此反復循環，直至完成原先設定的測試目標。

圖2 探索性軟件測試模型圖

5 探索性測試的應用

5.1 實驗數據分析

首先通過兩組實驗數據來分析探索性測試在實際工作的應用，被測軟件是一個大約3萬行的零售行業軟件，預埋缺陷24個。

通過這兩組實驗數據，我們可以觀察到以下三點：

（1）在傳統測試方法中，結合使用探索性測試方法，缺陷的檢出率明顯高于單一的使用傳統測試方法；

（2）探索性測試能發現更多測試設計以外的缺陷；

（3）進行探索性測試時，測試人員的經驗、態度、思維方法等方面都會影響測試的效果。

該實驗目的不是去證明探索性測試與傳統測試方法哪種更優秀，因為并不是所有的測試活動都適合使用探索性測試，只是希望在進行傳統測試方法時結合采用探索性測試。探索性測試一般適合在以下一些場景中使用，比如：需要快速了解產品質量；需要在短時間內發現軟件的重大缺陷；測試設計以外缺陷的檢查；已進行過傳統測試，需要對某一特定類型缺陷再進行測試；功能較為單一的小規模軟件；大型項目的回歸測試等，探索性測試并不是孤立的測試方法，我們在實際的測試過程中都會不自覺的使用它，比如當開發人員修改完一個缺陷后，我們在進行確認時，一些有經驗的測試人員不僅僅是對該缺陷進行確認，他們會進行一些額外的測試來探索修復該缺陷是否對某些功能產生影響，這就是典型的探索性測試。

5.2 探索性測試的管理及步驟

那么，我們在進行探索性測試時如何進行過程控制和管理的，通常情況下根據測試主管在測試項目中的作用可以分為以下兩種方式進行[6]：一種是由測試主管分配需要測試的模塊，他不參與具體的測試任務；測試人員來完成這些模塊的測試，并且將測試中的問題進行報告；測試主管根據測試情況定期召開項目組會議。另一種是測試主管和測試人員一樣參與某些測試任務；測試主管在測試過程中實時的根據測試質量和測試進度調整測試策略；測試主管持續的了解整個測試過程，與測試人員一起探討測試策略。

這兩種測試管理方式是目前國內外都普遍適用的方式，在任何一種管理模式下進行探索性測試，測試主管和測試人員都必須經過以下幾個步驟：

（1）識別軟件系統的目的，了解該軟件系統測試的重點及要達到的目標；

（2）識別軟件系統提供的功能，梳理出整個軟件系統的需要進行測試的所有模塊；

（3）識別軟件系統潛在的不穩定區域，與開發人員及測試人員討論，篩選出缺陷可能出現較多的模塊；

（4）在探索軟件系統的過程中記錄關于軟件的信息和問題，記錄好測試步驟以便進行下一輪回歸測試。

6 結束語

本文探討了探索性測試方法的基本原理并闡述了探索性測試的優缺點及能解決的問題，但并不是說用它來取代現有傳統測試方法，它只是對傳統測試方法的一種很好的補充，它適合在某一特定環境和要求下進行。探索性測試要求充分發揮測試人員的個人能力，要求測試人員有很好的主觀能動性，需要把自身的經驗技能及對系統的學習認知作為參考，靈活地經行測試設計和執行，只有在適合的項目、在合理的時機引入探索性測試才能充分發揮它的優勢，才能夠顯著提高軟件的測試效率，達到事半功倍的效果。

參考文獻：

[1]鄭人杰.計算機軟件測試技術[M].北京：清華大學出版社，1992：34～37.

[2]James　A.Whittaker.探索式軟件測試[M].方敏，張勝，等譯.北京：清華大學出版社，2010，4：9～15.

[3]練榮政.一個基于探索性軟件測試理論的測試用例生成系統的研究與實現[D].北京交通大學碩士學位論文，2008.06.

[4]謝經緯，吳昊.探索性方法在面向故障軟件測試中的應用[J].微計算機信息，2010，26（921）：145～146.

[5]段念.探索性軟件概述[EB/OL].http：//，2006，07.

[6]高翔.探索性測試進度控制的方法　51測試天地，2010，04.