一、记录背景
如果只进行单纯功能上的点点点很难保证功能的正确性，针对这点记录了下个人的测试观点；
先百度了下功能测试的定义：
上面的功能测试，基本上通过点点点加上基本的数据来验证功能是否正常；
我从自己的观点记录一下我个人理解的：
1、首页，我们要知道现有软件功能的基本运行方式和常见的一些工具；
2、比较常见有LMAP结构的：Liunx(OS)、Mysql(数据库)、Apache(服务)、PHP(前端展示)
3、现在的软件开发，基本方向都是走的高内聚、低偶合的方式；模块化、微服务的架子；
二、例举
（这里我举个 前后端分离 的栗子来描述下我个人的功能观点吧）
1、画出基本结构图：
基本的操作流程：就是用户在前端页面操作，前端发送请求到服务端，服务端处理请求再返回结果给前端，前端再展示给用户；
通俗点的例子：老板要看库存信息，那么具体查看的流程如下(前后端交互)；
老板(用户) 向 助理(前端)说我要看下库存信息，助理(前端) 把这个信息告诉 记账的人(服务) 老板要看库存信息；记账的人(服务) 向 仓管(数据库) 查看库存信息；仓管把库存信息返回给记账的人，记账的人把这个库存信息再给到助理，老板就可以看到助理给的库存信息了；
2、拆分功能内容：
前侧：接收用户操作，发送用户操作的请求到后侧，获取后侧的内容展示给用户；
后侧：后端接收前端的请求，去数据库操作并获取到结果，把结果发送给前端展示；
3、验证拆分的功能内容：
验证前端展示；
验证后端取值；
验证数据正确性；
4、具体操作流程：
工具：APP/PC 的抓包工具 Charles/F12；数据库连接工具：Navicat；接口文档管理工具：小幺鸡；
参照物：需求文档/测试用例、接口文档、表注释；
验证前端展示：通过需求文档/测试用例 结合 接口文档和抓包工具来核对各数据展示是否正确；
验证后端展示：通过接口文档 结合 抓包工具和数据库来核对各数据的取值是否正确；
验证数据：通过需求文档 结合 表注释，验证数据是否正确(有计算的要验证计算结果)；
三、附操作截图
前端验证： PC浏览器抓包(F12) - 红框内就是核对的内容（验证传参及展示是否正确）；
结合接口文档，核对前端数据是否正确展示（接口文档有问题的需要开发改）
保持三点一致（需求/接口/展示）
后端验证： 数据库 - 结合接口文档和表注释来验证后端取值是否正确(有计算的要验证计算结果)；
PS：SQL可以自写，也可以找开发同学要；核对下SQL，太难了就算了，别核对了，伤脑壳；
APP和PC的验证原理都差不多，差距在工具和手段上；
这种方法是我个人认为确保软件功能正确的一种效率比较高的方法，我也一直采用这种方法在验证；
另外，定位问题，也可以反向操作。临近问题源来追根溯源，分节点定位；比直接找日志可能会好点；
功能上有问题就直接找日志个人觉得有点片面了，何况还不一定会有对应日志；
思想语录：精准，就是力量；
个人观点，仅供参考；如有雷同，纯属巧合；
版本历史
| 版本 | 更新时间 | 变更内容 | 其他 | 备注 |
|---|---|---|---|---|
| V1.0 | 2022011316 | 新增文档 | - | - |
| V1.1 | 2022011410 | 新增目录 | - | - |
1万+
