python斷言

『壹』 python 介面測試怎麼做斷言

要看你是什麼樣的介面
比如比較簡單的http
service
的介面，需要提供介面的訪問地址，訪問方式（get？
post？put？delete？），以及參數
然後用python來模擬發出請求，得到介面的返回，返回是否正確
你做測試，肯定清楚什麼樣的輸入輸出是正確的

『貳』 Python中何時使用斷言

使用斷言表達式，通常會有人誤用它，所以我決定寫一篇文章來說明何時使用斷言，什麼時候不用。

為那些還不清楚它的人，Python的assert是用來檢查一個條件，如果它為真，就不做任何事。如果它為假，則會拋出AssertError並且包含錯誤信息。例如：

py> x = 23
py> assert x > 0, "x is not zero or negative"
py> assert x%2 == 0, "x is not an even number"
Traceback (most recent call last):
File "", line 1, in
AssertionError: x is not an even number
很多人用assert作為一個很快和容易的方法來在參數錯誤的時候拋出異常。但這樣做是錯的，非常錯誤，有兩個原因。首先AssertError不是在測試參數時應該拋出的錯誤。你不應該像這樣寫代碼：

if not isinstance(x, int):
raise AssertionError("not an int")
你應該拋出TypeError的錯誤，assert會拋出錯誤的異常。

但是，更危險的是，有一個關於assert的困擾：它可以被編譯好然後從來不執行，如果你用 –O 或 –oo 選項運行Python，結果不保證assert表達式會運行到。當適當的使用assert時，這是未來，但是當assert不恰當的使用時，它會讓代碼用-O執行時出錯。

那什麼時候應該使用assert？沒有特定的規則，斷言應該用於：

防禦型的編程
運行時檢查程序邏輯
檢查約定
程序常量
檢查文檔
（在測試代碼的時候使用斷言也是可接受的，是一種很方便的單元測試方法，你接受這些測試在用-O標志運行時不會做任何事。我有時在代碼里使用assert False來標記沒有寫完的代碼分支，我希望這些代碼運行失敗。盡管拋出NotImplementedError可能會更好。）

關於斷言的意見有很多，因為它能確保代碼的正確性。如果你確定代碼是正確的，那麼就沒有用斷言的必要了，因為他們從來不會運行失敗，你可以直接移除這些斷言。如果你確定檢查會失敗，那麼如果你不用斷言，代碼就會通過編譯並忽略你的檢查。

在以上兩種情況下會很有意思，當你比較肯定代碼但是不是絕對肯定時。可能你會錯過一些非常古怪的情況。在這個情況下，額外的運行時檢查能幫你確保任何錯誤都會盡早地被捕捉到。

另一個好的使用斷言的方式是檢查程序的不變數。一個不變數是一些你需要依賴它為真的情況，除非一個bug導致它為假。如果有bug，最好能夠盡早發現，所以我們為它進行一個測試，但是又不想減慢代碼運行速度。所以就用斷言，因為它能在開發時打開，在產品階段關閉。

一個非變數的例子可能是，如果你的函數希望在它開始時有資料庫的連接，並且承諾在它返回的時候仍然保持連接，這就是函數的不變數：

def some_function(arg):
assert not DB.closed()
...
# code goes here
assert not DB.closed()
return result
斷言本身就是很好的注釋，勝過你直接寫注釋：

# when we reach here, we know that n > 2

你可以通過添加斷言來確保它：

assert n > 2

斷言也是一種防禦型編程。你不是讓你的代碼防禦現在的錯誤，而是防止在代碼修改後引發的錯誤。理想情況下，單元測試可以完成這樣的工作，可是需要面對的現實是，它們通常是沒有完成的。人們可能在提交代碼前會忘了運行測試代碼。有一個內部檢查是另一個阻擋錯誤的防線，尤其是那些不明顯的錯誤，卻導致了代碼出問題並且返回錯誤的結果。

加入你有一些if…elif 的語句塊，你知道在這之前一些需要有一些值：

# target is expected to be one of x, y, or z, and nothing else.
if target == x:
run_x_code()
elif target == y:
run_y_code()
else:
run_z_code()
假設代碼現在是完全正確的。但它會一直是正確的嗎？依賴的修改，代碼的修改。如果依賴修改成 target = w 會發生什麼，會關繫到run_w_code函數嗎？如果我們改變了代碼，但沒有修改這里的代碼，可能會導致錯誤的調用 run_z_code 函數並引發錯誤。用防禦型的方法來寫代碼會很好，它能讓代碼運行正確，或者立馬執行錯誤，即使你在未來對它進行了修改。

在代碼開頭的注釋很好的一步，但是人們經常懶得讀或者更新注釋。一旦發生這種情況，注釋會變得沒用。但有了斷言，我可以同時對代碼塊的假設書寫文檔，並且在它們違反的時候觸發一個干凈的錯誤

assert target in (x, y, z)
if target == x:
run_x_code()
elif target == y:
run_y_code()
else:
assert target == z
run_z_code()
這樣，斷言是一種防禦型編程，同時也是一種文檔。我想到一個更好的方案：

if target == x:
run_x_code()
elif target == y:
run_y_code()
elif target == z:
run_z_code()
else:
# This can never happen. But just in case it does...
raise RuntimeError("an unexpected error occurred")
按約定進行設計是斷言的另一個好的用途。我們想像函數與調用者之間有個約定，比如下面的：

「如果你傳給我一個非空字元串，我保證傳會字元串的第一個字母並將其大寫。」

如果約定被函數或調用這破壞，代碼就會出問題。我們說函數有一些前置條件和後置條件，所以函數就會這么寫：

def first_upper(astring):
assert isinstance(astring, str) and len(astring) > 0
result = astring[0].upper()
assert isinstance(result, str) and len(result) == 1
assert result == result.upper()
return result
按約定設計的目標是為了正確的編程，前置條件和後置條件是需要保持的。這是斷言的典型應用場景，因為一旦我們發布了沒有問題的代碼到產品中，程序會是正確的，並且我們能安全的移除檢查。

下面是我建議的不要用斷言的場景：

不要用它測試用戶提供的數據
不要用斷言來檢查你覺得在你的程序的常規使用時會出錯的地方。斷言是用來檢查非常罕見的問題。你的用戶不應該看到任何斷言錯誤，如果他們看到了，這是一個bug，修復它。
有的情況下，不用斷言是因為它比精確的檢查要短，它不應該是懶碼農的偷懶方式。
不要用它來檢查對公共庫的輸入參數，因為它不能控制調用者，所以不能保證調用者會不會打破雙方的約定。
不要為你覺得可以恢復的錯誤用斷言。換句話說，不用改在產品代碼里捕捉到斷言錯誤。
不要用太多斷言以至於讓代碼很晦澀。

『叄』 python 正則表達式 斷言解釋

>>>re.findall(r'(?<=ab).*?(?=d)',s)#非貪婪模式，先找左邊有ab，再開始0個字元，
#查看是否右邊有d，不滿足再向後獲取一個字元，直到滿足右邊有字元d；
#剩餘字元串dddd再開始查找ab，搜索到字元串結尾，未找到，退出
['c']
>>>re.findall(r'(?<=ab).*(?=d)',s)#貪婪模式，先找到ab，
#再匹配後面所有字元，查看後面有沒有d，如果不滿足再拋出右面一個字元
#倒退查找後面有沒有d，直到找到；剩餘字元串d中繼續查找ab，不能找到，退出
['cddd']
>>>re.findall(r'(?<=ab).*?',s)#左邊有ab，非貪婪模式【先找到ab，後面0個字元，
#滿足整個匹配；從剩餘的dddd中再次查找，沒找到ab，退出】
['']
>>>re.findall(r'(?<=ab).*',s)##左邊有ab，貪婪模式【找到ab，匹配後面整個
#字元串，滿足條件；沒有剩餘字元串，退出】
['cdddd']

>>>re.findall(r'.*(?=d)',s)#先是貪婪模式匹配所有字元，依次倒退找右邊是d的
#下次查找位置在本次位置的後面開始，即剩餘一個d字元串中找，能夠匹配，但匹配的是空串
['aabcddd','']
>>>re.findall(r'.*?(?=d)',s)#從0個字元串開始，判斷後面有沒有d，如果沒有向右
#取得一個字元繼續判斷，直到找到d{故第一次aabc}；下一次從剩餘的dddd找，仍然是從0個字元
#判斷，後面有d，返回空串；下次從剩餘的ddd中……故四個空串
['aabc','','','','']
>>>re.findall(r'(d)',s)#單個字元的捕獲，有幾個d返回共多少個元素的列表
['d','d','d','d']

『肆』 appium+python 斷言和輸出

其實就是檢查頁面某一固定的元素是否存在。可以用assert斷言，當然也可以自己寫if語句進行判斷。assert用得比較多，舉例說明：例如，登錄成功後的界面，某個固定控制項包含字元串「aaa」，找到，則證明登錄成功。assertEqual('aaa',driver.find_elements_by_class_name("android.widget.EditText").text)assertEqual()只是其中一個方法。斷言的用法還有很多，感興趣可以網路一下。

『伍』 selenium python 斷言怎麼寫

斷言就是判斷是否跟預期結果一致，不一致的話，測試用例直接失敗，程序便不再執行下去。

舉個簡單的例子。比如點擊某個按鈕會跳轉到某個頁面上，我們會設置斷言為是否能成功跳轉到這個頁面上，驗證的話，一般為這個頁面的信息。如果都不跳轉成功，那麼頁面信息就什麼沒有，那麼驗證也無從入手。

斷言使用的主要是assertEqual的方法

如驗證網路搜索的標題是否為「123_網路搜索」

self.assertEqual(u"123_網路搜索"，driver.title)
如要驗證是否為false

self.assertFalse(driver.title)
如要驗證是否為true

self.assertTrue(driver.title)
而驗證為了保證失敗也能正常運行下去，一般情況下都是在驗證的基礎上加異常捕獲

如驗證網路搜索的標題是否為「123_網路搜索」

try:
self.assertEqual(u"1234_網路搜索", driver.title)
except AssertionError as e:
print u"找不到這個標題"

『陸』 Python中何時使用斷言 assert

assert用於調試程序，如果與斷言不相符則會拋出異常，如：

a=0
asserta!=0,'aiszero'
#Traceback(mostrecentcalllast):
#File"<pyshell#93>",line1,in<mole>
#asserta!=0,'aiszero'
#AssertionError:aiszero

即如果斷言語句為False，拋出異常並列印字元串，如果斷言語句為True，則程序繼續執行。

『柒』 python常用的斷言方式有哪些

（一）assertEqual 和 assertNotEqual
assertEqual：如兩個值相等，則pass
assertNotEqual：如兩個值不相等，則pass
下面看下具體使用方法
self.driver.find_element_by_xpath("//android.widget.LinearLayout[1]/android.support.v7.app.ActionBar.e[2]").click()#切到超模25tab
sleep(3)
self.assertEqual(self.driver.find_element_by_id('com.boohee.secret:id/tv_title').text,u'超模25','切到超模25tab失敗')
（1）這邊是通過id（com.boohee.secret:id/tv_title）獲取它的text值，與預期「超模25」對比，如相等則pass；不相等則fail。
（2）後面的「切到超模25tab失敗」是fail時需要列印的信息，可寫可不寫。
斷言assertNotEqual反著用就可以了。
（二）assertTrue和assertFalse
assertTrue：判斷bool值為True，則pass
assertFalse：判斷bool值為False，則Pass
下面看下具體使用方法
self.driver.find_element_by_xpath("//android.widget.LinearLayout[1]/android.widget.TextView[1]").click()#點擊登錄入口
sleep(2)
self.driver.find_element_by_xpath("//android.widget.LinearLayout[1]/android.widget.EditText[1]").send_keys("testq1")#輸入用戶名
sleep(2)
self.assertTrue(self.find_element_by_id('com.boohee.secret:id/btn_login').is_enabled(),'未輸密碼登錄按鈕為不可點狀態,Fail')
（1）這邊是通過id（com.boohee.secret:id/btn_login）獲取它的激活狀態，如為True則pass；反之則fail。
（2）後面的「未輸密碼登錄按鈕為不可點狀態」是fail時需要列印的信息，可寫可不寫。
斷言assertFalse反著用就可以了。
（三）assertIsNone和assertIsNotNone
assertIsNone：不存在，則pass
assertIsNotNone：存在，則pass
下面看下具體使用方法
self.driver.find_element_by_xpath("//android.widget.LinearLayout[1]/android.widget.TextView[1]").click()#點擊登錄入口
sleep(2)
self.driver.find_element_by_xpath("//android.widget.LinearLayout[1]/android.widget.EditText[1]").send_keys("testq1")#輸入用戶名
sleep(2)
self.driver.find_element_by_xpath("//android.widget.LinearLayout[2]/android.widget.EditText[1]").send_keys("boohee")#輸入密碼
sleep(2)
self.driver.find_element_by_xpath("//android.widget.LinearLayout[1]/android.widget.Button[1]").click()#點擊登錄按鈕
sleep(10)
self.assertIsNotNone(self.driver.find_element_by_id('com.boohee.secret:id/tv_edit_profile'),'無編輯資料按鈕,登錄失敗,Fail')
（1）這邊是通過尋找id（com.boohee.secret:id/tv_edit_profile）的元素是否存在，如存在則pass；不存在則fail。
（2）後面的「無編輯資料按鈕,登錄失敗,Fail」是fail時需要列印的信息，可寫可不寫。
斷言assertIsNone反著用就可以了。

『捌』 大家好，python中的斷言如何使用

斷言是只用於開發階段的工具，作為介面設計上的契約檢查，在生產環境上一般要去掉減少斷言對性能的影響（python可以編譯成.pyo以關閉斷言）

『玖』 python斷言assertequals是什麼意思

根據老外的解釋就是說assertEqual與assertEquals沒有區別，可以說是完全一樣的函數，而現在assertEquals函數已經被棄用，也就說不建議你使用了，以後可能這個方法就在python中消失了，在python3.0中已經趨向使用不帶s的assert方法了，但是現在仍然沒有刪掉的原因是因為有一些舊代碼和項目在使用帶s的方法，語言要保持舊代碼的兼容性。

至於assert那就很好解釋了，就是判斷0,1 也就是python中的真假關系

assertAlmostEquals這2個方法存在的原因與上面的相同，建議你不要使用帶s的方法了，這個方法是做一個粗略判斷，判斷的值為你4舍5入後的值，也就是說5.1與5.2是相等的，如果使用這樣的assert方法。

『拾』 Python 中何時使用斷言

1、assert語句用來聲明某個條件是真的。
2、如果你非常確信某個你使用的列表中至少有一個元素，而你想要檢驗這一點，並且在它非真的時候引發一個錯誤，那麼assert語句是應用在這種情形下的理想語句。
3、當assert語句失敗的時候，會引發一AssertionError。
測試程序：
>>> mylist = ['item']
>>> assert len(mylist) >= 1
>>>mylist.pop()
'item'
>>> assert len(mylist) >= 1
Traceback (most recent call last):
File "", line 1, in< mole>
AssertionError
>>>
這個問題是如何在一些場景下使用斷言表達式，通常會有人誤用它，所以我決定寫一篇文章來說明何時使用斷言，什麼時候不用。
為那些還不清楚它的人，Python的assert是用來檢查一個條件，如果它為真，就不做任何事。如果它為假，則會拋出AssertError並且包含錯誤信息。
建議的不要用斷言的場景：
不要用它測試用戶提供的數據
不要用斷言來檢查你覺得在你的程序的常規使用時會出錯的地方。斷言是用來檢查非常罕見的問題。你的用戶不應該看到任何斷言錯誤，如果他們看到了，這是一個bug，修復它。
有的情況下，不用斷言是因為它比精確的檢查要短，它不應該是懶碼農的偷懶方式。
不要用它來檢查對公共庫的輸入參數，因為它不能控制調用者，所以不能保證調用者會不會打破雙方的約定。
不要為你覺得可以恢復的錯誤用斷言。換句話說，不用改在產品代碼里捕捉到斷言錯誤。
不要用太多斷言以至於讓代碼很晦澀。