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. 享受测试带来的一切

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

作者：华北区  Amy