接口测试-工作心得记录二

又是小一个月才写这篇,有的时候还不知道要写什么。刚发了一个大版本app版本,后面有些下一个版本的客户端测试用用例,和PM撕测试排期各种新仇旧怨各种撕逼真的是挺无语的。呵呵,昨天写测试脚本的遇到一个小问题我觉得正好拿出来写一篇。

背景:

最近test环境测试的总会遇到RD需要找你造数据的情况(我负责商家端,各种发帖子,但是字段又特别多),发完帖子,还要去crm去审核,当然直接改数据库也可以,一般情况我也是这么做的,但是总是这样的还是挺烦的。正好这两天不是特别忙就想写小脚本,思路是首先post请求发布接口(postpub接口),然后连接数据库更改对应表中的状态字段即可。思路很简单,写的时候就各种坑了。

首先我之前用的接口框架所有测试case都是继承Base_TestCase(就是基础测试类)里面包含各种生产的url域名,header,电话,常用类的实例化和ORM链接数据库session实例等等。所以我本能就写一个测试环境环境基类即Base_Test配置一个测试环境上面那一套。内容下面图片的内容:


然后我的测试case就继承Base_Test类和unittest.TestCase类,正常书写一个case。然后实例化suite然后run(suite)。然后第一个坑就出现了,一直提示我测试类没有self.session这个属性当时我就困惑了,首先我先查看我的Base_Test基类是不是哪里有问题,后来发我排除没有问题。然后我就怀疑是不是一个包不能有两个测试基类,当时我就位置放在这里,如图:


然后我就新创建一个包把Base_TestCaseTest.py文件放到里面去,然后再去run(suite),仍然还是报错一直提示我测试类没有self.session这个属性,当时真的疯了,各种百度发现根本没有,就想着RD聊了一下,开发写功能这种继承肯定没有问题,然后我想1天多我猜问题可能出现unittest这个框架,是不是不支持这种继承,后来特别偶然的发现是因为我的def setUp()手误写成了def setup() "u"没有大写,那心中的感觉简直了。除了这个问题还有一个很重要的方向也有一个问题,就是我本意是想写一个发布帖子的功能并成功置成各种需要状态,总是使用单元测试思路去写肯定是有问题的。主要还是习惯了unittest单测了,第一反应就是这个。而且还有很重要的一点就是测试环境和生产环境很多东西还是要区分开这样以后也方便维护,如果乱糟糟放到一起以后维护就是噩梦了。

既然要写还是要有最基本的分层,因为功能很少所以分层也很少,如图:


config_vipB就是配置类了,把一些常量放到里面去。BasePostpub类就是发布基类,放置东西就是url域名,header等等了如图:


唯一的区别就是增加了params,主要想法是因为发布字段很多,而且所有发布功能都是拼这个参数,所以把不变的都放到这里面了。

配置写好了,剩下就是写功能了,这个就看你想写什么了,其中我觉得很重要就是方法的备注,备注太重要了,我写了很多case了,因为是我自己写还好一点,但是有一些时间长了我也记不起,造成后面我都要自己看写的啥,很蛋疼,别懒写的详细一点也方便别人。如图:


cookie肯定要根据传入的电话不同调用login接口获取到cookie,所以封装一个方法。帖子有开始时间和结束时间嘛都是获取本地的时间根据需要是直接变成string还是转成时间戳看接口的参数定义了。这里面我最想说的还是sqlalchemy中跟新对应字段值的方法update(),如图:


想说update({})是因为好多博客都是些查询的,更新很少,也是找了很久磨磨唧唧的,就想拿出来简单说一下。和查询相似query(表映射的类名).filter(查询条件和sql中where一个意思).update({key:value})。

除了更新还有就是creat创建一个新数据,如图:


想创建一个新记录直接用映射类名把值输入完成后,通过session.add(obj)添加进入session,然后使用session.commit()写入数据库对应表中.

这里面有一个坑就是映射关系的数据类型一定要和数据库表中对应字段保持一致(当然这个地方定义不对,但是写的时候对了也可以),另一个就是写参数的值的时候数据类型也要小心也对了,要不然会有莫名其妙的错误比如说我昨天遇到的,如图:


这个错误顾名思义就是sql语句有错误,但是它提示的是在“)”附近,我就以为是附近有问题,也是找了一天,昨天真的都崩溃了,晚上实在不行找的rd问了一下,后来发现参数show_city_ids字段对应值的数据类型是varchar而不是int,改一下就写进去了。有时候定位问题还是太年轻了,方向不对,大概就这些,接口测试后面真的可以扩展出好多东西,以后想慢慢集成进去看看效果。






  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: 接口测试用例-金融银行类参考.xlsx是一个金融银行类接口测试用例的参考文件,包含了一系列接口测试用例的详细信息。在接口测试中,我们主要关注接口的功能、性能、安全等方面的测试。 在该文件中,每个接口测试用例都包含了以下几个关键要素: 1. 用例编号:每个用例都有一个唯一的编号,便于标识和查找。 2. 用例名称:用例的名称描述了被测试接口的功能或行为。 3. 测试步骤:详细描述了每个测试流程的步骤、操作、输入和期望结果。 4. 前置条件:指明了执行该用例之前需要满足的条件和环境。 5. 测试数据:包括了每个测试步骤所需的输入数据、参数和预期结果。 6. 期望结果:用例执行完成后,每个步骤应该得到的预期结果。 7. 实际结果:用例执行后,实际获得的结果。 8. 测试结果:用例执行后,根据实际结果与期望结果的对比,给出测试结果的判断,如通过、失败、未通过等。 通过参考该文档,我们可以了解到金融银行类接口测试重点和测试需求,能够更好地设计和执行接口测试用例。同时,该文档也能够帮助测试团队在编写测试计划、测试报告等方面提供依据,提高测试效率和质量。 总结而言,接口测试用例-金融银行类参考.xlsx是一个重要的测试文档,提供了金融银行类接口测试用例的详细信息,帮助测试团队进行接口测试工作。通过参考该文档,我们可以更好地了解接口测试的要点和需求,提高测试效率和质量。 ### 回答2: 《接口测试用例-金融银行类参考.xlsx》是一个用于金融银行类接口测试的参考文档。该文档包含了一系列测试用例,用于验证金融银行类接口的功能和性能。 接口测试是在软件开发过程中非常重要的一环,它主要用于测试系统之间的数据传输和交互。金融银行类接口测试则是指对金融银行相关的接口进行测试,包括用户注册、登录、账户管理、转账等功能。 《接口测试用例-金融银行类参考.xlsx》中的每一个测试用例都对应了一个接口测试场景和预期结果。在测试过程中,测试人员可以根据这些测试用例的描述和预期结果,通过调用接口进行测试,并验证接口是否符合预期功能。 例如,一个测试用例可能包含如下信息: 接口名称:用户登录接口 测试场景:使用正确的用户名和密码进行登录 预期结果:登录成功,返回用户的相关信息 测试人员可以根据这个测试用例的描述,去调用用户登录接口,并检查返回结果是否和预期一致。如果预期结果和实际结果一致,那么说明该接口通过了测试;如果不一致,则说明该接口存在问题,需要进行修复。 通过使用《接口测试用例-金融银行类参考.xlsx》,可以帮助测试人员快速了解金融银行类接口测试需求,并根据需求编写相应的测试用例。同时,该文档也可以作为测试人员进行接口测试的参考,提高测试的效率和质量。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值