周六再一次参加邰晓梅老师的专业软技能培训课，软件缺陷技能，收获远超预期， 再此记录一下。
软件中的缺陷（ bug）是如何被发现
如果别人发现一个bug， 自己却没有发现，这个是为什么？是靠运气。 如果自己发现一个bug，别人没有发现？ 是运气，还是另有一番玄机？ 感觉背后隐隐约约有一些思考的套路，却说不出来 抑或这份玄机只可意会不可言传？ 如果有人可以将这个bug背后的故事，如何思考的链条可视化的展示出来，并且对常见思考套路归纳出来，相信对于后来学习的人将是一笔财富。 这个就是今天学到的 DDI（ Debug Discovery Insight）， 缺陷发现洞察。 DDI里面包含三个过程， Trigger, E&E( Exploration & Experiment) 和Test Oracle。
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的全景图，从技术流程知识团队去改进避免，同一个地方摔两次。
从左到右， 第一what，回答bug的背景信息，产品信息，简而言之bug及其上下文。第二个Why？ bug 为什么产生？ 三个where， bug是哪里发现的？ bug是哪里引进来？ 不是应该在哪里被发现？对于where，在继续问why？ 以及回答实践中做如何避免。 这个之前做过，但是还是没有这么系统的总结清楚。
最后回顾一下整天内容：
留下晓梅老师一张靓照，再次感谢:)