51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 9822|回复: 34
打印 上一主题 下一主题

[原创] 大型系统的业务流程、逻辑特别复杂的用例适合自动化吗?

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2009-10-22 10:22:55 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
单个界面的增、删、查、改这些操作都非常简单,写自动化脚本也都非常容易。但是大型系统的业务一般都比较复杂,要完整的测试一个功能流程都需要很多步骤,可能需要从步骤A—>B--->C--->D--->E----F等等,我想做过大型系统测试的朋友都有体会。当然我说的这种测试是在对系统业务理解非常好的情况下,对整个系统流程做的比较深的测试。算是很有价值的测试。如果不把每个步骤关联起来,只在A界面或B界面点来点去,则不属于我说的这种情况,这种测试在大型系统的测试中基本没什么价值,因为每个界面的简单功能开发人员一般不会出错。难的就在复杂业务流程的实现上。所以很多做大型系统的公司招人时都要求有那个行业的经验。有些还是必须的条件,除非是招应届生。要完整的测试一个业务流程需要非常细心认真,执行完每一个步骤,都要去看相关联的其他地方是否有相应的正确的改变,然后再去执行下一步,执行完下一步,导致后面的步骤也会有相应的改变,有的也会对前面的步骤做出改变。比如A步骤产生数据给B步骤,B步骤把数据处理后传给C步骤,同时因为B步骤已经对A步骤产生的数据做了处理,则A步骤的数据不允许再编辑等等,总之业务很复杂,很多方面都要来回反复的考虑到。如果对业务很熟悉后,手工测试这种业务流程基本没什么问题。但是这么复杂的一个测试流程适合用一个自动化测试用例来实现吗?请有经验的朋友来指点一下。

[ 本帖最后由 戒情人 于 2009-10-22 11:46 编辑 ]
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
 楼主| 发表于 2009-10-22 10:36:39 | 只看该作者
请朋友们帮忙指点一下。我做自动化测试也很长时间了,甚至现在是专门做自动化测试。但是上面说的问题真的是一个难题,如果那么复杂的测试去用自动花实现,中间要查看很多状态和数据,步骤又很多,写脚本一定很复杂。如果中间的数据或状态那里有一点问题,整个复杂的脚本可能就无法运行下去。但是如果把复杂的流程拆分过一个个小过程,然后写脚本,虽然简单但又没有什么意义,因为那些流程在现实中是一气走完的,拆开测没现实意义。我们测试应该模仿系统在现实中的真实使用情况,应该模仿用户的使用情况,这样才能找到有价值的问题,才有意义。

[ 本帖最后由 戒情人 于 2009-10-22 10:53 编辑 ]
回复 支持 反对

使用道具 举报

该用户从未签到

3#
 楼主| 发表于 2009-10-22 11:12:35 | 只看该作者
我顶
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2009-10-22 11:42:29 | 只看该作者
看看能不能把流程图画清楚,毕竟这是编程的基础
如果能画清楚,路径覆盖不知道可不可以
回复 支持 反对

使用道具 举报

该用户从未签到

5#
 楼主| 发表于 2009-10-22 12:49:46 | 只看该作者

好问题

值得讨论
回复 支持 反对

使用道具 举报

该用户从未签到

6#
发表于 2009-10-22 13:23:41 | 只看该作者
对复杂流程系统测试会碰到以下困难:
   1、流程组合复杂,路径多;
   2、业务复杂会有设计上考虑不周的漏洞;
对于前者,可以通过刻画关键流程,组件化测试脚本的方式来解决。
对于后者,这个本不是自动化测试能解决的问题,不用讨论了。

自动化测试的目标是通过机器验证设计中的测试用例,提高测试效率和质量。
至于想要通过软件发现人没有考虑到的漏洞,那就是fuzz testing范畴的问题了。
回复 支持 反对

使用道具 举报

该用户从未签到

7#
发表于 2009-10-22 13:37:09 | 只看该作者
业务流程的测试本身就是很麻烦的,因为业务流程中每个操作步骤每个输入数据都可能会影响到后续的操作,所以没别的办法,就一个操作一个操作的实现吧,我现在写的最复杂的业务用例脚本有将近1100多行的脚本……
回复 支持 反对

使用道具 举报

该用户从未签到

8#
 楼主| 发表于 2009-10-22 13:51:03 | 只看该作者

回复 7# 的帖子

确实是你说的那么回事,我一直在做大型系统的测试,对此深有体会。每一个操作步骤每一个输入数据都会影响到后续的操作,所以手工测试比较灵活。根据你的经验,这么复杂的业务测试用例在实际工作中到底起了多的啊的作用?是不是非常有效?
回复 支持 反对

使用道具 举报

该用户从未签到

9#
发表于 2009-10-22 13:58:47 | 只看该作者
是否适合用QTP来实现自动化主要取决于2个方面,一个是对象识别,第二个是重复度。

LZ关心的业务复杂度应该是与自动化的覆盖率扯上关系,再复杂的业务,对QTP来说,也只是执行一组操作。如果对该业务的覆盖率要高一点,那就弄成数据驱动,不同的数据输入可能执行不同的业务操作。

大型的系统要特别注意业务的分割,尽可能的将业务操作分割成粒度较小的独立业务操作,将之封装成公用的Action或者Function,一个完整的业务操作就可以看成是这些一个个子操作的组合。

切忌对脚本期望过高,如果希望脚本能处理该业务能允许的所有操作,那性价比将会非常低,实际上对用户来说,他们常用到的业务功能可能只占到整个系统的20%。
回复 支持 反对

使用道具 举报

该用户从未签到

10#
 楼主| 发表于 2009-10-22 14:11:34 | 只看该作者

谢谢大家的帮助

谢谢大家的帮助,我现在有了一点点认识,可是对这个问题理解的还不是那么透彻。
回复 支持 反对

使用道具 举报

该用户从未签到

11#
发表于 2009-10-22 14:27:33 | 只看该作者
我认为如何颗粒化我们的业务流程这才是使用QTP测试的精髓,使用QTP测试,不再于你写出了多么复杂的脚本,而在于对软件的分割,不只是在物理上的分割,也包括业务流程上的分割。过长的脚本,产生的结果只有一个,业务流程一但稍有改变,也许只是顺序上的稍有不同,你就得过重新写脚本。
回复 支持 反对

使用道具 举报

该用户从未签到

12#
 楼主| 发表于 2009-10-22 14:55:16 | 只看该作者
大家指点的都非常好,欢迎大家继续来指导,非常感谢大家
回复 支持 反对

使用道具 举报

该用户从未签到

13#
 楼主| 发表于 2009-10-23 11:08:31 | 只看该作者
欢迎大家继续讨论
回复 支持 反对

使用道具 举报

该用户从未签到

14#
 楼主| 发表于 2009-10-26 14:11:04 | 只看该作者
欢迎大家继续讨论
回复 支持 反对

使用道具 举报

该用户从未签到

15#
发表于 2009-10-26 21:01:03 | 只看该作者
不才以为,也只有大型的系统才适合做自动化,因为小规模的自动化成本很难收回来,不系统化,规划的成本太高
回复 支持 反对

使用道具 举报

该用户从未签到

16#
发表于 2009-10-27 16:42:51 | 只看该作者
看来楼主的功力尚浅,做了很长时间自动化测试都没搞清楚自动化测试是怎么回事
回复 支持 反对

使用道具 举报

该用户从未签到

17#
 楼主| 发表于 2009-10-27 17:09:31 | 只看该作者

回复 16# 的帖子

这位朋友看来你很在行,给大家讲讲怎么样?
回复 支持 反对

使用道具 举报

该用户从未签到

18#
发表于 2009-10-27 17:24:27 | 只看该作者
其实就一句话,你做的是测试,不是开发
回复 支持 反对

使用道具 举报

该用户从未签到

19#
发表于 2009-10-27 18:04:47 | 只看该作者
原帖由 lyscser 于 2009-10-26 21:01 发表
不才以为,也只有大型的系统才适合做自动化,因为小规模的自动化成本很难收回来,不系统化,规划的成本太高

相当有才阿!
回复 支持 反对

使用道具 举报

  • TA的每日心情
    开心
    2017-3-3 10:21
  • 签到天数: 4 天

    连续签到: 1 天

    [LV.2]测试排长

    20#
    发表于 2009-10-27 18:39:38 | 只看该作者
    9#,11# 都是高人啊,学习了〉。。。
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-26 23:23 , Processed in 0.078897 second(s), 27 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表