基于敏捷軟件開發(fā)方法的C語言符號表構(gòu)造實現(xiàn)研究

摘 要：信息化飛速發(fā)展，需求隨之變動，現(xiàn)今社會對軟件產(chǎn)品質(zhì)量的要求逐漸提高。該文首先介紹傳統(tǒng)軟件開發(fā)和敏捷軟件開發(fā)體系，然后對比分析瀑布模型與極限編程，測試驅(qū)動開發(fā)與傳統(tǒng)軟件測試、V模型的各自特點(diǎn)，并結(jié)合實際，具體闡釋敏捷軟件開發(fā)方法在C語言符號表的構(gòu)造實現(xiàn)，最后從測試覆蓋率方面評估此次測試集。從測試評估報告結(jié)果看，采用先測試再編碼步驟的測試驅(qū)動開發(fā)TDD方法開發(fā)的軟件，不僅測試更為完備、徹底，而且更適用于需求變動的環(huán)境。

關(guān)鍵詞：軟件質(zhì)量；敏捷軟件開發(fā)；極限編程；符號表；測試驅(qū)動

中圖分類號：TP311.5 文獻(xiàn)標(biāo)志碼：A 文章編號：2095-2945（2024）27-00１８-0４

Abstract： With the rapid development of information technology， the demand changes accordingly， and the requirements for the quality of software products are gradually improving in today's society. This paper first introduces the traditional software development and agile software development system， then compares and analyzes the respective characteristics of waterfall model and extreme programming， test-driven development， traditional software testing and V model， and combines with practice. The construction and implementation of agile software development method in C language symbol table is explained in detail， and finally the test set is evaluated in terms of test coverage. According to the results of the test evaluation report， the software developed by the test-driven method of test-driven development with the first test and then coding steps is not only more complete and thorough testing， but also more suitable for the environment of changing requirements.

Keywords： software quality; agile software development; extreme programming; symbol table; test-driven

傳統(tǒng)軟件開發(fā)方法，如瀑布模型是一早期軟件開發(fā)模型，遵循軟件生命周期從需求分析、設(shè)計編碼，運(yùn)行維護(hù)各階段按順序依次進(jìn)行，如同瀑布自上而下。瀑布模型要求早期詳盡需求分析，需求文檔一旦固定不再改變。當(dāng)客戶需求發(fā)生變更，無疑極大增加了成本，從而影響項目開發(fā)進(jìn)度。

相比較傳統(tǒng)瀑布模型拒絕用戶需求變化，Agile Development敏捷軟件開發(fā)是近些年來一種以快速響應(yīng)用戶需求變化的輕量級軟件開發(fā)方法[1]。它強(qiáng)調(diào)快速編寫軟件，及時交付軟件小功能模塊，迭代式開發(fā)，將用戶一并納入到開發(fā)團(tuán)隊中，包括Rational Unified Process（RUP）、Feature Driven Development（FDD）、Extreme Programming（XP）、Crystal Method等。

1 軟件開發(fā)方法分析

在所有敏捷軟件開發(fā)方法中，Extreme Programming（XP）極限編程是一種要求協(xié)作、迭代、不斷改進(jìn)的軟件開發(fā)方法，強(qiáng)調(diào)響應(yīng)需求變化、及時交付高質(zhì)量的軟件。

XP克服了傳統(tǒng)瀑布模型過于依賴文檔需求快速響應(yīng)需求的缺陷，強(qiáng)調(diào)積極應(yīng)對需求變化，整個開發(fā)過程通過小規(guī)模、迭代式的開發(fā)模式快速交付系統(tǒng)部分功能，積極適應(yīng)外部環(huán)境變化，并以測試先行、持續(xù)集成，極大提高了軟件質(zhì)量和可靠性，從而減少了軟件錯誤、缺陷。

相比傳統(tǒng)瀑布模型先編碼再軟件測試，上一個階段結(jié)束才能開始下一個階段的線性模式，極限編程倡導(dǎo)測試先行，即先編寫測試用例代碼，再編寫通過測試的實際代碼，迭代式推進(jìn)整個開發(fā)過程。瀑布模型以早期需求文檔為中心，用戶無需參與開發(fā)全程，這往往導(dǎo)致最后交付的軟件不滿足用戶實際需要。極限編程則以溝通為核心價值，倡導(dǎo)用戶參與開發(fā)過程，積極響應(yīng)用戶需求，在最短的時間內(nèi)，小型、頻繁發(fā)布系統(tǒng)部分功能。

2 測試驅(qū)動開發(fā)

Test-Driven Development（TDD）測試先行開發(fā)是極限編程XP的核心技術(shù)之一。它不是一種軟件測試方法，而是一種獨(dú)立的軟件實踐方法，用測試驅(qū)動和指導(dǎo)設(shè)計編碼，將單元測試和程序設(shè)計結(jié)合在一起[2]，為軟件的可靠性和質(zhì)量提供支撐。

整個開發(fā)過程需要一套在自動化測試框架下自動運(yùn)行完備的測試集，步驟為先黃、后紅、再綠，好比交通燈交替顯示。在具體編碼之前需要先編寫測試代碼，由測試來指導(dǎo)需要什么樣的代碼[3]。通過測試只是測試驅(qū)動開發(fā)的前提，它還強(qiáng)調(diào)重構(gòu)性，在測試通過后需對代碼進(jìn)行重構(gòu)，并且重構(gòu)后的功能代碼也需要通過測試。按照以上步驟開展，直到系統(tǒng)所需功能全部通過測試。

2.1 測試驅(qū)動與傳統(tǒng)軟件測試分析

由表1可知，傳統(tǒng)軟件測試往往是在設(shè)計開發(fā)完成后由專門的軟件測試員負(fù)責(zé)完成，而測試員需要花費(fèi)時間和精力去理解代碼，容易造成理解不到位而遺漏某些測試。而測試驅(qū)動開發(fā)就不存在這樣的情況，代碼基于測試，均由程序員完成，節(jié)約時間成本。當(dāng)發(fā)現(xiàn)錯誤時，傳統(tǒng)軟件測試是滯后的，很難快速定位錯誤位置。而在測試驅(qū)動開發(fā)中，系統(tǒng)增添新代碼引入bug，測試集能快速定位bug位置，從而大大減少了調(diào)試時間。

2.2 測試驅(qū)動開發(fā)與V模型對比

V模型強(qiáng)調(diào)測試及驗證在軟件開發(fā)過程的重要，其實施步驟如V字母，一邊為開發(fā)流程，另一邊為測試流程，每一個階段的輸出都有與之對應(yīng)的測試階段。

雖然測試驅(qū)動開發(fā)與V模型都主張在具體編碼之前先設(shè)計好測試用例，但區(qū)別點(diǎn)是V模型只是設(shè)計測試用例在編碼之前，而創(chuàng)建測試用例及執(zhí)行測試用例仍在編碼之后，但在測試驅(qū)動開發(fā)中，設(shè)計、創(chuàng)建及執(zhí)行測試用例均在實際編碼之前[4]。二者的執(zhí)行力度也不同。相比較V模型，測試驅(qū)動開發(fā)要求測試先行，測試用例運(yùn)行要比V模型運(yùn)行更頻繁。

3 符號表設(shè)計

本文以測試驅(qū)動開發(fā)實現(xiàn)在C語言編譯過程符號表的設(shè)計構(gòu)造實現(xiàn)為例進(jìn)行介紹。

3.1 語言特點(diǎn)分析

編譯為將源程序翻譯成目標(biāo)語言的過程，其過程可以是多趟掃描或一趟性掃描源程序。無論多趟還是一趟，作為收集和存儲在源程序中標(biāo)識符的相關(guān)屬性信息，符號表生成構(gòu)造是整個編譯過程必不可少的。編譯過程符號表中的相關(guān)信息是動態(tài)變化、不斷更新的。

編譯第一階段為詞法分析，即從源程序識別出的單詞符號。在C語言，單詞符號分為變量、常量、關(guān)鍵字、算符和界符等。變量為字母數(shù)字下劃線組成的符號串。關(guān)鍵字有以下類型：數(shù)據(jù)類型如int、控制語句類的如while、存儲類型的如static，以及其他類如typedef等。算符有雙目、單目、關(guān)系與邏輯運(yùn)算符等。界符分為（）、{ }、[ ]等。常量包括整型或?qū)嵭蛿?shù)值型、字符型等。

在遍歷源程序過程中，對識別出的一個個單詞，本文依據(jù)單詞類別，不同種類的單詞分門別類存儲在不同的符號表中，而不是所有單詞信息存在一張符號表中。對于單詞信息，本文采用三元組形式（類別，名稱，屬性值）記錄單詞相關(guān)信息，使用數(shù)值來區(qū)分不同類別，即一類別一數(shù)值。如關(guān)鍵字類別數(shù)值為1，變量類別數(shù)值為2，常量類別數(shù)值為3……依次類推。根據(jù)C語言特點(diǎn)，這里，符號表關(guān)鍵字、常量、算符、界符類別的單詞存儲在靜態(tài)符號表中，而變量類別的存儲在動態(tài)符號表中。在動態(tài)符號表中，依據(jù)變量類別的不同分別存儲，如全局變量存儲在全局變量符號表中，局部變量存儲在局部變量符號表中。

3.2 符號表設(shè)計

在本文中，不同單詞種類的符號表均涉及新增、刪除、查找、修改操作。考慮實例化操作頻繁，這里初始化過程采用Factory工廠設(shè)計模式來完成，即不同單詞子類以繼承方式實現(xiàn)父類初始化操作。

如圖1所示，接口父類WordTable包含增修刪及遍歷查找操作方法。這些方法由各派生類符號表在各自操作方法中具體實現(xiàn)。從父類派生的全局符號表GlobalTable類、局部LocalTable類、函數(shù)符號表類……依據(jù)單詞類別，將識別出的單詞需存儲在不同類符號表中。對于符號表新增節(jié)點(diǎn)的初始化操作，這里統(tǒng)一交給操作類NodeCreateFac的Initial（）方法完成，使得節(jié)點(diǎn)的初始化操作將會動態(tài)調(diào)用相應(yīng)符號表的方法。

4 設(shè)計實現(xiàn)

4.1 開發(fā)環(huán)境

本文選取JUnit測試開發(fā)環(huán)境。JUnit是XUnit測試框架家族成員之一，一款支持自動化回歸測試的單元測試框架，支持單元測試、功能測試、集成測試，支持多語言創(chuàng)建和運(yùn)行測試，提供多個TestCase測試用例、Assert斷言、Report報告等功能[5]。

JUnit測試框架采用的是組合設(shè)計模式。其中Test是接口類，含有Run方法，是運(yùn)行測試、收集測試結(jié)果。測試用例集合TestSuite會調(diào)用Run方法依次遍歷所容納的所有從Test派生而來的對象。斷言方法集合靜態(tài)類Assert，用于比對期望值和實際值，若是比對失敗則拋出異常。抽象類TestCase則是整個測試框架的核心，我們創(chuàng)建具體測試用例都是通過繼承抽象類TestCase來實現(xiàn)。

4.2 測試驅(qū)動實現(xiàn)

本文采用測試驅(qū)動開發(fā)方法，按照先測試再編碼的步驟逐步實現(xiàn)C語言符號表構(gòu)造。這部分以符號表初始化為例，介紹測試用例編寫到代碼實現(xiàn)過程。

按照設(shè)計階段列出的所有測試任務(wù)優(yōu)先級先后順序創(chuàng)建測試用例。細(xì)化測試任務(wù)，第一條測試任務(wù)為輸入空，輸出空。開始編寫TestCase測試用例，創(chuàng)建測試方法TestEmptySourcePragm，具體如下：

public void testEmptySourcePragm（ ） {

LexicalAnalyzer LA= new LexicalAnalyzer（""）;

assertEquals（"Null Result！"，""，LA.getAnalResult（ ））;

}

運(yùn)行測試方法，編譯失敗。產(chǎn)生報錯信息顯示：類LexicalAnalyzer、getAnalResult方法未定義。

原因在于目前還不存在任何代碼，所以也無類LexicalAnalyzer和方法getAnalResult存在。按照TDD開發(fā)步驟，接下來依據(jù)報錯信息，創(chuàng)建類LexicalAnalyzer 及方法getAnalResult，具體如下：

public class LexicalAnalyzer {

LexicalAnalyzer（String source}{

}

public String getAnalResult{

return ;

}

}

在getAnalResult方法中，我們設(shè)置返回結(jié)果null。再次運(yùn)行測試方法。JUnit綠燈出現(xiàn)，編譯通過。然后檢查源代碼是否需要重構(gòu)，有無重復(fù)冗余。按照測試—編碼—重構(gòu)的步驟完成了第一個測試任務(wù)。

接下來，需要按照任務(wù)單順序依次測試驅(qū)動實現(xiàn)各類符號表的構(gòu)造。以局部變量符號表構(gòu)造實現(xiàn)為例，所需要測試任務(wù)有節(jié)點(diǎn)新增、刪除和修改等。按照從簡單到復(fù)雜的測試順序逐步實現(xiàn)并完善代碼功能。首先對局部變量符號表最簡單的測試為當(dāng)局部變量符號表為空時，返回變量個數(shù)為0。先編寫測試用例testLocalTableEmpty：

public void testEmptyVartableSize（ ）{

LocalTable Lt=new LocalTable（LexicalAnalyzer.getLocalTable（ ））;

assertEquals（"Size of LocalTable is Zero"，0，Lt.getSize（ ））;

}

執(zhí)行測試用例 testEmptyVartableSize，JUnit顯示黃燈，編譯不通過。依據(jù)報錯提示信息，這里需要創(chuàng)建局部變量符號類LocalTable及getSize方法，并且需要在分析器類LexicalAnalyzer中添加相應(yīng)代碼，使其通過編譯。在getSize方法中依舊采用最簡單的實現(xiàn)方法，讓其返回值為0。

局部變量符號表LocalTable一旦生成后，后續(xù)的測試就是圍繞局部變量符號表的基本操作，即增、刪、改。以增加變量節(jié)點(diǎn)為例，測試方法如下：

public void testAddOperaofLocalTable（ ）{

VarNode newVar=new VarNode（2，"ch"，"a"）;

Lt.addNewVar（newVar）;

assertEquals（"Size of LocalTable is 1"，1，Lt.getSize（ ））;

}

新增變量節(jié)點(diǎn)newVar后，局部變量符號表的數(shù)量應(yīng)返回1。增加的單詞類型為類型2變量，其名稱為ch，值為a。運(yùn)行測試用例，JUnit出現(xiàn)紅燈，測試失敗。報錯信息為：“size of localTable is 1，expected ：<1>，but<0>”。依據(jù)錯誤提示，查找原因，定位在代碼getSize方法中。因為當(dāng)初為了使其通過編譯采用最簡單的辦法，使getSize方法返回值為0，且addNewVar方法沒有具體內(nèi)容。接下來，需要在getSize方法和addNewVar方法增添相應(yīng)代碼實現(xiàn)符號表的新增和個數(shù)統(tǒng)計功能， 并且在testAddOperaofLocalTable測試通過后，需要繼續(xù)增加變量節(jié)點(diǎn)反復(fù)測試新增功能是否完善。

同樣，局部變量符號表的測試任務(wù)單也少不了對于符號表的遍歷功能的測試，即遍歷符號表，返回它在符號表中所在的位置，若存在期望結(jié)果應(yīng)為真，若不存在期望結(jié)果應(yīng)為假。根據(jù)測試任務(wù)單編寫測試用例testLocalTableSearch方法，如：

Lt.addNewVar（newVar1）;

Lt.addNewVar（newVar2）;

assertTrue（"newVar1 should be in LocalTable"，Lt.SearchVar（newVar1））;

assertTrue（"newVar2 should be in LocalTable"，Lt.SearchVar（newVar2））;

assertFalse（"newVar3 shouldn't be in LocalTable"，Lt.SearchVar（newVar3））;

在本測試用例中增加了變量newVar1和newVar2，期望應(yīng)為真；對于newVar3實際不存在期望應(yīng)為假。執(zhí)行測試，運(yùn)行失敗，編寫具體代碼在LocalTable類中增加遍歷方法SearchVar使其通過測試。測試通過后需檢查代碼是否冗余，若存在則對代碼進(jìn)行重構(gòu)。

依照極限編程思路遵循先測試再編碼重構(gòu)迭代原則依次完成其他類別符號表的構(gòu)造設(shè)計，并將詞法分析輸出的結(jié)果分別存儲在對應(yīng)的符號表中，為語法、語義分析及代碼生成等后續(xù)編譯階段的使用提供支撐。

在完成符號表設(shè)計構(gòu)造后，還需進(jìn)行測試評估。軟件測試分為黑盒、白盒測試。極限編程TDD倡導(dǎo)測試徹底，所以采用更為徹底的白盒測試，即從先編寫測試用例再編碼的循序，對程序內(nèi)部邏輯進(jìn)行測試，力求提高測試覆蓋程度。本文采用Cobertura軟件測試覆蓋計算工具對代碼進(jìn)行全面測試，從語句覆蓋率、語句分支覆蓋率二維角度對程序代碼情況進(jìn)行綜合評測，并生成測試評估報告。此次的測試覆蓋評估報告顯示Line覆蓋、Branch覆蓋都達(dá)95%以上，其中部分Class達(dá)到100%。從結(jié)果看，測試集比較完備，測試較為充分。

5 結(jié)束語

本文對比分析了傳統(tǒng)軟件開發(fā)瀑布方法與敏捷軟件開發(fā)TDD方法的特點(diǎn)，按照極限編程測試驅(qū)動開發(fā)思路，測試驅(qū)動構(gòu)造實現(xiàn)C語言符號表，并對代碼進(jìn)行了測試評估。從測試評估結(jié)果得出測試驅(qū)動生成的代碼測試更為充分。

參考文獻(xiàn)：

[1] 劉鈺槐．敏捷軟件開發(fā)方法在軟件重構(gòu)中的運(yùn)用分析[J]．通信電源技術(shù)，2017，34（6）：155-156.

[2] LASSE K.測試驅(qū)動開發(fā)的藝術(shù)[M].李貝，譯.北京：人民郵電出版社，2010.

[3] 林勇.淺談測試驅(qū)動開發(fā)[J].中國金融電腦，2012（4）：48-50.

[4] 陳迪舸.芻議測試驅(qū)動開發(fā)在軟件開發(fā)中的作用[J].電子技術(shù)與軟件工程，2016（7）：60.

[5] 王孝梅.測試驅(qū)動開發(fā)的研究[J].電腦編程技巧與維護(hù)，2021（2）：47-49.