BUG背后的故事——缺陷技能提升如果别人发现一个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。看看别人是怎么思考的？反思自己问什么没有想到？思考的时候为什么漏掉是哪方面欠缺？如何避免下一次漏掉同样的问题？比如课堂上用有道词典的拍照取词功能作为被测对象。

　缺陷深入测试（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？以及回答实践中做如何避免。这个之前做过，但是还是没有这么系统的总结清楚。

　最后回顾一下整天内容：

缺陷技能全景图