在软件测试这个行业已经摸爬滚打了10年，经历过Top 500外企标准化的流程，也体验过BAT的快速迭代。做过复杂耗时的功能测试，体验过纠结的UI自动化，深入过底层通讯的白盒测试、执行过60亿的数据迁移、分析过2000万用户量服务器的性能。我经常会听到一些测试同学的抱怨声：“我做的工作没有技术含量，整天就是点按钮，测试真是太无聊了，我要做自动化测试，我要做性能测试”。今天我的这篇文章不是想讨论自动化测试或性能测试，因为讲自动化和性能的文章太多太多。我就想讲一讲我自身对测试的一点体会和感悟，或许有不被大家认同的地方，欢迎吐槽。
大多数的测试同学目前的工作可能都是在写测试用例和执行测试用例，以及报Bug。这些工作都是作为一个QA最基本的工作和必备的能力。如果你定位自己的角色仅仅是一个执行者的话，那你可能就只能一直点按钮了。我不知道大家是否思考过这样一个问题没有：“一个工作的可替代性”？ 当一个工作谁都能干的时候，你自己在这个岗位上就是非常的危险。因为企业很可能某一天找一个更为廉价的劳动力，就可以将你替代。企业不是慈善机构，他的目标永远是利润最大化。那么，作为一个功能测试的QA来说，应该如何去思考自己的未来和提升自己的能力呢？ 我的一点建议就是“跳出测试看测试”。这句话如何理解？其实，我们现在做的测试工作仅仅是整个软件项目中的一部分。而我们应该跳出测试这个圈，上升到对软件项目的一个整体把控，包括：参与到需求分析、需求评审、系统设计、系统设计评审、代码评审等各个环节。这样你对整个系统将会有一个全局的把控，对系统有更深的理解，对你测试的工作也会起到很好的帮助。
该图是一幅标准的软件开发测试流程体系图。实际上作为一个专业的测试人员除了应该涉及到黄色部分“测试工作”的区域外，还应该要涉及到红色箭头的部分，包括：需求、系统设计、代码评审、测试评审。这样你才能更好的了解整个产品的设计和实现，并且更多的去了解产品的细节，也能够为你更好的测试服务。因为你的测试更加有针对性，你了解设计的缺陷或者可能存在的安全隐患，而不是之前胡乱的一通乱点。这也是我这篇文章标题的意义，只有你站在更高的层次，更全面的看整个软件的开发测试过程，你才能得到更多的成长。
给身陷测试困惑的同学一点建议：
- 多去和开发沟通，了解系统设计和整体架构
- 多参加方案和代码评审，以学习的身份融入开发
- 以目前参与的项目为切入点，学习开发语言，并且坚持下去
- 多思考现有项目流程的痛点，自己能做一些什么样的改进
- 多在团队做一些知识分享，提高自身的团队影响力
