功能测试心得

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

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

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

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

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

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

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

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

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

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