测试人员应该是软件项目团队中加班时间比较多的团队之一，因此强调提高测试效率是我们的追求目标。测试团队不仅面临各种计划内的测试任务，而且经常还需要面对各种突发任务，例如：突发的软件版本、用户现场突然发现的严重问题等，此时关注测试效率必然是我们的极致追求。

但是，测试时间短、测试任务重等挑战，要求测试人员提高效率和不断赶工期，往往容易忽视测试思维在测试工作中的重要作用：片面追求测试效率、忽视思维效率，也是我们不断加班的原因之一。因为缺乏思维，导致做事方法有问题，事情做不完，面对的问题越来越多。最终，我们希望找到神奇的测试工具、技术和方法来帮助自己，将大量的时间和精力花费在它们上面，但结果往往是没有解决测试过程中各种问题，反而徒增了测试工作量。这属于典型的战术上勤奋，战略上懒惰，即高估效率的重要性，而低估思维的重要性！

因此，测试过程中追求测试效率和测试思维的平衡，是每个测试人员需要思考的问题。测试贯穿于整个开发生命周期，每个测试活动都有其自身特点，测试人员在完成测试任务时同时考量效率和思维，从而推动测试工作更有效更高效更高质量的完成。

一、重复性工作提升测试效率

对于要求思考较少的每天重复性的测试工作，可以更多的追求提高测试效率，例如：每天填写测试日志，比如根据公司提供的评审检查模板，检查需求规格说明是否符合QA的要求等。通常情况下，测试过程中一些重复性工作都可以通过测试工具的支持以达到效率的提升，典型的是测试执行的自动化。配合采用时间策略，例如：将每天时间分为黄金时间、常规时间和碎片时间，不同时间处理不同类型的测试工作。再比如测试过程中采用番茄工作法：专注于一件工作、不被打扰、工作时间和休息时间相结合等手段提高效率。

但是，很多重复性工作背后，是以前期的测试思维输出为基础的，例如：测试执行的自动化，其效率和有效性依赖于前期测试分析和设计得到的测试用例，而测试用例的质量高低更体现在测试人员背后的测试思维能力。测试工作更多属于脑力劳动范畴，想要将测试用作做好，仅仅点点鼠标、机械验证需求是否正确实现，或者开发人员说什么我们就去做什么等，只能说看起来有点高效但实际没有什么技术含量，对于个人的成长并不能提供很好的提升。

因此，测试人员将目光从单纯追求提高效率，纠结每天完成了多少个测试任务，转向关注提升测试思维能力、解决测试问题、提高产品质量，关注每天有多少有价值的产出等方向，才是测试人员真正的价值所在。

二、思考性工作增强测试思维

前面提到，测试工作更多是脑力劳动的范畴，其价值更多体现在背后的测试思维能力，以及基于思维能力解决问题和输出有价值资产的能力。本小节以测试过程中的测试分析与设计为例，说明结构化思维和发散性思维能力在其中的作用。

测试用例是测试分析与设计阶段的重要输出，其质量直接影响了后续的测试执行效率和有效性。结构化思维的应用有助于提升测试分析与设计活动的质量，其核心是构建框架，把表象杂乱复杂的测试点/测试用例变得结构而有序。“问题驱动的软件测试设计”课程体现的就是结构化思维在其中的应用过程 - 自上而下的结构化构建（可以参考下面的框架图）：

1、选择框架：根据测试过程中经常面临的4大问题入手，搭建了有4个维度组成的框架，分别是基于质量模型、基于领域知识、基于规格说明、重点选择和测试执行。结构化思维中其属于搭架子的过程，常见的架子除了基于行业背景知识外，还有时间架、空间架和三角架等；

2、分层/分类：对框架中的每个维度或架子进行分层和分类。例如：针对领域知识，包含了功能交互模型和用户场景模型等。

3、继续细分：根据对测试目标和测试人员能力等因素的考虑，确定测试点的颗粒度，然后根据颗粒度要求继续对每个维度/架子进行不断详细化，直到满足要求为止；

4、检查框架：分层/分类和细化过程，需要不断检查每个层次之间是否满足MECE原则（相互独立、完全穷尽，简单地讲就是各个分类之间不重叠不遗漏）；

而在2009年开始构建“问题驱动的软件测试设计”课程时，实际采用的过程是自下而上的结构化构建。其基本过程如下：

1、罗列要点：通常通过测试团队头脑风暴的方式，尽量多的罗列可能的测试点；常用的思维工具可以是思维导图，更多的是借助其发散性思维过程；

2、归纳分类：将步骤1中得到的测试点，根据空间、时间、逻辑顺序等个方面的考量进行归纳分组。采用的思维工具也可以是思维导图或者逻辑树，借用的是其思维收敛的过程，将发散的测试点按照一定的逻辑关系归类，并对步骤1的结果进行修正和补充；

3、构建框架：经过罗列要点和归纳分类，实际上已经构建出框架。但是此时的结果更多体现的是测试团队的思考过程，但不一定是很好的展示结果的形式。因此步骤3主要是选择合适的框架展现给不同的利益相关者，方便他们的理解和使用，例如：二维矩阵图、金字塔结构、思维导图结构等；

4、检查框架：同自上而下的结构构建一样，需要检查不同层次之间的是否满足MECE原则（相互独立、完全穷尽，简单地讲就是各个分类之间不重叠不遗漏）；

通过测试分析与设计过程中不断应用结构化思维和发散性思维，持续不断进行自上而下和自下而上的结构化构建，不断完善“问题驱动的软件测试设计”体系化结构。通过公司内部的实践和外部的企业内训和公开课效果评估，可以不断提升测试人员的测试分析与设计思维能力，进而不断改进测试覆盖率、测试效率和测试有效性，并最终提升测试质量和软件产品质量。

测试分析与设计阶段假如可以得到比较系统化的测试用例，测试执行阶段是否就可以完全按照测试用例的要求进行执行了呢（更多体现的是脚本化测试的思路）？答案是否定的。假如我们将测试分析与设计的过程，更多看成是结构化构建的过程，那么测试执行过程应该是基于结构化构建基础之上，尽量多的应用发散性思维和批判性思维，并将得到的结果不断反馈到前面的结构化构建中，从而持续对测试分析、设计和执行进行优化。这也是我们在测试执行过程中经常强调的：平衡脚本化测试和探索性测试的初衷。

[本文提到的结构化思维、时间架、空间架、三角架、发散性思维、批判性思维、可视化思维、解决问题、思维导图、逻辑树等内容，将在后续的文章中陆续推出，敬请关注并欢迎大家与我对文中内容进行探讨！]