Bug背后的故事——缺陷技能提升

发表于:2018-4-13 13:21  作者:生活如同马拉松_yagua   来源:简书

字体: | 上一篇 | 下一篇 |我要投稿 | 推荐标签: Bug 软件测试管理 缺陷管理

  周六再一次参加邰晓梅老师的专业软技能培训课,软件缺陷技能,收获远超预期, 再此记录一下。
  软件中的缺陷( bug)是如何被发现
  如果别人发现一个bug, 自己却没有发现,这个是为什么?是靠运气。 如果自己发现一个bug,别人没有发现? 是运气,还是另有一番玄机? 感觉背后隐隐约约有一些思考的套路,却说不出来 抑或这份玄机只可意会不可言传? 如果有人可以将这个bug背后的故事,如何思考的链条可视化的展示出来,并且对常见思考套路归纳出来,相信对于后来学习的人将是一笔财富。 这个就是今天学到的 DDI( Debug Discovery Insight), 缺陷发现洞察。  DDI里面包含三个过程, Trigger, E&E( Exploration & Experiment) 和Test Oracle
  
T-E&E-I model
  Trigger
  针对一个特定的场景,会触发大脑的思考, 大脑会根据已有的知识信息经验,构造出用例 。多么神奇的大脑! 但是这个黑盒对于学习本身于事无补,如果刻意打开看看神奇大脑如何工作?那么刻意改造他。可惜现在达不到。但是下面的办法刻意去引导大脑,让其按照你期望的去工作。
  当与软件交互的过程中,需要关注情绪。
  比如测试有道字典的快速取词功能。 这个挺有意思,好奇那就玩一下。拍照与物体大小远近有关系。 那么联想到字体大小不同; 那么试试不同类型的字形,宋体的宽体的? 再试试大号字与小号字? 更大与更小? 合在一起呢? 再试试字体摆法,是不是水平的,斜着试试,倒立会怎么样? 圆柱上面上的字体?字符间距有关系吗? 这个字怎么颜色不同,字体颜色有关系吗?那么会有背景色干扰吗?那么有光线有关也试试? ...... 简直停不下来:)
  发现一个英译汉提示,怎么发现居然可以识别汉字?藏有彩蛋(文字不一致), 那么试试其他语言?日语, 果然可以识别,但是没有翻译出来。 原来没有做完就发布没有做完吗:) . 那试试韩语?不行,而且将韩文识别出中文?哎什么鬼? 找找有没有其他彩蛋?
  在这个过程互动过程中,是会有心情变好,千万别丢掉自己这种感觉。感觉会引导我们去更好的探索。
  分享 鲁班发明锯子的故事,据说鲁班接到一个大项目,去山里寻找木材,山路滑不小心给摔一跤差点滚下去,赶紧去抓旁边的小草,才逃过一劫好险。但是怎么手上有血? 这么小的草怎么会滑坡我粗糙的手(好奇)。仔细观察原来小草的是齿轮状的。 再看发现旁边一只虫子在大口吃草叶,虫子的牙齿也是齿轮状的。齿轮有这么厉害? 回家研究研究,后面就有了锯子的发明。 这个是好奇驱动他发明,如果忘记好奇,那么也就没有锯子发明估计也没什么事情了。
  我们常用的有哪些情绪会启发引导发现bug:
  1. 关联 (Association)
  2 矛盾 (Contradiction )
  3. 趋势( regular trend)杨辉三角规律
  4. 好奇 ( Curiosity)
  5. 惊讶 ( Unexpected)
  6. 熟悉问题( Familiar Problem)
  7. 偶然( Coincidence)
  E&E(Exploration & Experiment)
  这个有上面触发问题,很自然就到一个探索求证的过程。 大胆假设小心求证。千万别忘记,没有上面的触发,这个探索过程很难解释。
  note: 发散和关注
  在探索中发现其他的问题,克制住自己的被带偏的冲动,先记下来,待会回过头再收拾;(推广 树形笔记,不重不漏,条理清晰,同时复盘回顾的时候,帮助你重现思考的过程)
  Test Oracle
  洞察到这些一些问题, 可能是潜在的bug。 但是需要进一步验证。 其实就跟基准做比较, 基准不一样就是bug。bug本来就是期望与实际的差异。 这个过程就是Test Oracle做的事情。(为什么交Oracle,谁帮我解答一下)
  课堂上一个有意思的例子,比如有个三角形分类测试练习,输入三边,判断是一个什么三角形。 程序告诉(不等边,等腰,等边三角形), 但是与常见另外一套分类按照角度( 锐角,直角,钝角三角形分类)不同,那这个是个bug吗? 需要澄清和验证, 需要知道为什么采取这个按照边分类而不是按照角度大小分类。
  但是有哪些基准,其实Spec 里面并不会方方面面都会写到。 和自己意图, 产品行为是不是一致,同类产品比较,用户的期望, 专业知识甚至常识去做对比。
  同类产品比较
  自己意图
  一致性。同一款产品,其行为前后是不是一致?
  感觉这三部分都可以刻意练习,来提高测试技能。比如下面两个方式
  1. 多个人同时去测试一个东西,去讨论一下别人发现自己没有发现的bug。看看别人是怎么思考的? 反思自己问什么没有想到?思考的时候为什么漏掉 是哪方面欠缺? 如何避免下一次漏掉同样的问题?比如课堂上用有道词典的拍照取词功能作为被测对象。或者下面这个刻意练习测试的网站,你会发现惊喜。
  http://www.developsense.com/triangle/triangle.html
  缺陷深入测试(DFT-defect followup Test)
  发现一个bug,心情愉悦,就大功告成结束吗? 如果到此为止,如果没有经验总结,那么就是浪费一次扩大战果的机会。 下面介绍 RIM原则,帮助你更好做到。
  RIM分别是 可重现Reproduce , 隔离Isolation, 最大化Maximum .
  Reproduce: 这个是最基本的。 但是如果出现发现不了的bug,请留意不要轻易放过。 需要对于这个bug保持一定敏感度。 可以查看log等。同时这一步将自己的干扰因素去除掉。
  Isolation: 专业测试体现自己地方。 将bug中无关紧要的东西去除掉,尽可能简化步骤直达bug。这个需要假设和验证。
  Maximum: 最大化这bug的影响。 从用户角度上来看,影响是什么?不同因素组合起来将会发生什么? 经常bug会扎堆,可以确认范围,扩大战果。
  最后就是记录 一个bug,这个一个水到渠成的过程。
  Bug 的描述(DD)
  bug的描述,一般就是:Setup环境 、steps步骤、result结果、expect期望。 bug 就是期望与实际的差异。
  DD里面同样用了一个结构化的描述 G-W-D-T-O-C. (Given-When-Due to - Then-Object-Cause). 信息更足一些。
  缺陷分析(T-RCA, Tai-Root Cause Anlysis)
  缺陷发现,如果不加总结回顾,同样的问题还会继续犯下去。 那么从软件整个生命周期里面来看如何做到缺陷分析。缺陷分析如何用10w + 5 hat框架, 同时是一个很好的引导方式。让bug相关的人一块尝试发现这个bug的来龙去脉,去看这个bug的全景图,从技术流程知识团队去改进避免,同一个地方摔两次。
  
10w + 5 hat
  从左到右, 第一what,回答bug的背景信息,产品信息,简而言之bug及其上下文。第二个Why? bug 为什么产生? 三个where, bug是哪里发现的? bug是哪里引进来? 不是应该在哪里被发现?对于where,在继续问why? 以及回答实践中做如何避免。 这个之前做过,但是还是没有这么系统的总结清楚。
  最后回顾一下整天内容:
  
缺陷技能全景图

上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。

【直播预售】接口测试行业大佬带你从青铜上王者>>立即查看

评 论

论坛新帖

顶部 底部


建议使用IE 6.0以上浏览器,800×600以上分辨率,法律顾问:上海瀛东律师事务所 张楠律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2018, 沪ICP备05003035号
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪公网安备 31010102002173号

51Testing官方微信

51Testing官方微博

扫一扫 测试知识全知道