最近要做自动化测试用例设计方面的工作，以前有写过手工的测试用例，感觉自己对测试用例设计这一块儿还行。但是对于自动化测试用例，就有些生疏了，不过感觉应该是相同的。手工测试用例是对人，自动化测试用例是对机器，人比较灵活，但是机器就比较死脑筋了，不告诉它做什么，怎么做，它肯定不会自动帮你完成，反正就是不通人性就对了。所以在网上搜了一下有关这方面的知识，现在跟大家分享一下。废话少说，请看下文转帖。
1、 手工测试用例和自动化测试用例功能定位的区别。
a) 手工测试用例
i. 较好的异常处理能力，能通过人为的逻辑判断校验当前步骤的功能实现正确与否。
ii. 人工执行用例具有一定的步骤跳跃性。
iii. 人工测试步步跟踪，能够细致的定位问题。
iv. 主要用来发现功能缺陷
b) 自动化测试用例
i. 执行对象是脚本，任何一个判断都需要编码定义。
ii. 用例步骤之间关联性强。
iii. 主要用来保证产品主体功能正确完整和让测试人员从繁琐重复的工作中解脱出来。
iv. 目前自动化测试阶段定位在冒烟测试和回归测试。
2、 自动化测试用例设计管理不善可以直接导致自动化测试开展的失败。
误区：
1、 不编写测试用例直接投入测试脚本编写。
2、 直接拿手工测试用例来编写自动化测试脚本。
自动化测试替代不了手工测试，目的仅仅在于让测试人员从繁琐重复的机械式测试过程解脱出来，把时间和精力突入到更有价值的地方，从而挖掘更多的产品缺陷。
目前咱们TD中对用例加入了自动化测试的标签。
目前自动化测试定位在冒烟测试和回归测试。
冒烟测试执行的是主体功能点的用例。
回归测试执行全部或部分的测试用例。
怎么编写自动化测试用例，如何将自动化测试用例和手工测试用例相辅相成。
用例选型注意事项：
1、 不是所有的手工用例都要转为自动化测试用例。
2、 考虑到脚本开发的成本，不要选择流程太复杂的用例。如果有必要，可以考虑把流程拆分多个用例来实现脚本。
3、 选择的用例最好可以构建成场景。例如一个功能模块，分n个用例，这n个用例使用同一个场景。这样的好处在于方便构建关键字测试模型。
4、 选择的用例可以带有目的性，例如这部分用例是用例做冒烟测试，那部分是回归测试等，当然，会存在重叠的关系。如果当前用例不能满足需求，那么唯有修改用例来适应脚本和需求。
5、 选取的用例可以是你认为是重复执行，很繁琐的部分，例如字段验证，提示信息验证这类。这部分适用回归测试。
6、 选取的用例可以是主体流程，这部分适用冒烟测试。
7、 自动化测试也可以用来做配置检查，数据库检查哦。这些可能超越了手工用例，但是也算用例拓展的一部分。项目负责人可以有选择地增加。
8、 如果平时在手工测试时，需要构造一些复杂数据，或重复一些简单机械式动作，告诉自动化脚本，让他来帮你。或许你的效率因此又提高了。
用例转型注意事项：
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、看到这里，你一定觉得开展自动化测试很累人。没错，这本不是一件立竿见影的利索活。它的发光，需要一定时间的沉淀，我们现在讨论的，和接下来要做的工作就是为了如何来缩短这部分的时间。
总结：今天讨论的仅仅是自动化测试开展实施的一部分，这部分很关键，需要大家的支持，因为用例是整个自动化测试的灵魂，没了灵魂，框架搞得再好，也仅仅是个躯壳，行尸走肉。我自己写测试用例的水平远不如咱们部门的测试负责人，这是真话。讨论自动化测试用例的选型和转型难免有些力不从心，尽管这样，我还是憋着喊出来，希望能得到大家的更好见解，俗称：抛砖引玉。
