这篇文章我觉得特别适合发在新手区，一方面我是社区的新手，另一方面也是想对测试新手说的一些话。

我认为，测试人员应该具备三种基本能力：测试思维、测试技能、测试方法。（这里不谈沟通能力、组织能力等软技能）

一、测试思维
测试思维，是一种特质，就好象小说里写的火属性体质或者水属性体质一样。是测试人员看待一个事物的角度，思考一个问题的角度，解决一个问题的思路。

不管你是做开发还是测试，当你暂时处于” 测试 “这个角色时，你就必须转换你的思维模式，进入测试思维。

比如逆向思维、比如永远怀疑、比如推翻假设、比如用户思维、比如追求完美。。。

这里可以列很多很多，但是重点在于，做测试这个角色时，所需要的思维方式，是和做开发是不一样的。一个好的开发人员，不一定是一个好的测试人员。

遗憾的是，很少有书籍可以告诉我们，如何去训练、培育这种思维模式。很多人都是天生的。

这里我可以举一个比较极端的真实例子，我以前的一位同事，在和开发一起做敏捷的时候，非常努力愉快的和开发一起解决了各种难题，然后成功的让软件运行起来了，各个流程都能跑通了。但是他来给我汇报测试工作已经完成的时候，我给领导说，这个同事不适合做测试，后来让他转了开发（后来成为了一名很成功的开发）。
因为对测试来说，软件可以正常运行，仅仅是一个开始，开发要做的是努力完成它，我们要做的是努力打倒它，直到我们无法打到它为止。如果你根本就没有这种想法，或者光有想法，完全不知道如何去做，那么就必须想办法学习了。

二、测试技能
测试技能主要指对测试工具的掌握、对测试技术的掌握，这里同样也包括编码能力的掌握。我并没有把编程能力单独拿出来说，因为我觉得编程能力只是技能的一种。

一句话来说，为了能更快、更好的完成你的测试目的，你需要使用工具，这些工具包括像 Jmeter、RF、Rest Assured、Jenkins、Appium、TestNG、WebDriver、Nmap、Excel（是的，我确实写了 excel）等等等等，你还必须会编码，比如写 java、写 C#、写 python、写 Go、写 JS。。。

现在很多老一辈的测试人员，会在测试技术上比较落后，因为各种原因，比如编码能力薄弱，比如没有及时跟进新的技术，抱残守缺，比如踏入管理岗位后丢弃了技术，比如学会了混日子再也没有了激情。

如果一直这样下去，被淘汰是必然的。

我个人认为，一名合格的测试人员，最少必须要掌握所在公司开发所使用的主要语言，然后再加一门脚本语言，再加一门前端语言。你不光要能写代码，你还要能写界面，这样才能向项目组展示你的成果。

在我看来，测试最终会有两个分支：业务测试专家和专项测试专家。

前者是在某一行业具备了相当的背景后，特别擅长测试某一类产品，比如金融软件测试专家、比如医疗软件测试专家。
后者是特别擅长测试产品的某一项特征，比如性能测试专家、安全测试专家。

不管如何发展，必然是需要各种测试技能的。当别人都在用导弹、飞机了，还拿着菜刀必然要被时代淘汰。

三、测试方法
测试方法不是测试理论，但是会包括一部分测试理论。

现在你有思维了，也掌握了技术了，如何利用好你掌握的技术去进行测试，这种方法论就是测试方法。

如果说测试技术是绝世宝剑，那么测试方法就是招式，或者说如何去更好的使用宝剑。

同样的一把刀，拿在庖丁的手里，和拿在我的手里，效果是完全不一样的。

有很多业界的前辈，其中特别是我最喜欢的 James Bach、James Whittaker、Martin Fowler 等人，努力的把自己的一些经验，转化为一种模式。我觉得这些测试方法，就应该对应开发的设计模式、软件研发方法。我特别喜欢《软件测试经验与教训》、《Google 软件测试之道》、《软件测试的艺术》等书。
有人说这些很多都是手工测试的书，这里我想声明一下，书里是讲如何去测试，但是没有规定你一定就要手工去做啊，你可以打车去，也可以坐轻轨去，你可以尽量的使用你所会的各种技术，如果没有合适的技术，你还可以学习。

测试方法其实也可以是非常简单、落地的。
举例说接口测试吧，现在接口测试的基本代码已经写好了，你有了一种很犀利的工具，可以去做业务测试无法做的事情，这是一把尖刀，非常锋利。
至少，你要懂得测试用例不光要根据输入字段去设计，还要根据输出（什么样的输入才能覆盖各种可能的输出）、服务器上各种数据的状态变迁图去设计用例。
这就是最简单的方法论，太简单到所有的人都觉得这个不是理所当然的吗。

有人会比较鄙视只会夸夸其谈，说起理论一堆一堆的，但是动起手来就什么都不会的人。我也很鄙视这种人。
不过理论也是必须的，想一想这个问题：
为什么开发同学，除了看《某某语言精通》《深入某某语言》这类的书外，还要看《设计模式》、《重构》、TDD 这类的书呢？
前者是学会一门语言，后者是学会如何用好语言，后者通常是跨语言的，实际上就是一种方法论，如何用好自己学会的语言。

测试在这方面比较薄弱，形成的大家都认同的方法论比较少，但是为什么就不应该有呢？或者说就不重要了呢？
难道不是应该有人站出来，不断的把自己的经验传递下去，最终形成方法论吗？

除非一开始，大家就已经认为测试是一种比较低级的工作，很简单就能做好，难是难在学习一门编程语言上。。。

四、总结
在《Google 软件测试之道》的评论中，夏林娜，阿里巴巴集团测试总监，说：具备开发能力、测试思维，还要具备业务思维，能深刻理解业务所服务的客户需求及客户价值。我非常赞同这句话，如果一个人只有思维没有能力，那么他就是跛的，如果一个人只有开发能力，那他就是开发，根本不是测试。

现在最流行的” 测试开发 “岗位，大家有没有想过，到底测试开发同学，是什么样的同学？
到底和开发有什么区别？到底” 测试开发 “和” 帮不会编码的测试同学写代码的同学” 有什么区别？到底和 “编写平台工具的同学 “有什么区别？

公司的测试需要一段非常高级的代码，但是不会写，于是从开发调了一个同学过来帮忙，这样这个开发同学就变成了” 测试开发同学 “了吗？

测试需要尽早介入，这句话大家都不会有异议吧。那么，在需求评审阶段，测试人员应该做什么呢？如何去做呢？

需求是否合理、是否可测试、是否符合相关利益人的利益是否是测试人员应该关注的？

用户体验是否也是测试人员需要关注的点？

风险分析是否也是测试人员应该做的工作？

界面美观整洁是否也是测试人员应该关注的？

崩溃后的易恢复性是否也是测试人员应该关注的？

我在想，测试开发，应该是掌握了开发能力的测试人员，而不是写测试不会写的代码的开发人员。
测试开发，其本职工作是进行测试，是掌握了更强大技术的测试人员。他掌握了更强大的技术，目的是进行更好的测试。

如果仅仅是编写一套工具交付给测试，那么还是应该算开发人员。因为编写的工具，也有可能是一个商业产品，比如写 Jmeter 的人应该算是开发人员的。写 rest assured 的人是开发，用 rest assured 进行接口测试的是测试人员。

注 1：我在写的时候，有开发同事在背后说 Martin Fowler 不是测试，的确如此。但是 Martin Fowler 发表了很多篇关于 testing 的文章的，可以去看他的博客。
注 2：TesterHome 社区正在编辑一个武功秘籍的目录，也就是我们通常说的测试线路图，我和大家都在尽情的期待中。
注 3：有很多很多的人，说测试还可以往业务专家走，往架构师走，往开发走，这个不是测试的分支，是转行。。。转行了你就不是测试了。
注 4：我是测试开发的新同学，虽然从 02 年开始写 C51，后来写 VB，写 Delphi，写 C++Builder，写 MFC，写 C#，写 Java，但是都半会不会的。现在我的定位是测试开发的新手。
注 5：要上班，写不完，本来心里有千千万的话想要说。