unittest

一、运行第一个单元测试： 1.在Xcode 5中新建一个工程默认自带一个单元测试的文件夹，IDE自动生成了一个实现 XCTestCase 的.m文件，里面有一个失败测试(早期版本中实现的是SenTestCase，是苹果集成的第三方的，现在苹果建议使用新的XCTestCase)。 2.测试函数的要求是：1.必须无返回值；2.以test开头； 3.测试函数执行的顺序：以函数名中test后面的字符大小有关，比如-（void）test001XXX会先于-（void）test002XXX执行； 4.运行单元测试的快捷键：CMD + U; 二、各种断言测试： XCTFail(format…) 生成一个失败的测试； XCTAssertNil(a1, format...) 为空判断， a1 为空时通过，反之不通过； XCTAssertNotNil(a1, format…) 不为空判断，a1不为空时通过，反之不通过； XCTAssert(expression, format...) 当expression求值为TRUE时通过； XCTAssertTrue(expression, format...) 当expression求值为TRUE时通过； XCTAssertFalse(expression, format...) 当expression求值为False时通过；

unittest框架： 1、核心组成部分： 1）test case,测试用例，一个方法，必须以test开头，eg:test_login(),test_add(),test_minus() 2) test suite，测试集/测试套件，加载测试用例，用于执行测试，通常是以测试集方式方可执行,unittest.main() 3) test runner，执行测试 4) test fixture，测试装置：setUp(self),tearDown(self)；setUpClass(cls)，tearDownClass(cls) a)初始化（前置动作），回收资源（收尾）,setUp(self),tearDown(self)，方法级实例，每次执行均需要执行；每个测试用例执行前均执行一次初始化，执行一次资源回收 b)初始化（前置动作），回收资源（收尾）,setUpClass(cls)，tearDownClass(cls)，类级实例，每次执行只执行一次，单例设计模式;所有用例执行前只初始化一次，执行后只资源回收一次 5）Unittests for :光标在哪，运行至哪；Unittests in:执行所有用例 6）测试集：TestSuite,实例化测试测试集，然后添加测试用例至测试集 suite=unittest.TestSuite()#实例化测试测试集 suite.addTests

# import unittest # # todo # # class testhhh(unittest.TestCase): # # @classmethod # # todo:重要部分：类开始执行一次 # # def setUpClass(cls): # # print('开始') # # @classmethod # # todo:重要部分：类结束执行一次 # # def tearDownClass(cls): # # print('结束') # # def setUp(self): # # todo:重要部分：任意方法开始就执行一次 # # print('test___1') # # todo:重要部分：任意方法结束就执行一次 # # def tearDown(self): # # print('test___2') # # def test_1(self): # # print('hhuhuhuh') # # def test_2(self): # # print('seccc') # # if __name__ == '__main__': # # unittest.main() 来源： CSDN 作者： 青稞不是酒 链接： https://blog.csdn.net/weixin_40636547/article/details/104448546

import unittest class SimpleUnitTest(unittest.TestCase): def test_Fail(self): self.failUnless(True) def test_Fail(self): self.failIf(False) def test_assertEqual(self): self.assertEqual(1,3-2) def test_assertNotEqual(self): self.assertNotEqual(1,3-0) def test_assertTrue(self): self.assertTrue(True) def test_assertFalse(self): self.assertFalse(False) def test_assertIs(self): self.assertIs(10,5+5) def test_assertIsNot(self): self.assertIsNot(10,5+4) def test_assertIsNone(self): self.assertIsNone(None) def test_assertIsNotNone(self): self.assertIsNotNone('we are not none ok?') def test_asserIn

目录 1、unittest接口测试 2、简单实例 3、运行结果 unittest接口测试 上篇已经讲了接口测试的做法，利用的是postman工具，工具始终是工具，它有一定的局限性，比如测试数据的存放，断言的方法以及上下接口关联使用灵活性。python对http接口封装了一个requests库可以调用接口，结合unittest单元测试框架可以完美测试。 简单实例 import unittest import requests class GetEventListTest ( unittest . TestCase ) : """查询发布会接口测试""" def setUp ( self ) - > None : self . url = 'http://127.0.0.1:8000/api/get_event_list/' def test_get_event_null ( self ) : """发布会id为空""" r = requests . get ( self . url , params = { 'eid' : '' } ) result = r . json ( ) print ( result ) self . assertEqual ( result [ 'status' ] , 10021 ) self . assertEqual ( result [

前面总结了一篇关于接口测试的常规面试题，现在接口自动化测试用的比较多，也是被很多公司看好。那么想做接口自动化测试需要具备哪些能力呢？ 也就是面试的过程中，面试官会考哪些问题，知道你是不是真的做过接口自动化测试？总的来说问的比较多的就是以下几个问题： 1.json和字典的区别？ -对基础数据类型的考察 2.测试的数据你放在哪？ -数据与脚本分离 3.参数化 - 数据驱动模式 4.下个接口请求参数依赖上个接口的返回数据 - 参数关联 5.依赖于登录的接口如何处理 -token和session的管理 6.依赖第三方的接口如何处理 -mock模拟数据返回 7.不可逆的操作，如何处理，比如删除一个订单这种接口如何测试 -造数据 8.接口产生的垃圾数据如何清理 - 数据清理 9.一个订单的几种状态如何全部测到，如：未处理，处理中，处理失败，处理成功 - 造数据，改数据库订单状态 10.python如何连接数据库操作？ 11.其它的就是运行出报告、代码管理（git）、运行策略和持续集成jenkins相关了 1.json和字典dict的区别？ 现在自动化培训烂大街，是个人都能说的上几个框架，面试如果问框架相关问题，求职者只需一瓶82年的雪碧，会吹的让你怀疑人生！ 所以面试官为了更清楚的知道你是停留在表面上的花拳绣腿还是有扎实的基础，就不会问框架这种东西了。基本上问几个数据类型的基础就知道有没货了。

单元测试 单元测试是用来对一个模块、一个函数或者一个类进行正确性检验的测试工作 比如对Python中的abs 的测试 输入正数： 比如 1, 2, 3, 返回值不变 输入负数： 比如 -1, -2, -3, 返回值是本身取反 输入0： 比如 0, 返回值0 把上面的测试用例放到一个测试模块里，就是一个完整的单元测试。 如果单元测试通过，说明我们测试的这个函数能够正常工作。如果单元测试不通过，要么函数有bug，要么测试条件输入不正确，总之，需要修复使单元测试能够通过。 单元测试通过后有什么意义呢？如果我们对abs()函数代码做了修改，只需要再跑一遍单元测试，如果通过，说明我们的修改不会对abs()函数原有的行为造成影响，如果测试不通过，说明我们的修改与原有行为不一致，要么修改代码，要么修改测试。 这种以测试为驱动的开发模式最大的好处就是确保一个程序模块的行为符合我们设计的测试用例。在将来修改的时候，可以极大程度地保证该模块行为仍然是正确的。 我们来编写一个Dict类，这个类的行为和dict一致，但是可以通过属性来访问，用起来就像下面这样： >>> d = Dict(a=1, b=2) >>> d['a'] 1 >>> d.a 1 Dict 类的具体实现： 1 class Dict(dict): 2 def __init__(self,**kw): 3 super(Dict,self)

本人做测试工作，使用python编写自动化脚本，刚开始写博客，写一篇看看 unit test框架是基础框架，收集汇总了一些断言的写法如下： assert*():一些断言方法：在执行测试用例的过程中，最终用例是否执行通过，是通过判断测试得到的实际结果和预期结果是否相等决定的。 assertEqual(a,b，[msg=‘测试失败时打印的信息’]):断言a和b是否相等，相等则测试用例通过。 assertNotEqual(a,b，[msg=‘测试失败时打印的信息’]):断言a和b是否相等，不相等则测试用例通过。 assertTrue(x，[msg=‘测试失败时打印的信息’])：断言x是否True，是True则测试用例通过。 assertFalse(x，[msg=‘测试失败时打印的信息’])：断言x是否False，是False则测试用例通过。 assertIs(a,b，[msg=‘测试失败时打印的信息’]):断言a是否是b，是则测试用例通过。 assertNotIs(a,b，[msg=‘测试失败时打印的信息’]):断言a是否是b，不是则测试用例通过。 assertIsNone(x，[msg=‘测试失败时打印的信息’])：断言x是否None，是None则测试用例通过。 assertIsNotNone(x，[msg=‘测试失败时打印的信息’])：断言x是否None，不是None则测试用例通过。

执行测试用例 # -*- coding: utf-8 -*- # @Time : 2020/2/12 22:56 # @File : run_test_16.py # @Author: Hero Liu import sys sys.path.append("h:/python_lemon") import unittest from day_20200208_mooc.base.test_class_15 import TestRequest import HTMLTestRunner suite = unittest.TestSuite() loader = unittest.TestLoader() suite.addTest(loader.loadTestsFromTestCase(TestRequest)) # runner = unittest.TextTestRunner(verbosity=2) # runner.run(suite) with open("../data/result.html", "wb") as file: runner = HTMLTestRunner.HTMLTestRunner(stream=file, title="依赖case测试", description="加油，相信一定可以看到曙光") runner.run(suite) 来源：

一.POM模式 POM结构: 项目名称文件: common文件夹: base.py文件:对selenium二次封装: 1.打开浏览器 2.打开地址 3.元素定位 4.元素操作 page文件夹: 1.对项目每个页面封装 2.page文件夹:将页面分为三层 表现层:页面中可见的元素 操作层:对可见元素的操作 业务层:由操作层组合形成场景/业务 3.page类: 编写内容: ①封装表现层:制作定位器 ②封装操作层:对定位器中各个元素操作,将操作形成方法 ③page类继承Base script文件夹: 存放测试用例,使用unittest管理用例 1.只关注操作步骤,如果涉及到测试数据,暂时写成死数据 2.确定断言 3.关注测试数据灵活性 二.unittest框架 1.作用: 规范自动化测试用例编写 管理自动化测试用例的执行 2.基本概念 测试夹具:test fixture 处理测试前的数据准备和测试后的数据清理 测试套件:test suite 批量收集需要执行的测试用例 测试用例:test case 核心部分,编写的测试用例符合unittest框架的要求 测试执行:test runner 执行测试套件收集的测试用例 3.特殊方法 setUp:在一个py文件,在测试用例执行之前先执行,有多少测试用例,执行多少次 tearDown:在一个py文件中,在测试用例执行之后再执行,有多少测试用例