[测试十年]思维模式（二）：鱼骨图分析法

前言

回顾之前<<【测试十年】搜狗测试五六年：思维模式(一)>>一文中，我们介绍了结构化思维的大致思想，它一般包括以下步骤：理解问题-->拆分问题-->得到解决方案。本篇我们将分享第二步拆分问题中所使用的一个工具：鱼骨图分析法。

鱼骨图分析法

1.鱼骨图分析法的定义. 一般情况下，遇到问题时我们可以通过这五个要素来进行分析： 人：造成问题产生的人为要素。 机：指对问题有影响的所有软、硬件条件。 料：基础的准备以及物料。 法：指与问题相关的方式与方法。 环：内、外部环境因素的影响。 以上每项细分下来还有更多的原因，整体看起来就像是鱼骨头。

2.鱼骨图分析法的应用步骤：

1. 明确要解决的问题，并把问题写在鱼骨的头上。
2. 将5M的各个方面画在鱼脊上，形成鱼骨的大骨。
3. 召集同事进行头脑风暴，针对5M的各个方面，讨论导致问题出现的所有可能原因，形成鱼骨的小骨。
4. 将找出的各要素进行归类、整理，明确其从属关系。
5. 小组讨论，分别针对各个方面，筛选、总结出相对重要的因素。
6. 归纳问题的根本原因，寻找相应的解决方案。

应用案例

一天，组内会议上，大熊、小明和娜娜在讨论组内近期遇到的一些问题。

大熊：最近我们的测试中出现了几个问题发现晚的问题，比如在输入法的打字速度相比以前有明显卡顿，这个问题在临上线前才发现。这个问题大家怎么看？

小明：这确实是问题，之前我们在测试过程中其实也感受到了打字速度有卡顿的情况，但是因为项目任务紧没有深入去追查问题，以后我们会提升对问题的敏感度。

大熊：只是提升敏感度并不能从根上解决问题，我们还是需要对问题的本质原因进行分析探求。

娜娜：我认为是回归测试不足导致的。比如，我们每个版本都会增加许多新的功能，大家的精力都集中在新增功能以及相关联功能的测试验证上，所以对打字速度这种基础性的回归测试关注不够。

小明：我倒认为不是回归测试不足，而是回归测试太晚了。比如我们现在的流程是：开发实现、开发提测、一轮测试、二轮测试、回归测试、灰度上线，正式发版上线，而打字速度的测试是在回归测试阶段才进行的，有点偏晚了。

大熊：参照A项目组的持续集成测试流程，我们可以复用开展吗？

娜娜：持续集成的测试流程搭建还是有一定的困难。我们之前也向其他团队取过经，但是在落地实施中遇到了不少问题，使得这个工作没有开展起来。

大熊：这样吧，大家看看手里的资料，里面详细介绍了鱼骨图分析法。我想让大家先了解一下这种分析法，然后运用这种方法一起寻找持续集成测试流程搭建的困难。

大熊：现在我们来实践一下鱼骨图分析法，我们先将人、机、料、法、环画在鱼骨的大骨上。接下来，我们首先从"机"的角度来分析。大家认为在软硬件环境的因素方面，有哪些原因导致这个流程开展不起来呢？

小明：我认为在机的因素方面大致分为两类：开发环节和测试环节。

大熊：那么在开发环节和测试环节又分为哪些具体原因呢？

小明：在开发环节所使用的自动编译打包系统扩展性较差，如果要扩展增加自动化回归功能的话，需要额外对系统进行开发修改；在测试环节，因为现有的接口测试平台与自动编译打包系统是两套不同的系统，两者之间目前没有交互过程。

大熊：那么我们是不是可以改用Jenkins系统进行自动编译、构建、部署和测试呢？

小明：可以是可以，但是需要重新梳理自动编译打包过程中的工作，成本较大。如果改为在现有Build系统上进行功能扩展，成本相对较低。

大熊：好的，我们将问题和解决方案记录下来，再看下下一个环节有哪些问题吧。

…..…..

经过大家积极的讨论之后，形成了对于"持续集成测试流程搭建困难"的整体分析。

基于对上述问题的分析，大熊等人形成了对应重点问题的解决方案。

附录

Visio中的鱼骨图使用方法：

• 打开Visio，在左侧导航栏中找到"商务"，选择因果图形状。

• 添加"效果"

• 添加分类

• 添加每个问题的原因

• 添加整个鱼骨图框架

结束语

“有一个相关的道理非常重要，那就是你们必须坚持终身学习。如果不终身学习，你们将不会取得很高的成就。我不断地看到有些人在生活中越过越好，他们不是最聪明的，甚至不是最勤奋的，但他们是学习机器，他们每天夜里睡觉时都比那天早晨聪明一点点。 ”

--查理芒格