朱道雨

摘 要 本文首先介紹了測(cè)試驅(qū)動(dòng)開(kāi)發(fā)，繼而介紹了測(cè)試模式，描述了測(cè)試驅(qū)動(dòng)開(kāi)發(fā)的優(yōu)勢(shì)、一般步驟、測(cè)試的原則和對(duì)一般開(kāi)發(fā)人員的要求，最后比較詳細(xì)地介紹了幾種基于Python的測(cè)試框架。

關(guān)鍵詞 測(cè)試驅(qū)動(dòng)開(kāi)發(fā) Python 測(cè)試框架

中圖分類號(hào)：TP3 文獻(xiàn)標(biāo)識(shí)碼：A

1測(cè)試驅(qū)動(dòng)開(kāi)發(fā)介紹

測(cè)試驅(qū)動(dòng)開(kāi)發(fā)（TDD）是一種不同于傳統(tǒng)開(kāi)發(fā)流程的新型的開(kāi)發(fā)方法，采取了很小的增量式開(kāi)發(fā)方式，強(qiáng)調(diào)測(cè)試在軟件開(kāi)發(fā)過(guò)程中的作用。TDD是一種編碼之前進(jìn)行單元測(cè)試的軟件開(kāi)發(fā)思想。TDD先行定義了需求，擴(kuò)大測(cè)試覆蓋率，從而推進(jìn)整個(gè)開(kāi)發(fā)過(guò)程。其編寫(xiě)的代碼簡(jiǎn)潔、健壯且高質(zhì)量，加快軟件開(kāi)發(fā)。

2測(cè)試模式介紹

針對(duì)軟件開(kāi)發(fā)典型的瀑布模型，其是一種帶有部分反饋的自上而下的開(kāi)發(fā)模式，對(duì)文檔支持要求高。該模型按照階段劃分了檢查點(diǎn)，最終產(chǎn)品只能在后期才能看到最終結(jié)果，測(cè)試階段一般占一半時(shí)間。軟件測(cè)試和軟件開(kāi)發(fā)過(guò)程一樣遵循軟件工程原理，下面以V模型和X模式為例對(duì)測(cè)試與開(kāi)發(fā)之間的關(guān)系進(jìn)行說(shuō)明。

2.1 V測(cè)試模型

V模型和瀑布開(kāi)發(fā)模型一樣，存在需求分析、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)、代碼編碼等階段，這些過(guò)程都需考慮對(duì)應(yīng)的測(cè)試工作，同時(shí)設(shè)計(jì)測(cè)試用例、編制測(cè)試計(jì)劃。V模型明確標(biāo)明了測(cè)試的不同級(jí)別，清楚地描述了測(cè)試階段和開(kāi)發(fā)過(guò)程期間各階段的對(duì)應(yīng)的關(guān)系。需求分析產(chǎn)生的錯(cuò)誤直到驗(yàn)收測(cè)試才能發(fā)現(xiàn)是其最大的局限性。

2.2 X測(cè)試模型

圖1：X模型圖

如圖，X模型更詳細(xì)地描述了詳細(xì)設(shè)計(jì)和編碼階段的開(kāi)發(fā)行為，分離單程序片段的編碼和測(cè)試，直到集成為可執(zhí)行程序，然后測(cè)試這些可執(zhí)行程序。已通過(guò)集成測(cè)試的成品既可封裝并提交給用戶，也可作為更大規(guī)模集成的一部分，針對(duì)多程序片段，分離編碼和測(cè)試，并定義了探索性測(cè)試，強(qiáng)調(diào)單元測(cè)試和集成測(cè)試的重要性。

3 TDD的優(yōu)勢(shì)以及一般步驟

3.1 TDD優(yōu)勢(shì)

TDD相較于傳統(tǒng)的結(jié)構(gòu)化開(kāi)發(fā)過(guò)程方法，具有以下優(yōu)勢(shì)：

3.1.1更快更好地迎接需求變化

根據(jù)客戶需求編寫(xiě)測(cè)試用例，關(guān)注用戶反饋和以使用者的角度對(duì)功能的過(guò)程和接口進(jìn)行設(shè)計(jì)，可及時(shí)響應(yīng)需求變更，更符合后期開(kāi)發(fā)的需求。同時(shí)覆蓋完全的單元測(cè)試，提高了代碼的可靠性。

3.1.2明顯地縮短了設(shè)計(jì)決策的反饋循環(huán)

基于易測(cè)試和測(cè)試獨(dú)立性的要求，更多地依賴于接口，通過(guò)實(shí)現(xiàn)松耦合的設(shè)計(jì)，提高系統(tǒng)的可擴(kuò)展性和抗變性；同時(shí)對(duì)其功能的分解、使用過(guò)程、接口都進(jìn)行了設(shè)計(jì)。

3.1.3降低了后續(xù)測(cè)試的成本

TDD先考慮代碼的使用需求――功能、過(guò)程、接口等，再確認(rèn)需求是無(wú)歧義的、可驗(yàn)證的。首先將測(cè)試提到編碼之前并頻繁地運(yùn)行所有測(cè)試，盡早地發(fā)現(xiàn)或避免錯(cuò)誤，不斷地重構(gòu)代碼并消除重復(fù)設(shè)計(jì)，提高代碼的重用，極大地提高代碼的健壯性。

3.1.4提供持續(xù)的回歸測(cè)試

TDD能幫助開(kāi)發(fā)人員持續(xù)地跟蹤軟件生命周期內(nèi)的全部狀態(tài)，并快速地反饋開(kāi)發(fā)人員，使開(kāi)發(fā)人員無(wú)需過(guò)分擔(dān)心不可預(yù)知的異常并大膽地實(shí)施重構(gòu)。

3.1.5提供合格的文檔

TDD所產(chǎn)生的單元測(cè)試代碼是最完美的開(kāi)發(fā)者文檔，含有API如何使用的信息，同時(shí)與最新的代碼保持同步。

3.2 TDD的一般步驟

（1）明確當(dāng)前主要完成的功能，并形成電子或者書(shū)面的記錄表單；

（2）快速地編寫(xiě)此功能的測(cè)試用例；

（3）運(yùn)行測(cè)試，發(fā)現(xiàn)新增的測(cè)試不能通過(guò)測(cè)試；

（4）改動(dòng)測(cè)試程序，盡快讓測(cè)試程序通過(guò)運(yùn)行

（5）重構(gòu)已完成的代碼，消除重復(fù)設(shè)計(jì)，優(yōu)化程序結(jié)構(gòu)，并保證測(cè)試通過(guò)

（6）循環(huán)完成所有功能。

3.3測(cè)試原則

（1）測(cè)試隔離，不同代碼的測(cè)試相互隔離，對(duì)單塊代碼的測(cè)試應(yīng)只考慮該代碼的測(cè)試，

（2）測(cè)試列表，在軟件開(kāi)發(fā)的任意階段，添加新功能需求時(shí)，需將相關(guān)功能點(diǎn)添加到測(cè)試列表中，不斷地完成測(cè)試用例，并重構(gòu)。

（3）測(cè)試驅(qū)動(dòng)，在完成代碼類、功能設(shè)計(jì)前，首先編制測(cè)試代碼，考慮如何使用與測(cè)試，繼而設(shè)計(jì)編碼。

（4）測(cè)試與斷言優(yōu)先，在編寫(xiě)代碼之前編寫(xiě)測(cè)試，在編制代碼過(guò)程中，首先編寫(xiě)斷言語(yǔ)句，再編寫(xiě)輔助語(yǔ)句。

（5）可測(cè)試性，代碼設(shè)計(jì)過(guò)程必須具有較強(qiáng)的可測(cè)試性，有助于提高代碼的內(nèi)聚性和復(fù)用。

（6）及時(shí)重構(gòu)，無(wú)論是功能代碼還是測(cè)試代碼，對(duì)結(jié)構(gòu)不合理、重復(fù)的代碼，都要進(jìn)行及時(shí)的重構(gòu)。

4測(cè)試框架

4.1 unittest測(cè)試框架

該測(cè)試框架中最核心的概念為：test case，test suite，test runner，text fixture。unittest提供了TestCase基類來(lái)構(gòu)造單元測(cè)試用例，在構(gòu)建測(cè)試用例的時(shí)候，使用setUp方法初始化測(cè)試環(huán)境，tearDown方法執(zhí)行掃尾結(jié)束工作并還原測(cè)試環(huán)境，這類似于上下文管理器，setUp和tearDown每次必須運(yùn)行一次（如圖2）。

圖2：測(cè)試流程圖

TestLoader用來(lái)加載TestCase、TestSuite，可使用LoadTestsForm方法，創(chuàng)建測(cè)試實(shí)例，繼而add到TestSuite中，返回一個(gè)TestSuite實(shí)例。使用TextTestRunner執(zhí)行測(cè)試用例，其中，測(cè)試結(jié)果保存到Result中，包括運(yùn)行的用例數(shù)量、成功與失敗信息。Fixture完成測(cè)試環(huán)境的搭建和銷毀。

通過(guò)命令行或者main函數(shù)來(lái)啟動(dòng)單元測(cè)試，main會(huì)調(diào)用run來(lái)執(zhí)行，當(dāng)Runner執(zhí)行時(shí)，將執(zhí)行結(jié)果輸出到控制臺(tái)或文件，通過(guò)設(shè)置verbosity參數(shù)控制執(zhí)行結(jié)果的輸出。unittest框架比較笨重且難以擴(kuò)展，必須在TestCase子類中編寫(xiě)所有的單元測(cè)試和斷言方法，必須為測(cè)試活動(dòng)建立測(cè)試套件。

4.2 doctest測(cè)試

doctest測(cè)試框架在文檔字符串（docstring）內(nèi)嵌注釋，這些注釋將各單元模塊的期望結(jié)果予以表達(dá)，字符串如同交互式shell會(huì)話搜索Python代碼，繼而嘗試執(zhí)行并驗(yàn)證結(jié)果。測(cè)試用例的位置必須放在整個(gè)模塊文件的開(kāi)始部分或緊接聲明語(yǔ)句的下一行。設(shè)置verbose 參數(shù)用于控制是否輸出詳細(xì)信息，默認(rèn)不輸出任何東西，除非測(cè)試失敗。

當(dāng)不帶任何參數(shù)運(yùn)行 test_basic.py 時(shí)。將test_basic 導(dǎo)入到腳本的命名空間中，可導(dǎo)入其他希望要測(cè)試的模塊。testmod函數(shù)去遍歷模塊本身、模塊函數(shù)及其所有文檔字符串，以找出所有類似交互式 shell 會(huì)話的內(nèi)容。

doctest 在解析顯式會(huì)話時(shí)，將空行作為會(huì)話結(jié)束來(lái)處理?？衫梦臋n字符串自定義的函數(shù)來(lái)解決此問(wèn)題。一方面由于文檔字符串畢竟是字符串換碼，所以要注意＼n這樣的序列被擴(kuò)展。另一方面由 doctest處理的文檔字符串可能會(huì)在其內(nèi)部包含回溯。

4.3 nose 系列

由于擴(kuò)展自u(píng)nittest的擴(kuò)展，nose 也支持類似于 setUp、setUpClass、setUpModule 的測(cè)試環(huán)境創(chuàng)建方式，所以python的測(cè)試更加簡(jiǎn)單。nose自動(dòng)發(fā)現(xiàn)測(cè)試代碼并執(zhí)行，nose提供了大量的插件，比如測(cè)試輸出的xUnitcompatible，覆蓋報(bào)表等等。

路徑、模塊（文件）、類、函數(shù)的名字若匹配上testMatch，那就會(huì)被認(rèn)為是一個(gè)用例，另外所有 unittest.TestCase 的子類都會(huì)被當(dāng)做測(cè)試用例。nose主要檢查一個(gè)測(cè)試用例的文件夾，否則會(huì)忽略此文件路徑。顯式地避免某個(gè)對(duì)象被當(dāng)做測(cè)試用例的方法是：給其或其容器添加一個(gè) _test_ 屬性，并且運(yùn)算結(jié)果不為 True，只要 bool（_test_） == False 即可。

nose可不使用特定的格式、不需要一個(gè)類容器，甚至不需要 import，但nose測(cè)試用例的命名仍需以 test_開(kāi)頭。

4.4 pytest

作為unittest的替代工具，pytest是一個(gè)語(yǔ)法簡(jiǎn)單且功能豐富靈活的測(cè)試框架。相比unittest，實(shí)現(xiàn)相同的測(cè)試功能，pytest更簡(jiǎn)潔高效；支持簡(jiǎn)單的單元測(cè)試和復(fù)雜的功能測(cè)試，支持參數(shù)化，支持重復(fù)執(zhí)行失敗的case，支持運(yùn)行由nose、unittest編寫(xiě)的測(cè)試case。

pytest 創(chuàng)建測(cè)試環(huán)境（fixture）的方式，通過(guò)顯式指定scope參數(shù)來(lái)選擇裝飾器。一個(gè)fixture 函數(shù)的類型一旦定義即確定，對(duì)于 scope=function 的 fixture 函數(shù)會(huì)在測(cè)試用例的前后分別調(diào)用 setup/teardown。測(cè)試用例的參數(shù)只負(fù)責(zé)引用具體的對(duì)象，并不關(guān)心作用域；同時(shí)setup/teardown 語(yǔ)法與 unittest 的兼容性不如 nose 高。fixture在參數(shù)列表中可以明了地知道哪些tests使用了一個(gè)資源，無(wú)需人為地創(chuàng)建類，只需分離fixture應(yīng)用。而對(duì)于一個(gè)資源而言，teardown代碼是緊密地和setup代碼耦合的。常常需在資源setup代碼的位置處指定資源的生命周期的范圍來(lái)節(jié)省測(cè)試時(shí)間。

一般而言，測(cè)試類以Test開(kāi)頭的類，但不能帶有 _init_方法；測(cè)試文件以test開(kāi)頭或者結(jié)尾的文件；測(cè)試函數(shù)以test開(kāi)頭。pytest會(huì)自動(dòng)進(jìn)行收集測(cè)試用例，在pytest.ini配置文件中，python_classes指定測(cè)試類和測(cè)試文件、python_functions 指定測(cè)試函數(shù)。在setup.cfg文件中norecursedirs 指定禁止目錄。

4.5 unittest2測(cè)試框架

unittest2測(cè)試框架是unittest的升級(jí)版，改善了API以及診斷語(yǔ)法。由于篇幅所限，只說(shuō)明一點(diǎn)：可使用import unittest2 as unittest在unittest與unittest2之間進(jìn)行切換。

5結(jié)束語(yǔ)

構(gòu)建“TDD友好”的系統(tǒng)，需要進(jìn)行分層架構(gòu)，建立標(biāo)準(zhǔn)一致的系統(tǒng)，操作環(huán)境可控，努力創(chuàng)建高內(nèi)聚低耦合的結(jié)構(gòu)，在TDD實(shí)踐過(guò)程可實(shí)現(xiàn)代碼的低層設(shè)計(jì)。而TDD 并不能直接提高設(shè)計(jì)能力，它要求開(kāi)發(fā)人員思想上重視測(cè)試，掌握重構(gòu)與設(shè)計(jì)模式等知識(shí)，從而間接改善軟件設(shè)計(jì)。

參考文獻(xiàn)

[1] Beck，K.測(cè)試驅(qū)動(dòng)開(kāi)發(fā)（中文版） [M].孫平平譯.北京：中國(guó)電力出版社， 2004.

[2] 雨痕.Python3學(xué)習(xí)筆記（上卷）[M].北京：電子工業(yè)出版社，2018.

[3] Matthew，K.Python機(jī)器學(xué)習(xí)實(shí)踐，測(cè)試驅(qū)動(dòng)的開(kāi)發(fā)方法[M].劉江一，上官明喬，白皓，劉旭威譯.北京：機(jī)械工業(yè)出版社，2017.