而由于公司产品的原因，大部分时间都是在做web测试。
因此，很容易因为工作重复的原因，经常会忽略一些测试要留意的地方。
以下列出几点 前后端web测试需要留意的点。
一、从界面入手。比对原型图。
从界面显示适配浏览器到 数据显示————这就是一个大家来找茬的游戏，有眼即可。
主要就是 需求评审前看一遍需求——评审时别打瞌睡，听下产品经理的设计考虑帮助理解很重要。——第一次测试时，开着原型图比对时就可以了。
二、字段取值
重点留意有多个数字需要取值的界面——比如 实缴金额、应缴金额——要特别留意前端是否取错值。
操作
1、在web界面 点击F12 使用Google自带的抓包工具，准备抓包。
2、界面点击，再次向后端发起请求——我这里示例是点击“查询”。
开始分析：
1、接口前端有没有调对？
在headers里拿获取到的url里的接口跟开发的接口文档比对，看前端是否调对接口。
（如果没有接口文档，一般也有开发的接口管理平台，比如swagger等，一般开发很少犯调错接口的错）
2、检查前端开发取值是否正确——这个是开发经常出bug的地方。
这个就要看接口文档，后端开发对字段的定义了。——哪个是应缴、哪个是实缴。
嗯，那如果应缴金额跟实缴金额的值都一样，比如都是金额 500.那怎么判断前端是否取对值？
答案——改数据库字段,（直接在Navicat手动修改、或者按业务流程在测试环境造异常缴费数据）
2.2 在linux数据库查看接口调的sql——核对数据从哪个数据库表取值——也是手动改数据校验接口返回数据取值是否正确的前提。
从接口知道要去 estate-trade 服务查看日志。
首先要知道自己要去哪个服务的日志获取查询sql——————服务的日志放的位置要问开发，同时自己也要有服务器的访问权限。
敲下Enter开始动态查看日志后，web界面再点击“查询”，重新发起查询请求。
数据库运行查询sql。顺带检查sql返回的数据是否符合业务需求+数据是从哪个数据库表查，取值是否正确的。
2.3检查数据条数是否正确——比如数据库符合业务条件的确定是28条，而不是27条或30条——这个需要直接去数据库表查下。
同时也跟web界面的数据条数比对，确定我们没有取错sql。
从sql我们知道源数据是从哪个表来的，就可以去对应哪个表该对应数据。——同时也校验后端开发接口取值没取错表。
如果实缴应缴金额一致，可以在数据库改对应数据的值。————但是一定要记得校验完成后就改回来——不然以后大概率挖坑埋自己。
总结：检查前端取值、检查前端取值、检查前端取值。不要点点看看就过了。要溯源！！！
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
