軟件靜態(tài)測試實驗教學(xué)方案設(shè)計

趙衛(wèi)東 王聰

摘 ?要： 靜態(tài)測試是軟件測試的一種重要方法，利用靜態(tài)測試工具可以方便測試人員和程序員較早的發(fā)現(xiàn)并消除代碼缺陷。但是高校在設(shè)置軟件測試實踐課程時對靜態(tài)測試并不重視，缺少有效的實踐環(huán)節(jié)。本文選擇Jupiter作為靜態(tài)測試工具，設(shè)計了靜態(tài)測試實驗的內(nèi)容，對傳統(tǒng)實驗教學(xué)方法進行的改革，經(jīng)過實際教學(xué)運用，收到了良好的教學(xué)效果。

關(guān)鍵詞： 靜態(tài)測試;實踐教學(xué);Jupiter

中圖分類號： G642 ? ?文獻標識碼： A ? ?DOI：10.3969/j.issn.1003-6970.2019.06.016

本文著錄格式：趙衛(wèi)東，王聰. 軟件靜態(tài)測試實驗教學(xué)方案設(shè)計[J]. 軟件，2019，40（6）：7477

【Abstract】： Static testing is an important method of software testing， using static testing tools makes it easy for testers and programmers to detect and eliminate code defects earlier. However， colleges do not pay much attention to static testing when setting up software testing practice courses， and lack effective practice links. This paper chooses Jupiter as a static testing tool， designs the content of static testing experiment， and reforms the traditional experimental teaching method. After the actual teaching and application， it has received good teaching results.

【Key words】： Static test; Practical teaching; Jupiter

0 ?引言

隨著當今社會對計算機系統(tǒng)需求和依賴的與日俱增，軟件失效導(dǎo)致的計算機故障越來越多，軟件質(zhì)量成為貫穿軟件生命周期的一個極為重要的問題，作為軟件質(zhì)量保證手段之一的軟件測試在軟件質(zhì)量保證中發(fā)揮的作用越來越明顯[1]，而靜態(tài)測試又是軟件測試的重要組成部分，在軟件測試領(lǐng)域占有無法替代的地位。

靜態(tài)測試可以手工進行，也可以借助靜態(tài)測試工具自動進行。人工代碼審查方式工作量大、對測試人員的要求高。經(jīng)驗表明，當代碼行數(shù)超過百行時，發(fā)現(xiàn)軟件問題的難度和代價也會隨之大幅增加。靜態(tài)測試工具根據(jù)程序結(jié)構(gòu)、編程規(guī)范或文檔來評價軟件系統(tǒng)，而不需要執(zhí)行程序，可以較早地發(fā)現(xiàn)程序代碼中的缺陷，有效節(jié)約測試時間，降低測試成本。

高校為本科學(xué)生開設(shè)軟件測試課程，目的是使學(xué)生系統(tǒng)的掌握軟件測試的基本概念，培養(yǎng)學(xué)生的軟件質(zhì)量意識，提高學(xué)生在軟件開發(fā)中的綜合能力，進一步幫助學(xué)生在軟件開發(fā)中減少缺陷的產(chǎn)生。但是高校對靜態(tài)測試的重要性不夠了解，很多情況下讓學(xué)生使用過時的工具對一些小型的例子程序進行測試，缺乏有效的實踐環(huán)節(jié)，學(xué)生收獲不大。

1 ?靜態(tài)測試傳統(tǒng)教學(xué)問題分析

1.1 ?靜態(tài)測試的基本概念

靜態(tài)測試包括代碼檢查、靜態(tài)結(jié)構(gòu)分析、代碼質(zhì)量度量等，它無須執(zhí)行被測代碼，可以人工進行，也可以借助專用的軟件測試工具評審軟件文檔或程序，度量程序靜態(tài)復(fù)雜度，檢查軟件是否符合編程標準，借以發(fā)現(xiàn)編寫的程序的不足之處，減少錯誤出現(xiàn)的概率;可以發(fā)現(xiàn)違背程序編寫標準的問題，程序中不安全、不明確和模糊的部分，找出程序中不可移植部分、違背程序編程風格的問題，包括變量檢查、命名和類型審查、程序邏輯審查、程序語法檢查和程序結(jié)構(gòu)檢查等內(nèi)容[2]。

1.2 ?靜態(tài)測試教學(xué)存在的問題

由于重理論、輕實踐的傳統(tǒng)教學(xué)模式使得高校在開設(shè)軟件測試課程時，對靜態(tài)測試不夠重視，分配給靜態(tài)測試的教學(xué)時間太少，尤其是實踐這一方面，教學(xué)內(nèi)容創(chuàng)新度不夠，教學(xué)方法達不到預(yù)期的效果，學(xué)生對靜態(tài)測試的了解還只是浮于表面，不僅對理論知識的認識不夠深刻，對靜態(tài)測試工具的應(yīng)用更是不熟練，無法掌握如今主流的靜態(tài)測試工具。具體存在的問題主要有以下幾個方面：

（1）師資隊伍缺乏項目測試經(jīng)驗，教學(xué)內(nèi)容缺乏針對性和連貫性[3]。靜態(tài)測試課程在高校中分配給學(xué)生的動手操作時間很有限，而且老師全部講完才會讓學(xué)生去實踐[4]，這樣的教學(xué)模式使得學(xué)生還沒有掌握前面所講的內(nèi)容，馬上就要進行后面內(nèi)容的學(xué)習(xí)，對學(xué)生實踐能力的提高幫助不大。而且教師大多教學(xué)經(jīng)驗豐富、理論功底深厚，但是缺乏軟件項目測試的實戰(zhàn)經(jīng)驗，無法針對實際案例進行深入分析和研究，面對一個完整的測試思路時，無法形成一個完整的測試思路。

（2）學(xué)生不夠重視。大多數(shù)的學(xué)生只注重編碼能力的提高，對軟件測試有一種錯誤的認識，認為編碼能力不夠的人才會去做測試，其中又因為靜態(tài)測試不需要運行代碼，對靜態(tài)測試更是不重視。這就導(dǎo)致很多學(xué)生排斥這門課程，不會熟練運用靜態(tài)測試工具，更不了解主流的測試工具有哪些[5]。

（3）教學(xué)案例太過于簡單，多以基礎(chǔ)性實驗為主。實踐課所用到的教學(xué)案例過于簡單，這些簡單的案例雖然有助于學(xué)生對單個方法或知識點的掌握，但沒有貫穿整個測試過程的案例，學(xué)生難以形成一個完整的測試思路[6]。這種比較單一的實驗設(shè)計方式使得學(xué)生在企業(yè)工作中真正需要的知識和能力反而沒學(xué)到。

（4）內(nèi)容比較陳舊，測試工具跟不上形勢[7]。軟件測試是不斷發(fā)展的，但是現(xiàn)在很多高校要求學(xué)生完成的實驗題目都是幾年前的，被測系統(tǒng)的復(fù)雜性不夠，對學(xué)生能力的提高幫助不大，并且測試工具的覆蓋面也不夠，實用性不強。

2 ?靜態(tài)測試工具選擇

由于靜態(tài)測試工作量相對比較大，通常我們輔助一些靜態(tài)測試工具。靜態(tài)測試工具是直接對代碼進行檢查，代碼檢查包括代碼走查、桌面檢查、代碼審查等，并不需要運行代碼，也不需要對代碼進行編譯鏈接，生成可執(zhí)行的文件。靜態(tài)測試工具一般是對代碼進行語法掃描，找出不符合編碼規(guī)范的地方，再進行修改[8]。

靜態(tài)測試工具分為很多種，下面我們就對比較主流的幾款靜態(tài)測試工具進行比較：

（1）Jupiter：進行代碼審查的輔助管理，它是檢查整個的Java程序代碼;

（2）CheckStyle：幫助Java開發(fā)人員遵守某些編碼規(guī)范，自動化代碼規(guī)范檢查過程，主要檢查Javadoc注釋、命名約定、標題、Import語句、體積大小、空白、修飾符、塊、代碼問題、類設(shè)計和混合檢查（包括一些有用的比如非必須的System.out和printstackTrace）;

（3）PMD：靜態(tài)解析Java代碼錯誤，在不運行Java程序的情況下對Java代碼進行分析并報告錯誤，主要檢查空try/catch/finally/switch語句塊，未使用的局部變量、參數(shù)和private方法等;

（4）FindBugs：用來查找javabytecode（.class文件）中的潛在bug，包括NullPoint空指針檢查，沒有合理關(guān)閉資源等。

為了使學(xué)生能夠更深入地學(xué)習(xí)靜態(tài)測試，經(jīng)過比較，我們決定選擇Jupiter作為學(xué)生在實踐課程中學(xué)習(xí)使用的工具。Jupiter是一款開源并且可以提供給個人或者開發(fā)小組代碼審查的Eclipse插件，它將review數(shù)據(jù)存儲在XML格式文件中，通過SVN/CVS將review結(jié)果在團隊內(nèi)共享。一個很方便的功能是其建立了review問題跟具體源代碼的對應(yīng)關(guān)系（通過點擊review問題列表中的問題可以跳轉(zhuǎn)到對應(yīng)的代碼段，然后點擊代碼段上的review問題標記可對應(yīng)到具體的問題描述），review問題列表支持各種filter規(guī)則（根據(jù)review問題狀態(tài)、責任人等，通過這個filter可以列出具體階段需關(guān)注的問題）。

3 ?靜態(tài)測試內(nèi)容設(shè)計與教學(xué)方法改革

3.1 ?實驗的目的

靜態(tài)測試工具不是完美的，但是靜態(tài)測試工具對于檢測代碼缺陷還是很有幫助的，它能輔助測試人員較早、較快的發(fā)現(xiàn)一些特殊的缺陷，這些缺陷是大多數(shù)編譯器不能發(fā)現(xiàn)的，通過靜態(tài)測試來評審軟件文檔或程序，可以提高軟件質(zhì)量。對靜態(tài)測試進行實驗，就是要增強學(xué)生對靜態(tài)測試的學(xué)習(xí)，理解靜態(tài)測試的重要性，使用靜態(tài)測試工具進行代碼分析并且理解分析結(jié)果。

3.2 ?實驗內(nèi)容與步驟

3.2.1 ?實驗一：Jupiter的安裝及Review ID的創(chuàng)建及發(fā)布

任務(wù)一：安裝Jupiter

（1）在Eclipse 中選擇“Help” → “Install New Software...”;

（2）在彈出的對話框中單擊“Add...”按鈕，在“Name”中輸入Jupiter， 在URL中找到：C：＼jupiter- eclipse-plugin-master＼site這一路徑，單擊“OK”;

（3）在紅色字體“第二步：選中”處選中，并單擊“Next”，如圖1所示。

（4）之后一直“Next”并單擊“Finish”，完成安裝。

任務(wù)二：Review ID的創(chuàng)建與發(fā)布

（1）在“Project Explorer”列表中右擊需要審查的項目，依次選擇“Properties”，“Review”;

（2）單擊“New…”，在彈出的對話框中編輯“Review ID”及其“Description”;

（3） ?選擇要審查的文件（可以同時選擇多個文件）;

（4） ?在已添加的人員中選擇評審負責人（Author of this review session），再根據(jù)項目的需要或要求對“Type”，“Severity”，“Resolution”，“Status”的類型進行設(shè)置;

（5） ?設(shè)置.review文件將要存儲的目錄（文件夾）名稱（Storage directory），設(shè)置完成后進入下一步。

（6）設(shè)置三個階段（個人審查、團隊評審、問題修復(fù)）過濾器。前兩個階段使用默認過濾器即可（在“Rework Phase”下，如果希望開發(fā)人員能夠看到所有類型的bug（Open、Resolved、Closed、Reopened），需要將“Where status is：”前的復(fù)選框置于未選狀態(tài)），之后點擊“Finish”完成Review ID的創(chuàng)建。

（7）創(chuàng)建之后，在該項目的文件目錄下創(chuàng)建了一個“.jupiter”文件，將該文件發(fā)布到SVN或CVS等版本控制系統(tǒng)中，或通過郵件等方式發(fā)布Review ID。

3.2.2 ?實驗二：進行Individual Phase（個人審查階段）、Team Phase（團隊審查階段）及Rework Phase（修改Bug階段）三個階段的審查工作。

任務(wù)一：Individual Phase

（1）從SVN中獲取“.jupiter”文件并將其放在待審查項目的文件路徑（與src文件夾同級目錄）下;

（2）點擊Jupiter插件圖標的下拉箭頭，選擇“1 Individual Phase”選項，進入個人審查階段;

（3）在彈出的對話框中，選擇“Project Name”、“Review ID”及“Reviewer ID”，再點擊“Finish”，此時會發(fā)現(xiàn)在“Project Explorer”列表中待審查項目下生成一個文件夾，該文件夾用來存儲“xxx.review”文件;

（4）在完成了第（3）步之后，開始正式的個人代碼審查，當發(fā)現(xiàn)bug時，選中存在bug的代碼（所在行）并右擊選擇“Add Review Issue…”;

（5） 在“Review Editor”的“Individual Phase”選項卡中描述bug，并保存，在該代碼所在行的左邊有一個藍色標志，如圖2所示;

（6）提交“.review”文件到版本控制系統(tǒng)SVN中，并回復(fù)審核發(fā)起者你的任務(wù)已完成，并將“.review”文件一并發(fā)給審核發(fā)起者，個人審查階段到此結(jié)束。

任務(wù)二：Team Phase

（1）進入“Team Phase”;

（2）在彈出的對話框中選擇“Project Name”、“Review ID”及“Reviewer ID”，確定討論哪個審查者審查出來的問題后，點擊“Finish”，進入bug的瀏覽界面;

（3）通過雙擊每條記錄，可以直接導(dǎo)航到存在bug的代碼語句，在“Review Editor”中則顯示該條bug的具體描述，填寫“Assigned To”（指派給）、“Resolution”（解決方案）及 “Annotation”（對解決方案的具體描述），然后保存;

（4）將“.review”文件提交到版本控制系統(tǒng)，并通知代碼修改人員進行修改。

任務(wù)三：Rework Phase

（1）進入“Rework Phase”;

（2）在彈出的對話框中選擇“Project Name”、“Review ID”及“Reviewer ID”，其中此處的“Reviewer ID”代表代碼修改人員，點擊“Finish”，進入bug的瀏覽界面;

（3）雙擊bug記錄，可以導(dǎo)航到bug所在代碼處，并且在“Review Editor”中存在代碼描述及修改意見，修改完代碼后，調(diào)整“Review Editor”中的 ? 信息;

（4）將“.review”文件發(fā)布到版本控制系統(tǒng)，并通知代碼審查人員已經(jīng)修改完成bug修復(fù)。

3.3 ?實驗教學(xué)思路

實驗教學(xué)要從有利于調(diào)動學(xué)生實驗的積極性、主動性，有助于學(xué)生自主學(xué)習(xí)、合作學(xué)習(xí)和研究性學(xué)習(xí)，有利于學(xué)生實踐能力和創(chuàng)新能力的培養(yǎng)的角度出發(fā)。在進行實驗教學(xué)時，應(yīng)主要考慮如下4個因素：

（1）覆蓋面。對教學(xué)內(nèi)容進行重新組織，實現(xiàn)理論與實踐教學(xué)高度融合，并且教師所講的知識 ?點不一定大而全，但要覆蓋重點需要掌握的一些知識點。

（2）實用性。以企業(yè)軟件測試崗位需求為導(dǎo)向、以企業(yè)真實項目為驅(qū)動，加強校企合作，使得學(xué)生用的靜態(tài)測試工具是業(yè)界或接近業(yè)界所用的工具，讓學(xué)生感受到企業(yè)級的軟件測試[9]。

（3）綜合性。在有限的幾個實驗中，改變實驗過程中以教師為中心的教學(xué)方法和實驗步驟，還要綜合課程的多個知識點，采用隨講隨練的教學(xué)模式，讓學(xué)生及時的將所學(xué)的內(nèi)容轉(zhuǎn)化成自己的東西。

（4）工作量。實驗基本內(nèi)容設(shè)計應(yīng)難度適中和循序漸進，另外還可設(shè)計一些加分內(nèi)容，難度原則是使學(xué)生“跳起來夠得著”[10]。

4 ?總結(jié)

4.1 ?靜態(tài)測試工具的局限性

靜態(tài)測試工具根據(jù)特定的規(guī)則去檢測程序中的缺陷，如果沒有相應(yīng)的規(guī)則，就無法發(fā)現(xiàn)相應(yīng)的程序缺陷，另外，靜態(tài)測試工具只能給出“可能”的程序缺陷，需要經(jīng)過測試人員和開發(fā)人員的進一步分析，才能給出最終結(jié)論。每一種靜態(tài)測試工具要在“發(fā)現(xiàn)盡可能多的程序缺陷”和“減少缺陷誤報率”之間做出平衡[11]。

4.2 ?實驗總結(jié)

實驗教學(xué)的目的，就是希望學(xué)生可以針對項目實踐中所面對的問題，通過分析，補強所需要的相關(guān)理論知識，從而為解決問題提供方案，使學(xué)生真正從面對真實問題入手，實現(xiàn)到實踐中學(xué)習(xí)理論知識，并將所學(xué)的理論知識又運用到實踐中，真正實現(xiàn)項目實踐與理論知識學(xué)習(xí)的高度融合、在實踐中提升自身的職業(yè)能力和素養(yǎng)的目的[12]。

參考文獻

[1] 李玉蓉， 賈美麗. 軟件測試課程實踐教學(xué)改革與探索[J]. 計算機教育， 2014（21）： 105-107.

[2] 胡成杰， 宮云戰(zhàn)， 金大海. Java語言基于函數(shù)摘要的全局分析靜態(tài)測試方法[J]. 計算機研究與發(fā)展， 2010， 47（S1）： 64-68.

[3] 劉小飛， 李美滿. 基于工作過程的軟件測試課程實踐教學(xué)改革[J]. 計算機教育， 2018（6）： 68-71+75.

[4] 曹征. 軟件測試課程教學(xué)改革的探索與實踐[J]. 計算機產(chǎn)品與流通， 2018（11）： 184.

[5] 謝玲， 陸坤， 韓瑜. 軟件測試課程教學(xué)改革的探索與實踐[J]. 實驗室科學(xué)， 2018， 21（3）： 115-118.

[6] 杜剛. 高職院?！盾浖y試》課程教學(xué)改革探索與實踐[J]. 亞太教育， 2016（7）： 136.

[7] 周元哲， 舒新峰. 《軟件測試》課程教學(xué)模式探索與實踐[J]. 電腦知識與技術(shù)， 2018， 14（22）： 97-98.

[8] 張旭. 淺談軟件測試用工具的設(shè)計與實現(xiàn)[J]. 科技創(chuàng)新與應(yīng)用， 2012（6）： 32-33.

[9] 吳金秀. 軟件測試課程改革探索與實踐[J]. 南方農(nóng)機， 2018， 49（22）： 202.

[10] 楊秋輝， 洪玫， 郭兵， 何丹， 黃武. 軟件測試課程實踐教學(xué)改革研究[J]. 計算機教育， 2016（2）： 106-109.

[11] 李華瑩. 基于靜態(tài)測試工具的軟件測試方法研究[A]. 中國電子學(xué)會可靠性分會. 中國電子學(xué)會可靠性分會第十四屆學(xué)術(shù)年會論文選[C]. 中國電子學(xué)會可靠性分會： 中國電子學(xué)會電子制造與封裝技術(shù)分會， 2008： 6.

[12] 于海英， 武狄， 王希斌. 軟件質(zhì)量保證與測試課程教學(xué)改革探索[J]. 信息系統(tǒng)工程， 2016（2）： 155-156.