我眼中的软件测试,我眼中的软件测试

曾经，软件测试是软件工程教科书上薄薄的几页四号字，是百度知道上大段的介绍，是想象中繁杂的文档……

百度知道上这样定义软件测试工程师的工作：“软件测试工程师的工作就是利用测试工具按照测试方案和流程对产品进行功能和性能测试，甚至根据需要编写不同的测试工具，设计和维护测试系统，对测试方案可能出现的问题进行分析和评估。执行测试用例后，需要跟踪故障，以确保开发的产品适合需求”。

推敲一下，不难发现其隐含的对软件测试的定义：按照测试方案和流程对产品进行功能和性能测试，确保开发产品适合需求。再仔细推敲，感觉不对，按这个理解，测试只是从需求定下以后入手，以需求为标准，使得产品功能满足需求即可。实际的情况是怎样呢？稍夸张一点说，就像我们不能保证产品不存在bug一样，没有人能保证需求不变动。因此，需求定下以后测试工程师再介入只能是一句空话。

入职以来，亲身的经历是测试工程师从PRD评审阶段就介入了。这样的好处也体会到了：需求不再是word中冷冰冰的字眼，而是评审中经过大家讨论的，烂熟于心的东西，而且一些存在的问题尽早地被挖掘出来，尽早地解决，后期的需求变动减少甚至没有，使得上线前的压力减小。

当然也有一些问题：例如PRD文档写的过于简单或者拿到PRD到评审之间的时间很短，没有时间仔细研究PRD或PRD看的不是很清楚，这样会导致PRD评审的作用和意义就不那么明显了。

PRD评审后，测试的工作就全面铺开了。写TC，执行TC，记录bug，跟踪bug，回归测试，性能测试……各种测试的方法就可以择机而上，根据各自的特点发挥各自的作用，最终的目的就是：从各种角度，最大限度地保证产品的质量和性能。

刚入测试的门槛，心之所发，笔之所至。有不对的地方，大家多指教。