聊到自动化测试，我们做 GUI 自动化测试的过程当中，以前就只要把这个自动化做起来就好了，但随着你的用例，用的数量越来越多之后，你不单单是把一个场景自动化就可以了。因为随着你的用例变多之后，你所有的用例设置，包括你的代码的结构，都要考虑这个东西的可维护性，因为可维护性一直是 GUI 自动化测试很大的一个痛点。我们在后面的 GUI 测试过程中，就会去考虑，怎么来做分成？怎么来做基于可重用的脚本？怎么来做基于页面的对象模型？甚至到后面还有 BDD，就完全是业务，用户行为驱动的这种测试。那么，从这些概念当中，可能你已经听出来了，不管是你之前有没有接触过这些概念，你都能够发现一个很重要的信息点，自动化测试没你想的这么简单，也完全不是一个简单的录制，或者回放。
所以说，我自己当时在转型的过程中（从开发转向测试），我就是看到了这些点，觉得这里面的学问，或者说可以做得东西，尤其在当时的大环境下，是非常多的。因为当时没有人去做这块，而且当时是没有有开发经验背景的人会去专门做这一块的东西。我也是看中了这样一个机会，后来事实证明，转型并没有错。
随着时间的发展，后来就越来越证明整个自动化测试到后期的一些基于 API 测试，或者现在很多一些新的测试技术越来越多，而且整个测试地位也越来越高，从早年的并不受重视，或者是一些比较弱的开发去做测试，到现在一个优秀测试工程师可能是比一个开发人员更懂开发代码。因为如果他不懂代码，或者不懂开发是怎么来做得，你让他怎么去发现开发当中的一些问题？这个过程是相辅相成的。
其实我们很多测试已经分为了三大块。
一块是 所谓的传统意义上的基于业务功能的测试， 基于手动测试，或者现在非常流行的，基于探索式测试，也就是说基于一些错误猜测，以及基于一些你做了哪些测试，你假定哪些地方有可能会出错，而且做进一步测试，这样一个过程，所以说这是一部分做业务测试的同学。
那么 第二块是做自动化测试的同学， 自动化测试的同学对业务了解程度并不是很深入，但是他所做的事情是把一些手动的脚本，很方便得把它翻译成一些自动化的脚本，可以让机器去执行，那么他的主要技能是主流的一些 GUI 的 Framework，比如说现在主流的像 Mobile 端的可能就是 API，或者是不同框架的这种自动化开发技术，这是第二类。
第三块是很大的一块，就是现在意义上的叫测试开发。 测试开发并不是传统去做自动化用例的开发，他会去做一些测试平台、测试服务，或者一些测试基础架构的开发。你可能会问，这些基础架构包含什么东西？我可能举两个例子，你可能就知道了，你现在要跑测试，你要跑一个 Web 端的，或者跑一个 API 手机上的一个 Mobile Native 的 app 测试，你肯定一定要有执行环境，你如果是手机端的，你一定要有手机，要有安卓的 Device，或者有 IOS 的 Device，去让你跑这些测试，那么这些手机你怎么来？单个来拿吗？你肯定会去建一些机群，甚至建一些私有云，像国外的 Lab 服务，其实包括国内的一些其他服务器，类似云测的服务，就是把这些设备集中在一起。
那么这部分工作是谁做的？就是现在的测试开发去做。
软件测试对于学历的要求高吗？
茹炳晟：反问下大家，你在学校里面学的东西是什么呢？你真正去看，学校里面出来，你上了工作岗位之后，学校里的东西立马能用的有多少？我觉得基本上是在 10% 以下的，所以说我觉得学校里面学的是什么呢？我个人认为更多学的是一些思想方法，就是说你面对一项新事物的时候，你会用什么样的方式，如何在很短的时间内用自己的方法，把整个这件事物的来龙去脉搞清楚，并且你能够接受它并且你能够运用它，这是个很重要的点。
所以说跟学历没有必然的关系。像乔布斯这种公司，它不注重你的出生，或者你是从哪个方面去做这个事情，他看中的是你的思维方式，你的能力。 这又让我想到另外一个点，现在讲到面试，我个人是十分反对刷题的。 因为我们碰到过一些同学，面试过程中，你给他一个算法去做一下，如果他能立马给出一个最优解，那这个肯定是有问题的。因为我的理解，正常的情况下，你不可能一下子就找到这么一个非常好的最优解，你能找到这个最优解的前提一定是你之前看到过这样的算法，或者是你看到过这样一个最优的解法。
我们想看到的是一个什么样情况呢？你不是给我一个最优解，而是你给了我一个方法，这个方法不一定完美，但在我们的引导下，你逐渐把它完善，逐渐发现你这个算法的问题在哪里，哪些地方可以去做更多的改进，然后把这个算法逐渐变完美。 这个是我们想看到的，我们是想看到的是你在面对一个有挑战事物的情况下，你是怎么把一个大问题化解成一个小问题，每个小问题又是如何去解决，最终解决这个大问题，解决了这个大问题之后，再去回顾一下，你在解决这个大问题的过程当中，有哪些地方是可以改进的，是可以优化的。我们是想看到的是这种过程，所以是这样一个情况。
去 QE 时代，测试工程师该如何修炼？
茹炳晟：首先我想先解释一下，什么是“去 QE”。“去 QE”这个概念在国内还是非常新，但是在一些像 Facebook、Google、Ebay 这样的公司，已经都在做这些事情，而且有很多都已经真正落地了。首先我先表明我的一个观点，我并不是“去测试”这样模式的推崇者，因为去不去测试根本的原因不在于说，你觉得能不能去，而是完全取决于你的组织上下文、你的组织成熟度、你成员的水平、你工具的成熟度、你的体系、你的上下文、你生态的成熟度。
那为什么 Google 能做？
因为 Google 拉任何一个测试工程师出来，直接去做开发是没有任何问题的，但在国内，你让测试去做开发通常是比较难的， 所以你面对的上下文、面对的环境，差异性就非常大。这种情况下，你说去 QE 一定好，或者去 QE 一定不好，都是没有一个定论的。
我的观点在于，并不是一定要说那个好，而是我们应该面对一个特定的项目，或者面对某一个组织，我们怎样去两边取各自的长处，两边去各自的短处，有机地结合在一起。这也就是现在所谓的“去 QE”，就是“没有测试工程师，开发自己做测试”这种架构。
那么哪些情况下是适合让开发自己去做测试的？哪些情况下还是需要一些专业的测试人员来做测试的？
传统的测试策略，更多的是一个金字塔模型，也就是说 UT 会做的比较多，中间层，像 API 的集成，或者是集成测试会做的相对少一点，最上层的 UI 一般是更少，是个轻量级。
但在现在互联网的时代，尤其是一些去 QE 的公司，他是怎么玩儿呢？他会把整个三角形变成一个类似于菱形这样的一个架构，也就是说 UT 这块是非常的少了，中间层，API 这一层，由于微服务化，这层会非常的厚，上层的 UI，会做的相对比较少，而且更会去做端到端的，面向对终端用户的这种测试。除此以外，这个菱形的顶上还飘了一朵小的云，这朵小的云就是现在非常流行的 ET，也就是所谓的探索式测试。
没去 QE 之前，整个架构是金字塔，底部 UT 是开发做，API 测试跟 UI 测试都是测试人员来做，但是在去 QE 之后，是什么样的一个架构呢？UT 开发做，API 测试也是开发做，UI 测试还是开发做。 唯一是测试人员可以做的是哪里呢？是顶上飘的那块小云，也就上面那个 ET，探索式测试。 因为这一块需要更多的是一些发散性的思维，而且需要你对业务有非常好的理解。这还需要你除了理解业务外，还要明白产品内部的一些实现，以及它的架构，才能比较有针对性的去做一些探索性的测试。
面对这样一个大的变革，你可以看到有点类似于把测试上移了，就是你原来的测试工程师只是做上面的 ET 部分，但是原来的那些像下面的 API 测试，或者 UT，或者基于 UI 测试，这些测试谁做呢？由开发做，但是由开发做不表示这个活没有，测试这个活还是在的，只不过是换了一批人去做这个事情，本质上并没有根本性的变化。根本性的变化就在于可能从组织架构的角度来看，现在可能不再有集中的一个测试团队了，这些负责测试业务的测试工程师会打散到各个开发团队里面去，而且他承担的角色也不一定是全职的测试，他有可能会做一部分开发，也会去做一部分的测试。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
