3、自动化测试辨析

　　提及自动化测试，如果单纯这么说，那么范围非常广泛。单元测试的自动化，功能测试自动化，性能测试自动化都属于自动化测试的范畴。而我们常说的自动化测试往往指的是UI功能自动化测试。

　　其实，在自动化测试领域，较为成熟的应用集中在单元功能自动化测试和性能自动化测试。在单元自动化测试阶段，现在产生了很多成熟的理论和方法，指导着工作的开展与展开。

　　在我个人的编码过程中，也尝试过测试驱动开发，在功能编写之前先进行测试代码的编写，当然，我使用的语言往往是Python，用的是Python的白盒自动化测试框架：unittest。然后，这种模式是和语言无关的，包括各种*unit。

　　在后续的代码开发和重构中，之前构建的白盒测试用例也都有效的节约了测试的劳动力，大大提高了测试的覆盖度。

　　性能自动化测试工具的应用比较多。像我的工作中往往关注进程本身的CUP,内存，发展到后续的I/O，子进程数量，线程数等等。这些也都有成熟的工具可以应用。对于典型的协议层面的性能自动化测试，LR是比较成熟的工具。

　　曾经和一个自认为测试技术不错的人探讨过，他尊称LR为性能测试之王，对此我深表遗憾。还有很多非常好的性能自动化测试工具。我们的产品特性让我有机会接触到业界的思博伦，BPS等等厂商的性能测试设备，进行二三层的测试工作。

　　在这些测试工具中，开放了良好的二次开发接口，可以进行自动化测试工具。

　　当然，包括LR，包括思博伦或者BPS等厂商的测试设备，价值不菲。还有一种比较极端的请款就是自我开发。自我开发的工作难度比较过，因为要模拟并发很难，不过在一些要求并非十分严格的情况下，也是一种实现方式。

　　说了这么多，只是想说明，当我们在探讨自动化测试这个话题时，要明确其范围，这个领域非常的广，如果范围不清，探讨就不再有其意义。

　　4、关于自动化测试发展的思考

　　上面谈及了自动化测试的诸多领域。而我也一直在思考如果在我们实际的工作中应用自动化测试辅助我们的功能进行。

　　当前的UI功能自动化层面从业人员比较多，多也有回归测试阶段节约资源的观点。但我想，现在我们是否可以打破自己的视野，将自动化测试提前到前端去，而不是简单的后端被动应用。

　　首先说说UI的功能测试自动化。现在的技术发展据说有：应用为王的口号，在产品开发技术的逐渐成熟下，技术壁垒越来越低，而客户的感知往往决定着产品的成败。所以对于UI方面的测试重视逐步提高。

　　由此衍生了诸多的UI自动化测试方法的工具，QTP，Selenium，TC等等，太多了。

　　然后，抛开这些工具，让我们来思考UI功能自动化测试本身，它自身的投入产出比，我们当前是否做的足够好？

　　先说听到的两个案例吧：

　　1）看到微软的测试人员写的一篇论文，在浏览器兼容性测试之前，通过编码实现HTTP协议的GET，POST等函数，进行与后端web服务器的功能交互，验证功能的有效性。

　　从这个测试模式可以看出，至少在此测试阶段，弱化了UI的测试，而主要进行接口层面的功能验证。这也体现了模块化，解耦合的思想。后续当然也会进行UI的测试工作，但也许后续的会种感受，轻功能，当然是有相应的策略了，在此不作揣测。