一、unittest自动化框架介绍.... - 5 -
1、unittest核心工作原理.... - 5 -
1.1、TestCase. - 5 -
1.2、TestSuite. - 6 -
1.3、TestRunner. - 6 -
1.4、TestFixture. - 6 -
2、框架目录结构介绍.... - 6 -
2.1、config层.... - 6 -
2.2、data层.... - 7 -
2.3、log层.... - 7 -
2.4、report层.... - 7 -
2.5、test层.... - 7 -
2.6、utils层.... - 7 -
2.7、main.py. - 7 -
2.8、ReadMe.md. - 8 -
3、自动化框架整体的封装介绍和认识.... - 8 -
二、测试用例模板设计方案.... - 9 -
1、单接口测试用例方案.... - 9 -
1.1、方案一.... - 9 -
1.2、方案二.... - 10 -
1.3、方案三.... - 11 -
1.4、方案四.... - 12 -
2、组合接口测试用例设计.... - 14 -
2.1、模板说明.... - 14 -
三、针对用例模板的test代码编写模板.... - 15 -
1、单接口代码编写模板.... - 15 -
1.1、实例化模板解析器.... - 16 -
1.2、模板数据的解析.... - 16 -
1.3、setUpClass(cls)中的初始化数据.... - 17 -
1.4、测试案例说明的取值介绍.... - 17 -
1.5、解析响应值介绍.... - 17 -
1.6、断言.... - 18 -
2、组合接口代码编写模板.... - 20 -
2.1、实例化模板解析器.... - 21 -
2.2、模板数据的解析.... - 22 -
2.3、模板数据的提取.... - 22 -
2.4、测试案例说明的取值介绍.... - 22 -
2.5、上下游接口依赖处理.... - 23 -
2.6、解析响应值介绍.... - 23 -
2.7、断言.... - 23 -
3、excel存储用例的单接口编写模板.... - 23 -
3.1、模块名说明.... - 24 -
3.2、测试代码编写说明.... - 24 -
3.3、断言.... - 24 -
四、项目流程运作介绍.... - 25 -
1、项目运行流程.... - 25 -
1.1、获取token. - 25 -
1.2、令牌全局变量的设定存储.... - 25 -
1.3、测试用例的编写及存储.... - 25 -
1.4、测试用例模板的解析及测试代码的编写.... - 25 -
1.5、用例的匹配与加载.... - 25 -
1.6、用例执行结果写入报告.... - 25 -
1.7、发送邮件报告.... - 26 -
2、后台配置文件的掌控.... - 26 -
3、报告文件介绍.... - 28 -
3.1、总览区.... - 28 -
3.2、详情区.... - 28 -
3.3、图表区.... - 30 -
4、邮件与代码的对应区.... - 30 -
一、unittest自动化框架介绍 1、unittest核心工作原理unittest中最核心的四个概念是：test case, test suite, test runner, test fixture。
下面我们分别来解释这四个概念的意思，先来看张unittest的静态类图：
1.1、TestCase一个TestCase的实例就是一个测试用例。那么什么是测试用例呢？说白了就是一个完整的测试流程，包括测试前准备环境的搭建(setUp)，执行测试代码(run)，以及测试后环境的还原(tearDown)。
元测试(unit test)的本质也就在这里，一个测试用例是一个完整的测试单元，通过运行这个测试单元,可以对某一个问题进行验证。
1.2、TestSuite多个测试用例集合在一起，就是TestSuite，而且TestSuite也可以嵌套TestSuite,TestLoader是用来加载TestCase到TestSuite中的，其中有几个loadTestsFrom()方法，就是从各个地方寻找TestCase，创建它们的实例，然后add到TestSuite中，再返回一个TestSuite实例。
1.3、TestRunnerTestRunner是来执行测试用例的，其中的run(test)会执行TestSuite/TestCase中的run(result)方法，测试的结果会保存到TestResult实例中，包括运行了多少测试用例、成功了多少、失败了多少等信息。
一个class继承了unittest.TestCase，便是一个测试用例，但如果其中有多个以 test开头的方法，那么每有一个这样的方法，在load的时候便会生成一个TestCase实例，如：一个class中有四个test_xxx方法，最后再load到suite中时也有四个测试用例。
1.4、TestFixture对一个测试用例环境的搭建和销毁，是一个fixture。
2、框架目录结构介绍搭建的框架大致如下，关于框架的解释说明请看：
ZYL_Project： ├── config (配置文件) ├── data (数据文件) ├── logs (日志文件) ├── report (报告) ├── test (测试用例) ├── utils (公共方法) ├── main.py (入口函数) └── ReadMe.md (说明性的文件，告诉团队成员框架需要的环境以及用法)2.1、config层
放配置文件，所有项目相关的配置均放到这里，用Python支持较好的配置文件格式如ini或yaml等进行配置，实现配置与代码分离。
2.2、data层放数据文件，可以把所有的testcase的参数化相关的文件放到这里，一般可采用xlsx、csv、xml等格式，实现数据与代码分离。
这边对用例的类别也用文件夹做了区分：combindata——组合接口测试用例数据、singledata——单接口测试用例数据。
2.3、logs层所有生成的日志均存放在这里，可将日志分类，如运行时日志test log，错误日志error log等。
2.4、report层放程序运行生成的报告，一般可有html报告、excel报告等。
2.5、test层放所有测试相关的文件，如case——测试用例：combincase——组合接口测试用例代码、singlecase——单接口测试用例代码，common——项目相关的抽象通用代码、mock——模拟服务请求代码、interface——socket接口测试。
2.6、utils层所有的支撑代码都在这里，包括读取config的类、写log的类、读取excel、xml的类、生成报告的类（如HTMLTestRunner）、数据库连接、发送邮件等类和方法，都在这里。
2.7、main.py把控整个流程的入口函数，包括获取登录令牌token，将token写入配置文件设置全局变量，加载指定规则的用例，执行用例，写入报告，发送报告等方法。
2.8、ReadMe.md说明性文件，当前各个版本库及环境的说明：
3、自动化框架整体的封装介绍和认识
以主控函数为主线，往下展开看项目结构：
二、测试用例模板设计方案
这边设计了四种单接口测试用例模板的设计方案，各有各的优缺点和对比，如果采用yml测试用例模板，个人比较推荐第三种方案，但从低代码的最佳实践模式，我更推荐excel测试用例模板，可以用较少且封装的代码模板完成对测试用例的解析并生成报告，底层我都封装好了，容易入手。
1、单接口测试用例方案 1.1、方案一# 测试用例模板一 tests: - case: 验证功能xxx request: method: POST path: /api/test01 headers: Content-Type: application/x-www-form-urlencoded params: a: 1111 b: 2222 expected: data: statue: 成功 - case: 验证功能yyy request: method: POST path: /api/test01 headers: Content-Type: application/x-www-form-urlencoded params: a: 3333 b: 4444 expected: data: statue: 成功
1.1.1、模板说明
tests: 是固定模板名
case: 用例名称，用于说明验证了什么功能
request: 请求数据的集合
method: 请求方法
path: 请求路径
headers: 请求头
params: 请求参数
expected: 期望值，数据结构可以根据实际项目自定义
1.1.2、模板优缺点
优：一条用例对应对应一个case架构，结构清晰。
缺：对于请求方法和请求路径没必要每次都加载，有点冗余。
1.2、方案二# 测试用例模板2 tests: request: method: POST path: /api/test01 headers: token: $token Content-Type: application/x-www-form-urlencoded params: a: - 1111 - 2222 b: - 3333 - 4444 expected: - data: job: 测试工程师 statue: 成功 - data: statue: 失败
1.2.1、模板说明
tests: 是固定模板名
case: 用例名称，用于说明验证了什么功能
request: 请求数据的集合
method: 请求方法
path: 请求路径
headers: 请求头
params: 请求参数
expected: 期望值，数据结构可以根据实际项目自定义
1.2.2、模板优缺点
优：请求方法、请求头、请求路径用一个节点并以数组的形式进行存储，避免多模板子集，请求参数和期望数据也用数组存储，案例按照数组下标一一对应。
缺：对于不同条件情况的请求头，无法区分；功能验证说明体现在测试用例代码中，在用例中体现不出；对于请求参数在测试用例设计模板中体现不出用例的颗粒度。
1.3、方案三# 测试用例模板三 tests: common: #公共部分 method: POST path: /api/test01 testcase: - case: 验证正常登录后请求数据 request: headers: Authorization: $Authorization Content-Type: application/x-www-form-urlencoded params: a: 1111 b: 2222 expected: data: job: 测试工程师 statue: 成功 - case: 验证登录后请求数据类型为字母 request: headers: Authorization: $Authorization Content-Type: application/x-www-form-urlencoded params: a: aaa b: bbb expected: data: statue: 失败
1.3.1、模板说明
tests: 是固定模板名
case: 用例名称，用于说明验证了什么功能
request: 请求数据的集合
method: 请求方法
path: 请求路径
headers: 请求头
params: 请求参数
expected: 期望值，数据结构可以根据实际项目自定义
1.3.2、模板优缺点
优：结构清晰，一条用例一个case，提取了公共部分的请求路径和请求方法，重点放在请求头，请求参数和期望值的组合用例化。
缺：对于请求路径和请求方法的错误没法单独验证，但是对于请求路径的错误可以自己模拟，体现在用例中的作用意义不大。
1.4、方案四用excel编写测试用例：
1.4.1、用例模板说明
用例相关字段的说明和格式要求，请参考下表规范去编写：
1.4.2、sheet表维度设计
针对sheet表维度设计有两种方案：
方案一、sheet名为模块名，则sheet表中的内容为这个模块的所有接口的所有情况的校验，测试代码名为test_模块名；
方案二、sheet名为接口名，则sheet表中的内容为对这一个接口的所有情况的校验，测试代码名为test_接口名；
综合sheet表的有效利用率和字段的避重复性原则，这边我比较推崇方案一，可以使得测试用例模块化，测试接口多元化。
1.4.3、模板优缺点
优：按excel给出的接口测试用例编写模板，可以对应表头字段去对应swagger接口文档填写对应内容，可以运用等价类、边界值、场景设计法、判定表、因果图、正交法、错误猜测法等方法对用例的参数进行随机组合场景。
不需要会代码就可以做自动化，代码都封装好了，只需要复制模块代码，传入对应的sheet名就可以了。
缺：目前这个模板暂不支持多接口的开发。
2、组合接口测试用例设计# 测试接口集合用例模板 tests: - case: 使用正确的数据新增api密钥 request: method: POST path: /api/test01 headers: Content-Type: application/x-www-form-urlencoded params: a: aaaa b: 2222 expected: data: apiKey: 222222 statue: 成功 - case: 删除已存在的api密钥 request: method: POST path: /api/mockman headers: Content-Type: application/x-www-form-urlencoded params: name: li id: $id expected: data: statue: 成功2.1、模板说明
tests: 是固定模板名
case: 用例名称，用于说明验证了什么功能
request: 请求数据的集合
method: 请求方法
path: 请求路径
headers: 请求头
params: 请求参数
expected: 期望值，数据结构可以根据实际项目自定义
这边上下游接口的衔接是通过“$param”的形式进行传参，即上一个的接口的返回值作为下个接口的入参的形式进行，且这边基本不做接口的异常情况案例处理了，因为接口的异常案例在单接口测试中已经校验过了，多接口这边做的更多的是请求成功的接口间的数据流程传递。
三、针对用例模板的test代码编写模板 1、单接口代码编写模板# 实例化JMESPath抽取器
j = JMESPathExtractor()
# 实例化TEMPLATE模板解析
T = TEMPLATEExtractor()
# 实例化CASE模板解析器
c = CASEExtractor()
# 测试用例的文件路径
data_path = SINGLE_DATA + 'testName.yml'
# 参数关联-获取登录令牌（需要登录接口的处理，若不需要登录，则不需要这部分代码，获取模板数据直接为T.extract(data_path)
Authorization = {'Authorization': str(Config(config=TOKEN_PATH).get('token'))}
# 获取模板数据
t = T.extract(data_path, Authorization)
class Test_03(unittest.TestCase):
''' 测试三用例模板 '''
@classmethod
def setUpClass(cls):
warnings.simplefilter('ignore', ResourceWarning)
print("------------------------------------ 开始执行用例 ------------------------------------")
# 获取请求头
cls.headers = c.get_headers(t, n)
# 获取请求的url
cls.url = T.getUrl3(t)
# 获取请求方法
cls.method = c.get_method(t)
# 请求
cls.client = HTTPClient(cls.url, cls.method, cls.headers)
@classmethod
def tearDownClass(cls):
print("------------------------------------ 用例执行结束 ------------------------------------")
@verificating_case(t, n)
def test_01(self):
""" {0} """
print("n请求地址：%s n请求方法：%s n请求头：%s" % (self.url, self.method, self.headers))
# 测试需要
response = self.client.send(data=c.get_params(t, n))
# 请求成功断言
assertHTTPCode(response, [200])
# 获取返回结果
statue = j.extract(query='data.statue', body=response.text)
# 期望的结果
expect = c.get_expected(t, n)['statue']
# 比较返回结果和期望结果
self.assertEqual(statue, expect)
代码模版讲解：
1.1、实例化模板解析器这些都是我封装好的，可以先实例化后再使用：
# 实例化JMESPath抽取器 j = JMESPathExtractor() # 实例化TEMPLATE模板解析 T = TEMPLATEExtractor() # 实例化CASE模板解析器 c = CASEExtractor()1.2、模板数据的解析
data_path就是测试用例的路径，对于数据模板的解析，这边主要分为两种情况：
情况一，不需要登录的接口
对于不需要登录的接口，不修改原模板值的情况下，直接传入模板路径解析
t = T.extract(data_path)
情况二、需要登录的接口
测试代码的处理：植入token
Authorization = {'Authorization': str(Config(config=TOKEN_PATH).get('token'))}
t = T.extract(data_path, Authorization)
测试用例模板的处理：
request: headers: Authorization: $Authorization
就是以$key值的形式去引入变量值
1.3、setUpClass(cls)中的初始化数据以下方法都是封装好的，具体n的取值就是数组的下脚标，对应测试用例模板取数据就可以了：
请求路径：
T.getUrl3(t)
请求头：
c.get_headers(t, n)
请求方法：
c.get_method(t)
请求数据：
c.get_params(t, n)
期望数据：
c.get_expected(t, n)1.4、测试案例说明的取值介绍
@verificating_case(t, n)
def test_01(self):
""" {0} """
案例名称：@verificating_case(t, n)
{0}默认都取一个值
1.5、解析响应值介绍
j.extract(query='data.node', body=response.text)
这个解析器也是封装好的，具体要取哪一层的数据用，对应数组下脚标去取就可以了。
1.6、断言self.assertEqual({实际的结果}, {期望的结果})
当然这只是一种断言的函数，还有很多种函数
这边有一些关于断言的介绍和总结：
可以理解assert断言语句为raise-if-not，用来测试表示式，其返回值为假，就会触发异常。
self.assertEqual(a,b,msg=msg) #判断a与.b是否一致，msg类似备注，可以为空
self.assertNotEqual(a,b,msg=msg) #判断a与b是否不一致
self.assertTrue(a,msg=none) #判断a是否为True
self.assertFalse(b,msg=none) #判断b是否为false
self.assertAlmostEqual(a,b,places=none,msg=none,delta=none) #该判断过程有点复杂，判断过程如下
注：places与delta不能同时存在，否则出异常
#若a==b，则直接输入正确，不判断下面的过程
#若delta有数，places为空，判断a与b的差的绝对值是否<=delta，满足则正确，否则错误
#若delta为空，places有数，判断b与a的差的绝对值,取小数places位，等于0则正确，否则错误
#若delta为空，places为空，默认赋值places=7判断
例 assertAlmostEqual(2,2) 正确，
assertAlmostEqual(5,2,delta=4) 正确
assertAlmostEqual(5,2,delta=2) 错误
assertAlmostEqual(2,2.005,places=1) 正确
assertAlmostEqual(2,2.05,places=3) 错误
self.assertNotAlmostEqual(a,b,places=none,msg=none,delta=none) 同上，但判断相反
注，delta与places不能同时存在，否则抛出异常
例 assertNotAlmostEqual(2,2) 错误
assertNotAlmostEqual(a,b,delta=c) #a不等于b 同时 a-b>c 则正确，否则错误
assertNotAlmostEqual(a,b,places=2)
#a不等于b 同时|b-a|*0,01 不等于0 则正确，否则错误
self.assertSequenceEqual #有空在研究，源码很长
self.assertListEqual #有空研究
self.assertTupleEqual #有空在研究
self.assertSetEqual #有空在研究
self.assertIn(a,b) 判断a in b是否成立，正确则True，否则为False
例： assertIn(“2” in “23”) 成功
assertIn(“1” in “23”) 失败
self.assertNotIn(a,b) 判断a in b是否成立，不成立则True 否则 False
例：assertIn(“2” in “23”) 失败
assertIn(“1” in “23”) 成功
self.assertIs(a,b) 判断a 与b的对象是否相同，成立则True，否则False
注，判断是否同一对象 id(a) 若id相同，则为同一对象
例 a,b=1,1.0
assertls(a,b) 失败
a,b=1,1
assertls(a,b) 成功
self.assertIsNot(a,b) 判断a 与b的对象是否相同，不成立True，否则False
self.assertDictEqual(a,b) #判断字典a和字典b是否相等，a,b为字典
self.assertDictContainsSubset
self.assertItemsEqual(a,b) #比较两字符串是否一致，同sorted(a)==sorted(b)
注：sorted排序，方法内部为，将a,b分别list，生成各自列表，在sorted排序在比对
self.assertMultiLineEqual(a,b) #比较a文本与b文本是否一致，即便多了个换行，也会区分
self.assertLess(a,b) #判断a
self.assertLessEqual #判断a<=b 成立则通过，否则失败
self.assertGreater #判断a>b 成立则通过，否则失败
self.assertGreaterEqual #判断a>=b 成立则通过，否则失败
self.assertIsNone(obj=””) #判断obj=None 成立则通过，否则失败
self.assertIsNotNone #判断obj=None 成立则失败，否则通过
self.assertIsInstance(a,b) #判断a的数据类型是否为b，isinstance(a,b) 成立则通过，否则失败
self.assertNotIsInstance #判断同上相反
self.assertRaisesRegexp #正则判断匹配，没仔细看，过程复杂
self.assertRegexpMatches(a,b) #正则匹配 同re.search(b,a)匹配有则成功，否则失败
注：a为匹配的正则表达式，必须字符型，b 为要匹配的内容
self.assertNotRegexpMatches #同上，判断相反
2、组合接口代码编写模板
# 实例化JMESPath抽取器
j = JMESPathExtractor()
# 实例化TEMPLATE模板解析器
T = TEMPLATEExtractor()
# 实例化组合模板解析器
S = SUITEExtractor()
# 测试用例的文件路径
data_path = COMBIN_DATA + 'testName.yml'
# 获取模板数据
t = T.extract(data_path)
# 用例名
case = S.get_suite(t)
class Test_01c(unittest.TestCase):
''' 测试接口集合用例模板 '''
@classmethod
def setUpClass(cls):
warnings.simplefilter('ignore', ResourceWarning)
print("------------------------------------开始执行用例：%s ------------------------------------ " % case)
@classmethod
def tearDownClass(cls):
print("------------------------------------用例执行结束：%s ------------------------------------" % case)
@verificating_suite(case)
def test(self):
""" {0} """
client = HTTPClient(T.getUrl(x, t), S.get_method(t, n), S.get_headers(t, n))
response = client.send(data=S.get_params(t, n))
statue = j.extract(query='data.statue', body=response.text)
self.assertEqual(statue, S.get_expected(t, n)['statue'])
apiKey = j.extract(query='data.apiKey', body=response.text)
t1 = T.extract(data_path, {'id': apiKey})
client1 = HTTPClient(T.getUrl(x, t1), S.get_method(t1, n), S.get_headers(t1, n))
response1 = client1.send(data=S.get_params(t1, n))
statue = j.extract(query='data.statue', body=response1.text)
self.assertEqual(statue, S.get_expected(t1, n)['statue'])
2.1、实例化模板解析器
这些都是我封装好的，用就好了：
# 实例化JMESPath抽取器 j = JMESPathExtractor() # 实例化TEMPLATE模板解析器 T = TEMPLATEExtractor() # 实例化组合模板解析器 S = SUITEExtractor()2.2、模板数据的解析
data_path就是测试用例的路径，对于数据模板的解析，这边分为两种情况：
情况一，不需要登录的接口
t = T.extract(data_path)
情况二、需要登录的接口
测试代码的处理：植入token
Authorization = {'Authorization': str(Config(config=TOKEN_PATH).get('token'))}
t = T.extract(data_path, Authorization)
测试用例模板的处理：
request: headers: Authorization: $Authorization
就是以$key值的形式去引入变量值
2.3、模板数据的提取以下方法都是封装好的，具体n的取值就是数组的下脚标，对应测试用例模板取数据就可以了：
请求路径：
T.getUrl(x, t)
请求头：
S.get_headers(t, n)
请求方法：
S.get_method(t, n)
请求数据：
S.get_params(t, n)
期望数据：
S.get_expected(t, n)2.4、测试案例说明的取值介绍
@verificating_suite(case)
def test(self):
""" {0} """
案例名称：@verificating_suite(case)
case名可以通过case = S.get_suite(t)来提取组合名称
{0}默认都取一个值
2.5、上下游接口依赖处理
如何将上个接口的返回数据传到下个接口作为入参，这边的处理参考登录的处理类似：
apiKey = j.extract(query='data.apiKey', body=response.text)
t1 = T.extract(data_path, {'id': apiKey})
2.6、解析响应值介绍
j.extract(query='data.node', body=response.text)
这个解析器也是封装好的，具体要取哪一层的数据用取数组下脚标的方式去取就可以了。
2.7、断言self.assertEqual({实际的结果}, {期望的结果})
当然这只是一种断言的函数，还有很多种函数，可以参考上面的总结。
3、excel存储用例的单接口编写模板SHEET_NAME = "登录"
@docstring_parameter(SHEET_NAME)
class TestCase(unittest.TestCase):
'''{0}'''
@parameterized.expand(getExcelData(TEST_CASE_PATH, SHEET_NAME))
def test_login(self, rowNumber, caseRowNumber, testCaseName, priority, apiName, path, method, parmsType,
data, checkPoint, isRun, result, bugUrl):
if isRun == "Y" or isRun == "y":
headers = {"Content-Type": "application/json;charset=UTF-8"}
# 选择环境拼接url
url = get_url(path)
logger.warning("[开始执行测试用例：{}]".format(testCaseName))
print(
"测试用例编号：%s n测试用例名称：%s n优先级：%s n接口名：%s n请求方法：%s n请求数据类型：%s n请求url：%s n请求参数：%s" % (
caseRowNumber, testCaseName, priority, apiName, method, parmsType, url, data))
# 对解析出来的excel的用例数据处理
flag = data_deal(SHEET_NAME, data, rowNumber, headers, url, method, checkPoint, result, bugUrl)
# 断言
self.assertTrue(flag, msg="检查点数据与实际返回数据不一致")
else:
unittest.skip("不执行")
3.1、模块名说明
@docstring_parameter(SHEET_NAME)
class TestCase(unittest.TestCase):
'''{0}'''
模块名称：@verificating_suite(SHEET_NAME)
用SHEET_NAME = "登录"来直接指定
3.2、测试代码编写说明
代码都是封装解析好的，可以全部直接引用，文件名可以为模块名或接口名，只需要修改SHEET_NAME就可以指定excel执行用例。
3.3、断言断言在excel中进行编写 *** 作，具体可查看1.4.1的用例模板说明。
四、项目流程运作介绍 1、项目运行流程 1.1、获取token登录成功后从响应从获取token。
1.2、令牌全局变量的设定存储将token写入yaml文件并设置为全局变量，作为所有需要登录接口的令牌。
1.3、测试用例的编写及存储在数据层编写测试用例，测试用例数据分为两个目录，combindata目录下编写组合接口的用例，singledata目录下编写单接口用例。
1.4、测试用例模板的解析及测试代码的编写用例层编写测试用例执行代码，测试用例代码也分为两个目录，和数据层一一对应，combincase目录下编写组合接口用例的代码，singledata目录下编写单接口用例的代码。
1.5、用例的匹配与加载项目的入口主控在main.py函数，all_case()可以加载测试用例代码，默认是加载所有用例，根据自己的需要，可在config.yml文件中选择自己想要加载的用例类型和接口用例目录。
1.6、用例执行结果写入报告run_case(all_case, reportName="report”)函数执行加载的用例并写入报告，报告名默认为report，支持自定义报告名
1.7、发送邮件报告send_report(report_abspath=None)邮件发送对应的测试报告
2、后台配置文件的掌控主要包括对环境、日志、用例、报告、邮件、socket 接口、数据库、通用参数等的配置控制，包括一些对于模块的控制开关也可以在这部分封装。
# 环境 host: http://localhost:3000 # 测试环境 # http://localhost:3001 # 开发环境 # http://localhost:3002 # 预发布环境 # 日志 log: file_name: test.log # 文件名 backup: 5 # 保留的日志数量 console_level: INFO # 日志输出级别 file_level: DEBUG # 日志输出级别 pattern: '%(asctime)s - %(name)s - %(levelname)s - %(message)s' # 日志输出格式 # 用例 case_control: rule: test_*.py # 用例文件名的匹配原则，此处匹配文件名以“test”开头的“.py”类型的文件，星号“*”表示任意多个字符 # 测试用例的代码的存放路径,不填或路径不存在默认加载全部用例 path: #/singlecase # 单接口用例存放路径 #/combincase # 联合接口用例存放路径 # 报告 report: verbosity: # 执行用例的详细程度,不填或者填写的值大于2都为默认值2 # 0 # (静默模式): 你只能获得总的测试用例数和总的结果。 # 1 # (默认模式): 非常类似静默模式 只是在每个成功的用例前面有个“.” 每个失败的用例前面有个 “E” 2 # (详细模式):测试结果会显示每个测试用例的所有相关的信息 并且 你在命令行里加入不同的参数可以起到一样的效果 title: xxx有限公司自动化测试报告 # 报告标题，如XXX自动化测试报告 description: *** 作系统：macOS 版本11.6,Google Chrome：95.0.4638.69 (正式版本) (x86_64) # 说明；比如 *** 作系统、浏览器等版本 # 邮件 mail: title: xxxx有限公司测试报告 # 邮件标题 message: 这是今天的测试报告，请查收！ # 消息 receiver: xxxx@zyyy.com # 接受者邮箱，多个邮箱接收用;隔开，例如：xxx@zyyyy.com;yyyy@zuuu.com server: smtp.qq.com # 服务 sender: xxxxxxxx@qq.com # 发送者邮箱 password: nyyyyyyyyyyy # 密码 path: [ "report.html", "xxx.html" ] # 报告附件路径，可传入list（多附件）或str（单个附件） # socket 接口 socket: ip: 127.0.0.1 port: 8080 # 测试环境数据库 test_mysql: host: xxx.xxx.xxx.xxx # 地址 port: 3306 # 端口号 user: root # 账号 passwd: "12344x" #密码 db: xxxx_dev #连接的库名 # 本地环境数据库 local_mysql: host: 127.0.0.1 port: 3306 user: root passwd: "xxxxx" db: xxxx_project # redis数据库 redis: #host, port, password, db, list_name host: # 地址 port: # 端口号 password: #密码 db: # 连接的库名 list_name: # 列表名 # 通用参数 general_parameters: charset: # 字符集类型 - utf8 - utf_8_sig default_file_name: export #默认文件名3、报告文件介绍 3.1、总览区 3.2、详情区
模板1、2、3的针对yml文件提取数据的详情
模板4提取excel表中内容进行解析的数据详情：
用例Pass后的详情：
用例Fail后的详情：
除了前面的基本接口信息外，若某一条接口测试用例执行失败后，会在excel测试用例模板[执行结果]的字段回写结果[Fail]，测试人员会在禅道提bug，并在用例模板[对应禅道bug-id]中手动填写bugID与用例做关联,直到用例被验证通过，且脚本自动将[执行结果]的字段回写为[Pass]状态，脚本才会自动清除bugID。
关于用例Fail部分的详情除了接口基本信息外，错误的追踪信息包括：
A、对应禅道bugId
B、断言失败的完全路径及断言异常的具体行数
C、返回断言失败原因
3.3、图表区 4、邮件与代码的对应区欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）