小马的测试用例那些事 缺陷报告与缺陷定位的那些事

小马 · November 22, 2018 · Last by kuale replied at November 22, 2018 · 2527 hits

大家好,我又来了,今天和大家聊一聊如何定位缺陷与报告缺陷.

高质量Bug Report的10条属性

1 Structure组织:

测试人员应该采用深思熟虑的,小心谨慎的方法执行测试,并且做详尽的记录。这样可以促使他们对测试下的系统有很好的认识。当错误发生的时候,一个有组织的测试人员能够知道最早出现问题在哪。

2 Reproduce重现:

测试人员在编写bug report之前必须在检查问题是否可重现。如果错误不可再重现,仍然应该写下来,但是必须说明问题的偶然性。一个好的处理原则就是在编写bug report之前反复尝试3次。

3 Isolate隔离:

在尝试编写bug report之前,必须试着隔离错误。可以采用改变一些变量的方法,如系统的配置,它可能可以改变错误的症状。这些信息可以为开发人员着手调试提供思路。

4 Generalize归纳:

在测试人员发现了一个已隔离的,可重现的问题后,应该对问题进行归纳。同一个问题是否出现在其他的模块或其他的地方?同一个故障是否有更加严重的问题?

5 Compare对比:

如果测试人员以前曾经验证过现在出错的测试用例,那么他就应该检查以前的测试结果以检查相同的条件是否通过以前的测试。如果是的话,那么这个问题就象是一个回归的错误。注意由于同一测试条件有可能出现在多个测试用例中,这个步骤就不仅仅只是检查一个测试用例在以前的多个结果。

6 Summarize总结:

在bug report的第一行写上错误的总结是非常关键的。测试人员要花些时间思考已发现的错误对客户有何影响。这不仅仅要求测试人员编写的报告要能够吸引读者,使和管理层的沟通清晰,还要能够帮助设置错误修复的优先级别。

7 Condense精简:

在bug report的初稿完成后,测试人员应该反复阅读它,集中剔除那些没有关系的步骤或词语。隐含的或模糊的说明和那些由于对没有任何关系的细节或者那些在重现错误过程中不需要的步骤而消磨报告欢迎程度的无穷唠叨都不是bug report的目标。

8 Disambiguate消除歧义:

测试人员在精简空话的同时或其之后随即应该再仔细检查报告是否有会产生误解的地方。测试人员应该尽量避免使用模糊的,会产生歧义的和主观的词语。目标是使用能够表述事实,清楚的,不会产生争执的词语。

9 Neutralize中立:

如文中所述,作为坏消息的传递人,和善地提交消息是一个挑战。如同所有的错误总结一样,独立的bug report在措辞方面应该保持公正。攻击开发人员,指责潜在的错误,企图诙谐或使用挖苦将引起开发人员的憎恶,并且使注意力从“提高产品质量”这个大的目标上转移开了。谨慎的测试人员只用Bug report来描述事实。

10 Review检查:

一旦测试人员感觉bug report是他能够编写的最好版本,他应该将报告再给一个或多个同行进行检查。他的同事们也应该给出一些建议,为了澄清问题不断地提问,如果适当的话,甚至可以挑战“错误成灾”的结论。在允许的时间里,测试小组应该尽可能提交最好的bug report。

缺陷报告与缺陷定位的一般框架

其实本图,是一种系统测试,也就是偏后期的测试情景下来发散出来的.这种偏后期的测试情景也是大多数公司所面临的测试过程阶段.
该图基本是按照
目前流行的B/S 和C/S 三层结构,来逐渐排查定位的.

目前无论是互联网应用还是web网站,还是各类APP 都无外乎要么是B/S 要么是C/S.

B/S 和C/S共有的,三层结构就是 :
1 前端 Broswer&Clinet (包含传统的web 和 各种PC客户端 和各种安卓 苹果APP) ;
2 服务端Server(传统的web服务 如面向业务处理的 tomcat 等 )
3 数据库DB (各种数据库 Oracle Mysql等)

那么后期的系统业务测试阶段,其实排查缺陷和定位缺陷,主要就是往以上三层上来推理,最终断定是哪一层结构的问题,那么这就涉及到缺陷类型了,那么常见的缺陷类型如上图有,
我们按照它出自的不同层可以这么划分:
1 前端 Broswer&Clinet问题: 页面脚本数据计算 页面脚本数据校验拦截过滤 页面数据显示 图形样式 浏览器参数配置 前端处理性能 前端安全问题
2 服务端Server问题: 服务接口 接口数据计算 接口数据校验拦截过滤 服务参数配置 服务处理性能 服务安全问题
3 数据库DB问题: 落地数据错误

业务功能 业务流程 需求歧义 建议意见 这四个比较宽泛,就是这4个其实属于偏业务层面的问题,非技术实现层面的问题.缺陷分类从大的角度面向开发测试生产流程来看,其实就是
业务问题和技术实现问题两大类.

那么实际各层面向的开发角色是不同的,面向各层使用的开发技术栈也是不一样的.如在该篇 功能性测试用例设计方法深入理解 以人为纲小节提到的,有前端开发 服务接口开发 和 DBA数据库开发. 那么面向不同的层的开发实现技术,我们遇到大致猜到是该层的问题了就需要用到相应技术栈的调试或分析工具来进一步定位问题.
能尽量定位到代码级别的对开发是最有益处的.

另外就是要注意上图中,"实际结果"的描述, 这个实际结果,一定要将 三层的问题 ,比如 前端的firebug 接口请求响应截图 , console控制台js调试信息, 或其他前端浏览器或app前端相关等, 服务tomcat业务处理日志,你的数据库查询SQL和查询所得内容 一并尽量齐全的写进实际结果. 你缺少任何一层的信息,都将影响到BUG的修复速度. 这样具体的Bug Report 只要你缺陷类型判断准确,准确投递给相应开发,那基本没跑了,我们做测试的就像警察和法官 , 警察讲究证据 (实际结果),法官判案也要讲(实际结果),这样开发就没跑拉,也避免了前端开发和服务接口开发互相扯皮推诿.

再说一个,大家看上图"缺陷分析定位",实际按上下顺序是排了序了,为什么要先查数据库呢? 这里边其实提到的体现了排查定位缺陷的效率问题, 也体现了一种排查问题的思路,杀猪焉用宰牛刀, "夹板思路" 先夹大黑盒,再夹小黑盒,逐渐缩小问题发生范围, 也就是三层 前端 服务 数据来夹. 就是大夹板是最大的黑盒 也就是 只管前端 和 数据库落地 的输入和输出,如果这个大夹板没问题,输入也对,落地数据也对,那就基本说明,整个处理链路是通的.

大早上,先码这么多,希望帮助到大家.如果您觉的有道理,就给个赞,收藏一下,关注下专栏.

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 12 条回复 时间 点赞

不错的分享,学习了

点赞先!

点赞666

第一次留言点赞

liuwenjie2011 回复

感谢贡献了你的第一次😂

感觉就是业务测试的逻辑

kuale 回复

是吧 "其实本图,是一种系统测试,也就是偏后期的测试情景下来发散出来的.这种偏后期的测试情景也是大多数公司所面临的测试过程阶段."

业务功能系统测试 更准确吧 .就是后期 眉毛胡子一把抓阶段,给大家一个快速测功能 定位功能问题 发生出处 和 提升找缺陷效率的一个思路

小马 回复

是的,其实现在对于大多数的公司而言,还是业务测试多一些,而QA的要求也的却是必须具备bug准确定位的能力,楼主写的还是比较详细的。

kuale 回复

QA只是要求, 大多数理解不上去,谈不到具体的和行之有效的具体可操作思路和步骤.

我只谈实效的,理论思路+步骤工具 尽量详尽.不过该文 主要是面向web测试方向的少量 ,定位调试分析工具例举的不全还.

小马 回复

其实有一点我不是很赞同,就是缺陷分析定位先查看数据库,其实对于大多数的web测试而言,我们第一个关注的点应该是它前端的报错和后端的response以及console吧。本身就是通过它页面的报错才去深入排查的,这个和数据库应该关联不大吧。。。

小马 #11 · November 22, 2018 作者
kuale 回复

呵呵 就知道 你会这样问 注意 排查"效率"问题. 先抓大夹板 前端输入 和 落地数据库的数据 覆盖好前端的输入等价边界 和 落地数据的字段类型和枚举等 这样大夹板下,最大的黑盒没问题了, 你也基本可以放心内部服务的处理或者不用关心它了. 尽快去测或者说先过其他业务功能. 快速冒烟.

这样 测试效率会提升 这种策略有风险 实际你的前端输入和落地数据 组合到位 检查很全面 实际也大的问题不会太有.

咱们有时间了, 再继续小夹板, 一定要先保证大夹板 落地数据是很关键的. 也就是传统的黑盒思路. 只不过 我们有了夹板思路了,被夹的任何一层 都可以看做黑盒,只是不同层的被测对象不一样,像接口就是我 接口用例里 总结的 接口输入 接口内部处理逻辑 和 接口输出.

比如 情景如下:
1 数据都没落地 或者数据落地字段 或 相关表都操作错了 那一定是服务接口 比较严重的问题. 然后我们才需要调试接口 和 排查前端问题 因为 数据的前两层 是 服务 和 前端.

(我们肯定要先抓大问题 再抓小问题 你上来就看接口和服务Log有点得不偿失 一定要先保证落地数据 . 实际好的测试习惯 是同时打开前端浏览器的firebug tomcat log tail -f 一下 然后准备好数据库查询sql )

2 然后抓取接口 看前端传的参数是否有误, 如果这个无误 那基本定位到服务接口 服务层问题了

3 就是 看tomcat或相关web容器的 log 来看服务业务处理到底哪里错误.

小马 回复

这样一说,好像也是这么回事,厉害了哦。可以学习一波,哈哈哈

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up