自主开发自动化测试工具（一）

一提到自动化测试工具，大家都会想到QTP, LoadRunner, Silk Test这样的企业级第三方自动化测试工具，不可否认，这些工具的功能强大，支持平台广泛，易操作，基于RPF的机制也降低了对测试人员技术的要求，可以将更多的时间放在测试流程，测试用例和脚本更新上。但是，这些企业级第三方自动化测试工具对于一些企业来讲并不适合，主要原因有：

一、企业花很大的成本去购买这些自动化测试工具，然而却不能物尽其用，甚至只是体现自动化测试水平的一个摆设。

二、对于中小型企业，购买工具的成本是一笔很大的投入。

三、对于某些测试场景，第三方测试工具显得力不从心。

四、某些情况下，应用程序的对象不能被正常识别。（当然有很多其他的方法可以解决，比如QTP中的虚拟对象，描述性编程等）

针对于第三点，我们设想以下场景：

一、应用程序在进行安装卸载测试过程中往往要设置非正常环境，如硬盘、内存空间不足的情况下去进行安装。如果安装测试做的不好，就有可能安装到一半出现硬盘空间不足，安装中止，你想腾出一部分空间后再次安装，程序提示该程序已安装，请先卸载后再安装，你想完全卸载，程序又提示，某DLL丢失，未能正常卸载…然后只有删除注册表键值，删除文件夹后再去安装。

一般我们做此类测试的办法是准备一系列“砝码”，用1M，10M，100M，1G的文件去配比，直到硬盘空间小到临界值（例如100M），但这样不但费时，精准性也难以把握。

所以我们可以自己写个小程序，在毫秒级生成一个大的空文件来占位，然后再运行安装测试，测试结束后，直接将该文件删除即可。这样可以极大程度上提高测试效率。甚至我们可以把程序作为自动化测试的前期环境搭建环节及后期的恢复环节加到整个自动化测试中去。

二、某个产品要做性能优化，针对相同内容的文件做格式压缩处理。例如1.0版本的一个文档大小是1M，在2.0版本中希望把文档大小降至800K。

        我们通常的做法只能是打开2个文件列表窗口，一个文件一个文件去对比，效率极低。针对这种验证也可以自己开发个小程序，将2套文件大小的信息读进来做对比，然后通过XML＋XSL的形式输出，凡是2.0的文件大于1.0的用红色的FAIL表示，小于等于的用绿色的PASS表示。我们还可以设置对比阀值，如2.0的文件在1.2M以下就认为是合法的。

 

    在微软，测试的职位通常是SDET（软件测试开发工程师），当然也有STE，但大多数都外包了。SDET的主要职责就是开发自动化测试工具供项目使用，这样最大的好处是可以实现与项目的无缝兼容性，便于更新，维护，重用。