自动化测试用例设计的几点分析

一、手工测试用例和自动化测试用例功能定位的区别

 

a)手工测试用例

 

i.较好的异常处理能力，能经过人为的逻辑判断校验当前步骤的功能实现正确与否。

ii.人工执行用例具备必定的步骤跳跃性。

iii.人工测试步步跟踪，可以细致的定位问题。

iv.主要用来发现功能缺陷

 

b)自动化测试用例

 

i.执行对象是脚本，任何一个判断都须要编码定义。

ii.用例步骤之间关联性强。

iii.主要用来保证产品主体功能正确完整和让测试人员从繁琐重复的工做中解脱出来。

iv.目前自动化测试阶段定位在冒烟测试和回归测试。

 

二、自动化测试用例设计管理不善能够直接致使自动化测试开展的失败

 

误区：

一、不编写测试用例直接投入测试脚本编写。

二、直接拿手工测试用例来编写自动化测试脚本。

 

自动化测试替代不了手工测试，目的仅仅在于让测试人员从繁琐重复的机械式测试过程解脱出来，把时间和精力突入到更有价值的地方，从而挖掘更多的产品缺陷。

 

目前我们TD中对用例加入了自动化测试的标签。

 

目前自动化测试定位在冒烟测试和回归测试

 

冒烟测试执行的是主体功能点的用例

 

回归测试执行所有或部分的测试用例

 

怎么编写自动化测试用例，如何将自动化测试用例和手工测试用例相辅相成

 

用例选型注意事项：

 

一、不是全部的手工用例都要转为自动化测试用例

 

二、考虑到脚本开发的成本，不要选择流程太复杂的用例。若是有必要，能够考虑把流程拆分多个用例来实现脚本

 

三、选择的用例最好能够构建成场景。例如一个功能模块，分n个用例，这n个用例使用同一个场景。这样的好处在于方便构建关键字测试模型

 

四、选择的用例能够带有目的性，例如这部分用例是用例作冒烟测试，那部分是回归测试等，固然，会存在重叠的关系。若是当前用例不能知足需求，那么惟有修改用例来适应脚本和需求

 

五、选取的用例能够是你认为是重复执行，很繁琐的部分，例如字段验证，提示信息验证这类。这部分适用回归测试

 

六、选取的用例能够是主体流程，这部分适用冒烟测试

 

七、自动化测试也能够用来作配置检查，数据库检查哦。这些可能超越了手工用例，可是也算用例拓展的一部分。项目负责人能够有选择地增长

 

八、若是平时在手工测试时，须要构造一些复杂数据，或重复一些简单机械式动做，告诉自动化脚本，让他来帮你。或许你的效率所以又提升了

 

用例转型注意事项：

 

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

 

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

 

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

 

四、每个步骤都要衔接好，错了，脚本要报异常，我要去烦你

 

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

 

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

 

七、不是每个步骤都须要验证点，让子弹飞一下子

 

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

 

九、开门记得要关门，配置信息要回归原点，不然脚本要迷路

 

十、当你设计自动化测试用例时，不免对一个用例的功能点加加减减。不要所以而剪掉了一些验证点。由于手工用例+自动化用例=1

 

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

 

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

 

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

 

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

 

四、若是之后你看到自动化测试报告单，没有发现一个bug，请不要抱怨，自动化脚本主要不是来帮你找缺陷，而是告诉你没有缺陷

 

五、若是未来你参与了自动化测试脚本编写工做，请作好面对一大堆错误的心理准备。在前期，测试结果每每会夹杂着一大堆的各类错误，多是框架机制问题，多是脚本编写问题，多是用例问题，还有多是需求自身的问题

 

六、我们部门刚刚开展自动化测试，须要大伙的支持和理解。它的发展须要一个渐进的过程，从无序到有序，从困惑到豁然开朗。这个过程不免曲折艰辛，甚至会引来非议，可是从一些成功案例中，仍是坚决了我继续走下去的信心。我渴望和你们一块儿分享这份成果，尽管如今连花儿都不曾开放

 

七、会自动化测试和会QTP是两回事，学习自动化测试不必定要会QTP，你也能够经过Selenium入门

 

八、请考虑下你负责的项目是否须要实施自动化测试，咱们能够一块儿坐下来讨论，圈定一个范围和实施的计划。咱们都是产品线上的一颗螺丝钉，我这颗螺丝钉很乐意为你的项目提供自动化测试的帮助

 

九、不要过分信任自动化测试，它也是个撒谎高手。因此，自动化用例须要测试，框架须要测试，脚本函数须要测试，脚本过程须要测试，驱动数据须要测试

 

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

 

总结：今天讨论的仅仅是自动化测试开展实施的一部分，这部分很关键，须要你们的支持，由于用例是整个自动化测试的灵魂，没了灵魂，框架搞得再好，也仅仅是个躯壳，行尸走肉。

 

转载：http://mp.weixin.qq.com/s?__biz=MjM5Mjg0MzMzMw==&mid=212914751&idx=3&sn=78e3660143ff76c24b500bfa7275760b&scene=0#rd