关于测试及其本身的探讨

最近一直在思考这个问题，不管你不得不承认，测试确实是一个很难让所有人都认同的工作，从拿的工资就可以看出来，在那些没有真刀真枪拼出来的项目经理眼中更是如此，甭管有时候说的有多好听。 这的确适合了一部分在IT界发展的女孩子的愿望，问题是一个男人该怎么做, 软件测试人员有没有可能发展到架构师，关键是自己怎么看，想要怎么去发展，有些时候机会很重要，别人听说你是做测试的，即使有这个能力也不给你这个机会，现在做工作不是造原子弹，让别人做也照样做的来，，的确，测试人员在今后的发展中将会面临更大的机遇挑战问题。

软件测试的能力到底要怎么样去体现，在一个项目的实现中，有一个技术头头，会担当一个"架构师"的角色，他会来指导具体的代码实现，只要不是违反大的需求，他就是老大，什么都是他说了算，测试的头头，在他眼中也不过是个二流的角色，高兴了叫给面子，即使项目经理在中间调停，最终也还是会偏向开发的， 可见把开发跟测试混在一起，很容易导致测试成为二流的角色，所以有时候想想，国内想实行敏捷开发，简直是扯淡。。

国内有很多项目是很轻视测试的，一方面是观念问题，一方面是养不起，也不想养，但是教训告诉他，不测又不行，所以多面手在很多项目中是很受欢迎的，就我看来，小的项目，测试人员很少，把测试和开发搞在一起是有利于提高效率的，大的项目，测试和开发是要分开的，最好不要天天能够见面，这样测试只对测试本身和产品负责，而不是对开发负责，负责在其中协调的是项目经理的责任，测试的头头，只负责测试的本身，这样才能与开发对等，测试人员才能将更多的经历投入到测试中，避免成为一个小脚女人，两头不讨好，也避免开发人员自以为是，看不起测试人员，同样也可以避免测试人员不务正业，过分关注开发技术，导致双方的这种不平等加剧。。

任何项目的本身必须要有量化的指标来评定，开发人员，有代码量作为评定指标之一，测试人员也必须有类似于Bug量来作为评定指标之一，当然评定的指标有很多，测试人员更应该有量化的指标，否则很容易给人一种无所事事的感觉，甚至有时候自己否定自己。

关于测试技术，，首先申明一点，编码能力不是测试技术的体现， 测试懂编码似乎是个很流行，也让很多测试的认为很牛逼，也让很多开发看不起测试的原因之一，测试懂编码只是一个必要条件，的确一个测试人员最好能懂一门脚本语言，但是会编码只是一个Coder，不是做开发也不是做测试，做开发有开发的技术做测试有测试的技术，开发认为自己牛逼，其实是认为自己把最主要最重要的东西实现了而已，这其实与国内长期分工不明确造成的，任何一门软件工程的书都会告诉你，实现了系统最多只能算是做了一个流程40%的工作，还有开发人员认为自己也能测试，所以更加轻视测试人员的工作，而事实上测试和开发是必须分开的，一个开发人员可以去做测试，但是必须是专职的。

测试的具体细分在这里不必要多说，测试必须要有清晰的概念和良好的分工，测试人员必须要对所测试的系统有全方位的了解，这点倒是和架构师的责任很相似，所以说测试人员发展成架构师是有可能的，问题是你怎么样来规划你的发展，如果永远只是做做点鼠标的工作，或者只是醉心与自动化的工作，在支支点点和Coder之间徘徊，还不如改行去做编码，这个更能体现你的价值，测试所有的工作是为了更好产品发布和更少的Bug出现，不是为了测试的本身，醉心于测试本身，必然会以偏概全，而不能把握全局是测试人员的大忌。

以本人一年多来的所主要从事两种工作：性能测试和自动化测试为例，性能测试和自动化测试的工具有很多种，几乎每种都有不同的脚本语言，怎么 办？每种工作都去尝试一下？一辈子的时间也不够，要想尽快上手，显然要综合全方位的因素去尽快确定一种工具，然后开展工作，工作的本身是为了产生分析数据（性能测试），减轻工作负担（自动化测试），不必要去醉心与Coder本身，coder的规范化，以及测试框架的扩展性，都是随着项目本身的发展和项目周期长短来决定的，一个字必须“快”，否则自动化很容易堕落为写Coder，这对于一个测试人员来说是可悲的。。（发表于2007年8月16日）