在我们行业中，总有人在pk在这问题。大约半年还是一年前，我在《测试架构师修炼之道 从测试工程师到测试架构师》微信群里面也辩论过这个问题，当时被认为是站在“测试技术”一端的我，有种被群起而攻之的感觉。这周面试一个平安的小伙伴，给我推荐了testhome的文章《测试方法论－质量的基石》里面的辩论，想不到，这个问题还有这么广泛的群众基础。这里我就也忍不住插一脚。
自省
在插之前，我问了我自己两个问题。
一、我太偏颇“技术”了？ 别人看来也许是，但是我一直觉得我就是“墙头草”。后面我也会说，不论技术还是思维，在我面前，能发现问题、解决问题就是王道。
二、互联网公司声音大，只是觉得互联网公司的测试才是测试？ 这些年有几次分享学习的机会，包括TID，QCON，海西等等，确实也见识了银行系统、toB的软件对质量的重视，也知道原来还有TMMI这种质量相关的体系来评估，所以我自觉眼界不算太窄，能公平地说这个事情。下面来说我的第一个观点。
局限
做好测试，测试思维只是其中一种思维
以前看过一篇我觉得归纳得挺好的文章《做好软件测试需要具备的思维方式 》，文章里面也提到了思维。但是测试思维只是其中一种。他归纳了三种思维，分别是用户思维，架构思维和测试思维。认真想想，所谓“知己知彼，百战不殆”就在此，测试思维代表测试角色，用户思维和架构思维就分别代表着测试角色最常打交道的两个角色，产品角色和开发角色。
这里更深一层的启发是，思维。思维的重点不是怎么做，而是为什么做。所谓了用户思维，架构思维，测试思维，其实是让自己在不同角色来思考，为什么做。例如测试为什么要介入到不同的阶段，为什么要做性能测试，为什么要做功能测试，为什么要需求评审。
工程效率是个好维度
测试在于发现和预防风险，那基于此的测试思维其实是一个单维度，单目标的系统，这也是我为什么很喜欢《测试方法论－质量的基石》里面辩论提到的“工程效率”的原因之一。因为“工程效率”很好地给“质量”加了个“期限”，让单目标的系统变成多目标的系统，也让测试给项目带来的价值更明确，更好度量。
举个真实案例，QQ钱包里面有许多类似运营需求，控件行为都是一样的，什么抽个奖、给个奖品之类，无非就是换个图，不同的wording而已。如果从测试思维的角度，我们会想用什么策略去测试，当然也不排除怎么逼迫开发自测。而从工程效率角度，我们可以推动他变成一个拖放控件的平台，让控件的逻辑可以沉淀到工具平台，直接可以不用测试。这里的区别就是“不是在整个研发阶段能做什么测试，而是测试这个角色能做什么？”
思考题：是否非要给测试需要的思维和技术带上“测试”的头衔呢？
知行合一
“测试行业最难的命题不是测试技术，而是测试质量......尤其重要的是－测试方法论。”，
“现在有太多的人盲目地走在追求自动化的路上，忽视了自身对质量保证意识的全局思考，其实所谓技术只是质量保证的一种手段而已，真正的核心还是思想啊”,
这些其实很有道理的，因为在几百年前到现在，朱熹的理论就很让人称道，如知难行易，先知后行。如果完全没道理，大家也不会听。只不过这个道理叫做“公说公有理，婆说婆有理而已”。如果我换个造句说，一样很通顺，“现在有太多的人盲目地走在追求测试思维的路上，忽视了实践，实践过程中遇到的问题，忽略了用技术来解决问题，其实所谓测试思维只是想法而已，真正的核心还是实实在在的测试技术啊”
这里更有价值的其实是，王阳明提出了知行合一，知和行是一体的，不存在鸡先还是蛋先的问题，有思维就必然有对应的技术，有技术必定有对应的思维，为什么要分裂来看这个事情呢？我们很多工作的价值在于如何更有效地“解决问题”，而不在于思维还是技术。
说点实际案例，探索性测试。探索性测试应该是测试思维的一个很好的体现。有次通道面试，我作为面试官也遇到了这个一个小伙伴在说自己在“探索性测试”的成果。他是这样描述到的，我落地了探索性测试，带领团队学习，发现了a问题，发现了b问题，bug量增加多少。听到这里，我不会给他过的，难道是因为毫无技术含量么？
是因为没有解决探索性测试引入的问题，要解决问题，技术手段是避不开的。这里起码有两个问题，
1. 大家对探索性测试理解的深浅不同，掌握的信息不同，测试的效果就不同，测试经验要如何传承？
2. 质量和效率如何平衡，探索性测试总能发现一堆鸡肋bug（改与不改的犹豫之间），浪费时间。
也许面试者不是没有给第一个问题的答案，就是“学习”。只通过“学习”能解决问题？你相信么？在这时把“技术”和“思维”对立起来，就会失去一些更有效解决问题的方案。在探索性测试里面有个叫邮递员测试（快递测试，邮差测试）的，是依据数据的流动来进行测试。但是如果当app是黑盒，你是知道数据怎么流动，还是猜到数据怎么流动。如果我利用技术，如内存快照，把数据变量和activity的绑定关系分析出来，把这个信息在测试的时候展现出来给测试看呢？告诉你这个界面有什么数据，什么数据会因为你的操作而变换，什么数据会传递到下一个界面。这样的探索性测试不是更好吗？
还有长路径测试法，博物馆测试法，能不能使用技术呢？前者能通过monkey平日遍历的数据，通过计算，推荐给你长路径。后者可以通过svn记录的分析，找出那些陈年代码，而且最近居然还修改了的地方。这些都是技术能给予的。
思考题：怎么评价测试质量的好坏？用了多少技术？多少漏测？发现了多少bug？思想有多精妙？
医生与测试
也是在讨论区中的启发，他们用“中医”的迂腐不进取、不会先进技术来比喻只懂测试思维的人，用“西医”的动不动就动手术，拍片子来比喻只懂测试技术的人。
我同样用医生来说说。医生无非就是做三个事情，获取信息，判断症状，开药治疗。测试也是类似，通过设计测试用例获取信息，然后通过自己的经验来判断症状，最后一步，同样是根据经验、方法论来定制解决方案。如下图所说，这里终究还是离不开技术。但是反过来说，懂得这么做，其实就是有对应的思维嘛，通过技术获取更多信息的思维，通过技术沉淀经验的思维，通过技术整合经验的思维。所以还是那句“知行合一”。
思考题：借助大数据、AI，你解决了什么软件质量建设的问题？有什么好实践
文章里有三道思考题，期待你的回复。最后一题与下文密切相关。
最后，最近在筹备2018年的QCon， 在征集专题《大数据下的软件质量建设实践》的分享，如果大家有什么在这方面的干货、好的实践，求推荐，大家一起推进测试行业的发展。下面是专题的介绍。
专题介绍：
在从源码撰写、持续集成、测试调试、发布运营，整个流程中大数据无所不在，svn的checkin日志，来源于人工、自动化、APM系统发现的缺陷、缺陷的堆栈和日志、缺陷的解决流水、用户行为数据、App性能数据、甚至是代码本身，每个数据关联起来对软件质量中的发现、度量、定位都有着重要的价值。本次专题，我们会收集在各个公司中利用大数据来改善软件质量的最佳实践。希望听众从中能收获到，
借力大数据技术来解决软件质量中的顽固问题的思路和创意，例如重复bug要如何减少，如何识别自动重要紧急的问题，如何快速定位随机crash、卡顿、甚至是功能问题。
借力大数据的软件质量建设中遇到的难点以及解决方案，例如质量类数据如何处理才能更高校地结合到大数据工具spark、hive。
大数据带给软件质量的具体效益，例如提升大数据帮助我们发现了什么隐藏缺陷，帮助我们节约了多少人力投入和定位缺陷的耗时。
