关于这次在淘三年的内容，我自己也是思索了好久，不知道要写什么，测试感悟的、测试技术的、测试方法的各个方面都想写，又都不想写。

　　都想写的理由就是本身测试行业就是个比较工程和系统性的行业，自然有自己的一些领域知识，说太少了，怕有些人真的以为测试就是点点鼠标而已。

　　都不想写的理由就是怕说太多了，就复杂了，就更让人摸不着头脑了；而且很多观点和事情不是说说就能明白的，只有自己亲身经历了才有深刻的体会。也所谓 如人饮水，冷暖自知。

　　最后还是决定好好回顾下这几年的测试想法，因为这几年测试行业发生了很大的变化，不仅仅是敏捷测试、新测试技术、开发自测等等，都会影响我自己个人在测试行业的发展和能力的提升。真的怕自己走过弯路，所以需要不停的反省自己，这个能力是不是必须的、这个技术是不是应该需要了解的等等。

　　介于北京的崔启亮的建议，还是确定了自己的部分写作思路，也大致分成几个部分吧。

　　遇到的困难以及解决办法

　　第一个三年：

　　在06年毕业后的测试三年中，遇到了一些基础困难，幸好自己在观察和学习的同时，很快就能解决这些问题。 由于之前写过一个blog介绍了部分问题，大家可以参考下：http://www.51testing.com/html/70/n-807570.html

　　但是这边我还想发表下自己的观点，是针对于黑盒测试方法来说的。 记得几天前讨论是否需要QA的时候，段念 写个一篇blog来说明 一个正常的工程师 都能在一个下午学会和理解大部分的黑盒测试方法。 对此观点，我是不敢苟同的，这就讨论到这些黑盒测试方法的深度的问题了。

　　（0）学会和理解测试方法的使用步骤是很简单的，但是真正的在项目需求中应用起来可不是一朝一夕的。这就好比给你一张扑克一样，高手就能拿它杀人，一般的人能做到什么程度呢。 这个也很像有些人能发现你不能发现的bug一样。至于原因有很多，具体看在淘两年的blog。

　　（1）谈谈我自己的感想吧，我自己在工作前两年也是认为这个黑盒测试方法一下午就可以学会的，找几个例子试着使用下，感觉自己掌握到这些黑盒测试方法，但是后来我看过很多这些测试方法的背景以及应用的注意点后。我发现自己真的是了解了一些皮毛，没有深入的了解。对于个项目需求，如何快速且完整的应用这些黑盒测试方法设计出不多不少的测试用例，这个需要的经验的积累，也就是你测试价值的核心体现。

　　（2）去年在成都MPD时，很多学员说自己都说自己是工作2-3年的人，已经遇到瓶颈了，感觉测试很单调和无味。我给的建议其实很简单，那就是真正的理解和掌握所有的黑盒测试方法。怎么来验证呢，我自己就是这样：给你一个白板，你能把所有测试方法的5W2H（What、Why、When、Where、Who、How、How Much）都能非常清晰明了的演讲出来，记住是不需要参考ppt或其他资料的情况下。

　　就像火影里面的鸣人一样，他只会螺旋丸这个核心的攻击忍术，但是在扩展其他忍术之前，他会把这个忍术的深度发挥到机制，从而研究出威力更强的超大螺旋丸、超大玉螺旋丸、风遁螺旋丸等等。

　　在淘宝的这几年也越到了很多的困惑，而且随着年龄的成长，考虑的问题就会越来越犹豫，需要权衡利益的去提升自己和学习。主要考虑的就是测试的深度和广度问题。自己毕竟在测试行业待了那么长时间了，周围其他测试同仁的发展、国外测试行业的发展、自身利益和环境的影响等等，这些都会影响自己对某些测试问题存在个人极端的想法。

　　个人认为了解一个人测试的水平，需要考虑其测试行业中的深度和广度的知识。

　　测试的广度：主要就是测试相关类型的了解。具体包括如下：需求分析、测试流程、测试管理、开发流程、开发技术、测试模型、基础测试方法和测试技术、功能测试、性能测试、自动化测试（页面自动化、API）、安全测试、可靠性测试、易用性测试、稳定性测试，探索式测试（ET）、基于风险的测试（RBT）、兼容性测试等等。

　　测试的深度：也就是对广度说到的某一项你了解到的深度。当然这个深度，每个人都有自己的定位和看法，关键还是看自己是如何来对待的，这边我说下自己对自动化测试的深度的看法吧。

　　基础：了解简单的测试脚本/代码的编写，了解不完整的测试框架架构。

　　进阶一：快速编写测试脚本/代码，解决部分代码编写的问题，了解完整的测试框架架构。

　　进阶二：理解和了解自动化测试设计，自动化测试在项目中的融入和实施策略问题，了解其他类似的测试工具，并能做出正确的判断。

　　进阶三：快速编写合理的测试脚本/代码（体现在测试设计和测试数据设计上），指导他人编写可维护性的测试脚本，深入了解测试框架的实现细节和开发技术。

　　高级：整体上来解决自动化测试效率和价值的问题，找到测试框架的问题或困难，并能解决它，或提出有效的建议，深入了解其他类似测试框架或工具，并了解其功能技术细节。提升测试框架的应用性和实效性和效率。

　　就我个人而言，我一直也在扩大自己的测试广度，也在提升自己的测试深度。在淘宝的这几年，淘宝测试部的发展非常的快速，自己也从中学到了很多，我也庆幸自己在来淘宝之前就把某些的深度问题给解决了，从而可以提高自己其他的广度。

　　一开始来淘宝，就选择 自动化测试这个广度，并在页面自动化测试和API接口测试方向 提升自己的深度（这是个长期的过程）。另外也选择了兼容性测试这个 广度，不过这个进展笔记缓慢。接着根据自己的方向和优势，选择了 探索式测试 这个广度，从而在这个领域学习到了更多的知识，从而影响其他广度的选择。接着不停的提升自己在需求分析、测试流程、测试模型、性能测试方面的深度，也会接触安全测试这个广度等。 最近选择了 前端测试和无线测试领域，这也是扩大自己的广度，不断的学习和了解该领域的测试特点和工具。

　　给大家的建议是根据公司测试技术的发展策略，有针对性的选择某几个测试广度，然后在其上提升自己的深度。你的测试能力就是 你的广度 * 你的深度。

　　不管我去扩大其他的测试广度，有几个测试领域我是必须要求自己，也强烈建议其他测试同仁需要达到的较高深度的。也就是我自己一直深信的测试理念，我是一个测试工程师，你可以说我level不高，考虑不到高层想要的东西。但是我是会追求自己所相信的，那就是测试设计能力：也就是不同测试类型的测试方法的应用能力。不仅仅是有这个能力，而是 更快、更准、更狠的 测试设计。

　　个人测试感悟

　　0、时刻牢记自己的状态和目标

　　你需要确定你目前所在的广度有哪些，和深度是怎么样的。根据自己的特点和测试信念和公司情况，选择深度和广度，然后指定计划和目标，执行下去。这个可以整体上解决 你的瓶颈问题。

　　1、开发和测试是亦敌亦友的关系

　　以前一个测试同仁说过，没有和开发吵过架的测试不是一个好测试。我虽然不是很认可，但是他还是有一定的道理，本身开发和测试的立场和思维逻辑就不一样，短时间较难改变，那这里就需要表现测试的价值。但是测试需要开发的帮助才能更好的理解设计和代码，才能更好的设计用例，才能更好的保证质量，才能更好的提升自己的技能。这是个平衡，测试和开发走的太近不好，走的太远也不好。不要说开发和测试共享质量、共同承担责任啥的，目前国内是这样，以后可能会不一样。

　　2、测试需求分析时多问为什么

　　需求评审和需求分析，对应大多数测试同仁来说是个不易提高的地方，也是很难传承经验的地方，这里还是需要去学习一些需求分析方法，总体上就是建议你凡是多问问什么、为啥会这样、还有没有更好的。

　　3、验证bug时多看看code change

　　记得在华为和微软Onsite测试的时候，就讨论过了很多次，我还是很喜欢在验证bug时看code change。看不懂的地方直接问开发，不断的提升自己在代码方面的经验和敏感度，那段时间真的很快乐。后来我还会参与bug fix，这些都是多看code change的后期提升，让自己更加有价值，不仅仅能发现bug，还能fix bug。

　　4、持续优化你的测试设计

　　不管是项目还是产品，你只要是负责人，一定要保证该产品或项目的测试设计是最新状态，并且在不同的信息输入期间都有新版本的测试设计产出，特别是测试执行后期，那些未通过测试用例发现bug的用例，一定要保证测试设计的时效性和完整性和最新性。

　　5、没事多看看其他人提的bug

　　线下bug场景和线上故障的场景都是非常好的案例，不是单纯的由某个黑盒测试方法能发现的，所以我们需要关注这些场景案例，总结起来，并转换为自己所用。这个经验积累不是那么容易看出来，而且经验也不是那么容易show出来，但是不要低估它，关键时刻就靠他了。

　　6、 控制自动化和它的价值

　　这里让大家理解自动化测试的价值和目的是没有任何问题，关键是控制它。根据自己产品的特点要找到一个平衡点，不要盲目的自动化。一定要控制手工测试用例、自动化测试用例的比例（UI级别、API级别的）。不要让它成为你的累赘，不要让你每次的脚本排查成为惯例现象。

　　7、坚持自己选择的测试信念

　　之前很早就提到过test school，建议每个人根据自己的个人信仰和特点来选择某个test school。因为一旦你选择是某个school的人物，你就会学习这个school的很多测试理念和测试想法，坚信它们并在自己的团队中应用起来。我个人就是属于context-driven school。

　　8、用户体验和代码完美性是王道

　　很多人都应该说过测试人员测试就是应该站在用户角度去思考问题，多去考虑用户体验，的确这是个能帮助测试人员研究用户和提升易用性测试的一个途径，另外可以多看看用户提供的反馈意见，完善自己的测试思路和需求分析思路。另外一点就是，我们很多bug开发都会说用户不会这么去做，几乎不可能的，所以这个bug是invalid的。我们不仅仅是考虑用户应该做什么，我们还要考虑用户不应该做什么，有可能做什么，能够做什么。这些都是不一样的，多从代码健壮性和容错性考虑代码的完美性。

　　9、享受测试带来的一切

　　不管你是毕业就从事测试工作，还是先干开发再转测试，不管你做测试的原因和动机是什么，个人建议你只要还在测试行业，试着去发现测试的美，不要人云亦云，也不要固步自封。测试会让你开心、会让你单调、会让你愤怒、会让你痛苦、会让你疯狂、会让你无味。不要担心自己会不会失业或没有价值，不管怎样，提升自己的广度和深度，逐步的享受测试带来的一切。

　　测试的发展趋势和职业发展

　　看这几年，国内的测试发展还是不错的。不过相比较国外来说，我还是比较悲观的，测试和开发一样还是至少落后于国外10年。我们这几年在不停的学习和实践自动化测试、探索式测试、敏捷测试、基于模型的测试等等。很多国外走过的弯路，国内的我们还是在走，这似乎就是历史的轮转。

　　个人认为测试的多元化发展还是一个主要的方向，也就是测试本身所提供的价值。测试手段的多样性和深度是必须要经过的环节。个人认为没有一到两种测试方法、技术、手段能够解决被测产品的所有测试任务，我们需要不断的从不同角度去测试，去工具SUT，最近流行的分层测试、敏捷测试其实都是基于这个认可。对于持续集成，个人认为只要自动化测试不消失，事实上他的价值还是不错的，也应该不会出现这个情况，那持续集成就还是基础的测试底层框架搭建。只是这个持续集成的作用，我们现在还只用到了不到五成，接下来大家应该会在这方面有所突破，不过这方面还是有难度的，且不好考核。

　　另外个就是提升开发自测，提升开发自测的质量对测试来说，实在是太重要了，但是不意味着测试可以掉以轻心。目前的开发自测状况是开发人员发现20%的bug后，到时间了，开始提测。测试这边发现70%的bug，到时间了，该上线了。那么开发自测的目标就是开发人员发现60%的bug，fix后，提测。测试这边发现35%的bug，fix后上线。表面上看总体上只多发现了5%的bug，而测试发现bug也减少了，但是从开发整体进度和项目进度上来说，可是个非常大的进步，绝对的快速发布了，测试人力成本也会减少较多。

　　由于答应了某位测试同仁，这里大致说下探索式测试的发展。个人是在09年底开始了解ET，目前淘宝在ET方面并没有大范围的展开，还是在某些测试组、某些项目实施了不同形式的ET方式（部分项目是Freestyle形式，部分是ET辅助或bug bash的，主要是我这边来把控的，我个人时间有限，你懂的），至于结果，仁者见仁智者见智。大家也可以我个人其他的blog里面看到，至于工具使用的是Freemind和Session tester。个人认为ET应该是未来测试发展的某个重要的方向，几乎可以和自动化测试齐步，特别在ROI上，自动化测试肯定会低于ET的，但是事物都有两面性，ET必然有它不完整、不成熟的阶段，这个阶段需要大家一起去完善，一起去坚持自己的测试信念。

　　关于职业发展，我是想走技术的，但是我自己也迷茫了很多次，做到什么样的程度呢，我的测试广度和深度到底要达到什么样的程度呢？公司需要我这个测试广度吗？公司需要我这个测试广度下面的这个深度吗？是不是还需要再深入一点呢？我心里有很多这样的迷惘。比如开发技术就是一个矛盾点，这个深度真的不是那么容易把握的，大家都知道了解开发知识、懂开发知识对做好测试是有益的，但是到底应该懂得啥程度呢，能带来多大的好处呢，啥情况下呢，开发自己都痛苦的学来学去，测试真的一定要跟着后面吗？这个精力我是否应该多了解下兼容性测试呢？是不是应该多了解下RBT呢？我心里确实有很多的矛盾，很多次我都不知道怎么过来的。不过我还是有自己的决定，我会尽量地去寻找自己的平衡，时刻的去review自己的状态，自己的这个测试广度达到了什么样的深度了，是不是可以暂停下，去提升下其他测试广度的深度了。

　　想走管理的，就是测试管理了，多考虑一线测试工程师的生活，他们是如何进行测试的，他们遇到什么问题，解决问题才是王道，解决他们的痛苦，提升他们的效率，让大家快速的干完，可以去做些自己感兴趣的事情。另外就是多考虑下国外的测试新技术，有些不一定现在有用，以后呢，做些储备是必要的，就像军队一样，平时没事做，关键还要用的，特别是特种部队了，各方面要求都很高，做这些储备更需要管理层的觉悟和想法了。

　　想走技术的路线，就是尽最大的努力提升开发技术，另外就是多扩展自己的测试广度吧，争取在几个核心的测试广度上达到最深的深度，成为真正的测试专家。

　　另外就是可以考虑走产品经理或其他路线的，比如SQA等。另外提一下，我也喜欢叫tester，不喜欢被叫QA。

　　废话说的有点多，期望对大家有帮助，大家有任何不同的观点，欢迎提出。