背景介绍
众所周知，软件测试不可能发现所有的缺陷，而且软件开发周期各个阶段仍然存在注入缺陷的可能，但是，有一些缺陷是可以避免却容易被忽略的，通过本篇文章我们主要谈谈笔者最近测试期间发现的一些容易忽视问题。
前端
01 浏览器“回退”和“前进”按钮
试想我们创建一个事物需要三个步骤，每一步添加完，都会先保存这一步的数据。在中间任意一步点击页面的其它按钮都会删除已经创建的部分数据，以保证数据的完整性。大部分人可能都会关注页面的按钮而很少会关注创建过程中点击浏览器“回退”按钮的情况。这样在创建中间步骤时用户根据习惯点击“回退”按钮，就可能会导致系统中存在错误的部分数据，影响系统功能。
02 js错误
在测试web系统时，浏览器最好在F12（开发者调试）模式，一方面方便查看接口的请求与响应，另一方面方便检查页面交互是否会有js错误。有些情况即使页面功能没有问题，也应该排查为什么会出现js错误。
03 修改比新增问题多
修改编辑功能一般比单独的新增、删除操作问题多，测试过程中应该多留心。
04 前端边界值测试
读者可以先看下图的两个进度条有没有什么问题，细心的同学会发现在绿色的部分显示的是白色的字，而下面的显示的是黑色的字，这样显示的原因比较明显（白色的字在白色的底是看不见的），但是大家想象下，图中第一个进度条的进度是1%或者2%是什么情况。真实情况是在1%或者2%的进度下绿色部分是不能覆盖住白色的字，到时候页面展示的可能就是个1或者2啦。
05 接口调用顺序
笔者在测试报表的时候，查询条件较多，接口返回的速度不一致。那么在切换不同的查询条件的时候，经常会出现最后查询结果是最开始的查询条件。针对返回较慢的接口一定要注意查看数据是否正确。
服务端
01 查看开发代码
测试新任务之前，至少要review下代码，不能轻易听信开发的改动点。有些服务端的改动，在前端根本看不出来。其次，最好查看开发的代码实现，现在很多项目软件架构越来越复杂，业务流程也更加的繁复，仅通过黑盒方式越来越难以控制软件质量，查看开发代码，可以帮助我们新增一些测试case，测试更充分。具体体现在下面三方面：
- 加强业务理解，发现逻辑缺失；
- 帮助开发定位问题，增加开发对QA同学的认可，提升专业性
- 学习新的技术以及架构设计；
在代码走查的时候，我们也要避免这个误区，接到测试任务沉溺于查看开发代码，以致测试时间过半才开始测试系统，最终项目延期。
个人建议在接到测试任务的时候，先进行一遍冒烟测试，熟悉业务逻辑后，针对复杂业务查看开发代码，而一些简单的增删改查我们直接查看日志中的sql即可，不用每个都去分析，挑一些看起来比较重要的，抽时间去排查、定位问题代码，这个不会花费太多的时间。
02 0与空
服务端在没有数据的情况下有时会以0填充返回结果，这是很不合理的。0与空具有不同的意义，0代表的是一个数值，说明数据值为0，最好在没有数据时以“--”等特殊符号代替，而不是以一个有具体值含义的0代替。
03 难复现的bug
任何时候发现bug再次验证没有复现的一定还是bug，可以多想想测试步骤，多试几次将bug找出来；实在不能复现的，必须如实的记录发生的问题。
关系型数据库
一般来说，测试的时候我们会验证数据从输入、转换直至存储到数据库这一流程是否正确，还会根据数据库中字段的长度验证前端输入以及接口的请求，但往往容易忽略数据库中一些特殊类型的的检查。
01 timestamp类型
关注数据库中timestamp类型的数据，校验是否确实需要将timestamp设置为根据当前时间戳更新。试想一下，假如数据表中“结束时间”字段我们设置为“根据当前时间戳更新”，然后将这张表新增一个字段，那么所有的结束时间都会更新结束时间，导致系统数据出现严重问题，用户也肯定会特别纳闷吧。
02 create_time、update_time的验证
我们会遇见这种情况，明明是插入操作，数据库却都存为更新时间，没有创建时间。也会出现这种情况，更新字段的值在每次更新却没有更改，这些常见的小问题虽然在页面显示不出，但是对排查线上问题有很大帮助，都应该关注。
03 varchar、text这类型的校验和预估
验证每个字段的类型以及长度是否合理，255长度之内的一般前后端开发都要有校验，对于text类型字段，一定要预估用户可能的数据量，尤其是那种不断追加的字段，很有可能随着时间的增长，出现越界问题。
总结
测试是一个迭代反复的过程，在这个过程中再怎么认真仔细都不为过，一定要抠住细节，精确到页面每个按钮，每个功能逻辑点，最终保障我们的产品有一个好的交付质量。
原文地址：https://www.cnblogs.com/yulia/p/8616163.html