规划自动化测试:测试用例,测试脚本,测试框架

huangcm

在执行QTP自动化测试前其设计的测试用例应该注意些什么

感觉应该和手工测试设计的测试用例会有所不同吧,至少注意点不一样吧.

有过QTP自动化实施经验的请说说,应该怎么设计更好些

[ 本帖最后由 huangcm 于 2007-2-5 17:45 编辑 ]

beginnl

我做自动化测试时依照的用例大部分还是参照手动测试时写的用例。我说说我的经验，大家一起探讨下：
1）关注点不同
自动化测试的每个用例测到的会有好几个功能点。
手工测试的每个用例测的可能就是具体的一个功能点。
2）用例编写方式不同
自动化测试的每个用例一般都是会从新增开始，到删除结束，做过的操作数据会在最后删除。
手工测试的每个用例不用关注数据是否保留。
3）其他
自动化测试的每个用例的起始页面和退出页面一般都是同一个页面，从哪里开始，在哪里结束。
手工测试用例无这个要求。

举例说有这样一个模块，下分三个功能：新建用户，修改用户，删除用户。
我录脚本时一般会录制2个，1。登录－新建用户－删除用户－登出；2。登录－新建用户－修改用户－删除用户－登出。
注：登录，登出事先录制好一个通用的脚本，供其他脚本调用。

在1。新建用户－删除用户脚本中，新建用户又分成好几个action，如必须输入项检查，非法字符检查，最大长度检查等等，最后才输入完全合法的值创建新用户，创建用户成功后再直接删除。
2。新建用户－修改用户－删除用户脚本中，新建用户这块不需再录制，直接调用第一个脚本中的action，接着与第一个脚本中一样，录制修改用户的action，最后再删除用户。

kevin_swpi

先顶楼上的一个
"
在1。新建用户－删除用户脚本中，新建用户又分成好几个action，如必须输入项检查，非法字符检查，最大长度检查等等，最后才输入完全合法的值创建新用户，创建用户成功后再直接删除。
"
这一步是不是可以不用多个ACTION
直接就一个副本 然后在这个副本中包含一些检查项目或者其他的操作
对于一些输入的规范的话 就可以直接设置参数 然后在数据表中循环读取就是了

个人意见sdlkfj5

huangcm

谢谢beginnl的回复,
有些地方不是很明白,再问你下

"我录脚本时一般会录制2个，1。登录－新建用户－删除用户－登出；2。登录－新建用户－修改用户－删除用户－登出。"
其中2不是已经都包含了1中的用例调用,那是否只要一个2就可以了

就是是否可以这样
各个功能单独为一个用例脚本: 新建用户 ,  修改用户  ,   删除用户
之后在建一个测试,调用各脚本: 登录－新建用户－修改用户－删除用户－登出

(当然这样就会存在各个功能用例不能相互独立:
如 "修改用户"功能的测试用例可能要在 "新增用户"功能测试用例执行完之后,
但是可以把 新建用户－修改用户－删除用户 当做一个 用例来看,那就是独立的)

[ 本帖最后由 huangcm 于 2007-1-30 15:59 编辑 ]

huangcm

这个是我看"软件测试自动化"电子书,贴出一部分内容, 有些我也不是很理解,大家可以说说自己的意见:

自动化测试用例设计原则：
1）        设计相互独立的测试用例。测试用例的独立性能够保证一个测试用例不依赖另一个测试的成功完成来运行（不依赖于前一个测试用例的结果）。它也确保了即使在无人干预的情况下，自动化测试套件也能得出结果。如果不独立，第一随后的实验可能无法执行，分离失败的原因变的困难。
2）        设计自包含式的（self-contained）测试用例， 具有基准数据库这样基本状态的需求，基本状态消除了测试用例之间的线性依赖。
3）        设计基于出发点的（home-based）测试用例。如果每个测试用例都是从一个己知点开始而目结束后会进行清理．这样做可以确保每个脚本都与先前测试脚本一样开始于同样的条件．有助于保证测试脚本是独立的。
4）        设计无重叠的测试用例

创建自动化测试用例的三步方法；，下面给出了具体的实施方案：
    第一步：设计测试用例-Fuchs说每一个测试用例都应该包含1-10个密叨相关的场景-具有10个以上场景的测试用例应该分成多个测试用例．每个场景都应该与一个惟一的预期结果相关联。
    第二步：手工运行测试。Fuchs指出在回归测试中自动化测试是发现错误的最好方法，而在第一回合中用手工测试比较好；
    第三步．自动化测试用例。在每个测试场景中．测试脚本应该包含以下几个部分：
  ．进行设置
  ．进行测试
  ．验证结果
  ．记录结果
  ．处理意外情况：跟踪意外情况并对它们进行恢复。
  ．决定停止还是继续测试用例
  。进行清理工作：测试用例返回到出发点。

beginnl

谢谢你的意见！
我的做法是这样的：
在新建用户的时候我也录制了2个action，如create user-valid,create user-invalid，两个action相对独立的说。这样在其他模块中要调用新建用户这个脚本时，只需调用create user－valid，不用重新去验证invlid部分了。

对于一些输入的规范的话 就可以直接设置参数 然后在数据表中循环读取就是了。－这个方法怎么做的，能具体点说说吗？偶的方法笨笨的说^_^

beginnl

我录脚本时一般会录制2个，1。登录－新建用户－删除用户－登出；2。登录－新建用户－修改用户－删除用户－登出。"
其中2不是已经都包含了1中的用例调用,那是否只要一个2就可以了

答：两个脚本还是有区别的，因为第二个脚本经过了修改用户这一步操作，数据会有改动，如果对这些改动不加验证点验证倒是可以调用同一个脚本，但验证点会有变动，这时可以调用删除用户这个action的副本，然后再修改下验证点。

wssgily

原帖由 huangcm 于 2007-1-30 15:17 发表
这个是我看"软件测试自动化"电子书,贴出一部分内容, 有些我也不是很理解,大家可以说说自己的意见:

自动化测试用例设计原则：
1）        设计相互独立的测试用例。测试用例的独立性能够保证一个测试用例 ...

能否把你的这本"软件测试自动化",共享一下,大家都学习一下,或者发到我的信箱可以吗?谢谢!
c7v8@hotmail.com

huangcm

软件测试自动化,我已经上传共享,没有的话可以去下载
http://bbs.51testing.com/thread-64429-1-1.html

huangcm

谢谢大家的回复,对于 设计自动化测试用例 和 脚本ACTION的架构
我在研究下,再和大家一起讨论

keynes_2005

挺好的. 学习一下!

walker1020

从本质上来说，为使用QTP而设计的测试用例和为进行手工测试而设计的测试用例没有什么区别，因为QTP只是代替了某些手工操作步骤。至于beginnl 说的那几点不同，其实也不算它们的不同，因为我要求他们写测试用例的时候，这几点都要考虑到的，无论是手工测试还是用QTP进行测试。
当然，手工测试相对来说随意一些，但也可能会遗漏某些检查点；用QTP进行测试对脚本有一定的要求（如开始页面和最好的结束页面要一致），但它进行多次的、大量的测试后，仍然可以保证把脚本中的检查点都测试一遍。
个人观点，仅供参考。

chris_328

我觉得完全可以作为一个自动化测试流程来做，Action的运行和验证点的执行可以实现自动控制，只做一个流程对于脚本编写的效率和今后的维护成本都非常好，自动化测试不应该是录制手工测试用例的脚本，脚本设计也很重要
个人观点sdlkfj5

huangcm

经过我几天来的研究，我觉得从自动化测试用例来说，与手动区别还是不大的，beginnl说的这点很赞同：
自动化测试的每个用例测到的会有好几个功能点。
手工测试的每个用例测的可能就是具体的一个功能点。

但在设计脚本时，要设计一个测试框架，在基于测试框架上设计各Action脚本会起到事半功能的效果。测试框架需要独立于应用程序。脚本必须独立测试用例。
也就是说设计的测试框架不能因为换了一个应用程序就无法使用了，脚本也不能因为换了个测试用例数据就要进行大修改维护。

如用户管理模块，我分别设计了 新增用户，修改用户，删除用户  三个Action。 这三个脚本相互独立，不依赖于前一个脚本执行结果的成功．
针对测试用例１： 新增A 修改 B 删除 c，
我用一个主脚本，调用　新增用户，修改用户，删除用户  三个Action。
直接在数据驱动中录入测试数据Ａ；Ｂ；Ｃ，便可执行．
而无法修改Action来满足执行的测试数据

针对测试用例2：新增 B C D
我用一个主脚本，调用　新增用户   Action。
直接在数据驱动中录入测试数据B；C；D，便可执行．

在数据驱动中增加一些字段用来区分调用什么Action,进行什么验证等等,这个由你设计的测试框架和功能决定.

[ 本帖最后由 huangcm 于 2007-2-5 13:06 编辑 ]

hiyizhiyu

"自动化测试的每个用例测到的会有好几个功能点",之所以这样说,只是我们开发脚本的一个体会.但假如让一个没有开发过脚本的人来些test case,他又如何能很准确的判断哪些功能点应该合成一个case呢,而且他也无法保证合成出来的case是否符合你的开发习惯,等等.这样还是有一些弊端的.
现在测试团队的test case基本上都是一个功能点一个case,改变这种方式是否合理或者说单独来写自动化case,感觉需要平衡的东西还是很多的.
相比而言,脚本的设计架构更重要一些.和软件设计一样,分层是提高开发效率,降低维护成本的一个好方法,但由于缺乏高效的错误处理机制和本身调试环境的限制,又增加了额外的负担.
这个是俺前段时间做QTP的一点感受,反正是没有什么好的办法,希望各位DX多给好的意见

huangcm

按照我的方法,
开发脚本时 无需考虑 哪些功能点应该合成一个case,因为脚本的设计不依赖于case ,

如某一Action 设计时,读取数据驱动字段,
如果 录入数据不为0,则录入数据,
如果  该记录有提示,则执行验证提示
如果 执行动作为保存,则执行保存;执行动作为取消,则执行取消

这样测试人员只要关心设计测试数据,和一些区分执行脚本的字段

huangcm

设计的脚本Action 中考虑该功能中 所有测试可能的动作,和可能的结果
读取数据驱动数据,进行判断执行相关代码

hiyizhiyu

to huangcm: 不知道你是怎么定义"该功能"的,就是指一个功能点,还是一组功能点呢?如果是一个功能点,那如果每个功能点都如此设计,感觉是一个很复杂的过程啊!
还有我的理解是你为每个功能都设计几种场景,然后根据驱动数据中的字段来判断执行哪个场景,不知道这些场景是只属于这个功能还是可以被所有功能共享,如果是只属于特定功能,那脚本的开发可能也不简单,而且感觉结构也不太合理!
我接触QTP不久,也许对你的描述理解不够,呵呵,就当灌水吧
倒是期望你们多多讲一些好经验
thanks

Coffey111111

对脚本设置一个测试框架，如何设计一个好的框架便于测试效率的提高以及以后脚本的维护，我觉得是个难点，也想和大家讨论这个问题~~     对脚本的设计到底要注意点写什么？有经验的人可以谈谈吗？sdlkfj5

topor

学习了，希望有经验的人可以接着coffey111111的话题继续讨论。sdlkfj2