本文写于2012.7.27
================================
前几天在知乎（http://www.zhihu.com/question/20269633）上看到了这么一段，说“测试人员能达到的层次大概有这么几个级别”：
1 开一个bug;
2 查找一些额外的资料如设计文档和历史，确定这是一个问题，然后给出详细的bug重现步骤；
3 对重现步骤做一些精炼，确定能够重现bug的最少步骤；可能的话，将重现步骤做自动化；
4 尝试通过研究代码确认问题所在；
5 尝试给出一个fix；
6 对错误的原因进行分析，提出一些标准化的方法来检测出类似的问题，比如stress，fuzzing等等；
7 能够对标准化的测试流程定义对应的数据分析方法，可以保证开发和项目主管都能从中得到需要的信息来掌控质量状况。
我数了一下自己的，基本上能做到1-3，自己实在是算不上个好测试。当然各方面原因也有，比如公司对软件测试工程师的定义不一样，对自己的要求也的确没有那么高过。我觉得这七个层次是很不错的标准了，对于想长期做测试的人来说可以拿来参考一下。看到这个帖子之后呢，就有了自我总结一下的念头。
我也注意到，国内软件行业，尤其是互联网行业，非常重视自动化测试，从最开始的跑自动化测试、到读脚本改脚本、再到自己整合开源工具写一套脚本、再到自己直接开发自动化测试工具，是很多互联网企业的测试正在热衷的。不过自己所在的部门算是个传统软件行业，所以具体情况具体分析吧。
自己所在的team大约稳定在8-12人，长期组里会有1-2个实习生，负责的产品总计10个左右，项目周期基本是1天-6个月不等，每个项目的参与人数一般1个人-6个人不等。绝大部分产品我们完全没有机会接触到源码，除了我现在手头正在做的，因为老跟着开发加班和开发关系比较熟，代码我也能读到，不过自己没追求，从来不去看>_<
整个team里除了一个lead主要做管理很少做项目，其他的人大约有1-2个会参与自动化测试相关的开发和维护，1-3个是不能独立处理大的release项目需要跟着别人做项目，其他的人基本都有独自做大项目和带人做项目的能力和经验。工作的主要内容基本就是对着用了很久的测试用例做手工测试，纯黑盒。少部分时候会需要自己写测试用例。和别的公司一样，并不是太重视测试用例。
我总结一下自己从09年6月开始实习到现在这三年的一点经历吧。
09年6月-10年6月 internship
第一个月是培训期，对着三大本英文书学习产品。基本三周把三本书看完，每周一做一次presentation总结上周学到的内容，并且同事会提问，最后一周会做一些简单的sample，比如产品的升级、功能的简单回归测试。
第二个月开始处理hotfix，流程大致是：根据相关的defect记录，搭环境，重现问题，应用hotfix，确认问题被修复，跑automation regression。工作这三年我大致做了上百个hotfix，主要都是在实习期做的，毕业之后就不会安排这种活儿了，除非实在没有level更低的人做or某个hotfix是是自己做过的别人没经验。
半年后开始跟着做大的release。大的release包含的内容比hotfix要多一些，最开始一般由level比较高的人写new feature的测试用例，开发给了build之后交叉测试new feature，同时也安排人测defect（一般大的release都包含上个release到现在之间的所有的hotfix）。之后会有manual regression(对着超长超详细的英文文档做手工测试，覆盖几乎所有功能)、automation regression、compatibility（和相关的十多个产品在不同的os和database上之间的兼容性）。再之后基本就是install和doc review了。这几个测试之间有一定的先后顺序，比如install肯定是所有平台的build都出了，所有测试基本都结束之后去做的，不过具体哪个阶段做什么还是要看具体的情况，有时候项目快要结束了defect忽然开始爆发。
在没有大的release的时候基本就在忙hotfix，也有闲着的时候，自己上上网看看书什么的。
10年7月-11年7月 graduate=level 0
毕业之后没多久就开始做一个新出的很小的产品的测试，自己针对new feature和功能测试写测试用例，没有自动化测试，整个测试阶段自己大致负责了一半，由一个比我高两届的MM来带我。那个产品release之后到现在也没有下一个版本，不过也没有hotfix（意味着客户这么久都没有提bug）。
之间跟着做了些产品的release，这时候才基本熟悉了大的release的基本流程和步骤。11年4月开始花了两个月在维护一套很老的silktest的脚本，觉得这套脚本设计的很好，覆盖的功能很全，高内聚低耦合，之前为这套自动化测试脚本写测试用例的人很牛。相反，觉得脚本本身倒不是什么特别难的东西。期间也用java调一些api去测一点性能，不算重点，但是比手工测试必然要有意思得多。
11年7月-12年3月 junior=level 1
开始在头儿的指导下带领俩实习生做大的release，期间遇到了一些问题，比如这次release的变动很大（数据库结构变了），要测的覆盖面会比较多，但是之前留下来的测试用例有一些问题，比如写的极详细，阅读两三页的英文文档要花半小时，操作却只要可能几分钟，或者这么多年来产品更新之后，有些测试用例基本是无效的或者没有意义的，但是一直没有更新，也有部分测试用例写得过于简洁，以至于读起来特别费劲，但是读懂之后就容易得多。i所以每当一个测试阶段结束之后开发给下一个版本的build之前，还要抓紧时间按照自己的理解去更新测试用例（有的地方甚至完全没有测试用例），然后在下一阶段交叉测试，然后再更新。这个项目做了大概三个月之后，因为开发遇到了困难，加上项目本身优先级不高，于是暂时搁置了。
这期间也是跟着做另外的产品的release，做离职同事的交接，学点东西。
12年4月-现在 senior=level 2
挂牌成了个senior engineer，4月开始做一个release，预计8月中旬结束。这次算是真正意义上的在进度压力下去带人做。lead一个项目的时候要考虑的事情比跟着别人做项目要多得多，至少会有一种“这是我自己带出来的产品，我要对它的质量负责”的心态，就算要加班也是心甘情愿，不会有“跟着文档做就行了不用动脑子想”的态度。同时要规划整个测试阶段的进度安排，根据人员的能力去安排任务，和他们沟通让他们愿意更努力一些，去和开发沟通推动问题解决，等等。遇到了很多问题，犯了不少错误，在同事的指导下有的很快改了，有的产生了一些不良后果。这个过程中学到了很多东西，并不仅仅是技术上的。
如果继续做软件测试……
下一阶段我会倾向于把精力放在自动化测试上，希望能有大段的时间专心弄一套东西出来，之前和lead聊过，他也挺有意向。有这个想法的原因有几个，一方面当然是因为自动化测试的经历能给自己当块敲门砖啦，一方面是因为没有项目的压力做一些有意思的事情会让上班变得“幸福”一些：）女生可能赚钱的压力没有男生那么大，我觉得在一个氛围很open工作比较轻松的公司待着学了很多东西而且还有钱赚，比在氛围很open学习比较轻松的学校待着学了很多东西可是还要付给学校一大笔钱要有意思点儿。
当然有时候的确会很累，下班了之后眼睛都是直的。有时候也会因为一些沟通的问题弄得自己很沮丧，有时候会担心项目而自己跑去加班，有时候也会因为状态不佳无心工作而效率低下，事后要么加班要么打鸡血把进度给赶回来。毕竟bug是无限的，而时间和资源是有限的，所以在有限的时间内测了自己想到的能测的该测的各种东西之后，基本就只剩下上帝保佑产品到了客户那边可千万不要出问题。反正到目前为止，我仍然是个很菜的小测试。。。
路漫漫其修远兮，吾将上上下下左左右右ABBA而求索。
