前言
在公司已经干了6年的测试了，干测试经理也5年了。眼看就要离开奋战了6年的岗位，还真有点儿舍不得。但没办法，该离开的时候就要离开，光伤感是没有用的。正好趁此机会把自己6年来一直想写但没写的东西写出来。这篇文件纯粹是对自己工作的回顾。由于时间仓促基本上是想到什么些什么，有点儿乱，也请大家多多担待了。只要还有些人能从中找到些儿同感，或从中得到一些帮助，一些经验，我就知足了。
什么是测试
首先我要谈谈什么是测试。相信好多测试人员跟我一样，来公司之前也没有从事过任何测试工作。对于测试都是从零开始的。也有好多人跟我一样，从各种书上或是培训中得到过有关测试的各种定义。但不知道大家有没有净下心思考一下。什么是测试。在公司公司测试工作的定义是什么，测试的工作范围是什么。
测试的定义根据测试技术的发展，历经了3个主要的阶段。第一个阶段，认为测试就是找产品中的bug。第二个阶段，除了找bug以外，又增加测试是对软件质量的度量这一概念。第三个阶段，明确了测试是指为了度量和提高被测试软件的质量，对测试件进行工程设计，使用和维护的并发生命周期。注意其中提高的测试件，其主要是与软件这个词进行对应。明确测试也是一种开发过程。他的工作成果就是测试件，好像平时我们所谓的测试案例、测试脚本等等都可以称为测试件。然后使用测试件去度量和提高被测试软件的质量。
目前，在中国大部分软件企业，尤其是中小型的软件企业还停留在第一阶段。我个人觉得公司稍微好一点儿，处于一、二阶段之间。因为我们平时做的最多的一件事，还是找bug。至于测试案例和测试脚本等等，只占用工作量的很小一部分。而且我看不到大家在平时的测试工作中是完全依据测试案例进行测试的。目前测试案例等工作更多的成为了一种形式上的产物。从有些部分所有产品的测试案例在一个下午就能评审完就能看得出来。
说到这里顺便在谈一句测试计划。目前的测试计划是作为产品计划的一部分。先明确大概发版时间，然后是各个阶段的里程碑，其中提交集成的里程碑是死的。开发需要的时间就是那么多，剩下倒推的时间就是测试的时间。这样定出的计划是否能够起到计划的作用就不好说了。现在的计划更多的是罗列联调测试的各种内容，至于时间，不说也罢。所以从中也可以开出公司的测试也就停留在一、二阶段之间。
明确了公司测试的定义（个人理解），也就不难理解公司给测试人员的定位了。在测试人员中经常流传的一种说法就是国外测试人员的地位多么多么的高，开发就是coding。咱们公司开发比测试多拿多少多少，测试人员地位是开发序列中最低的。大家也要看看人家公司测试人员的素质，测试在开发过程中的重要性。再看看自己所从事的工作，就是找软件的bug。当然我也个人认为有经验极其丰富的测试人员对产品的贡献比开发和需求大。明确了这些，心里也就能少点儿不平衡感。
测试方法的思考
说完个人对测试含义的理解，再说说个人对测试方案的一些思考。
个人认为在公司6年，测试方法没有什么提高。主要还是以黑盒测试为主。中间也曾经引入过各种各种工具，但测试人员真正用起来的也就是robot。而且robot主要是进行回归测试，再加上一些人并没有真正认识到其价值，应用范围也极其有限。对整体测试效率的提升影响不大。所以目前的测试方案还主要是以需求为依据的黑盒测试。至于什么极限值了，成对测试法等等，都是建立在黑盒测试的基础上，而且从我一来公司就有相应的测试项目，只不过没有明确概念而已。
另一个说个人觉得6年来公司测试方法没有什么提高的原因是，6年前测试是以人为主，靠得是测试人员的经验，对产品的熟悉程度，对业务的理解程度。6年后测试还是以人为主，人就是测试的主体，产品质量的保证。还没有过渡到测试案例就是测试的主体，测试案例的完整性是产品质量的保证。只要测试还是以人为本，我觉得测试的效率就不会有太大提高，产品质量的信心来源也是对相关测试人员的信任。
我个人觉得以黑盒测试为主要的测试方法没错，而且也比较符合目前公司的测试现状。但一定要注意各种经验的总结、积累，更重要的是共享。虽然目前测试案例在测试工作过程中的地位不重要，但其毕竟是编写者的经验积累。汇总起来也是一笔可观的财富。可现在如果有人问我850的测试方案在那里，其中还有多大比例能够用在现在的产品中，在现在的测试工作中有多少以前的案例能够复用。其他产品中的测试案例中有多少是关于接口功能，有多少我可以借鉴。我不知道，这也是自己工作不到位的地方。所以我要说的作为黑盒测试为主要的测试方法，一定要注意测试经验的总结和共享。
文章来源于领测软件测试网 https://www.ltesting.net/