个人测试感悟

　　1. 时刻牢记自己的状态和目标

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

　　2. 开发和测试是亦敌亦友的关系

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

　　3. 测试需求分析时多问为什么

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

　　4. 验证bug时多看看code change

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

　　5. 持续优化你的测试设计

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

　　6. 没事多看看其他人提的bug

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

　　7. 控制自动化和它的价值

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

　　8. 坚持自己选择的测试信念

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

　　9. 用户体验和代码完美性是王道

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

　　10. 享受测试带来的一切

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

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

　　看这几年，国内的测试发展还是不错的。不过相比较国外来说，我还是比较悲观的，测试和开发一样还是至少落后于国外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。

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