大家好,我又来了,今天和大家聊一聊如何定位缺陷与报告缺陷.
测试人员应该采用深思熟虑的，小心谨慎的方法执行测试，并且做详尽的记录。这样可以促使他们对测试下的系统有很好的认识。当错误发生的时候，一个有组织的测试人员能够知道最早出现问题在哪。
测试人员在编写 bug report 之前必须在检查问题是否可重现。如果错误不可再重现，仍然应该写下来，但是必须说明问题的偶然性。一个好的处理原则就是在编写 bug report 之前反复尝试 3 次。
在尝试编写 bug report 之前，必须试着隔离错误。可以采用改变一些变量的方法，如系统的配置，它可能可以改变错误的症状。这些信息可以为开发人员着手调试提供思路。
在测试人员发现了一个已隔离的，可重现的问题后，应该对问题进行归纳。同一个问题是否出现在其他的模块或其他的地方？同一个故障是否有更加严重的问题？
如果测试人员以前曾经验证过现在出错的测试用例，那么他就应该检查以前的测试结果以检查相同的条件是否通过以前的测试。如果是的话，那么这个问题就象是一个回归的错误。注意由于同一测试条件有可能出现在多个测试用例中，这个步骤就不仅仅只是检查一个测试用例在以前的多个结果。
在 bug report 的第一行写上错误的总结是非常关键的。测试人员要花些时间思考已发现的错误对客户有何影响。这不仅仅要求测试人员编写的报告要能够吸引读者，使和管理层的沟通清晰，还要能够帮助设置错误修复的优先级别。
在 bug report 的初稿完成后，测试人员应该反复阅读它，集中剔除那些没有关系的步骤或词语。隐含的或模糊的说明和那些由于对没有任何关系的细节或者那些在重现错误过程中不需要的步骤而消磨报告欢迎程度的无穷唠叨都不是 bug report 的目标。
测试人员在精简空话的同时或其之后随即应该再仔细检查报告是否有会产生误解的地方。测试人员应该尽量避免使用模糊的，会产生歧义的和主观的词语。目标是使用能够表述事实，清楚的，不会产生争执的词语。
如文中所述，作为坏消息的传递人，和善地提交消息是一个挑战。如同所有的错误总结一样，独立的 bug report 在措辞方面应该保持公正。攻击开发人员，指责潜在的错误，企图诙谐或使用挖苦将引起开发人员的憎恶，并且使注意力从 “提高产品质量” 这个大的目标上转移开了。谨慎的测试人员只用 Bug report 来描述事实。
一旦测试人员感觉 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 只要你缺陷类型判断准确,准确投递给相应开发,那基本没跑了,我们做测试的就像警察和法官 , 警察讲究证据 (实际结果),法官判案也要讲 (实际结果),这样开发就没跑拉,也避免了前端开发和服务接口开发互相扯皮推诿.
再说一个,大家看上图"缺陷分析定位",实际按上下顺序是排了序了,为什么要先查数据库呢? 这里边其实提到的体现了排查定位缺陷的效率问题, 也体现了一种排查问题的思路,杀猪焉用宰牛刀, "夹板思路" 先夹大黑盒,再夹小黑盒,逐渐缩小问题发生范围, 也就是三层 前端 服务 数据来夹. 就是大夹板是最大的黑盒 也就是 只管前端 和 数据库落地 的输入和输出,如果这个大夹板没问题,输入也对,落地数据也对,那就基本说明,整个处理链路是通的.
大早上,先码这么多,希望帮助到大家.如果您觉的有道理,就给个赞,收藏一下,关注下专栏.
