十天内，从北京到福州、再到深圳，完成了三场测试思维训练课程，从测试的基本思维到系统性思维、分析性思维（包括批判性思维）和发散性思维的训练，虽然期间还讨论了探索式测试和自动化测试。这也说明不少测试同仁渴望得到这方面训练，因为人类已经进入一个智能的时代，不会思维就可能很快被这个社会所淘汰  不仅仅是一般简单机械的劳动会被机器所代替，而且越来越复杂的工作也会被机器人所代替，未来留给人类的工作空间会越来越小，最终可能只剩下那些需要强大的思维能力才能完成的工作。

今天就和大家谈谈软件测试的系统性思维，为什么先讨论这个问题呢？因为有的同学眼睛、视力丝毫没有问题，但常常还是像“盲人摸象”一样，只看到软件测试的某个方面，甚至眼中只有测试用例和缺陷，连Test Oracle、质量模型都不了解，对用户、业务、技术和开发关系等也关注不够。要知道， test oracle是指“对测试执行结果是否通过测试的判断准则（ The mechanism for determining whether a test has passed or failed ，可以参考： 软件测试的一个新公式引起的思考  ）”，如果不知道test oracle，如何做测试？但有人会说，“没什么影响吧，我不是已经好好做了几年的测试？”。但又有谁知道，你的测试质量和效率怎样？缺陷命中率有多高（有多少缺陷误报）？有多少缺陷（非那种出错的功能缺陷，而是另一类缺陷，如易用性、合规性、合理性、一致性、潜在经济/健康的风险性等方面的问题）在你眼前被错过？交付的质量又如何？如果不知道产品质量模型和使用质量模型（ 参考：完整诠释软件质量模型 ），如何评估一个软件产品的质量是否符合要求、是否能够上线？“幸运”的是，软件属于高科技产品，得到国家特别的“优待”，软件产品和服务可以不遵守国家标准也能上线（一般工业产品没有这种“待遇”），但如果这样下去，人类社会有一天可能会毁于自己开发的软件（希望这是杞人忧天）。

如果以系统性思维来分析和解决问题，就不会出现：

• 只见树木不见森林

• 片面地追求单个目标

• 被表象所迷惑，看不到本质

• 忽视某些产品质量风险

• 千里之堤、溃于蚁穴

• 用线性的思维方式来理解非线性的问题

而是会整体地、多角度地、多层次地分析问题。软件测试的系统性思维会帮助我们能够全盘掌控软件测试的目标、要素及其之间的关系。例如，当我们思考最基本的概念“什么是软件测试？” 时，就会从不同的角度去思考，正向的、反向的、狭义的、广义的、......有不同的思考，就有不同的测试策略、测试方法，会决定我们是如何制定测试项的优先级、会影响我们的测试分析、设计与执行的某些活动。

有了系统性的思维，对测试结构、黑盒测试方法等会重新审视，这样可以把握测试自身、测试方法的精髓。例如，对软件测试、黑盒方法，我们就会关注测试的输入、输出，还会关注被测系统（ 延伸为“被测对象”）的所处环境、条件、接口等。针对输入，也不仅仅看到正常的输入数据，而且要考虑异常的数据输入、不同角色的用户操作等等。针对Test Oracle也不局限于Spec/标准等确定性的准则，还有不确定性的准则。

针对软件测试的目标、功能看，也不会仅局限于发现缺陷、验证功能特性的正确性等，会思考软件测试的其它价值，包括提供产品质量信息、完整地评估软件质量、不断地揭示软件产品的质量风险、测试能产生经济效益（投入产出分析，RoI）、增加管理者的信心等。

除了从不同维度测试软件产品，如进行不同的类型测试（功能测试、性能测试、安全性测试、兼容性测试......）和进行不同层次的测试（单元测试、集成测试、系统测试...）之外，借助系统性思维，会督促我们去全面了解做好测试的成功要素、影响我们做好测试的各种因素等，例如我之前在写《完美测试》时，构建了一个软件测试的金字塔，列举了软件测试五个要素：质量要求、人员、技术、资源、流程等。在去年绘制的软件测试思维全景图 （ 这才是世上最全的“软件测试”思维导图！ ），软件测试的要素被概括为： 思想（流派）、方法、方式、技术、流程（过程）、管理等。当然，人、团队是做好测试的决定性的要素。除此之外，还要考虑项目中的范围、进度、业务领域、市场等因素的影响。

基于系统性思维，了解测试的成功要素、影响测试的各种因素等之后，还要确定它们之间的关系，能够将它们连接起来，而不是孤立地对待它们。只有了解它们之间的关系、相互影响，才能更准确地确定测试范围、采取更有效的测试方法（如组合测试），才能比较彻底地完成测试，即能从多个层次、多个维度来保证测试的充分性，这样的充分性才是客观、可靠的（这里省略了......几千字 ）。

• 业务需求决定了用户角色的需求，而这些会反映在系统功能上，或者说，功能需求是为了支撑业务需求（系统构成的依赖性）；

• 针对业务需求的验证就是传统意义上的验收测试，而系统测试是为了覆盖系统功能和非功能性需求，而集成测试、单元测试则是为了覆盖接口、代码层次等（系统构成的层次性）；

• 业务数据贯穿整个系统处理的过程，包括业务规则和流程，整个过程中如何保证数据的完整性、一致性、保密性等，确保数据和系统功能的和谐相处、有效协作（系统的交互性）。

• 测试分析是测试设计的基础，测试设计是执行的基础。反过来，测试执行、设计分别为设计、分析提供反馈，以帮助我们优化测试的分析、设计（系统的反馈性）；

• 站在更高的层次上，能够综合运用与管理测试方式、测试方法、、测试数据等（系统的全局性、综合性）；

• ......

所以系统性的思维不仅从整体上把握被测试对象，如采用黑盒方法着重考察在不同的上下文驱动下系统的输入/输出，考察系统的不同的应用场景、不同的运行平台之下的测试；而且，经常需要对系统进行分解、分层，考虑它们的相互影响，各个击破，并考虑风险与效率的平衡，例如，如何分配UI、API、单元的测试投入，达到质量和效率的最佳收益（虽然许多团队没这么去考虑）。针对更具体的软件测试计划、分析、测试设计等工作，系统性思维显得更重要，由于时间所限，这部分具体的内容就不展开讨论，留到有偿的思维训练课程中去讨论  总之，系统性思维能力才是普适的、终身受益的一种能力，需要在日常工作中去训练。有了系统性思维能力，测试工作不仅做得又快又好，还能感受软件测试之美（系统之美）。