本文想針對(duì)測試中一種很常見的測試場景,即參數(shù)化測試,繼續(xù)聊聊關(guān)于測試的話題,并嘗試將這幾個(gè)測試框架串聯(lián)起來,做一個(gè)橫向的比對(duì),加深理解。
1、什么是參數(shù)化測試?
對(duì)于普通測試來說,一個(gè)測試方法只需要運(yùn)行一遍,而參數(shù)化測試對(duì)于一個(gè)測試方法,可能需要傳入一系列參數(shù),然后進(jìn)行多次測試。
比如,我們要測試某個(gè)系統(tǒng)的登錄功能,就可能要分別傳入不同的用戶名與密碼,進(jìn)行測試:使用包含非法字符的用戶名、使用未注冊的用戶名、使用超長的用戶名、使用錯(cuò)誤的密碼、使用合理的數(shù)據(jù)等等。
參數(shù)化測試是一種“數(shù)據(jù)驅(qū)動(dòng)測試”(Data-Driven Test),在同一個(gè)方法上測試不同的參數(shù),以覆蓋所有可能的預(yù)期分支的結(jié)果。它的測試數(shù)據(jù)可以與測試行為分離,被放入文件、數(shù)據(jù)庫或者外部介質(zhì)中,再由測試程序讀取。
2、參數(shù)化測試的實(shí)現(xiàn)思路?
通常而言,一個(gè)測試方法就是一個(gè)最小的測試單元,其功能應(yīng)該盡量地原子化和單一化。
先來看看兩種實(shí)現(xiàn)參數(shù)化測試的思路:一種是寫一個(gè)測試方法,在其內(nèi)部對(duì)所有測試參數(shù)進(jìn)行遍歷;另一種是在測試方法之外寫遍歷參數(shù)的邏輯,然后依次調(diào)用該測試方法。
這兩種思路都能達(dá)到測試目的,在簡單業(yè)務(wù)中,沒有毛病。然而,實(shí)際上它們都只有一個(gè)測試單元,在統(tǒng)計(jì)測試用例數(shù)情況,或者生成測試報(bào)告的時(shí)候,并不樂觀??蓴U(kuò)展性也是個(gè)問題。
那么,現(xiàn)有的測試框架是如何解決這個(gè)問題的呢?
它們都借助了裝飾器,主要的思路是:利用原測試方法(例如 test()),來生成多個(gè)新的測試方法(例如 test1()、test2()……),并將參數(shù)依次賦值給它們。
由于測試框架們通常把一個(gè)測試單元統(tǒng)計(jì)為一個(gè)“test”,所以這種“由一生多”的思路相比前面的兩種思路,在統(tǒng)計(jì)測試結(jié)果時(shí),就具有很大的優(yōu)勢。
3、參數(shù)化測試的使用方法?
Python 標(biāo)準(zhǔn)庫中的unittest自身不支持參數(shù)化測試,為了解決這個(gè)問題,有人專門開發(fā)了兩個(gè)庫:一個(gè)是ddt,一個(gè)是parameterize。
ddt 正好是“Data-Driven Tests”(數(shù)據(jù)驅(qū)動(dòng)測試)的縮寫。典型用法:
import unittest from ddt import ddt,data,unpack @ddt class MyTest(unittest.TestCase): @data((3, 1), (-1, 0), (1.2, 1.0)) @unpack def test_values(self, first, second): self.assertTrue(first > second) unittest.main(verbosity=2)
運(yùn)行的結(jié)果如下:
test_values_1__3__1_ (__main__.MyTest) ... ok test_values_2___1__0_ (__main__.MyTest) ... FAIL test_values_3__1_2__1_0_ (__main__.MyTest) ... ok ================================================== FAIL: test_values_2___1__0_ (__main__.MyTest) -------------------------------------------------- Traceback (most recent call last): File "C:/Python36/lib/site-packages/ddt.py", line 145, in wrapper return func(self, *args, **kwargs) File "C:/Users/pythoncat/PycharmProjects/study/testparam.py", line 9, in test_values self.assertTrue(first > second) AssertionError: False is not true ---------------------------------------------- Ran 3 tests in 0.001s FAILED (failures=1)
結(jié)果顯示有 3 個(gè) tests,并詳細(xì)展示了運(yùn)行狀態(tài)以及斷言失敗的信息。
需要注意的是,這 3 個(gè) test 分別有一個(gè)名字,名字中還攜帶了其參數(shù)的信息,而原來的 test_values 方法則不見了,已經(jīng)被一拆為三。
在上述例子中,ddt 庫使用了三個(gè)裝飾器(@ddt、@data、@unpack),實(shí)在是很丑陋。下面看看相對(duì)更好用的 parameterized 庫:
import unittest from parameterized import parameterized class MyTest(unittest.TestCase): @parameterized.expand([(3,1), (-1,0), (1.5,1.0)]) def test_values(self, first, second): self.assertTrue(first > second) unittest.main(verbosity=2)
測試結(jié)果如下:
test_values_0 (__main__.MyTest) ... ok test_values_1 (__main__.MyTest) ... FAIL test_values_2 (__main__.MyTest) ... ok ========================================= FAIL: test_values_1 (__main__.MyTest) ----------------------------------------- Traceback (most recent call last): File "C:/Python36/lib/site-packages/parameterized/parameterized.py", line 518, in standalone_func return func(*(a + p.args), **p.kwargs) File "C:/Users/pythoncat/PycharmProjects/study/testparam.py", line 7, in test_values self.assertTrue(first > second) AssertionError: False is not true ---------------------------------------- Ran 3 tests in 0.000s FAILED (failures=1)
這個(gè)庫只用了一個(gè)裝飾器 @parameterized.expand,寫法上可就清爽多了。
同樣提醒下,原來的測試方法已經(jīng)消失了,取而代之的是三個(gè)新的測試方法,只是新方法的命名規(guī)則與 ddt 的例子不同罷了。
介紹完 unittest,接著看已經(jīng)死翹翹了的nose以及新生的nose2。nose 系框架是帶了插件(plugins)的 unittest,以上的用法是相通的。
另外,nose2 中還提供了自帶的參數(shù)化實(shí)現(xiàn):
import unittest from nose2.tools import params @params(1, 2, 3) def test_nums(num): assert num < 4 class Test(unittest.TestCase): @params((1, 2), (2, 3), (4, 5)) def test_less_than(self, a, b): assert a < b
最后,再來看下 pytest 框架,它這樣實(shí)現(xiàn)參數(shù)化測試:
import pytest @pytest.mark.parametrize("first,second", [(3,1), (-1,0), (1.5,1.0)]) def test_values(first, second): assert(first > second)
測試結(jié)果如下:
==================== test session starts ==================== platform win32 -- Python 3.6.1, pytest-5.3.1, py-1.8.0, pluggy-0.13.1 rootdir: C:/Users/pythoncat/PycharmProjects/study collected 3 items testparam.py .F testparam.py:3 (test_values[-1-0]) first = -1, second = 0 @pytest.mark.parametrize("first,second", [(3,1), (-1,0), (1.5,1.0)]) def test_values(first, second): > assert(first > second) E assert -1 > 0 testparam.py:6: AssertionError . [100%] ========================= FAILURES ========================== _________________________ test_values[-1-0] _________________________ first = -1, second = 0 @pytest.mark.parametrize("first,second", [(3,1), (-1,0), (1.5,1.0)]) def test_values(first, second): > assert(first > second) E assert -1 > 0 testparam.py:6: AssertionError ===================== 1 failed, 2 passed in 0.08s ===================== Process finished with exit code 0
依然要提醒大伙注意,pytest 也做到了由一變?nèi)?,然而我們卻看不到有新命名的方法的信息。這是否意味著它并沒有產(chǎn)生新的測試方法呢?或者僅僅是把新方法的信息隱藏起來了?
4、最后小結(jié)
上文中介紹了參數(shù)化測試的概念、實(shí)現(xiàn)思路,以及在三個(gè)主流的 Python 測試框架中的使用方法。我只用了最簡單的例子,為的是快速科普(言多必失)。
但是,這個(gè)話題其實(shí)還沒有結(jié)束。對(duì)于我們提到的幾個(gè)能實(shí)現(xiàn)參數(shù)化的庫,拋去寫法上大同小異的區(qū)別,它們在具體代碼層面上,又會(huì)有什么樣的差異呢?
具體來說,它們是如何做到把一個(gè)方法變成多個(gè)方法,并且將每個(gè)方法與相應(yīng)的參數(shù)綁定起來的呢?在實(shí)現(xiàn)中,需要解決哪些棘手的問題?
在分析一些源碼的時(shí)候,我發(fā)現(xiàn)這個(gè)話題還挺有意思,所以準(zhǔn)備另外寫一篇文章。那么,本文就到此為止了,謝謝閱讀。
作者簡介: 豌豆花下貓,生于廣東畢業(yè)于武大,現(xiàn)為蘇漂程序員,有一些極客思維,也有一些人文情懷,有一些溫度,還有一些態(tài)度。
評(píng)論
查看更多