有時候,在測試過程中,可能會用到測試樁。舉個例子,模組a是我們的被測試系統,但是模組a需要從模組b獲取到需要的資料才能正常執行,但是模組b還沒有ready,那這種情況下如何測試模組a呢?這個時候就需要乙個測試樁,用測試樁來模擬模組b響應模組a的請求。
尤其是一些新手,一聽到測試樁,可能就懵逼了,覺得是乙個超級高大上的東西。其實它的原理非常簡單,幾行**就能搞定的事情。通常情況下,測試樁就是乙個執行著的普通http/https服務,本身沒有業務邏輯,僅僅被動響應被測試系統的請求,返回預定義的結構化的測試資料。這裡聽上去比較拗口,但是感覺也不太好用人話表述,直接上圖吧。
這裡一定要弄清楚誰是被測試系統,誰是測試樁,之前在評審乙個測試的時候,發現乙個員工稀里糊塗廢了半天勁,把被測試系統給模擬掉了,自動化用例直接呼叫測試樁,我當時想死的心都有了。
既然原理這麼簡單,那實現起來肯定也不會複雜。起乙個http服務,跟前請求的路徑和方法,響應對應的結構化資料就可以了。
我們舉個例子。
當收到http get請求,並且路徑名稱是「/getinfo」的時候,返回狀態碼200,外加響應資料;
當收到http get請求,並且路徑名稱不是「/getinfo」的時候,返回404;
當收到http post請求,並且路徑名稱是「/profile」的時候,返回狀態碼200,外加響應資料;
當收到http post請求,並且路徑名稱不是「/profile」的時候,返回404。
這個例子的邏輯夠清晰吧? 廢話不多說,直接上源**(這裡的**是當年用python2寫的,如果現在用flask實現,會更加精煉)。
:# 定義函式,用於處理http get請求
defdo_get
(self)
:# 當請求path為/getinfo的時候,響應200
if self.path.find(
"/getinfo"
)>=0:
result_code =
200 content =
# 否則,響應404
else
: result_code =
404 content =
'}' self.send_response(result_code)
self.send_header(
"content-type"
,"text/plain; charset=utf-8"
) self.send_header(
"content-length"
,str
(len
(content)))
self.end_headers(
) self.wfile.write(content)
# 定義函式,用於處理http post請求
defdo_post
(self)
:# 當請求path為/profile的時候,響應200
if self.path.find(
"/profile"
)>=0:
result_code =
200 content =
# 否則,響應404
else
: result_code =
404 content =
'}',
self.send_response(result_code)
self.send_header(
"content-type"
,"text/plain; charset=utf-8"
) self.send_header(
"content-length"
,str
(len
(content)))
self.end_headers(
) self.wfile.write(content)
# 定義http server的埠和ip位址,指定ssl證書,啟動http server
)為了展示執行效果,這裡簡單寫了幾個自動化測試用例來直接請求測試樁(重要的話說三遍,真實情況下,測試用例不可能直接呼叫測試樁,測試用例請求的一定是被測試系統)。
如下**,在txt檔案中簡單定義了4個測試用例,對應上述的4種情況。
$ python2 debug_stub.py
測試用例執行結果如下。
這個時候,測試樁終端會列印出對應的請求。
很簡單吧。
手把手教你寫Undo Redo程式
手把手教你寫 undo redo程式 undo redo 操作是很多具體編輯功能的軟體所不能缺少的。最典型兩種型別就是文字編輯和影象編輯軟體。然而它的實現在某種程度上來說也不是很簡單。我也廢話少說。要在程式中支援 undo redo 操作,就需要儲存一些必要的資訊,這個是眾所周知的。如果想支援無限級...
手把手教你寫Undo Redo程式
手把手教你寫undo redo程式 undo redo操作是很多具體編輯功能的軟體所不能缺少的。最典型兩種型別就是文字編輯和影象編輯軟體。然而它的實現在某種程度上來說也不是很簡單。我也廢話少說。要在程式中支援undo redo操作,就需要儲存一些必要的資訊,這個是眾所周知的。如果想支援無限級的und...
手把手教你寫ORM(三)
昨天處於暈死狀態,少寫了乙個元件,還需要乙個元件用來專門管理cache的,這裡說道為什麼要分這麼多元件,其實這是習慣問題,很多人喜歡寫乙個很大的dll,不過我比較喜歡拆分,小粒度的專案比較好管理和單獨測試,把用單元測試驗證好了的小組件湊起來除錯和寫成乙個巨大的dll慢慢一行行的追蹤 肯定是前者更加舒...