测试常遇到的BUG

测试人员经常发现的bug：

UI测试：

1、字体颜色、大小、对齐方式（根据字段的性质确定）、加粗的一致性问题

2、文本框、按钮、滚动条、列表等控件的大小、对齐、位置的一致性问题

3、所有新增、修改、查看页面加上页面说明（如：XXX新增、XXX编辑、XXX查看等说明字样），（弹出的）界面要有标题，标题与内容要一致

4、不同界面显示相同字段的一致性（如新增界面、编辑界面、查看页面）

5、输入框内有默认提示文字，则是当输入框获得焦点后文字就消失，还是用户输入文字后提示文字才消失…

6、所有弹出窗口尽量居中显示

7、信息列表中如果某个字段显示过长用“…”或者分行显示

8、对于带有单位的字段，需要字段的标签后面添加如下内容：“（单位）”

9、必填项一律在字段名称前用*表示

10、Icon用错、用混的问题

11、在不同浏览器或者不同分辨率下网页显示的效果和状态，兼容性问题

功能测试：

1、字段需要做校验，如果校验不对需要在处理之前要有相关的提示信息

（1） 长度校验
（2） 数字、字母、日期等等的类型校验
（3） 范围的校验

2、点选或者下拉选择的界面，如果一旦选择完了无法回到不选择的情况，尽量加上“清除”功能按钮，有级联关系的下拉框，级联关系正确

3、必填字段没有填、勾选的地方没有勾选、新增、修改、删除等等操作，提示的文案应该和操作场景匹配（尽量是产品给个文案清单，而不是开发自定义提示文案）

4、某些按钮在特定的状态下的状态（如置灰）

5、页面跳转是否正确，跳转的title是否正确（跳转方式是另开页面还是本页切换）

6、弹出的弹框或者弹窗是否和触发条件匹配，弹框的位置及显示时间

7、重复提交，任何按钮在提交以后，都要屏蔽再次提交的功能。否则会出现重复提交的问题，相同数据会在数据库里出现多次，而造成数据混乱

8、当有数据敏感性需求时，需要对相应的敏感数据进行加密

9、异常信息，当页面出错时，页面会抛出异常或者sql异常语句

10、列表的顺序排列应该统一（如按照时间倒序排列、数量排序等）

11、当页面加载数据比较大的情况下，加载较慢时，是否有相关提示画面、文案

12、自动计算的字段要随着别的字段修改更新（如单价变后，金额也变）

13、按钮的功能（提交是否可以提交，返回是否可以返回）

14、页面数据更新后是否会刷新（新增、删除后，页面数据是否会刷新）

15、需要考虑删除的关联性，即删除时有关联关系时无法删除或者删除时需要同时删除其关联的某些内容

16、界面只读的时候（查询、统计、导入）等，应该不能编辑

17、查询是否支持模糊搜索，查询条件是否有依赖关系，查询条件切换后是否正确

18、分页bug，页面切换至其他页后，数据未刷新等

19、接口类的问题，页面前端限制了长度、类型、范围，后台未做校验

开发人员产生bug或测试人员漏测的原因：

1、需求自身问题产生bug

需求不够规范，场景考虑不全，需求功能描述遗漏或描述较粗，功能没有交互描述，校验规则

2、程序自身运行的bug

程序自身报错，抛异常

3、与需求理解不一致产生的bug

就是程序本身语义没有问题，但是程序实现的需求和客户要求的需求不吻合

3、已有功能不了解产生的bug

对已有功能不了解，没有全面考虑新功能和已有功能的交互

4、自测不仔细产生bug

没有自测就直接丢给测试，或者在开发环境测试了，发新包后没有在测试环境测试，导致Reopen次数多，严重会降低项目的质量

5、自测思路局限产生bug

按照开发的逻辑去自测，导致考虑不够周全

6、新人问题产生bug

新人技术、经验、项目熟悉程度上容易产生bug

7、环境问题产生的bug

环境的部署分支、服务依赖、合代码不正确导致部署不成功，定位环境问题花费时间导致测试执行时间缩短或是bug的误产生

8、代码重构产生的bug

代码优化导致之前测试通过功能优化后测试不通过了，导致测试的项目要重新测试一遍，可能会导致延期

9、其他功能修改产生的bug或修改公共服务或组件产生的bug

修改其他bug引入更多的新bug，没有考虑到各个模块之间的交互

12、复杂性系统不可避免的bug

13、测试用例没有覆盖足够的场景或者测试用例没有执行

14、测试人员发现了bug，但没有重视或者没有及时提出来

15、需求变更，用例没有及时更新，导致原来的测试用例与现在的规格不相符合

16、测试人员验证bug后，没有对相关联的功能点进行测试，导致漏测

17、测试时间紧，导致测试不充分引起的bug

Bug的预防及改进：

1、针对需求，需要规范需求，开发和测试进行需求分析，提取需求点，在交互评审前解决掉大部分部分问题。然后再开发设计和用例设计时，由开发和测试去推动文档文档补全，进一步解决了需求文档有争议的一些点，又进一步细化了需求点。同时对于补全后的需求文档应及时更新归纳。

2、加强开发设计需求点的粒度细化，补充异常场景设计，对于测试来说，细化测试用例，比如一条用例如果含有多个场景，需要拆分成多条用例，对于开发或测试应与需求不一致产生的问题应该尽早的抛出来讨论

3、对bug较多的版本，应该进行复盘分析，展开bug回溯，分析问题并总结应对措施，在以后的版本中规避掉同类问题

4、开发加强异常场景的自测，尽量坚持质量优先原则，提供高质量的提测版本

5、对于临时介入的开发或者新人开发，可以在冒烟测试时，测试提供充足的测试用例，加大用例比例，覆盖足够多的异常场景，保证联调和冒烟自测通过

6、对于测试漏测的问题，及时将漏测的场景补充到用例库中，后续有类似的场景，也要将该类用例写进去

7、对于测试时间紧，可以将需求划分优化级，先测试优先级高的，后测试优先级低或者不重要的功能模块或者很少使用的功能模块，提出哪些测试了，哪些未测试到，将风险暴露出来

8、对于修改公共组件或者服务，不太容易评估影响范围的，可以引入接口和UI自动化，来保证服务的稳定和发现问题的时效性

总结

缺陷是不能杜绝的，缺陷发生后，我们需要学会思考，吸取经验教训，尽可能的降低缺陷的数量。