接口测试需要测试的内容(黑盒测试不到的内容)

接口测试和黑盒测试的区别在于,接口覆盖率更高,可以测试到UI测试不到或者难易实现的功能和场景。然而接口测试不能代替功能测试,在如下介绍的场景进行分析接口测试应该测试的内容。

        一、黑盒遗留问题

        1、忽略后端校验

大部分的功能测试只停留在UI层面,那么我们对于一些输入内容进行限制和校验也只能测试到前端。然而后台并没有进行测试,导致无法得知后端是否也做了校验。

例子:我所在的公司是做电商系统,到目前位置一直使用的是功能测试,没有任何的接口测试,那么我在职时候发现使用jmeter进行接口测试修改密码发现我输入“sd非非觉得很多4%……%……¥”为新的密码,结果直接成功了。

修正

(1)开发:对于所有的的校验都应该做前后端校验

(2)测试:对于重要数据和用户安全信息都应该绕过UI界面进行接口测试,包括输入规范,校验输入特殊字符(数据库代码select from....),类型检查等方面测试。(对于项目紧急的项目可以先发布再进行接口测试,在下个版本修改或者做个补丁)

        2、性能和稳定性(并发性、负载能力、内存泄露等)

性能测试是普通功能测试无法检测到的优劣。性能对于很多企业追求的其实不高,有句话说,“程序跑起来就行”。其实并不然,很多项目的扩展性比较强,但是由于底层代码写得太垃圾导致就算系统发展再好也在一段时间内发现bug频繁出现,数据错误。对于要实现大量数据事件,手动测试浪费很多时间,难于实现,然而接口简单一个脚本即可实现数据并发。

例子:最出名就是“铁路12306”软件的服务器奔溃和最近“滴滴事件”,这些软件是比较大的企业开发的软件,但由于在性能方面没有充分的进行测试和优化,导致服务器奔溃和数据泄露。我公司的电商系统在并发用户数100人就已经超过市面电商系统的200%以上的效应时间、错误率也存在5%。其实企业想更好的发展不仅仅是在员工薪资上进行反复折磨,而是怎么把公司的产品做好和优化系统。(当然,这个针对的是以后想发展更好的企业或者想上市的的企业)

优化

(1)后端:技能提升,拒绝“程序跑起来就行”心理,要不断学习新的技术和高效的方法,善于总结和规范,做到模块化开发,实现低耦合。重要的一点是代码“冗余”,代码冗余是所有程序员的通病,粘贴复制的代码直接复用,导致大部分代码无需执行却要占用运行时间。此次是算法乱用,最简单的是排序算法,不同场合应该使用不同的算法或者使用多算法并用实现运行效率更好,减轻服务器负担和用户等待时间。服务器容量把控,根据系统的用户量进行估算最大值服务器承受范围给系统分配容量。

(2)前端:使用框架开发、限制使用播放器、压缩图像、清理你的代码、使用缩略图、切换到CSS、减少服务器请求、可视化渲染。

(3)测试:jmeter进行压力测试,查看响应时间、吞吐量、cpu和服务器检测量,异常数量等。

        3、批量数据注入

大数据时代,我们做的系统用户量可能会很大,相应的数据量也会比较大,上万上亿条数据,那么如果靠手动的输入数据可能一个月都难以解决。那么对于大数据的注入,我们必须借助工具进行接口注入。

        二、接口同步异步任务

当接口涉及异步任务时。常规的接口测试用例设计思路,一般只会触发异步任务正常执行的场景。而异步任务失败,重试,定时被拉起这些异步流程,有可能会被遗漏掉。因此会降低代码覆盖率。

大部分的接口基本都是异步的,这样可以提高效率;但是涉及一些顺序执行的方法,我们必须要进行同步。同步异步在测试中基本是一个随机数,如果没有大量的测试很难发现错误,如何发现该使用同步时程序员没有使用?那么jmeter进行异步测试很好解决了这个问题,可以快速发现是同步异步问题。

        三、接口事务

当某个接口涉及事务,常规的接口测试用例设计,一般只会触发正常的事务流程。而实际开发人员是对具体哪一步回滚,回滚后需要的处理,都是做了一些特殊的业务实现的。这些场景容易被遗漏,也会影响代码覆盖率。

        四、上锁

当某个接口涉及到锁,也会有容易遗漏一些测试场景。以读写锁为例(读-读共存,读-写不共存,写-写不共存)。常规的接口测试用例设计,很可能会遗漏一些 读-读共存,读-写不共存,写-写不共存的场景。就算这些场景被覆盖了,关于锁过期,获取锁失败后等待的场景很难被覆盖到。很明显这会降低代码覆盖率。

上锁可能还有有一种情况,就是恶意上锁。像现在的很多软件都做了防治同一用户恶意点击,当时我公司对这方面做得还是有点欠缺。例如,我公司一个应用“易货券”里面涉及到类似于抢演唱会门票一样的购买抵扣券,但是我的公司没有做用户ID地址处理可能会导致一些不良用户借助类似jmeter进行同一用户多次点击所有的购物券,那么所有的购物券就会自动上锁,其他用户无法购买。

修正

上锁是系统一种安全策略。那么无法避免要使用上锁,那么对于这种情况可以有一下的解决方法。

(1)进行短信验证;

(2)用户纪录,一个用户短时间内只能点击上锁一个;

(3)登录IP地址唯一,可以设置同一IP下的用户只能上锁一个;

        五、接口缓存

接口中利用缓存技术是比较常见的,尤其是查询类接口。比如批量查询。如果接口涉及了缓存,常规的接口测试用例设计很容易忽略缓存的影响,而没有针对性对接口缓存相关的验证。这也会降低代码覆盖率。

首先说缓存的类别,客户端常见cookie,浏览器本地缓存,部分C/架构的文件缓存的,非常多;应用服务器或网络服务器,这个就比较多了,比如Nginx做反向代理服务器时也可以缓存静态图片,java本身的JVM等,各种MQ,各种cache等等;数据库端像Oracle还专门有缓存机制。具体缓存怎么测,不同问题不同处理,种类太多不一一说明。如果是黑盒,缓存就好测了,比如浏览器缓存或是看cookie,用HttpWatch就搞定了。

优化

程序员

  1. 程序设计中决定使用什么类型的数据库是至关重要的,要是涉及大量数据查询则可以用redis非关系数据库,redis只带的缓存可以快速进行查询。
  2. 在存储数据要考虑好使用那种缓存方式,cookie/浏览器/数据库等,合理的设置缓存可以有效提高程序效率也可以让系统更加的安全。

测试

  1. 浏览器缓存或是看cookie,用HttpWatch就搞定了。
  2. 要清楚什么数据应该放在哪个缓存方法,例如类似图片、大文件可以放到本地浏览器;个人用户信息可以放到cookie或者数据库。
  • 5
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
好的,针对用户注册的测试接口,以下是一些测试用例设计: 1. 测试用例名称:输入正确的用户名和密码,注册成功 测试步骤: - 输入合法的用户名和密码 - 点击注册按钮 - 检查是否成功跳转到登录页面 - 使用新注册的用户名和密码登录,检查是否可以成功登录 2. 测试用例名称:输入已存在的用户名,注册失败 测试步骤: - 输入已存在的用户名和一个合法的密码 - 点击注册按钮 - 检查是否出现错误提示,提示用户名已存在 3. 测试用例名称:输入过短的密码,注册失败 测试步骤: - 输入一个合法的用户名和一个过短的密码 - 点击注册按钮 - 检查是否出现错误提示,提示密码过短 4. 测试用例名称:输入非法的用户名,注册失败 测试步骤: - 输入一个非法的用户名,如包含特殊字符或长度超过限制 - 输入一个合法的密码 - 点击注册按钮 - 检查是否出现错误提示,提示用户名非法 5. 测试用例名称:输入非法的密码,注册失败 测试步骤: - 输入一个合法的用户名 - 输入一个非法的密码,如包含特殊字符或长度超过限制 - 点击注册按钮 - 检查是否出现错误提示,提示密码非法 6. 测试用例名称:不输入用户名和密码,注册失败 测试步骤: - 不输入用户名和密码 - 点击注册按钮 - 检查是否出现错误提示,提示用户名和密码不能为空 7. 测试用例名称:输入不同的密码和确认密码,注册失败 测试步骤: - 输入一个合法的用户名 - 输入两个不同的密码,一个作为密码,一个作为确认密码 - 点击注册按钮 - 检查是否出现错误提示,提示两次输入的密码不一致 以上是一些基本的测试用例设计,可以通过修改一些参数和操作来衍生更多的测试用例。

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值