逆流而上的软件测试

呵呵，又当了一回标题党。

这里说的逆流而上不是说什么东西在下滑而测试在上升，想说的意思是逆流程而上。

最近有机会去参加taobao的测试大会，通过大家问的问题发现不少的同行们对于测试还是有很多的疑问，常见的一个就是关于QA（软件测试人员的一种称呼）的value的问题。如果只是在软件开发好了之后去找问题，或者验证，那样value究竟有多大？

这是一个很难回答的问题，因为最大的难点在于各个不同组织的状况、需求、认识，还有所处的阶段。

这里基于个人的经验和思考说说我自己的一些看法。

从我看到的一些资料，最早的软件测试比较类似于debugging，就是程序运行出错之后去调试，很多时候应该是developer自己去做的。然后边调边去验证，某种程度上也不算是现在所谓的测试。

后来，测试往前走了，在交付使用之前，在内部先验证是否可以使用。这个时候，整个开发过程已经结束了。测试是针对整个系统的测试。

再往前走，就是在整个系统没有完成，而部分功能完成的时候开始测试，这是功能级别的测试，是我们通常所说的功能测试。

进一步向前，在一小块代码完成之后就开始测试，就有了单元测试。

如果很多时候一开始的设计就是有问题，那也不太可能做出正确的产品，所以就有了设计和SRS（software requirement specification）的测试，这种测试开展的形式是review，就是对于产品spec和design的评审，看是否满足要求，是否合理，是否有可测性等等。

结合我们的实践来看，从前面的测试过程走到这一步是有很大的益处，对quality的提高非常有帮助，及早的发现和阻止了很多问题，也帮助大家一起很早的时候就想到很多问题。而且如Weinberg在《完美软件》第16章中所说的，“即使测试人员真的不能在评审过程中找到缺陷（事实并非如此），他们也可以从评审的经历中学到一些东西，