软件测试的问题定位分析思路

定位分析思路

软件开发流程

一，前言

避免被开发忽悠，节省与开发扯皮

测试人反馈一个bug之后，开发（前端/后端）的回应？

能不能复现？有没有验证？再测一遍？脏数据？刷新一下？浏览器的问题？清一下缓存（前端）？重启一下（后端）？版本迭代/更新成功了没有？插件/补丁打上去了没有？地址链接发我，我看一下？网络抖动问题？环境问题？导致了什么现象？看下日志？截图发我？配置配错了，确认下？

是不是数据库字段没加？。。。。

前端的问题？后端的问题？

前端和后端，反复推让，相互扯皮，没完没了，不仅浪费了bug的修复时间，还浪费了测试的时间，在敏捷开发流程，测试的时间本来就是不够的。

二，为什么要做这件事？

1，避免被开发忽悠

2，提高bug修复的效率

3，精准定位bug，更显专业性以及协作性，让开发更加信任你，觉得你很靠谱

4，降低误报bug率，原因明确

5，对产品更加熟悉

三，常见的bug各种类型

1，环境问题，配置问题，

2，网络抖动问题，

3，浏览器问题，缓存问题

4，代码错误

5，布局，样式，字体问题

6，前端没有传入参数

7，数据库问题

8，脏数据问题

9，版本问题

四，测试人常见的bug

后端开发合并前端代码，打包提测后，进行冒烟测试，观察分析提测的版本能否走业务流程，是否有致命，严重的问题，或者是一眼就能看出的问题，或者是影响测试的问题，等等…出现类似的问题都可以直接将包打回开发。

页面打不开？

验证链接是否准确？
同一个环境（配置没有修改）的情况下，可能打包出现问题？验证方式，替换上一个版本的包，如果可以打开页面，说明是程序的问题；
检查网络是否正常？有没有使用代理？换台电脑试试？ping www.baidu.com
浏览器的问题？程序的浏览器兼容性
换个浏览器试试？谷歌/火狐/sougou/360极速
浏览器版本问题
浏览器能不能联网？访问百度试试

页面出现冗余的空行，字体呈方体（与上一个版本不同），布局出现错乱？

乱码，后端合并代码打包的时候没有进行转码

核心业务流程或者新功能出现50X，404得错误状态码？

这里可能考虑到留存的问题，要保证用户得沾粘性，就必须要保证迭代后，旧功能以及核心业务流程功能要能走通，不要出现一迭代版本后，不仅新功能出现问题，旧版本可以走通的功能现在不行了。所以这里旧体现出回归测试的重要性。
503，504是后端接口层面的问题，也有可能是前端没有将参数传到API导致的；可以利用浏览器的开发者工具F12或者是其他抓包工具（比如：fiddler,charles）观察，首先排除掉前端没有传入参数的问题，剩下基本上就是后端的问题，可以直接喊后端开发过来看；

产生脏数据？

用户删除数据时，可能网络出现抖动，或者丢包等异常现象，导致数据库的数据已经成功删除了，但是redis缓存的key-value还存在，这种情况就有可能产生脏数据；
还有一种情况，当你在进行删除操作得时候，MQ出现异常，没有订阅到消息，导致当时删除成功得假象，实际上数据库得数据并没有删除，刷新页面后，数据还是存在得；

前端要求要清除浏览器得缓存，这种情况可能是前端没有加版本号导致的；

后端开发说，bug已经修复或者是新需求已经做好，但是我们看到的表象是没有修复或者是新功能并不存在？

这种情况，首先要检查一下，更新版本时，替换的是整包还是插件（部分文件，或许是class后缀的文件），确认版本包package的替换时间，或者是确认插件替换的时间，重要的是替换后，还要进行重启。而且有些程序存在特殊性，比如：部分jar程序存在关联性，数据需要同步就必须要多个节点同时启动，才会生效。还要确认是否有配置需要修改？需不需要新增数据库表或者字段？如果确认后，发现表象还是之前版本后，就需要开发的协助。

在进行操作的过程中，出现一些相对人性化的错误提示？

这些提示一版都是开发自己写的，少数是按文档规范写的，具体是说明什么问题还得找开发，当然了，不能仅仅反馈个错误提示就行，还得监控程序得日志，日志要学会去看，看不懂才找开发；

五，如何定义一个bug

划分一个bug的级别

bug等级主要分为致命、严重、一般、轻微或者建议四个等级；

1.致命错误：系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定、价值较高功能异常（比如与金钱相关的功能）

具体基本上可分为：

（1）严重花屏

（2）内存泄漏

（3）安全问题

（4）用户权限问题

（5）网页无法正常打开

（6）严重的数值计算错误

（7）功能设计与需求严重不符

（8）系统崩溃/死机/冻结/死循环

（9）模块无法启动、调用或异常退出

（10）数据库数据丢失或破坏、数据库连接错误、发生死锁

（11）重要的一级菜单功能不能使用、无法登录、无法正常退出，程序重启、自动退出，关联程序间调用冲突

2.严重错误：影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性

具体基本上可分为：

（1）功能未实现

（2）系统刷新错误

（3）数值计算错误

（4）语音或数据通讯错误

（5）功能错误、主要功能丧失、基本模块缺失

（6）系统所提供的功能或服务受明显的影响（接口错误）

3.一般错误：界面、性能缺陷

具体基本上可分为：

（1）操作界面错误（包括数据窗口内列名定义、含义是否一致）

（2）边界条件下错误

（3）提示信息错误（包括未给出信息、信息提示错误等）

（4）长时间操作无进度提示（如导出功能）

（5）系统未优化（性能问题）

（6）光标跳转设置不好，鼠标（光标）定位错误

（7）涉及系统以及用户隐私数据没有处理或者隐藏（如密码没有隐藏化）

（8）代码在页面显示出来

4、轻微错误（建议性问题）：易用性

具体基本上可分为：

（1）界面格式等不规范

（2）页面显示重叠

（3）辅助说明描述不清楚

（4）功能描述不清楚

（5）操作时未给用户提示（如修改成功、删除成功、添加成功、加载中等）

（6）可输入区域和只读区域没有明显的区分标志（一般只读区域颜色设置较暗）

（7）个别不影响产品理解的错别字

（8）文字排列不整齐等一些小问题

（9）输入框没有限制字符数、符号等约束条件（如电话号码字段只能输入纯数字、姓名限制字符数为3-4位、身份证号码严格标准化约束）

bug状态

1.待处理：测试人员或者用户发现并待确认的问题

2.已确认：经测试人员及开发人员讨论后确认是BUG，并提交到缺陷管理系统（如禅道）

3.已解决：开发人员修复BUG，待测试人员验证

4.已验证：测试人员验证问题通过

5.再激活：经测试，BUG未修复成功

6.重复出现：上一个版本修复的BUG，这个版本又出现

7.设计如此：与开发人员和产品沟通后，确认不是BUG，或者建议，但是开发人员不采纳

8.暂不处理：当前版本不修改，后续版本再考虑（与开发人员确定修改日期）

处理bug的流程

bug权重分配

1.一些测试leader对TE工作评估的主要依据，发现的bug数，如果仅仅是bug数并不科学，因为根据bug等级的划分，有些bug甚至没有经确认或者重复，甚至有可能出现滥竽充数的现象也说不定。

2.如果按照bug等级划分来分配权重的话，明显更加科学；

BUG等级	权重
致命	2
严重	1
一般	0.5
轻微/建议	0.25

例如，我发现了2个致命的bug，4个提示的bug，3个建议的bug，最后的成绩=22+40.5+3*0.25

3.个人觉得，一些致命的bug或者是严重的bug（比如：一些影响到测试工作的bug等），相对比较容易发现，这些都是不具思考性的错误，为什么？因为发现这些问题，不用问，必须改的bug？难道不是这样吗？在测试日常中最难处理反而是一些建议性问题，往往更具有思考性，比如说用户需求没有说明，但是我觉得做了更能体现出用户体验的易用性，然而需求文档上没有，那就不是必须要做的，开发可以选择不做，这样开发和测试就有了争议了，那就捅到产品那里去吧。。。对于一些建议性问题往往是花费更多的时间的。

BUG等级	权重
致命	2
严重	1
一般	0.5
轻微/建议	0.25

注意：如果产品比较成熟的话第三种比较合适，如果产品还停留在开发基本功能的情况下第二种相对比较符合。

六，总结

在测试过程中，更加精准的定位问题的原因，不仅要熟悉业务（不明确或者没有需求文档要多问产品经理），而且还要熟悉系统架构的链路及其组成的工作原理，在其中起到什么作用等等。