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，修复它。
有的情况下，不用断言是因为它比精确的检查要短，它不应该是懒码农的偷懒方式。
不要用它来检查对公共库的输入参数，因为它不能控制调用者，所以不能保证调用者会不会打破双方的约定。
不要为你觉得可以恢复的错误用断言。换句话说，不用改在产品代码里捕捉到断言错误。
不要用太多断言以至于让代码很晦涩。