软件测试工程师必备之软技能：结构化思维

什么是结构化思维方式？

结构化思维简单来说就是，面向问题的时候你可以通过某种结构，把它拆解成一个个你能解决的部分。

举个很常见的例子来感受一下，假如你作为一个面试官，面试的时候，让候选人思考一个淘宝购物车功能，需要怎么测试？你可能会得到很多的答案：

  比如有些候选人会回答，先添加购物车，后删除，查看数量是否正确；
  勾选购物车，看价格是否计算正确；最多可以添加几个商品等等。
  计算下优惠券能否正常使用
  ……
复制代码

这些答案，可能对，也可能不对，但是大多数时候，都是基于我们的测试经验来分析问题，不一定能保证想清而且想全了。那么如何用结构化思维来更清晰更全面的分析这样的问题？作为测试工程师，其实我们都知道，测试的分类大抵可以分为：界面测试/功能测试/性能测试/安全测试/异常测试/兼容性测试。那如果我们从测试分类上对这个测试分析进行拆解，无非就是这几个测试分类怎么测，然后在各个分类上做细化，直到不能再拆解（如下）：

以上就是一个简单的用结构化思维来分析问题的过程，我们在写测试用例或者梳理测试点的时候也可以应用，通过按测试类别进行拆解，不仅能把事情讲全，而且分析的还相对比较清楚。

由此可见，结构化思维是一种从无序到有序的思考过程，这个过程中，你可以建立一个先总后分的立体化分析方式。先看能够解决问题的关键方面，然后往下分析，从而实现从全局到局部的鸟瞰，而不仅仅拘泥在一种细节里面。而这种常见的思维方式，其实就是一张金字塔的树状图,如下：

为什么测试工程师要学习结构化思维方式？

工作中，软件测试工程师需要面对的不仅仅是能够独立承担复杂产品或者模块的测试工作，还需要不断的去横向或者纵向与不同的角色沟通交流，面对复杂项目的时候，甚至会跨角色边界进行项目管理，流程把控，客户对接等等。

比如面对同一个问题，有的人能用三句话直击要害，而有的人可能30min也说不到核心；面对一个复杂业务模块，有的人能够快速有层次的做一次测试点的分析和组织一场高效的测试用例评审，而有的人却在测试分析上归纳混乱，导致用例评审不断在拖堂……工作中这样的例子举不胜数，那这块的思维差异体现在哪里呢？最根本的原因