功能测试心得

前面研究了很多自动化,有时候觉得有点好高骛远的意思,但是这些技术有时候确实需要。回头想想,基本的功能测试好像还做不好,用例写的也不是特别好用,还研究一堆技术。这篇文章以后应该会不断增加内容,写一些功能测试遇到的特殊点,距离上一个大项目时间有点长了,可能会漏一些东西,先把能记起的写这里。

一般用例设计都会说等价类、边界值。说都好说,真正写用例的时候,可能就漏了一些。

等价类,我理解的输入框输入字母、数字、汉字、特殊字符、空、全角,根据实际情况,测试哪些哪些能输入,哪些不能输入,特殊符号比较多,如果都试下来有点麻烦,我最常试的几个:'|\%*#=;还有空格,可能还有特例没发现(还有容易出bug的请下面评论一下,也像各位学习一下经验)。空格有些输入框可以输,会自动去掉前后空格。感觉如果有问题,只会在前面几个。去年一个测试测一个小接口,试了多个异常都给拦截了,我让试试’和|,果然这俩都成功通过,后面几个特殊符号都拦截了,也算提了两个小bug。

边界值一般都想到输入数字大小,长度。上个项目快上线的时候,突然想到一种情况,日期的边界值,从婴儿到儿童、儿童到成人的转变,试了一下,果然过了生日,没那么智能的把婴儿变成儿童,把儿童变成成人。日期还有一种情况,选择婴儿类型,输入儿童生日,不过这个在很早就试了。

上面的情况不只看能不能拦截异常,还要看报错信息是否准确,比如:密码格式有误和密码只能是8-20位字母和数字。

上个项目很大,分PC端会员中心、手机端会员中心、会员后台、还有多个渠道的会员接口,一开始是非常明确的只测一种,后来测了一段时间,由于有点懒了,直接从接口加了很多数据,然后去会员中心用,在这个时候又发现问题了,接口添加的信息,会员中心修改不了,包括PC端和手机端,只用这俩都会出问题,后面就又试了多种渠道互相验证。

还有一处我觉得我运气相当好,项目也涉及了数据迁移,从生产上迁移到新的数据库,自然测试环境也有了生产数据,随便找了几条数据,发现在会员中心的时候,有的账号报异常了,去会员后台看,显示的是正常。进数据库里找了一会儿,幸好数据库几乎每个字段都有备注,很快发现账号确实异常,但是在后台没判断那个字段,只判断了另一个字段。涉及到数据迁移真得好好看看,尤其两次数据库表是两个公司设计的,老数据性别用的0、1表示,新数据性别用的M、F表示,迁移过来自然0、1的不能正常显示出性别。类似这种情况还发生几处,都是后面发现的。

后面测试多了,也想试试用Appscan扫描一下有没有漏洞,但是之前没用过,而且电脑一直阻止Appscan运行,后面也没仔细研究,有专门测试安全的公司。后来领导说发现了一处,修改返回值,会出异常,大概步骤就是登录时候输入错误的账号和密码,然后拦截接口返回数据,把返回的状态码改为登录成功的状态码。用fiddler试了一下,果然修改以后,再看页面,像是登录成功的页面,里面还有点信息的样子,实际信息都是假的,但是被要求一定要改。还有一次可能是网卡了一下,添加信息鼠标点了两次,结果真添加了两次,实际只能添加一个,后来也用fiddler拦截试了一下,发现fiddler真是好东西,可以拦截请求,还能拦截返回值,修改返回值。还有一处用了fiddler,修改密码的时候,需求里写的密码一定要8-20位字母和数字组合,前端页面拦截了纯数字或者纯字母的情况,但是使用fiddler拦截请求,在里面修改参数,可以把密码改为纯数字或纯字母了。

基本问题就是这么多,不过感觉在需求评审阶段就发现问题真的很管用,需求评审时候已经填了很多坑,主要业务上的坑,如果业务不熟,恐怕测试时候难免漏了一些。就像这两天那个很火的产品经理一样,开发的圈子怎么说我不知道,测试圈子很多人都在说:要我我也得打他。

功能测试心得_第1张图片

从技术上来说,我觉得是有点异想天开,脑洞简直比测试脑洞还大,在讨论怎么实现的时候,我也想了一下这个需求:强制启动手机前置摄像头,对用户眼角膜的手机倒影进行图像分析。强制启动手机前置摄像头感觉很像流氓软件,然后这会儿用户正在看手机呢,肯定看手机正面,即使技术真实现手机倒影图像分析了,眼角膜里最多的恐怕是APP的默认主题颜色吧。如果说再去掉屏幕那一块,只识别边上。最近vivo出的一款手机好像已经没有边了,全是屏幕。最重要的一点,如果正面是白色,背面是金色,我觉得金色肯定是识别不到的。所以可以说:需求评审不通过,哈哈,这个时候感觉自己很强大,在测试群里说,还有很多拥护者。比较靠谱的需求:可以根据天气变化主题,用一个查询天气的接口,再需要一个位置信息,应该就可以了。

你可能感兴趣的:(随笔)