软件测试自动化方案探讨(一)自动化测试的发展及定义

软件测试自动化方案探讨

 

一、 自动化测试的发展

 

软件研发的发展过程，就像我们社会发展的过程一样，从刚开始的手工磨坊式，逐步的发展到现在的分工协作、流程化。每个阶段的改变，都夹杂着大量的改变方向与争论。最终，真正适合程序员与企业应用结合的，形成了我们现在的标准。从上世纪90年代起，针对软件自动化测试就已经开始，并且相应的工具就层出不穷。总体来说，按照时间段及特点，自动化测试可以分为以下几个阶段：
 
第一阶段的自动化测试大概在上世纪90年代初开始，透过硬件的方式录制键盘的输入并播放，但缺少检查点（checkpoint）的功能，而且测试脚本很难维护。

 

于是在上世纪90年代末，进入了第二阶段，这时已经由硬件转变成透过软件录制/播放（capture/playback）的方式产生测试脚本（script）， 并且也增加了检查点的功能，可以对软件做验证，测试的范围也比硬件方式的自动化方式大了许多。比较大的问题是测试脚本也是一种程序语言，所以测试人员也需要懂程序语言，换句话说就是要会写程序。而且当软件有变动时，测试脚本也需要同步更新，这对测试人员来说是一大挑战，测试人员常常就是整个测试脚本再重新录制一遍。

 

为了解决上述问题，在2001年诞生了第三代的自动化测试，我们称之为测试框架“test framework”，主要是把测试脚本给抽象化（abstraction）（注：如Keyword-Driven Test—关键字驱动测试），让非技术人员（如系统分析师、使用者等）即使不懂测试脚本，不会写程序的情况下，也可以使用自动化测试工具建立自动化测试个案。其后诞生了代表性的像Rational robot 和Mercury loadrunner这样的商业化工具。

 

在这个阶段之前，除了极少数对自动化测试重视的企业外（像微软，研究适合自己的自动化测试方式方法、研发自动化测试工具，而发展成自动化覆盖率很高的软件研发公司），大部分都对自动化测试不重视，当现在意识到自动化测试的重要性的时候，由于前期投入不够，只能从市场上选择商业工具进行自动化尝试。而市场上的商业化工具，有三大缺点：一是高昂的价格，二是用例库的维护难度太大及重用性低，三是这些工具不能扩展开发及与其他工具配合形成自动化平台。这些缺点阻碍了中小软件企业自动化测试的推广。

基于第三阶段的这些问题，促进一些组织和个人开始开发一些开源的，适合于中小企业应用的开源的自动化测试工具及模式。随着互联网的大量普及，大大提升软件业者的沟通效率，更加促进开源自动化测试的发展。由于这种模式往往是由一些个人爱好者形成的组织进行的研究与研发，所以形成的工具往往只针对与某一方面，且一些功能未实现的缺点。但其开源的模式，弥补了这些缺点，应用者可以根据自己的实际情况随意定制扩展自动化测试功能，并可以和其它开源框架结合形成一个完整的自动化平台。于是，自动化测试，进入了第四阶段。

 

二、 自动化测试的定义及划分

 

跟据我们的测试模式，自动化测试可以分为基于白盒/灰盒测试的自动化和基于黑盒测试的自动化。

基于白盒/灰盒测试的自动化，主要是针对黑盒无法覆盖的软件功能部分，通过白盒的方式，利用编写的程序进行自动化测试。如白盒的路径、逻辑、数据结构测试及灰盒的API  or 接口测试等等。这种自动化测试的特点是利用自己写的代码或者工具对软件进行测试，对测试人员的要求很高，不仅要有相当高的编程水平，还要对被测对象的内部逻辑结构非常了解。当然，

基于黒盒的自动化测试，就很容易理解了。就是通过一种或者多种工具，通过模拟用户操作的方式，对被测对象进行自动化测试。这种测试，就是我们通常所理解的自动化测试。由于该种自动化测试通过易用的工具对被测对象进行测试，因此，该种模式，对测试人员要求相对较低，只要熟悉业务及简单的脚本编写能力即可，更容易推广。

一般情况下，基于白盒/灰盒测试的自动化，我们通常划拨到白盒测试的范畴，而不属于自动化测试。因此，本文是以基于黒盒的自动化测试为基础，与大家一起讨论自动化实施的方案。