关于自动化软件测试用例设计的几点分析

发表于:2012-3-13 16:22

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:HYHOLINE    来源:51Testing软件测试网采编

  用例转型注意事项:

  1、首先测试人员应该了解脚本是怎么替代人工来执行用例。

  2、当你写自动化测试用例时,你需要意识到你的用例是写给一个“智障人士”执行,执行对象是脚本。

  3、当前的测试用例前置配置信息要写清楚。

  4、每一个步骤都要衔接好,错了,脚本要报异常,我要去烦你。

  5、每一个步骤要做什么,验证什么要写清楚,写具体。有时一个检查点,你只需看一眼,但是脚本要写一堆代码去验证,这样的做法是不可行的。

  6、用例之间不要有关联性,自动化测试开发同样是软件开发工程,脚本编写同样提倡高内聚低耦合的理念。

  7、不是每一个步骤都需要验证点,让子弹飞一会儿。

  8、别在多个地方重复相同的验证。脚本很忙!我没空。当然,除非有必要。

  9、开门记得要关门,配置信息要回归原点,否则脚本要迷路。

  10、当你设计自动化测试用例时,难免对一个用例的功能点加加减减。不要因此而剪掉了一些验证点。因为手工用例+自动化用例=1。

  写给项目测试负责人的一些话:

  1、项目加入了自动化测试平台,负责人要有全局的把握。因为你的用例被拆分成自动化测试和手工执行用例,原来一些被打入冷宫的用例因自动化测试而重生,重生的用例需要你的维护。

  2、当你迎来项目新立项,拿到需求文档,开始设计新用例,此时,别忘了该如何统筹安排你的用例。是的,这很像排兵布阵,有了自动化测试这把利剑,还得看你会不会用。

  3、不要永远做自动化测试的门外汉。可能你的职业规划是测试经理,产品经理,或者其他,又可能你对其感到畏惧或厌倦,认为自己无法跨越对编码的恐惧。但是,无论如何,今天你是这个项目的测试负责人(一个资深的测试工程师),你要负起这个责任,挑起大梁。

  4、如果以后你看到自动化测试报告单,没有发现一个bug,请不要抱怨,自动化脚本主要不是来帮你找缺陷,而是告诉你没有缺陷。

  5、如果将来你参与了自动化测试脚本编写工作,请做好面对一大堆错误的心理准备。在前期,测试结果往往会夹杂着一大堆的各种错误,可能是框架机制问题,可能是脚本编写问题,可能是用例问题,还有可能是需求自身的问题。

  6、咱们部门刚刚开展自动化测试,需要大伙的支持和理解。它的发展需要一个渐进的过程,从无序到有序,从困惑到豁然开朗。这个过程难免曲折艰辛,甚至会引来非议,但是从一些成功案例中,还是坚定了我继续走下去的信心。我渴望和大家一起分享这份成果,尽管现在连花儿都未曾开放。

  7、会自动化测试和会QTP是两回事,学习自动化测试不一定要会QTP,你也可以通过Selenium入门。

  8、请考虑下你负责的项目是否需要实施自动化测试,我们可以一起坐下来讨论,圈定一个范围和实施的计划。我们都是产品线上的一颗螺丝钉,我这颗螺丝钉很乐意为你的项目提供自动化测试的帮助。

  9、不要过度信任自动化测试,它也是个撒谎高手。所以,自动化用例需要测试,框架需要测试,脚本函数需要测试,脚本过程需要测试,驱动数据需要测试。

  10、看到这里,你一定觉得开展自动化测试很累人。没错,这本不是一件立竿见影的利索活。它的发光,需要一定时间的沉淀,我们现在讨论的,和接下来要做的工作就是为了如何来缩短这部分的时间。

  总结:今天讨论的仅仅是自动化测试开展实施的一部分,这部分很关键,需要大家的支持,因为用例是整个自动化测试的灵魂,没了灵魂,框架搞得再好,也仅仅是个躯壳,行尸走肉。我自己写测试用例的水平远不如咱们部门的测试负责人,这是真话。讨论自动化测试用例的选型和转型难免有些力不从心,尽管这样,我还是憋着喊出来,希望能得到大家的更好见解,俗称:抛砖引玉。

22/2<12
《2023软件测试行业现状调查报告》独家发布~

精彩评论

  • rogers
    2012-3-14 09:13:46

    +5

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号