测试-功能测试基础

功能测试是测试工程师的基础功，很多人功能测试还做不好，就想去做性能测试、自动化测试。

很多人对功能测试的理解就是点点点，如何自己不用心去悟，去研究，那么你的职业生涯也就停留在点点点上了。

　　一、功能测试所需要掌握的技能

　　1.1  熟练使用SQL

　　1、常用的 sql 语句一定会写。比如说增删改查之类。

　　2、了解数据库的事务、会编写存储过程、熟练常用的系统函数。

　　3、了解并可以进行数据库的备份、迁移、还原、镜像等操作

　　4、对 sql 语句进行调优，并对可以对运行的语句监控查看性能

　　5、了解数据库集群等操作。

　　1.2 Linux

　　Linux是测试人员的基础功，不需要掌握太难或者很不常见的Linux命令，正常能做到查看日志，定位问题就可以了。

　　1、基本命令

　　常用的Linux基本命令，面试经常会问的，或者给出一种场景，问你用什么命令。

　　2、查看日志

　　初级测试人员在工作时经常遇到，发现bug，开发不承认或者不愿意解决的情况，测试人员怎么摆脱这样的问题呢？

　　那就是根据发现的bug根据日志级别，来查看日志，定位问题。

　　那这里首先要说一下日志级别了。

　　首先记住这一点：日志级别越高，输出的信息越少 。

　　具体的日志级别分为四级：

　　info : 代码 info 信息，不包括sql语句等一些debug信息

　　warning warning : 代码警告信息

　　error : 程序本身报错信息 java.lang.outindexERROR.....

　　critical ：几乎用不到

　　一般不符合需求的bug在 debug中，程序本身报错的bug在 error中。

 

　　1.3 写好测试用例

　　测试用例必须包含的内容：

　　用例编号、用例名称、测试背景、前置条件、优先级、重要级、测试数据、测试步骤、预期结果、实际结果、备注。

　　1、测试用例的编写流程

　　需求分析->提取测试点->测试用例编写->测试用例评审

　　2、编写测试用例的思路

　　（1）根据产品的RPD，提取测试点。

　　（2）根据数据流的走向。

　　（3）根据的架构部署。

　　（4）编写测试用例的常用方法：等价类划分法、边界值分析法、流程图法等。

　　（5）覆盖弱网测试、接口测试、安全测试、性能测试等。

　　（6）常用测试工具有：Postman、 Charles、 Fiddler 、Jemter、Loadrunner等。

　　3、编写测试用例注意事项

　　（1）根据项目的实际情况设计测试用例表格

　　（2）用例格式不要生搬硬套

　　（3）根据具体情况编写

　　（4）学会质疑需求，不要完全按照需求来写测试用例，要从客户和产品的角度来理解需求，看到需求之外的功能和体验

　　1.4 http与https协议

　　1、Http协议原理

　　2、http和http协议的区别

　　3、TCP和UDP的区别

　　4、session和token的区别

　　5、公钥和私钥的理解

　　6、get和post的区别

　　7、从输入URL到页面加载发生了什么

　　8、什么叫代理，正向代理和反向代理？

　　1.5了解业务

　　做功能测试，一定要了解业务，甚至理解业务。只有把业务吃透，才能把功能测试做好，并且有一定的提高。

　　业务熟悉后，会知道很多常识，知道下面的常识之后，你就可以尝试进阶，学习做自动化测试、接口测试、性能测试

　　1、什么时候介入自动化 => 当你系统趋于稳定的时候

　　2、什么时候介入接口测试  => 当接口开发完毕的时候

　　3、什么时候介入性能测试 => 当出现促销的时候，或者抢购的时候(618大促，过年抢火车票，抢优惠券)

　　1.6 bug管理

　　做功能测试，还有个很重要的工作就是bug管理，一个优秀的的测试人员，线上bug非常多，多于和你一起工作的其他同事。

　　1、 bug定义

　　（1）不符合需求的

　　（2）程序本身报错

　　（3）不符合用户的使用习惯

　　2、bug生命周期当我们测试人员提交一个bug的时候，自始bug就有它的生命周期，从开始到

　　结束，生命周期如下

   

 

　　3、测试报告

　　同时为软件验收和交付打下基础测试报告和测试计划一样，一般由测试leader编写，测试人员需要了解

　　一下测试报告中都有哪些内容

   

　　1.7 典型bug

　　1、抓包作用: 测试一个app搜索功能，抓包，抓到一个搜索接口，突然发现抓到了两个请求接口 -> 当访问量上来了，服务的压力上升两倍

　　2、数据流走向 : 测试时候发现页面上数据只有一条，但是数据库里面多了一条 -> 1、数据量变大，查询变慢 2、脏数据太多，瞬间爆满，程序崩溃了

　　3、弱网测试：app项目一定要有弱网络测试（模拟2g、3g、4g，wifi网络状态以及丢包情况）；网络切换测试（网络断开后重连、3g切换到4g/wifi 等）

 

 

　1.录入的下拉选择项进行了过滤

　　根据表单的检索关键字作为过滤条件进行下拉列表过滤显示

　　2.录入的下拉选择项或单选项与别的录入项之间的联动过滤关系正确

　　检查多重关联的下拉列表字段的数据有效性

　　3.必填项字段控制与数据库必填项控制一致

　　4.正确输入所有相关内容，包括必填项，点添加按钮，记录成功添加

　　5.成功新增的记录在数据库显示的值与录入的一致

　　6.必填项内容不填、其它项正确输入，点添加按钮，系统有相应提示

　　7.内容项中输入空格，点添加按钮，记录不能添加成功

　　8.内容中不输入，保存后显示null

　　9.内容项中输入系统中不允许出现的字符、点添加按钮，系统有相应提示

　　10.仅填写必填项，点添加按钮，记录能否添加成功

　　11.添加记录失败时，有相应的提示，原填写内容保存

　　12.添加记录失败时，原填写内容保存

　　13.重复提交相同记录，系统有相应提示（同一客户端提交两次相同的记录，不同客户端提交一次相同的记录）

　　14.某些输入项不允许重复（注意大小写和前后空格问题），若添加重复的输入项，系统应有相应提示

　　15.提交时自动处理了内容首尾两端的空格

　　16.提交成功的记录后，可以正常显示此记录

　　17.提交成功的记录后，可以正常调用此记录

　　18.新增数据提交后，会清空缓存，如果没有清除再次提交有提示

　　19.提交成功后刷新页面，系统不会抛异常信息

　　20.是否有批量新增功能，如果存在，则要考虑对批量新增进行性能和压力测试

　　21.是否有批量新增功能，如果存在，则要考虑在批量新增过程中，如果出现系统异常，新增操作是否进行了数据回滚

　　22.新增按钮是否对应了一组事务处理（即点击新增的同时，在后台数据库进行了多项工作，而非一条添加），要在新增成功后，检查是否所有的事务操作都进行了正确完整的处理

　　23.新增按钮是否对应了一组事务处理，要在新增过程中，人为构造新增异常，检查是否进行了事务回滚操作

　　24.新增操作是否支持回车键或TAB键的输入切换操作

　　25.新增操作中是否具备撤销功能

　　26.新增操作异常后，不会影响其他的功能操作

　　27.新增操作的同时，是否在后台创建了对应的文件夹或文件，如果存在，要在新增结束后，在系统后台进行文件夹或文件的确认和检查

　　28.新增操作的同时，是否在后台网络中进行了相关数据或文件的传输，如果存在，要在新增过程中，检查网络数据传输的完整性和正确性以及安全性

　　29.新增操作后，是否会自动更新系统其他页面或数据库表的信息（例如网站新注册一个用户，该网站首页上对应的注册用户人数进行更新），如果存在，要明确更新的时间点，在时间点到来时，检查是否进行了更新

　　30.新增操作后，是否会自动更新系统其他页面中对应的下拉框数据（例如新增一个状态，在前台下拉框中会增加一个新的状态内容），如果存在，要在相关页面上逐一检查下拉框内容是否进行了更新

　　31.如果是B/S或C/S系统，在服务器端增加了一个信息，是否会影响到前台系统界面的数据，如果存在，那么在后台服务器端进行新增操作后，就要在前台客户端去查看相关的信息是否进行了更新

　　32.如果该功能存在假删除，要考虑在新增记录时，关于重复的校验，是否包括假删除数据

　　例如员工管理功能对应的删除操作是假删除，并且新增员工要求，员工姓名不能重复。

　　加入张三离职后，把张三假删除，在界面上看不到张三的信息，此时再次新增员工信息，是否能再次录入一个员工姓名为张三的？

　　33.新增界面中是否有右键快捷菜单，支持拷贝和粘贴等常见编辑功能

　　34.能否支持回车或TAB键的切换

 

 

1.1 了解需求

　　这一点，不但是功能测试，是所有测试都需要的第1步。通过需求文档，与产品经理的沟通，与开发的沟通，用户的使用习惯等各方法，了解APP的需求。

　　1.2 编写测试用例

　　当然之前可能是测试计划，测试方案的确认等。这是测试经理的主要工作。测试用例的编写，主要是建立在第1步的了解需求之后。测试用例主要包含：1用例标题；2用例数据；3测试步骤；4期望结果；5实际结果。当然还有其它的，包含测试人员，测试环境，测试工具等。

　　这里，APP测试的内容，一般包含：

　　1.2.1 APP的下载，安装，卸载。

　　能否正常下载

　　安装是否正常（有网，无网是否都正常），路径是否正确，文件或者占用手机内存大小等（如果需要）

　　是否没有得到用户允许就自启动

　　特殊情况下，比如内容不足情况下的安装。不要导致系统死机，重启，断电等严重问题。要提示用户内存不足，然后取消安装。重新安装没有问题。

　　卸载是否正常，是否将全部必要文件删除（如果需求需要，有的APP是要保留部分文件的，尤其是用户使用产生的文件）

　　直接删除文件导致不能使用，是否有提示

　　1.2.2 权限的验证

　　获取的权限是否得到用户的许可，尤其是部分重要的权限，如使用网络，使用摄像头，读取通讯录，短信，通讯记录等。

　　使用发送短信，打电话前要提示用户。

　　没有网络时，要提示用户。这里包含各页面时的提示，尤其是注册登录时，也可以放在功能模块的测试中。

　　如果得到短信权限，可能得到短信关键内容。例如接收短信验证码。

　　上面这些，其实也属于安全测试，但因为较简单，也可以当作功能测试。 至于是否存在用户数据泄漏，属于更专业的安全测试。

　　1.2.3 UI界面的验证

　　各界面是否需要需求，以需求文档和用户习惯为准。

　　1.2.4 各功能模块的验证

　　一般的功能模块包含：注册，登录，个人中心，各相应功能。。。

　　1.2.5 注册登录的通用的重要测试点：

　　没有网络时的提示

　　登录后，直接进入个人中心，或者是首页

　　密码的验证，密码的保存（是否加密保存在手机中），密码的长度，错误的提示，找回密码，密码最多错误次数的限制及后续处理逻辑（多久后或者怎么操作后可以重新登录）。

　　是否允许多设备的登陆，台式机和手机的同时登录，多台手机的同时登录

　　登录后，系统是否正确处理（个人信息是否正确，用户权限是否正确）

　　登录超时的处理

　　一般现在没有注销功能，若有，注销后是否能重新注册，且信息是否处理正确（新用户不受原用户信息的影响）

　　1.2.6 运行APP的重要点有：

　　应用前后台的切换，是否崩溃，是否能正常使用（时间短，正常使用；时间长了，相当于重新打开应用），是否能正常接收新数据

　　锁屏解屏对应用的影响，是否能正常接收新数据。

　　有电话进来后，再使用APP，功能是否正常。

　　关闭APP后再打开APP，是否正常

　　对于有数据交换的页面，每个页面都要进行前后台切换，锁屏触屏，电话接入等测试，因为这种页面最易出问题。

　　1.2.7 免登录功能

　　关闭APP后，再重新打开，是否免登录

　　切换登录用户，用户信息是否更新

　　修改密码后，是下次登录或者开户时校验新密码，还是本次登录要马上退出重新登录？

　　1.2.8 数据更新

　　哪些页面的数据是自动更新，哪些手动更新

　　前后台切换时，数据是否更新

　　哪些数据是实时从服务端请求，哪些缓存到本地

　　1.2.9 离线浏览

　　是否支持离线浏览？

　　支持离线时，前后台切换或者锁屏触屏后，是否都能浏览本地信息？

　　手动刷新时，是否有对连接网络的提示？

　　1.2.10 APP更新

　　打开老版本时，是否有新版本的更新提示

　　是否强制升级

　　不删除老版本情况下，直接更新，是否正常，更新后，是否能正常使用

　　1.2.11 相机使用

　　专门提到相机，是因为相机使用频繁。而照相质量，用户也很在意。所以当APP调用相机时，功能是否正常，质量是否可靠，也要多次测试。

　　1.2.12 消息推送

　　用户接受消息推送时，是否能正常接收各类消息？

　　不打开应用时，能否接收消息

　　打开应用时，能否接收消息

　　登录与不登录情况下，接收消息是否有区别（其实这些需求中都要明确，才能针对性展开测试）

　　精确推送，是否只推送给指定用户

　　1.2.13 兼容性测试

　　兼容性测试，严格来说不是功能测试。但这里功能测试，只是与性能测试，专业的安全测试区分后，笼统地称其它测试全为功能测试。

　　包括设备的兼容性测试，及网络的兼容性测试。

　　设备包括，不同品牌，不同系统（miui等）的手机，不同版本的android， ios， 不同屏幕大小的手机。

　　网络包括，WIFI,各种制式的3G, 各种制式的4G

　　对http和https分别适应，这点是以前没考虑到的。在星巴克等场所，需要输入用户名和密码才能上网，这样的网络通常是https。

1、单元测试的内容

　　(1) 模块接口测试

　　* 在单元测试的开始，应对通过被测模块的数据流进行测试。测试项目包括：

　　– 调用本模块的输入参数是否正确；

　　– 本模块调用子模块时输入给子模块的参数是否正确；

　　– 全局量的定义在各模块中是否一致

　　* 在做内外存交换时要考虑：

　　– 文件属性是否正确；

　　– OPEN与CLOSE语句是否正确；

　　– 缓冲区容量与记录长度是否匹配；

　　– 在进行读写操作之前是否打开了文件；

　　– 在结束文件处理时是否关闭了文件；

　　– 正文书写/输入错误，

　　– I/O错误是否检查并做了处理。

　　(2) 局部数据结构测试

　　* 不正确或不一致的数据类型说明

　　* 使用尚未赋值或尚未初始化的变量

　　* 错误的初始值或错误的缺省值

　　* 变量名拼写错或书写错

　　* 不一致的数据类型

　　* 全局数据对模块的影响

　　(3) 路径测试

　　* 选择适当的测试用例，对模块中重要的执行路径进行测试。

　　* 应当设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。

　　* 对基本执行路径和循环进行测试可以发现大量的路径错误。

　　(4) 错误处理测试

　　* 出错的描述是否难以理解

　　* 出错的描述是否能够对错误定位

　　* 显示的错误与实际的错误是否相符

　　* 对错误条件的处理正确与否

　　* 在对错误进行处理之前，错误条件是否已经引起系统的干预等

　　(5) 边界测试

　　* 注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。对这些地方要仔细地选择测试用例，认真加以测试。

　　* 如果对模块运行时间有要求的话，还要专门进行关键路径测试，以确定最坏情况下和平均意义下影响模块运行时间的因素

　2、 进行有效性测试（黑盒测试）

　　* 有效性测试是在模拟的环境 (可能就是开发的环境) 下，运用黑盒测试的方法，验证被测软件是否满足需求规格说明书列出的需求。

　　* 首先制定测试计划，规定要做测试的种类。还需要制定一组测试步骤，描述具体的测试用例。

　　* 通过实施预定的测试计划和测试步骤，确定

　　– 软件的特性是否与需求相符；

　　– 所有的文档都是正确且便于使用；

　　– 同时，对其它软件需求，例如可移植性、兼容性、出错自动恢复、可维护性等，也都要进行测试

　　* 在全部软件测试的测试用例运行完后，所有的测试结果可以分为两类：

　　– 测试结果与预期的结果相符。这说明软件的这部分功能或性能特征与需求规格说明书相符合，从而这部分程序被接受。

　　– 测试结果与预期的结果不符。这说明软件的这部分功能或性能特征与需求规格说明不一致，因此要为它提交一份问题报告