GUI的自动化测试可以由简入难分成三种类型：

　　1）纪录回放类：

　　这一类不需要太多的计划，编程和调试。优点在于简单，方便。缺点在于稳定性差，所以脚本运行寿命短，而且与不同配置的兼容性差。同时由于缺少结果的验证部分，基本上找不到什么Bug。可考虑在产品开发接近尾声时，用于尚未自动化的已知Bug的回归检验。

　　2）测试用例自动化类：

　　这一类是指将需要反复测试或在多种配置下重复测试的用例自动化。基本实现过程通常为：

　　- 设计测试计划

　　- 设计测试用例

　　- 针对每一个用例评估自动化的可行性和经济性

　　- 将决定要自动化的用例作详细步骤分解。

　　- 编写公用步骤，公用资源库（Logging 和 exception handling 部分是必不可少的）

　　- 编写自动化程序 （别忘了结果的验证部分）

　　- 调试

　　- 实际运行

　　这一类自动化测试最为灵活，也能发现较多的Bug。又能较好的与测试计划相协调。当前多数测试做的比较好的企业都主要使用这种类型的自动化。

　　3）自动测试类：

　　这一类是指自动生成测试用例并自动运行。这类自动化测试的最大的优点在于它的无限可能性。另外它通常能发现手工测试极难发现的错误。而且一旦实现了这种自动化，其维护费用实际上是大大低于前两类测试的。不过这类测试自动化的初始投入非常高，而且它的效果受其智能化程度的制约也非常大。除非是专业测试公司或是象微软、IBM这类超大型企业，多半都没有实力来研究这类测试自动化。

　　不过从长远来说，只要有较好的工具能将这类自动化的初始投入降下来，这类测试自动化才是软件测试发展的必然方向。

　　这一类测试的基本实现过程通常是：

　　- 购买或开发基本测试自动化框架

　　- 编写必要的接口，钩子，及其他公用资源。

　　- 建立软件、组件、或功能的行为模型

　　- 设立测试目标等参数

　　- 自动生成测试用例及测试计划

　　- 筛选并运行测试用例

　　- 评估结果

　　原帖地址：http://bbs.51testing.com/thread-562-1-1.html

版权声明：本文由会员 minz32 首发于51Testing软件测试论坛。

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。