为什么枚举要实现接口？
341
2023-01-28
接口自动化测试用例数量（接口自动化测试用例数量多少）
本篇文章给大家谈谈接口自动化测试用例数量，以及接口自动化测试用例数量多少对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享接口自动化测试用例数量的知识，其中也会对接口自动化测试用例数量多少进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
本文目录一览：
- 1、接口自动化测试测试用例设计
- 2、python+unittest接口自动化执行多条测试用例怎么实现？
- 3、标准测试中一天能写多少测试用例？执行多少用例？这个有标准不？
- 4、python读取Excel实现接口自动化并生成测试报告
- 5、web自动化测试计划和步骤
接口自动化测试测试用例设计
浅谈接口自动化测试测试用例设计一、 前言
很多中台项目，大部分为接口测试。为了使新入职的测试同事尽快融入项目，以及迭代开发中方便管理测试用例。完成该总结。
二、 测试用例设计思路
1、 接口类型概述及优先级
1） 提供给第三方调用的接口
2） 内部系统使用，核心功能接口
3） 内部系统使用，非核心功能接口
基本按照1）2）3）的顺序进行测试，特别情况除外
2、 单接口测试优先级
1） 优先测试正向测试用例，保证基本功能实现
2） 设计逆向测试用例，确保接口的健壮性
3） 满足前提条件的测试用例
4） 默认参数是否满足
5） 参数校验
6） 参数间联动关系
7）多参数错误处理的优先顺序校验
三、 设计分析
1、 满足前提条件的测试用例
测试目标接口需要满足前置条件才能成功获取数据。
例如：需要登录token，通过传入参数获取下游接口数据
2、 携带默认参数的测试用例
携带默认参数的测试用例仅需要设计一条，所有默认参数的字段都不填写，其他字段输入正常。
[if !supportLists]3、 [endif]参数校验
参数校验包含如下几方面：
[if !supportLists]1）[endif]输入参数是否为必须输入项
[if !supportLists]2）[endif]输入参数的类型
[if !supportLists]3）[endif]输入参数的枚举值校验
[if !supportLists]4）[endif]输入参数长度校验
以上测试用例最好根据字段一一校验，排除互相干扰
[if !supportLists]4、 [endif]参数间联动
有些参数见存在彼此制约的关系，根据实际情况设计测试用例
例如:A字段为1时，B字段一定为空。否则报错。
那么测试用例设计时应为：A字段为1时，B字段为空；A字段为1时，B字段不为空；A字段不为1时，B字段为空；A字段不为1时，B字段不为空；四条测试用例
这样基本覆盖所有分支流程。
[if !supportLists]四、 [endif] 测试用例实践操作
接口测试用例样例:
多条件查询接口
测试方法：使用robotFramework测试doubbo接口
协议请求方式：post
接口协议：JSON
消息请求列表
字段名数据类型默认值必须项备注
IDint 是长度为2
Tokenstring 是设备令牌
Statusstring 是1：正常
2：异常
typeint Status为1时，为必须输入项
sizestring 默认值
消息返回列表
字段名数据类型必须项备注
Codeint是正常：20000
异常：20001
Messagestring是
typeMessageint Status=1的所有ID
用例设计
NO. 测试内容 前置条件 输入参数 输出参数 用例属性
1目标数据为一条预置一条符合条件的数据Status=1，其他参数输入正常返回code=20000
typeMessage中返回的ID与预置数据一致
正向测试用例
2目标数据为多条预置多条符合条件的数据Status=1，其他参数输入正常返回code=20000
typeMessage中返回的ID与预置数据一致
正向测试用例
3 Token必须项检查 预置多条符合条件的数据Status=1，token输入为空，其他参数输入正常返回code=20001
typeMessage中返回为空
满足前提条件
4 Token正确性检查 预置多条符合条件的数据Status=1，token输入错误，其他参数输入正常返回code=20001
typeMessage中返回为空
满足前提条件
5 Status 必须项检查 预置多条符合条件的数据Status为空，其他参数输入正常返回code=20001
typeMessage中返回为空
参数校验
6 Status枚举预置多条符合条件的数据Status为1，其他参数输入正常返回code=20000
typeMessage中返回的ID与预置数据一致
参数校验
7 Status枚举预置多条符合条件的数据Status为2，其他参数输入正常返回code=20000
typeMessage中返回的ID与预置数据一致
参数校验
8 Status枚举预置多条符合条件的数据Status为3，其他参数输入正常返回code=20001
typeMessage中返回null
参数校验
9 Status=1，时联动校验预置多条符合条件的数据Status为1，type为空；其他参数输入正常返回code=20001
typeMessage中返回null
联动校验
10 Status！=1，时联动校验预置多条符合条件的数据Status！=1，type为空；其他参数输入正常返回code=20000
typeMessage中返回对应ID
联动校验
11 Status！=1，时联动校验预置多条符合条件的数据Status！=1，type不为空；其他参数输入正常返回code=20000
typeMessage中返回对应ID
联动校验
12 Size默认值输入校验预置多条符合条件的数据Size输入为空，其他参数输入正常返回code=20000
typeMessage中返回对应ID
默认值校验
13 Size默认值输入校验预置多条符合条件的数据Size输入不为空，其他参数输入正常返回code=20000
typeMessage中返回对应ID
默认值校验
14 ID 必须项检查 预置多条符合条件的数据ID为空，其他参数输入正常返回code=20001
typeMessage中返回为空
参数校验
15 ID 长度检查 预置多条符合条件的数据ID长度大于2，其他参数输入正常返回code=20001
typeMessage中返回为空
参数校验
16 破坏性测试预置多条符合条件的数据输入的参数类型错误请求未接收，返回404 稳定性测试
17 破坏性测试预置多条符合条件的数据输入的参数与提供的参数名称不一致请求未接收，返回404 稳定性测试
18 破坏性测试预置多条符合条件的数据输入的参数与提供的参数数量不一致请求未接收，返回404 稳定性测试
19 破坏性测试预置多条符合条件的数据输入的参数与提供的参数格式不一致请求未接收，返回404 稳定性测试
总结：自动化测试过程中会有一条自动化测试用例覆盖多种情况的可能（例如：正向测试用例与联动性验证的 Status=1，type输入不为空的测试用例重复，所以选择一条用例验证 。 ），以上的测试用例满足自动化的要求，手动测试过程中需要增加部分验证性的测试用例。且由于使用的测试工具特殊性，无需检查输入参数的类型。
python+unittest接口自动化执行多条测试用例怎么实现？
我的理解是，如果都在一个class里面，确实是需要 def test_xxx 20个的，也可以直接把所有的用例写到一个def test_xx里面的，如果前面的操作步骤一样的话，这两个的差距不大的标准测试中一天能写多少测试用例？执行多少用例？这个有标准不？
普通的测试用例（执行步骤不超过10步）的话，高质量的测试用例一天编写一般在30个左右，执行在50个左右。不标准，在工作过程中难免会有一些因素影响进度的。
测试用例的标准：
A.覆盖到所有的业务逻辑（包括正常逻辑和异常逻辑），即正常流和异常流。
B.覆盖到所有的典型用户场景。
C.覆盖到所有的需求点。
D.测试目标明确，并且测试步骤能够最快的达到测试目的或者测试时间很短。
E.没有冗余的用例。
F.测试用例能够直接附带测试策略，该模块的策略指定人和用例执行人能够非常清楚。
扩展资料：写测试用例的技巧：
（1）基于需求的用例设计过程：
A、用例编写过程：首先参照需求文档以及项目原形交互图，划分模块，以及具体的测试点，然后整理出详细的测试点文档，然后根据文档一条条编写测试用例；充分利用相关的用例编写技术。包括：
边界值分析法、等价类分析法、错误类推测法、路径覆盖法、因果分析法、正交分析法等；分析用例是否能够通过自动化或者其他测试手段来覆盖到。
B、用例评审过程：首先对照需求表来进行检查，是否全部覆盖到，不仅仅是测试用例，还包括测试步骤和期望结果，避免因为依赖研发的逻辑来设计用例导致问题。
其次评审该部分用例是否跟前面的逻辑用例和场景用例冗余；最后分析用例是否能够通过自动化或者其他测试手段来覆盖到。
（2）基于逻辑的用例编写过程：
A.用例编写过程：首先进行全面的需求分析，分析系统包含哪些功能模块，各功能模块下富含哪些子模块，每个模块之间的逻辑关系，分析一下这个需求是否存在不合理的地方。
其次完成业务逻辑图或者流程图，需要在测试的角度上面去画逻辑图，包括数据流完整的输入和输出过程，正常的逻辑过程以及异常的逻辑过程，并且自己能够理解为什么这样处理。
再根据自己的理解分析每个逻辑的处理是否完善，是否有没有覆盖到的地方，整合成具体的文档，小组讨论并提交缺陷预防bug。
另外根据逻辑编写测试用例，保证每个逻辑都能够有对应的用例覆盖；最后有一个原则要注意，用例要按照10分钟原则，即保证10分钟内能够执行完成，此原则针对较复杂的逻辑操作，对于大部分的测试用例都可以保证。
B.用例评审过程：前期要求参与审核的人员自己先进行需求分析，然后把自己不理解或觉得有问题的地方记录下来；然后项目主负责人先讲解整个业务逻辑图，需要保证评审人员对于整个业务逻辑图都非常清楚，并且能够理解为什么这样做。
并且分析整个业务逻辑图是否有没有覆盖到的场景或者分支情况（采用头脑风暴的方式），大家在一起讨论各种可能存在的情况，然后进行评判和筛选，找出更多的测试点。
分析业务逻辑的异常处理情况（是否每个业务逻辑都有对异常情况进行处理，也采用头脑风暴的方式）；是否将逻辑的用例分类比较合理，让大家通过逻辑很容易就找到对应的用例。
分析是否所有的逻辑都能够找到对应的用例（通过逻辑找到对应的用例）,包括前面没有考虑到的逻辑；分析用例是否有冗余，是否多个用例都是覆盖的同一个逻辑（包括测试步骤和检查点）。
分析用例的测试方法是否有改进，是否能够直接通过代码静态走读、接口测试、自动化测试（包括编写脚本）、引入工具等等来进一步提高我们的测试效率。
（3）基于场景的用例设计过程：
A、用例编写过程：整理清楚客户的原始需求，为什么需要这个功能，能够给客户带来的价值是什么；查看需求说明书里面的客户使用的典型用户场景，并且整合到场景用例里面。
在需求说明书的基础上进一步分析客户还可能有哪些实际的使用场景（主要是整个客户的拓扑结构）；客户会怎样去配置该模块以满足什么样的需求（头脑风暴）；过程中客户会有哪些操作（头脑风暴）。
B、用例评审过程：安排相关项目经理和主管来进行评审，主要是分析还可能有哪些场景没有考虑到，最好是能够有具体的客户。
安排讲解该模块的场景，保证用例责任人对模块场景是非常熟悉的，并且过程中分析是否可能会有其他情况，来进一步完善场景用例。
C、友情提醒：模块用户场景尽量是有真实的客户，而不是自己臆想出来的；模块用户场景最好是完整的客户使用过程，而不是某一个测试点；并不是所有的模块都有场景用例。
python读取Excel实现接口自动化并生成测试报告
#读取多条测试用例#1、导入requests模块
importrequests
#从 class_12_19.do_excel1导入read_data函数
fromdo_excel2 importread_data
fromdo_excel2 importwrite_data
fromdo_excel2 importcount_case
#定义http请求函数
COOKIE=None
defhttp_request2(method,url,data):
ifmethod=='get':
print('发起一个get请求')
result=requests.get(url,data,cookies=COOKIE)
else:
print('发起一个post请求')
result=requests.post(url,data,cookies=COOKIE)
returnresult #返回响应体
# return result.json() #返回响应结果：结果是字典类型：{'status': 1, 'code': '10001', 'data': None, 'msg': '登录成功'}
#从Excel读取到多条测试数据
sheets=['login','recharge','withdraw']
forsheet1 insheets:
max_row=count_case(sheet1)
print(max_row)
forcase_id inrange(1,max_row):
data=read_data(sheet1,case_id)
print('读取到第{}条测试用例:'.format(data[0]))
print('测试数据 ',data)
#print(type(data[2]))
#调用函数发起http请求
result=http_request2(data[4],data[2],eval(data[3]))
print('响应结果为 ',result.json())
ifresult.cookies:
COOKIE=result.cookies
#将测试实际结果写入excel
#write_data(case_id+1,6,result['code'])
write_data(sheet1,case_id+1,7,str(result.json()))
#对比测试结果和期望结果
ifresult.json()['code']==str(data[5]):
print('测试通过')
#将用例执行结果写入Excel
write_data(sheet1,case_id+1,8,'Pass')
else:
write_data(sheet1,case_id+1,8,'Fail')
print('测试失败')
# 导入load_workbook
fromopenpyxl importload_workbook
#读取测试数据
#将excel中每一条测试用例读取到一个列表中
#读取一条测试用例——写到一个函数中
defread_data(sheet_name,case_id):
# 打开excel
workbook1=load_workbook('test_case2.xlsx')
# 定位表单（test_data）
sheet1=workbook1[sheet_name]
print(sheet1)
test_case=[] #用来存储每一行数据，也就是一条测试用例
test_case.append(sheet1.cell(case_id+1,1).value)
test_case.append(sheet1.cell(case_id+1,2).value)
test_case.append(sheet1.cell(case_id+1,3).value)
test_case.append(sheet1.cell(case_id+1,4).value)
test_case.append(sheet1.cell(case_id+1,5).value)
test_case.append(sheet1.cell(case_id+1,6).value)
returntest_case #将读取到的用例返回
#调用函数读取第1条测试用例，并将返回结果保存在data中
# data=read_data(1)
# print(data)
#将测试结果写会excel
defwrite_data(sheet_name,row,col,value):
workbook1=load_workbook('test_case2.xlsx')
sheet=workbook1[sheet_name]
sheet.cell(row,col).value=value
workbook1.save('test_case2.xlsx')
#统计测试用例的行数
defcount_case(sheet_name):
workbook1=load_workbook('test_case2.xlsx')
sheet=workbook1[sheet_name]
max_row=sheet.max_row #统计测试用例的行数
returnmax_row
importcsv # 导入scv库，可以读取csv文件
fromselenium importwebdriver
importunittest
fromtime importsleep
importtime
importos
importHTMLTestRunner
importcodecs
importsys
dr =webdriver.Chrome()
classtestLo(unittest.TestCase):
defsetUp(self):
pass
deftest_login(self):
'''登陆测试'''
path ='F:\\Python_test\\'
# 要读取的scv文件路径
my_file ='F:\\pythonproject\\interfaceTest\\testFile\\ss.csv'
# csv.reader()读取csv文件，
# Python3.X用open，Python2.X用file，'r'为读取
# open(file,'r')中'r'为读取权限，w为写入，还有rb，wd等涉及到编码的读写属性
#data = csv.reader(codecs.open(my_file, 'r', encoding='UTF-8',errors= 'ignore'))
with codecs.open(my_file, 'r', encoding='UTF-8',errors='ignore') as f:
data=csv.reader((line.replace('\x00','') forline inf))
# for循环将读取到的csv文件的内容一行行循环，这里定义了user变量(可自定义)
# user[0]表示csv文件的第一列，user[1]表示第二列，user[N]表示第N列
# for循环有个缺点，就是一旦遇到错误，循环就停止，所以用try，except保证循环执行完
print(my_file)
foruser indata:
print(user)
dr.get(' https://passport.cnblogs.com/user/signin ')
# dr.find_element_by_id('input1').clear()
dr.find_element_by_id('input1').send_keys(user[0])
# dr.find_element_by_id('input2').clear()
dr.find_element_by_id('input2').send_keys(user[1])
dr.find_element_by_id('signin').click()
sleep(1)
print('\n'+'测试项：'+user[2])
dr.get_screenshot_as_file(path +user[3] +".jpg")
try:
assertdr.find_element_by_id(user[4]).text
try:
error_message =dr.find_element_by_id(user[4]).text
self.assertEqual(error_message, user[5])
print('提示信息正确！预期值与实际值一致:')
print('预期值：'+user[5])
print('实际值:'+error_message)
except:
print('提示信息错误！预期值与实际值不符：')
print('预期值：'+user[5])
print('实际值:'+error_message)
except:
print('提示信息类型错误,请确认元素名称是否正确！')
deftearDown(self):
dr.refresh()
# 关闭浏览器
dr.quit()
if__name__ =="__main__":
# 定义脚本标题，加u为了防止中文乱码
report_title =u'登陆模块测试报告'
# 定义脚本内容，加u为了防止中文乱码
desc =u'登陆模块测试报告详情：'
# 定义date为日期，time为时间
date =time.strftime("%Y%m%d")
time =time.strftime("%Y%m%d%H%M%S")
# 定义path为文件路径，目录级别，可根据实际情况自定义修改
path ='F:\\Python_test\\'+date +"\\login\\" + time + "\\"
# 定义报告文件路径和名字，路径为前面定义的path，名字为report（可自定义），格式为.html
report_path =path +"report.html"
# 判断是否定义的路径目录存在，不能存在则创建
ifnotos.path.exists(path):
os.makedirs(path)
else:
pass
# 定义一个测试容器
testsuite =unittest.TestSuite()
# 将测试用例添加到容器
testsuite.addTest(testLo("test_login"))
# 将运行结果保存到report，名字为定义的路径和文件名，运行脚本
report =open(report_path, 'wb')
#with open(report_path, 'wb') as report:
runner =HTMLTestRunner.HTMLTestRunner(stream=report, title=report_title, description=desc)
runner.run(testsuite)
# 关闭report，脚本结束
report.close()
csv文件格式：
备注：
使用python处理中文csv文件，并让execl正确显示中文（避免乱码）设施编码格式为：utf_8_sig，示例：
'''''
将结果导出到result.csv中,以UTF_8 with BOM编码（微软产品能正确识别UTF_8 with BOM存储的中文文件）存储
#data.to_csv('result_utf8_no_bom.csv',encoding='utf_8')#导出的结果不能别excel正确识别
data.to_csv('result_utf8_with_bom.csv',encoding='utf_8_sig')
web自动化测试计划和步骤
测试用例：前置、步骤、断言项目周期长：功能会越来越复杂
历史功能：比较稳定
回归，历史功能
开发-接口自动化同步
项目-8大模块-2000左右用例数
1、熟悉业务
需求文档/手动测试/产品聊，了解模块之间的关系/测试人员
项目目前在测试的阶段，棘手的问题
2、分析
系统当中哪些模块适合自动化、哪些模块不适合
历史功能稳定性、功能复杂性
核心模块
使用频率模块，哪一个模块bug率目前偏高
测试团队、产品 开会讨论
筛选2个模块 400个功能测试用例
如果是接口 ---接口有多少个，每个接口有多少个用例
3、功能测试 ---筛选自动化测试用例----核心功能、主流程、主功能点---140
用例评审===
4、自动化计划
自动化类型：web/接口
框架选型：
团队人员：
搭框架、定规范
时间规划：用例编写时间2个半月
效果：覆盖率是多少---用例通过率---跟项目测试进度结合 关于接口自动化测试用例数量和接口自动化测试用例数量多少的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 接口自动化测试用例数量的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于接口自动化测试用例数量多少、接口自动化测试用例数量的信息别忘了在本站进行查找喔。
版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。
相关文章
发表评论
暂时没有评论，来抢沙发吧~