有些测试朋友来问我,redis要怎么测试?首先我们需要知道,redis是什么?它能做什么?
redis是一个key-value类型的高速存储数据库。
redis常被用做:缓存、队列、发布订阅等。
所以,“redis要怎么测试?”这个问题就可以转化为:
在我所接触的技术栈中,发布订阅很少用redis的,我们主要说一说缓存和队列。
缓存有几种类型:文件缓存、数据库缓存、内存缓存、浏览器缓存。
浏览器缓存指的是浏览器自身的缓存能力。现代浏览器为了加快页面加载速度,往往会把css、js等资源文件下载一次之后缓存一段时间,直到缓存失效或者请求明确告知需要更新。
通过后端语言直接渲染、smarty等模板渲染方式输出界面的,一般都会选择文件类型缓存。
图--文件缓存
随着大前端技术迅速发展,前后端分离越来越流行,smarty渲染的方式使用越来越少,对后端服务的接口响应时间要求也越来越高,文件缓存不再适用这种场景,数据库缓存越来越流行。
数据库缓存目前最常见的:redis和memcached。它们都是分布式的key-value高速缓存系统。
上图--redis缓存
内存缓存跟数据库缓存也是类似的,但受技术栈限制,比如Java可以使用,并且Java中使用非常频繁,但PHP无法使用。内存缓存比数据库缓存更快,但因为内存不可能一直增加,所以限制更多,稍不注意就会出现内存泄漏等问题。
在实际的使用过程中,Java接口往往会将部分高频数据塞到内存缓存中作为一级缓存,次高频数据塞到redis中作为二级缓存,最后再从db查询数据。
上图--组合使用
缓存的作用:
从上面的内容你可能已经知道,缓存最重要的两个作用:加快访问速度、减少服务器和db压力。
- 现在我也找了很多测试的朋友,做了一个分享技术的交流群,共享了很多我们收集的技术文档和视频教程。
- 如果你不想再体验自学时找不到资源,没人解答问题,坚持几天便放弃的感受
- 可以加入我们一起交流。而且还有很多在自动化,性能,安全,测试开发等等方面有一定建树的技术大牛
- 分享他们的经验,还会分享很多直播讲座和技术沙龙
- 可以免费学习!划重点!开源的!!!
- qq群号:110685036【暗号:csdn999】
你可能会问,上面这些跟测试没啥关系啊?不,我认为了解上面的内容对测试还是有帮助的。你知道在技术实现上,什么时候应该加缓存,什么时候不应该加缓存吗?这就是对一个接口的技术把控,不光开发需要知道,测试人员也一样。
如果一个应该添加缓存的接口没有添加缓存在压测之前被你提前发现了,你不觉得自豪吗?其实跟缓存的作用一一对应,当接口的qps较高(比如超过100)或者对响应速度有要求,或者服务器性能、db性能较差的,都可以尝试使用缓存解决问题。
我举几个例子说明:
1、微信新版本中,个人中心多了一个“状态”功能。
微信的用户体量非常庞大,访问qps非常高,几十万人在同一秒访问,不可能每次都去查询数据库。
类似这种需求,一般会是这样的做法:先把用户的状态数据缓存在app中(浏览器缓存),在某个时间段通过主动推或者被动拉的方式调用后端接口请求“状态”数据;接口从redis/memcached的缓存中读取数据并返回;如果数据量不那么庞大,接口可以直接从内存缓存中读取数据并返回;数据返回后,再把用户app中的缓存更新。
上图--示例1
2、有一个小型电商的商品管理后台列表页面,访问人数不多,sku改动频次很低,可能3天才被访问几十次。这种场景一不需要使用缓存,二在商品信息被更新之后需要立即看到更新后的数据,不适合使用缓存,所以不建议使用缓存。
3、同样的电商管理后台,这次是一个统计页面,统计昨天/今天/近一周的商品销售情况。
这个场景可以分情况来看,有多种不同的解决方案。
(我们抛开大数据统计的各类技术方案,简单实现一个系统的统计功能)
了解到缓存的使用场景之后,我们来说说缓存的生成方式。
一般来说缓存有两种使用方式,我简单概括为:外面和里面。
先来说说一个接口的请求到了程序里,是怎么处理的:
上图--程序处理流程
这是一个典型的MVC,由Controller接收和处理请求数据,由Service处理Model中获取的数据,再由View输出。
对不同场景,我们可以采取多种方式,在多个节点增加不同的缓存,来解决不同的问题。
比如,针对请求参数多变,返回的数据如果跟请求参数强相关,适合在“外面”(请求参数过滤之后)缓存查询到的数据。这类数据一般缓存时间短,比如缓存5分钟。主要应对相同请求参数在短时间内的重复请求。如果遇到请求攻击,即使这个缓存有效期只有1秒,也是很有效的,能挡住大量的请求。
上图--在“外面”缓存
比如,针对请求参数变化不大,返回的数据跟db中存储的数据很接近的情况,适合在“里面”缓存数据,也就是在更新db的同时更新缓存,这种情况最优的状态下,只需要读缓存就够了,不需要跟db直接交互,能大大缓解db压力。这种缓存有效期可以设置很长。
上图--在“里面”缓存
说完生成,再来说说缓存的更新。缓存在生成之后,正常都不会一成不变,所以需要对缓存进行更新。
有几种更新方式:
1、性能测试角度
缓存增加/更新功能是否正确,查看缓存数据是否正确
缓存删除
超量淘汰机制:缓存达到上限怎么处理
缓存穿透
缓存雪崩
redis缓存服务停掉
缓存超时
缓存数据被误修改后,快速恢复到指定版本
缓存数据被误删除后,快速恢复数据
2、Redis功能测试角度
在自动化测试中,自动化测试用例设计原则就是:执行过程时不能存在依赖顺序。那么如果测试用例需要按照指定顺序执行,这个时候应该怎么做呢?
目前单元测试框架中UnitTest没有办法改变测试用例的执行顺序,但是另一个单元测试框架Pytest可以做到,辅助测试人员更改测试用例的执行顺序。
今天小编简单的介绍几种方法,教你如何通过Pytest进行更改自动化测试用例的执行顺序。
pytest
Pytest的执行顺序想必大家都清楚,是通过ascii码进行收集的,然后通过文件中从上往下的执行顺序进行运行,我们只需要将我们的测试用例在编写时,按照从上往下的顺序进行编写。
# coding:utf-8
import pytest
def test_a():
print('测试用例01')
def test_b():
print('测试用例02')
def test_c():
print('测试用例03')
(左右滑动查看完整代码)
通过运行后发现,顺序是按照从上往下的顺序依次执行。
pytest-ordering
pytest-ordering属于Pytest的一个插件,其目的就是帮助我们控制自动化测试用例的执行顺序,而且使用起来也比较简单。
安装:pip install pytest-ordering
/
使用方法
/
使用方法比较简单,我们只需要在编写好的测试用例前加上一个装饰器,然后通过改变装饰器传入的参数进行控制其用例执行的顺序。
小编这里拿到上方的用例,我们将从下往上的执行。
# coding:utf-8
import pytest
@pytest.mark.run(order=3)
def test_a():
print('测试用例01')
@pytest.mark.run(order=2)
def test_b():
print('测试用例02')
@pytest.mark.run(order=1)
def test_c():
print('测试用例03')
(左右滑动查看完整代码)
通过执行测试用例会很清楚的看到,我们已经将测试用例的执行顺序改变了。
- 现在我也找了很多测试的朋友,做了一个分享技术的交流群,共享了很多我们收集的技术文档和视频教程。
- 如果你不想再体验自学时找不到资源,没人解答问题,坚持几天便放弃的感受
- 可以加入我们一起交流。而且还有很多在自动化,性能,安全,测试开发等等方面有一定建树的技术大牛
- 分享他们的经验,还会分享很多直播讲座和技术沙龙
- 可以免费学习!划重点!开源的!!!
- qq群号:110685036【暗号:csdn999】
pytest_collection_modifyitems
pytest_collection_modifyitems属于Pytest的钩子函数,这个函数可以收集我们的测试用例,收集完成后可以对其进行一些修改和排序功能,下面小编简单的介绍该使用方法。
/
使用方法
/
首先需要将pytest_collection_modifyitems这个函数放入到conftest.py文件中,然后对其进行二次开发,这里小编通过倒叙的形似修改了收集到的测试用例,从而改变测试用例的执行顺序。
# conftest.py
# coding:utf-8
def pytest_collection_modifyitems(session, items):
print("收集到的测试用例:%s"%items)
# 修改执行顺序
items.reverse()
for i in items:
print('收集到测试用例名称:%s' %i.name)
(左右滑动查看完整代码)
编写3个简答的测试用例,通过命令行的方式进行运行,并且会发现也将我们的测试用例顺序改变和收集到了我们的测试用例相关信息。
# coding:utf-8
import pytest
def test_a():
print('测试用例01')
def test_b():
print('测试用例02')
def test_c():
print('测试用例03')
(左右滑动查看完整代码)
小编通过简单的案例介绍了如何在Pytest中改变测试用例的执行顺序。
当然上述方法并不是唯一的方法,只是提供一个简单的思路,小编还是希望大家编写测试用例时注意不要互相依赖,这样的话执行顺序就可以随机执行,保证我们的测试用例不受其他用例的干扰而成功执行。感谢您的阅读,希望本篇文章对您有所帮助