今天和同事聊天, 他是一位QTP老手, 对于QTP的开发模式有一些热烈的讨论. 同时对自动化测试的设计也有了一些新的认识.

-- 两种模式
总的来说, 对于QTP自动化测试项目, 两种开发模式:
第一种要充分利用QTP的能力,以Quick的方式开发一个测试项目, 一切以开发效率为目标. 一般适用于中小项目.
第二种关注"分离测试逻辑和执行的操作", 在testcase script和真正的操作中间建立一个强大的中间层. 一般适用于较大的项目.

-- 问题
这种分类看起来很理想, 其实用起来并不那么黑白分明. 问题就在于"测试逻辑"的粒度并不一样. 考虑下面两个testcase
    1. 测试用户的权限
        1. create user 'tom', with role 'admin'
        2. user 'tom' login system
        3. goto 'user management' page
        4. check 'tom' is able to create users
    2. 测试用户的创建
        1. goto 'user management' page
        2. create a new user
              input name 'lucy'
              select role 'normal user'
              input address 'shanghai'
              don't input password
        3. submit form
        4. check requiest failed with error message 'password cannot be blank'

很明显, 这两个testcase里测试逻辑的粒度是不一样的, 第一种非常适合"分离测试逻辑和执行的操作", testcase script可能如下
    createUser('tome', 'admin')
    logout
    login('tom')
    navto('user management')
    assert_true(Botton('create user').exist)

但是第二种就不合适了, 因为它的粒度太细.

有人说, 你可以设计一个createUser, 包含所有的参数, 并且都提供"缺省值", 这样就满足两个testcase的需要了
    createUser(name=>'tom')
    createUser(name=>'tom', role=>'admin', address=>'shanghai')
这种方法带来的问题是,
    1)恐怖的函数参数的增长
    2)还是没法执行error message的检查.

所以, 与其设计精巧的createUser函数, 还不如就使用录制的代码.

-- 解决方法
由此可见, 对于自动化项目的设计, 还是要根据实际情况来. 小项目也能有"reuse", 比如菜单导航这样的功能, 大项目也会有record&replay.

--更进一步
难道我们就只能接受这种抽象层次混杂的test script吗?
其实还有改进的空间的. 那就是对testcae进行分类. 一般针对完整的业务逻辑的测试都适用于第一种. 而针对某些功能点的测试适用于第二种. 在testcae的分类上就做好二者的划分, 比如分成两个不同的测试集合, 测试集合A关注业务逻辑, 用户场景, 测试集合B关注重要功能点的覆盖率. 这样出来的最终结果也是比较漂亮的.