軟件測試課程實驗教學體系設計與實踐

辜 萍 萍

(廈門大學 嘉庚學院 信息科學與技術學院，福建 漳州 363105)

0 引 言

我國的軟件測試行業是伴隨著軟件工程領域的研究而逐步發展起來的。隨著產業的蓬勃發展以及對軟件質量的重視，帶動了軟件測試行業的快速發展，已逐步與國際先進水平拉近差距，軟件測試在國內正在逐步成為一個新興的產業[1]。最新的行業調查報告顯示，目前在經濟轉型的過程中互聯網行業和金融行業正迅猛壯大，企業用人需求連年上升，軟件測試人才缺口巨大，因此，各所高等院校紛紛在軟件工程專業開設軟件測試課程，以求培養一批掌握測試技術以適應職業特定需要的年輕人。然而，大部分學生并未意識到測試的作用與重要性，在平時的學習中是將更多的精力投入編程的學習而忽視測試，導致降低了軟件測試課程的學習質量。因此，為了實現軟件測試人才的培養目標，必須扭轉當前的不合理現象，對課程內容及授課形式加以改進，以求引起學生對該課程的重視，進而增強對軟件測試領域相關工作的興趣，最后能夠具備專業技術能力以填補市場空缺。

1 軟件測試課程特點

(1)貌似簡單實則復雜。軟件測試是軟件工程領域的一個分支。一般情況下，高校在設置本科培養方案時會讓低年級學生先行修讀軟件工程，在后期才會深入學習軟件質量與測試。在軟件工程課程中會講解軟件測試的基本概念，如回歸測試、自動化測試、黑盒測試、白盒測試，也會涉及手工測試的基礎方法。這些概念雖然繁多，但是理解起來并不難，因此學生就片面地認為軟件測試簡單易學，相比于編程的學習輕松得多也不具有挑戰性，在升入高年級時自然對軟件測試課程不重視。但是，只停留在對概念的理解而沒有應用于實踐是不可能真正掌握相關技術的，面對實際的項目測試任務，這些單純的概念并不能轉化為解決問題的能力。更何況，實際上軟件測試的流程復雜、測試類型多樣、自動化工具難學，都需要在后續的測試課程深入學習才能體會何為真正的軟件測試。

(2)階段性強，實驗眾多。軟件測試的核心流程包括測試計劃、測試用例設計、測試執行以及測試結果記錄4個部分，從軟件開發周期的角度又可以劃分為單元測試、集成測試、系統測試、驗收測試4個階段。如圖1所示的測試與開發的關系模型H-mode來看，軟件測試應當貫穿于軟件開發的整個過程，才能合理地安排開發資源并規避開發后期的風險[2]。因此，在課程中應該分階段設計各種測試實驗，學生可以體會軟件測試的流程劃分，可以理解理論教學中的各種概念、技術，可以實際使用各種測試技術和測試工具，這樣就能極大地加強對理論知識的掌握和理解。所以，建設有效的實驗教學體系，對于提高軟件測試課程的教學效果很有必要。

圖1 測試與開發關系模型H-model

(3)與其他課程關聯緊密。軟件開發包含需求、設計、編碼、測試等諸多環節，軟件測試既獨立又與其他階段性工作密切相關[3]。例如，測試計劃的編寫需要依賴需求說明書，測試用例的設計需要參照需求與設計說明書，編碼階段需要執行單元測試與集成測試，系統成型后需要開始系統測試。因此，除了軟件工程之外，也同步開設軟件需求、軟件設計以及程序設計等課程，為軟件測試課程打基礎做準備，同時這些課程的學生作品應該被充分利用成為軟件測試實驗中的依據材料，如此將不同時期的課程串聯成線以模擬軟件項目開發的不同階段，讓學生更好地體會公司中項目運作的實際場景。

2 課程實驗體系

2.1 實驗分組

在安排學生參與實驗時，盡量尊重學生個人意愿，堅持團隊合作，引入角色扮演模式。近年的行業調查報告顯示，目前國內的大多數公司在測試部門設置明確的分工，對于測試流程的不同階段以及軟件產品的不同測試類型都有專項負責小組，以此確保每個成員各施所長通力合作。所以，在教學實驗中，也應該鼓勵學生正確認識自我，根據自身興趣特長參與測試相關工作。例如，熱愛編程的同學負責單元測試工作，擅長文檔讀寫的負責測試計劃工作，喜歡研究工具的就負責自動化測試等。任務包干到人之后也能增強學生的主人翁意識與責任感。

另外，一般情況下如果由學生自行組隊，可能出現各項強弱差距較大的局面。為了避免出現這種現象，在本實驗體系中，將采用隨機組合的形式，即分別從各專項負責小組中抽取相應人數進行組隊。當隊伍中的成員相互之間沒有合作過，那么在實驗初期彼此之間的磨合與溝通也將提高學生的適應能力。

2.2 實驗內容設計

(1)關于實驗項目的確定。為了將時間與精力都集中于測試的相關工作，應當鼓勵學生選擇之前的軟件課程里已經基本完成的軟件產品(包括軟件需求設計文檔和源代碼)作為本實驗體系中的測試對象及測試依據。從近幾年的行業調查數據中發現，軟件測試從業人員比較多從事的是Web項目的測試工作，因此，學生可以挑選自己作業成果中的J2EE項目、.Net項目或者PHP等項目。基于此，在相關的軟件課程制定教學大綱時，就與任課教師進行溝通合作，確保實驗資源的可用性，也可構建軟件工程系列課程組，促進知識體系的連貫性。

(2)必須詳細制定實驗步驟。結合軟件測試的核心流程及現有資源，在本實驗體系中，將實驗流程劃分為4個階段，如表1所示。

2.3 實驗任務執行

如圖2所示，目前從業人員最希望提升的技能是自動化和性能測試，軟件測試行業經過10年的高速增長之后，高端測試人才急缺，市場產生了自動化和性能測試工程師提升培訓需求[1]。多年的摸索實踐表明，自動化測試不僅可以在軟件持續集成和改進過程中的回歸測試時節省重復手工操作工作量，也可以通過自動化工具的錄制回放及數據驅動來執行測試以提高測試覆蓋率，還可以利用一致性的測試腳本更好地重現軟件缺陷來提高缺陷修復效率。因此，本實驗體系中大量引入當前在企業中應用比較廣泛的測試工具，力求做到自動化與手工的完美結合，鍛煉學生分析設計的邏輯思維能力以及自動化測試的實踐動手能力。

表1 實驗流程安排表

圖2 軟件測試從業人員調查統計圖

(1)單元測試與集成測試。單元測試與集成測試主要采用白盒測試的方法，主要分為靜態測試與動態測試兩種[4]。

在靜態測試中，將對代碼執行編程規則檢查。該項測試向學生們展示了程序語法之外的規則問題，編程語法是學習語言的基礎，在集成開發環境中也能夠被自動檢測，而編程規則是常常被忽略又不該忽略的部分，只有符合規范的代碼才能稱為質量級的，才能減少潛在的錯誤。然而，現行的大部分編譯器并沒有檢查規則的功能，完全人工篩查工作量過大效率低下，所以，實驗中引入自動化的規則檢查工具，能夠快速掃描代碼并清晰地提示違反規則的地方以便修改[5]。不同的語言有相應的工具選擇，例如，針對Java語言有開源軟件PMD，針對C/C++有PC-Lint等。

在動態測試中，先學習如何依據軟件設計文檔仔細分析代碼的邏輯結構，然后人工設計出白盒測試用例，在集成測試中學習及應用漸增式集成策略，再借助自動化測試框架JUnit4.0執行測試用例，并使用ElcEmma工具檢查測試代碼的覆蓋率。JUnit4.0是XUnit系列成員，XUnit是一套基于測試驅動開發的測試框架，其包含用于Python單元測試的PythonUnit、C++單元測試的CppUnit以及C#單元測試的NUnit，應用十分廣泛[6]。因此，學生通過JUnit4.0的訓練可以很容易舉一反三應用其他語言的XUnit框架。同時，JUnit4.0引入參數化機制，在執行測試驅動程序時可以很方便地對多組測試數據輪詢調用并分別報告測試結果，既簡化測試代碼的編寫工作又提高測試效率。ElcEmma能夠結合JUnit框架對測試代碼進行覆蓋測試，能夠在工作平臺中啟動直接對代碼覆蓋進行分析，覆蓋結果將立即被匯總并在Java源代碼編輯器中高亮顯示，也可程序運行的結果生成詳盡的覆蓋測試報告，如圖3所示。對于覆蓋率檢測結果不合格的，就需要讓學生補充白盒測試用例繼續測試，以此提高測試的深度[7]。

圖3 JUnit+ElcEmma應用界面

(2)系統測試設計與測試執行。系統測試不同于單元測試與集成測試。該階段中測試人員根據軟件需求設計文檔進行測試用例的設計與執行。測試人員將利用一系列經典的黑盒方法如等價分類法、場景法設計用例數據[8]。一般情況下，測試項的提取以及黑盒測試用例的編寫都使用文檔編輯器記錄，但是這種方法不便于后續的使用及維護。測試用例的設計與執行最好集中管理，因此，實驗中選用TestWriter作為自動化輔助工具。TestWriter是一款零編碼，測功能、測回歸、測兼容性的軟件，對于自動化系統測試的初學者尤其適用。工具中對測試對象、測試步驟、用例等層層封裝映射，清晰理清業務關系，易于更新與維護。測試人員根據軟件需求文檔中的軟件特性描述設計出一批測試用例，然后填入TestWriter，如圖4所示。當測試數據填寫好之后就可以利用工具的調用回放功能自動運行測試。而且，TestWriter官方技術支持每天在TW論壇及時答疑解惑，并且經常舉辦直播等活動講解如何使用此工具，借助此平臺也可以培養學生的課堂之外的自學習慣。對于每個小組擁有各自的項目而言，TestWriter也正是以項目為單位進行數據管理的，在服務器端建立了每個項目之后再分配對應的成員權限，每個成員只能登錄自身所屬的項目進行任務操作，所以，雖然項目都存取在同一臺數據庫服務器，但是項目與項目之間相互獨立互不干擾。

圖4 TestWriter測試用例編輯界面

(3)性能測試。軟件產品的質量取決于功能與性能兩項十分重要的因素。本文中的TestWriter主要針對軟件產品的功能進行測試，除此之外用戶也非常重視軟件的性能問題。因此，團隊中的測試人員還可以更細分為功能測試組與性能測試組，兩個小組可以各自選用相應的自動化工具并行作業。

軟件性能廣義上涵蓋健壯性、安全性、兼容性、高效性等一系列非功能特征[9]。本實驗體系中的性能測試主要關注的是系統響應時間、吞吐量、并發用戶數、資源利用率等性能指標。自動化的性能測試是通過測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項性能指標進行測試。在自動化性能測試技術使用之前，手動測試是大部分測試人員的首選。當時為了測試并發負載的性能指標，還必須召集一定數量的操作人員和同樣數目的電腦，在同一時刻進行操作訪問被測系統以求模擬高峰期的負載狀況，然后拿秒表記錄下反應時間，這樣的手工作坊式的測試方法費時費力不切實際且無法捕捉程序內部變化情況[10]。目前，性能測試工具的代表當屬Mercury LoadRunner，它可以通過創建大量的虛擬用戶來實行并發的負載的實現及同一時刻進行性能監測的方式來找出和確定系統中的問題，從中發現準確的系統瓶頸，從而得出相應的性能調優方案[11-12]。性能測試流程主要包括制定測試方案、創建虛擬用戶腳本、設計測試場景、運行場景以及分析測試結果。軟件需求文檔中關于產品的性能方面同樣編寫了非常詳細的要求，因此，負責性能測試的組員必須嚴格依照文檔設定性能指標，例如文檔中約定100個用戶并發查詢同一報表的交易響應時間不超過30 s，那么實驗中就必須創建100個虛擬用戶、編輯查詢報表的操作步驟，然后通過LoadRunner記錄的時間來進行驗證。圖5所示為LoadRunner運行場景界面圖，其中顯示了虛擬用戶從初始化到操作完成的過程中軟件服務器端的實時性能數據。

圖5 LoadRuuner運行場景界面

(4)缺陷跟蹤管理。測試人員找出缺陷的最終目的是使每個缺陷得到最合適的處理。缺陷的處理過程需要團隊中不同角色的成員協同運作，從缺陷最初被發現到最后被關閉的過程中可能經歷各種不同的狀態，常見的缺陷狀態包括：新建、反饋、認可、已確認、已分派、繼續跟蹤、已解決和已關閉[13]。主干的管理流程如圖6所示，首先由測試人員記錄缺陷的詳細信息，而后測試組長審核缺陷報告合格再分派給編碼人員進行缺陷的修復工作，最后由測試人員回歸測試確保缺陷真正被修復。在主干流程之外，還根據缺陷報告質量與缺陷修復等情況會出現其他分支流程，導致缺陷處于不同的狀態。

圖6 缺陷管理的主干流程

根據缺陷管理需求，缺陷跟蹤管理系統必須能對缺陷信息進行科學管理，形成規范的缺陷處理流程,才能保證缺陷得到及時恰當的處理。本實驗體系中選用Mantis作為缺陷管理工具，Mantis是一款能夠添加、修改、排序、查看、存儲軟缺陷的數據庫程序，其采用PHP語言開發，基于B/S架構，可以跨地域操作，具有完整的缺陷跟蹤管理功能，是適合大部分軟件開發團隊的輕量級缺陷管理工具[14-15]。實驗中測試人員需要搭建及配置Mantis后臺數據庫及前端頁面，需要在系統中創建不同角色，然后才能進入缺陷處理流程。圖7所示為測試人員在Mantis系統登錄項目之后查看缺陷信息的界面。

圖7 Mantis中查看缺陷界面

3 結 語

軟件測試已不再是軟件生命周期里最后一個階段，而是貫穿始終的一項任務。軟件測試作為軟件工程系列中獨立的一門課程承擔著為軟件行業培養一批強有力測試人才的重任。為了扭轉學生對測試工作的偏見，必須對課程教學進行改革，在課程中建立實驗教學體系。實驗以團隊形式展開，人員安排參考學生的意愿進行角色扮演，實驗題目可追溯到已修讀完畢的課程作品，實驗步驟按照軟件測試的核心流程來設定，實驗內容將人工操作與自動化測試有機融合。實踐證明，該實驗過程能更加提高學生對軟件測試的興趣，更加提升軟件測試的重要性，更加增強測試技術學習的效率，更加符合測試崗位對人員招聘的標準。