创新的源泉一般都是现实的问题。项目开发过程中有过一些典型的例子。在测试项目中，系统测试的开始时间点比较晚，这不利于及早发现系统问题。如果系统问题到了后期才被发现，那么修复的成本又高得多。那么，有没有办法使系统测试在开发过程的早期开始呢？基于现有的技术和条件，这不可能实现。在开发的中前期，系统的功能界面并不可用，只有后台的部分服务可供调用。开发服务所要提供的单元测试用例和代码是具备的。
那么，能否对单元测试的资源进行重用，把它们扩展成可以支持系统测试的资源？从可行性来看，这个方法具备了部分条件，单元测试用例从业务上可以拼装成完整的业务流程，只是没有相应的前端界面。需要进一步完善的方面包括系统测试需要更大的测试数据集，如何配合单元测试用例实现灵活的测试数据集？单元测试的用例只能满足单用户测试的需求，而系统测试则需要模拟并发场景，那么，能否把单元测试进行扩展以支持并发？基于这些考虑，测试项目组设计了一个能够基于普通单元测试用例进行并发系统测试的集成测试框架。框架具体解决了数据集的问题和用户并发的问题。有了这个新的测试框架，测试团队具备了在项目的中前期开始性能测试的能力。
可以说，创新需要建立在对本领域最新技术的深入学习及对这些技术无法满足的业务需求的充分理解基础之上。
创新可以是对实践方法的创新，也可以是对指导实践的理论的创新。对于测试工程师而言，实践创新和理论创新同样非常有价值。
1.3.4 测试的广度和深度
在设计测试方案时，可以涵盖的分支非常繁多。功能模块的操作场景可以抽象成一个树状的结构（测试场景树），对模块进行测试，相当于对这棵树进行遍历。遍历有深度和广度之分。广度遍历体现在对更多功能的涵盖，当一个功能点发生变化时，具有高广度的测试用例需要验证所有可能受影响的功能。深度遍历体现在对功能细节的深入，除了涵盖正常分支以外，还要涵盖异常分支和错误分支，把一个功能点的每种可能情况都包含在测试用例中。
面对众多选择，测试工程师必须权衡资源的投入和测试的涵盖度的矛盾。权衡的一般方法是，先确定测试的可用资源和测试方法，资源和方法确定以后，能够完成的任务数量就可以估算了。对同一个功能点的测试，每增加一个深度或广度级别，对测试资源的消耗也相应增加。这种增加的对应关系不一定是线性的，提高一个深度或广度级别，增加的相应工作量可能是一倍或接近一倍，因为需要有一个独立的子用例来关注一个分支。因此，权衡的时候得考虑种子覆盖深度和广度的提升在逻辑上是否必要，是否有业务需求。如果回答为否或一般，那么这种高投入的测试最好还是排除在测试计划之外。
与测试的覆盖相对应的重要指标是软件失败的风险。把有限的资源投放到风险最大的关键点，设计相应的测试深度和广度，测试工程师需要在矛盾中追求平衡。
割舍了测试的深度或广度，质量难免受到一定的影响，究竟如何判断是否应该割舍，是一种取舍的艺术。对于测试高手来说，有助于决策的，除了清晰的目标、丰富的经验以外，判断时的直觉也不可或缺。
1.3.5 无招胜有招
作为专业技术人员，测试工程师应该具有优秀的理性思考能力和逻辑分析能力。从前面的讲述中，不难发现理性思维对于一个优秀测试工程师的重要性。专业知识的学习、对系统和设计文档的理解、测试计划的编排和设计这一系列测试工程师涉及的主要工作任务，都需要理性思维方式来支撑。至于软件测试中最有价值的部分--发现及解决系统缺陷、测试方法的创新，理性思维的支撑依然不可或缺。然而，对于解决问题这部分，除了缜密的逻辑思考之外，对问题缘由的准确直觉可以发挥意想不到的功效。而方法创新，则对工程师的创新灵感有更高的要求。
直觉和灵感，都不属于理性思维的范畴，但对于测试高手而言，这两者至关重要。有一类原因比较复杂或很不明显的缺陷，使用通常的逻辑分析方法很难找到原因。这类问题，对于测试高手而言，直觉可以给予方向性的帮助。从问题表面来看，原因并不明显，但以往的测试经验可能会暗示问题出在某个不显眼的地方。这种寻找问题原因的方式似乎没有严格的科学依据，但是在工作中，直觉却很少看走眼。从思维的角度来看，直觉其实是右脑非逻辑性思维得到的一种输出。这也能够解释，为什么经验丰富的人，直觉通常更为可信。右脑思维的输入是人以往的经验及问题本身的表象，经过非逻辑性处理，得到的输出就是我们认为的"直觉"。人们通常觉得直觉不完全可信，是因为我们对右脑思维的方式并不完全理解，但是直觉的可信度在很多领域已经表现出来，在测试领域也不例外。我们的右脑是一个专门完成处理抽象信息处理的处理器，知识因为我们对其处理过程的不理解，因此这种方式往往没有得到重视。创新的灵感和直觉的产生方式是很类似的，也是右脑思维的产物。
无论测试新手、测试专家还是高手，其实都能完成右脑思维的过程。但是为什么测试高手能得到更多有效的直觉和创新的灵感？这正取决于输入信息的有效性。我们提到，输入的信息包括知识、经验及问题本身。知识通过学习获取，经验是实践积累得到的，而对问题本身的理解，是一种从表面现象进行抽象提取的过程。掌握的知识越多、经验越丰富、对问题的理解更深入，那么提供给非逻辑处理的输入就越有效、越准确，得到高质量输出的机会就越大。抽象思维的能力是正常人都具备的一种能力，然而，如何进行有效的抽象思维，如何激活右脑，则是一个思维方法的问题。
有一种有趣的右脑思考的方法是这样的。测试中遇到一个棘手的问题要解决，这个问题通过逻辑分析的方式找不到解决方案。这种情况下，可以尝试的方式是，把这个问题的所有表面现象和相关的技术信息画成一张发散的意识图（Mind Map）。以问题为中心，所有的相关信息向外发散。意识图使所有已知的内容都会体现在其中。明确所有内容以后，接着需要做的就是到户外走两圈，或者干脆睡一会儿，又或者直接把这个事情先给"忘"了。过些许时候，可能是一个小时，也可能是几天，问题的答案有可能在不经意的时候从脑海里蹦出来，同时带来的是一种恍然大悟的感觉。
其实这一个小时或者几天的时间，正是右脑进行"后台处理"的时间。构造意识图的过程，其实是过滤非逻辑思维的输入信息的过程，有了干净的输入，接下来就什么都不需要做了。这种方式很容易让人联想到武侠小说经常提到的一种境界--无招胜有招。非逻辑思维的结果常常以直觉或灵感的方式出现，这都是非常有价值的内容。我们说，要得到的结果越有价值，风险也会越高，因此，使用这种方法进行右脑思考之前，也要考虑到，右脑的"处理进程"可能处于不响应的状态，或者返回的结果并不理想。遇到这种情况，也许得回过头想想，当初提供的输入是不是足够有效。
思考是一种修炼，修炼可能是个艰苦的过程，而思考则可以是轻松愉快的。人最厉害的招数不在于看得见摸得着的技术，而在于看不见摸不着的想象力。思考，是一种境界。
测试既是技术，也是艺术。技术在不断变革，而艺术则更偏向于美学和哲学的范畴。技术和艺术的共同点是，在这上面的修为都不存在终点。即使成为了测试高手，在测试领域，依然还有许多值得追求的事物。随着对测试的理解认识越来越深，测试工程师可以对测试的哲学提出独创性的见解，这种见解也许是技术上的，也许是方法上的，或者是管理上的。能够提出这种见解，测试工程师已经到达了测试大师的水平了。新的技术、新的方法论和新的测试哲学的不断出现，推动着整个软件测试领域乃至信息科学领域的不断进步。
听过凯文对于测试工程师的发展的一番论述，小艾发现，在测试的专业领域上，可以做的事情还有很多。优秀的测试工程师，除了专业技能，最重要的还在于懂得如何思考。与其说解决问题的能力是不同水平的测试工程师的分野，不如说是思考的能力把不同的层次区分开来。
（未完待续）
相关链接：
