测试还是开发？ 

粗略算来，从事测试工作也有3年了，其实自己对测试确实没一点兴趣，最开始也只是因为白盒测试部能够熟悉服务器代码才决定进入测试部的，这三年来也看着公司的白盒测试部从最初创建到后来一步步的成长，包括公司的测试部门从开始的凌乱到逐步规范到现在完全的过程管理，整个测试部都是朝着一个比较好的方向发展的。《软件测试的艺术》自己都不知道读过多少遍了，测试的理论、流程已经烂熟于心了，但是理论和实践之间差距确实很遥远。
    初期白盒刚成立，花了半年的时间熟悉代码写注释，真是把那些代码当书看，从一开始的毫无头绪到逐渐学习到如何阅读代码，发现能够看懂代码也是一种能力啊，后面看MySQL代码也不是很费劲了，这期间只是分析了一些存在比较大的性能问题的功能如何改进之类的问题，另外就是熟悉工具，老大从网上不断的搜集着资料，什么样的工具可能有用，然后就研究，看看是否适用与我们的产品，Devepartner、Thread Profile、Performance Analyzer、Insure C++……一大堆的工具，一大堆的英文文档，熟悉一个写个文档做个报告，那时候就感觉这个很强大，那个不错，这个蛮合适，那个也可以用，后面真正用起来才发现各有个的优点，功能强大的不一定是适合你这个产品的。最终适用Devepartner来做覆盖率测试，当把所有测试用例跑了一遍之后，惊讶的发现，覆盖率居然50%都不到，也就是说50%的代码测试部门都是没有测试过的，就拿去给用户使用了，这也反应出了黑盒测试用例的不充分，之后固定有一名同事专门用来提升覆盖率，根据没覆盖到的代码编写测试用例，花了差不多一年多时间，最终才把覆盖率提升到80%多点，期间确实发现了很多的bug，但是毕竟目前只能做到语句覆盖而已，这样来提升覆盖率，即使达到95%，难道就能说明测试用例很充分了么？从而开始思索怎样写测试用例才能尽可能的保证其充分性？后面公司推行CMMI，开始对测试有了过程控制，需求完成后就开始编写测试方案，测试方案尽可能的挖掘出需求中的需求项，子需求项，给后面测试用例的编写提供大方向上的指导，并通过多人评审来保证方案的完备性，这样的措施确实对后面测试用例的完备性有很大的帮助，单个模块的覆盖率也有了很大程度的提升，不需要特别的针对没覆盖到的代码来大规模的编写测试用例，覆盖率也只是一个指导而已，但是现在就开始发现Devepartner只能测所有的覆盖率，没办法统计某几个文件的某些函数所组成的模块的覆盖率，于是提取需求，编写工具……
    系统中有时候还会出现线程之间的死锁问题，这时候想到Intel的线程检测工具，这个工具确实很强大，能够给出每个线程执行的函数调用图，每个函数消耗的时间，也能够检测线程之间资源竞争和死锁，但是前提是你的用例要能够跑出死锁情况来，死锁发生经常是偶然性的，并不是每次都那么容易重现出来，试验了很多次都无功而返，最终采用最笨的手段，人工检测，找出所有的竞争资源，分析使用情况，但是代码确实太庞大了，这样的工作人工进行不仅耗时，而且经常分析几天没个结果，怎么才能静态的自动化检测死锁？操作系统课上说，如果资源的分配都按照优先级顺序来分配释放的话，则可以避免死锁，那么写个工具把程序里面的所有竞争资源列出来，按照目前调用方式分配一个优先级，然后把所有使用到这些资源的函数子函数调用流程记录下来，分析申请资源优先级是否一致应该就可以把潜在的死锁问题的地方都找出来吧？于是提取需求，编写工具……
    当程序变得越来越庞大，内存泄漏总是躲在某个角落里面偷着笑，有很多的工具都可以检测系统的内存泄漏，Devepartner的Error Detection组件就可以，开源的vld也可以，但是我们的内存管理都是自己的，一次申请的一大块内存堆来自己调度，而那些工具都只能检测操作系统的内存分配函数，没办法，又是提取需求，看了vld的源代码，自己动手写工具……
    仔细回忆起来，这三年其实还是做了不少的测试工作哦，还有很多的东西没有写进来，如果有兴趣还是可以和同行交流一下：）但是内心却有个想法却一直在骚扰我：要是这些都做完了怎么办？如果这些都形成了流程，随便找个人培训一下都可以做了，那我接下来再做什么呢？做模块测试，根据接口写测试用例？除了对外提供的接口，对内的模块之间一般都很难实施。做代码走查？代码逻辑总是没开发人员熟悉，每次也只能发现一些编码问题而已。自己都不知道做什么了，经验太少了，国外的跨国公司到底怎么测试的呢？不知道，相信就是了解一点也只是皮毛。
    测试确实很有技术含量，要把测试做好真的很难，但自己见识少，不知道好的测试到底是什么样的，做开发的欲望还是把测试的欲望打压了下去，找家适合自己的公司做开发吧：）也许那会是测试的一个全新开始呢！