其次，
能独立负责某个模块，或者某个项目，或者某个迭代的测试
不需要老大去操心各种具体细节、事项
并且，
能按照公司测试环节的规范、流程去交付结果
无需老大去提醒各种细节、做事方法
最多，有技术难题、各种决策、方案等，
可以多跟老大讨论
当然，如上是老徐对测试三年同学的定义
仅个人观点，
扯这么多，结论是：
去了解老大的管理行事风格、对你的期望，
交付老大期望的结果～
而不是瞎忙
每天各种忙晕，并没啥用，瞎忙～
年轻人：多读书，多看文章，多思考，多问；
如果大家有问题，把问题能描述清楚的，老徐一般都会解答！
另外，一定要让老大看到你的成长，
否则，加薪是个难事！！！
1.学会提问：做一件事情，不确定具体的目标之前，先跟老大确认下，不要最终做的结果，不是老大要的，白折腾了，浪费时间
2.不懂的问题，问过的问题，一定要自己记录下来，不要下次在问
3.认真完成老大交付的每个任务，完成后，反馈结果（当天反馈），日事日清，及时响应，结果输出（测试完了测试报告，用例完成后，看是否要评审，发邮件等，能否有微创新，多想一下）
4.快速熟悉公司业务，看文档，看用例，BUG库，看线上问题反馈，与同事交流
5.文档落地、沉淀（下一个同事能直接看懂，不用重复投入时间）
汇报：
如果汇报对象是质量部老大
1.跟进部门现状，当前最严重的top3问题，给出解决建议
2.思维脑图（要做什么，大概怎么做）
3.落地能力，事物推进能力，主动汇报进度，主动抛出问题并给出自己的思考
4.定期跟老大沟通，哪里做的不好，没达到他的期望，然后高效解决掉
5.日报，周报，文档输出（层次清楚，阅读者快速知道，哪些对自己有用，哪些是自己要关注的，根据角色分布或者重点内容特殊颜色标记，工作文档，直接写工作中用到的，不需要花里胡哨，wiki不错）日报：今天完成了哪些有价值的内容，进度多少，明天计划做什么，有哪些问题需要协助（周报也是这几点，或者参数云之家的周报）
6.
让测试人员了解产品背后的商业意义
整个项目中什么功能模块是最重要的，为什么要开发这个新功能，这个功能在整个项目中有何种意义？这可以让测试人员对该功能产生一个内心重要级别，对测试用例和以后的回归都起到很大帮助。
7.
营造测试气氛
开发人员开发完功能后需要自测，然后再交送给测试人员，共同把好质量关。开发可能会说我写出来的东西我自己还要测试那还要你做什么。
如果开发的产品连正常流程都无法跑通就交给测试被一次一次的打回，这样不光影响项目进度，还可能会导致该测试人员对你开发出的产品有情绪抵触，质量很难得到保证。！
8.
测试技术学习
测试团队可以定期拿出一个课题由部分专人负责研究，然后定期Share 研究成果，组织团队人员研究讨论，促进工作、学习两不误。
9.
测试人员不够
如果碰到时间紧、任务重、测试周期被缩短的情况。我不建议省略写测试计划、测试用例、测试报告去闷头测试。测试可以分轻重，可以申请安排开发做辅助测试。也不能省略那些书面文字。
不是走形式。测试人员要彻底认识到这些东西是非常有价值的，在适当时候可以保护你。
先写测试用例再测试不是死规矩。事实上应该是这种工作流程，但是有些时候当没有测试用例思路时，可以先手工运行一遍功能，想到什么写什么，最后形成完整规范测试用例（当然，也可以先写测试点）。做到灵活测试。
测试人员有义务向PM 阐述对功能的流程以及易用性方面自己的想法。如果是为了功能的可伸缩性，那就不仅仅是测试人员需要参与讨论有可能还有项目经理 产品经理 研发老大等等。
最初目的是为了以后如何更方便的开展自动化。让自动化能覆盖的更多更全面。
为了保证产品质量测试越早进行越好。不仅是功能测试，其中也包含性能。
更需要单元测试、自动化测试的辅助。
10.
了解当前产品质量
测试人员每个人都应该了解当前产品质量，知道哪块薄弱，知道自己该干什么，提倡每个人都可以提出建设性意见，开发人员告诉测试人员你应该如何测试。
这种现象可以从多方面理解：
1. 作为测试人员你做的不够好，长时间来你充当一个喊话筒的角色，从你以往提交的Bug 来看没有任何深度。想受人尊敬、受人重视还是要靠自己踏实争取。
2. 测试团队不规范，
或者说根本就没有测试团队，让开发领着干活，自己又不会写代码，心理不好受，抱怨多多。
更多时候还是需要自己多努力，知识要靠一点一滴的积累。
很难重现的Bug 你能重现，能告诉开发哪块功能将来可能产生问题，指出系统瓶颈等等类似很多，这些都是需要经验积累。
渐渐的，你会发现自己在团队中起到了应有的价值，得到同事以及上司的认可。
11.
测试环境维护
测试环境由谁来维护，其实我觉得并不重要，这里指的“谁”可以是运维，可以是研发，可以是Tester，但是最好要保证专人来维护，不要谁都可以插手。再没有打招呼的前提下，擅自发布新功能或者修改是不可取的。
保证版本的统一性很重要：要做到正式发布功能之前，OP 可以在测试环境下抓取项目整包进行发布，当然对于极小功能小修改可以例外。
12.
收集需求文档
测试人员为了写出一份还算完整的TestCase东奔西跑，到处收集信息。
开发文档和产品需求文档出炉后请第一时间送交的QA 手里，保证QA 的工作开展
如上可得知，想要达到30K，至少应该具备的能力：
1. 脚本能力，python shell 等
2. 有持续集成这块的经验和能力（如 Jenkins）
3. 有扎实的测试理论知识，有一定的方法论，有测试体系知识
4. Linux 、DB等知识必须具备
5. 有开发语言基础，如Java 、C，至少能看得懂代码
6. 至少有一些自动化测试经验，以及一些自动化框架知识
7. 至少独立负责过某个产品/平台的测试，有一定的事项推动能力
8. 有新人指导能力（这个阶段，一般都要指导一些新人）
9. 对业界常用的测试工具了解
看完如上文章，应该能明白，老徐为何之前多次分享LInux/DB/Shell等方面的文章
1 -
对于有代码经验，并且对测试脚本感兴趣的同学；可以深入到测试技术，往自动化测试方向发展；
推荐学习：jenkins + python + Git + { other }（以及其他自动化测试框架）
- 2 -
对于完全对代码没啥兴趣，看了代码就头晕的同学，就不要思考弄什么自动化测试、性能测试了；
其实功能测试也挺好；
多思考思考业务，多扎实测试理论，以及测试模型，测试分析；
逐渐成为团队测试核心成员
关注项目管理，以及产品这块
后期可转向产品经理，或者项目经理
1、逆向思维方式
● 逆向思维在测试中用的很多，比如根据结果逆推条件，从而得出输入条件的等价类划分
● 其实逆向思维在调试当中用到的也比较多，当发现缺陷时，进一步定位问题的所在，往往就是逆流而上，进行分析
● 逆向思维是相对的，就是按照与常规思路相反的方向进行思考，测试人员往往能够运用它发现开发人员思维的漏洞
2、组合思维方式
● 很多东西单一的思考都没有问题，当将相关的事物组合在一起却能发现很多问题；如多进程并发，让程序的复杂度上了一个台阶，也让程序的缺陷率随之而增长
● 按照是否排序组合可以分为：排列（有序）和组合（无序）；针对不同的应用，可以酌情考虑使用“排列”或者“组合”
● 为了充分利用组合思维而不致于让自己的思维混乱，要注意“分维”，将相关的因素划分到不同的维度上，然后再考虑其相关性
3、全局思维方式
● 事物往往存在多面性，当我们掌握了越多的层面，我们对它的认识就越清楚，越有利于我们掌握其本质，全局思维方式就是让我们从多角度分析待测的系统；试着以不同角色去看系统，分析其是否能够满足需求
● 其实平常我们在软件开发过程中，进行的各种评审，就是借助全局思维的方式，让更多的人参与思考，脑力激荡，尽可能的实现全方位审查某个解决方案的正确性以及其他特性
4、两极思维方式
● 边界值分析是两极思维方式的典范
● 为了看系统的稳定性，我们采用了压力测试
● 两极思维方式，是在极端的情况下，看是否存在缺陷？
● 注意是两极，不是一极
● 测试人员做久了，往往容易走极端——职业病，不利于与人沟通
5、简单思维方式
● 剥离一些非关键特征，追逐事物的本质，让事物简单的只剩下“根本”
● 针对事物本质（解决问题的本质）的测试，让我们不至于偏离方向
6、比较思维方式
● 认识事物时，人们往往都是通过和头脑中的某些概念进行比较，找出相同、相异之处，或者归类，从而将其加入大脑中的知识体系，可能的话，再建立好的搜索方式，以便以后使用
● 应用模式是“比较思维”很常见的例子，现在模式很火，有设计模式、体系结构模式、测试模式、等等，一些专家针对一些相关问题的共性找出来的解决方法，取完名字后，可以让大家方便的复用
● 让经验在这里发挥作用，测试中经验很重要，比较思维是使用经验的方式
7、动起来，更精彩
● 关注程序的运行时状态
● 传统的基于结构的程序可以更多的在代码中反映将来程序的运行方式；而面向对象将代码和运行时显著分离
● 让我们在关注代码静态结构（如类结构）的同时，也要谨慎关注其动态（对象交互网）表现
其实这些思维方式，测试从业者都在有意识或者无意识的使用着，它们各自都有自己的妙处，将我们的思维发散，有意识的将他们用在问题的思考上，有时可以给我们一种“柳暗花明又一村”的感觉。
最后想说，只是知道这些原则意义不是很大，如果真能让它们成为思考的血液，才能发挥它的真正价值。
思维方式需要很多的历练，其实成为一名出色的测试人员，远没有那么简单
需要（不断的学习＋不断的经历＋不断的思考）