1. 前言
手工测试用例是针对手工测试人员，自动化测试用例是针对自动化测试框架，前者是手工测试用例人员应用手工方式进行用例解析，后者是应用脚本技术进行用例解析，两者最大的各自特点在于，前者具有较好的异常处理能力，而且能够基于测试用例，制造各种不同的逻辑判断，而且人工测试步步跟踪，能够细致的定位问题。而后者是完全按照测试用例的方式测试，而且异常处理能力不强，往往一个自动化测试用例运行完毕后，报一堆错误，对于测试人员来定位错误是一个难点，这样往往发现的问题很少。
下面介绍手工测试用例与自动化测试用例对比：
2. 自动化测试用例与手工测试用例对比
2.1手工测试用例
- 较好的异常处理能力，能通过人为的逻辑判断校验当前步骤的功能实现正确与否；
- 人工执行用例具有一定的步骤跳跃性；
- 人工测试步步跟踪，能够细致的定位问题；
- 主要用来发现功能缺陷。
2.2 自动化测试用例
- 执行对象是脚本，任何一个判断都需要编码定义；
- 用例步骤之间关联性强；
- 主要用来保证产品主体功能正确完整和让测试人员从繁琐重复的工作中解脱出来；
- 目前自动化测试阶段定位在冒烟测试和回归测试
2.3 小结
通过对比我们可以看到，手工测试用例与自动化测试用例之间是存在差异的。所以，直接拿手工测试用例来直接转化成自动化测试脚本。
在此笔者需要强调：自动化测试替代不了手工测试，目的仅仅在于让测试人员从繁琐重复的机械式测试过程解脱出来，把时间和精力突入到更有价值的地方，从而挖掘更多的产品缺陷。目前自动化测试更多的时候是定位在冒烟测试和回归测试；冒烟测试执行的是主体功能点的用例。回归测试执行全部或部分的测试用例。
3.自动化用例选型注意事项
怎么编写自动化测试用例，如何将自动化测试用例和手工测试用例相辅相成。
- 不是所有的手工用例都要转为自动化测试用例；
- 考虑到脚本开发的成本，不要选择流程太复杂的用例。如果有必要，可以考虑把流程拆分多个用例来实现脚本；
- 选择的用例最好可以构建成场景。例如一个功能模块，分n 个用例，这n 个用例使用同一个场景。这样的好处在于方便构建关键字或参数化测试模型；
- 选择的用例可以带有目的性，例如这部分用例是用例做冒烟测试，那部分是回归测试等，当然，会存在重叠的关系。如果当前用例不能满足需求，那么唯有修改用例来适应脚本和需求；
- 选取的用例可以是你认为是重复执行，很繁琐的部分，例如字段验证，提示信息验证这类。这部分适用回归测试；
- 选取的用例可以是主体流程，这部分适用冒烟测试；
- 自动化测试也可以用来做配置检查，数据库检查。这些可能超越了手工用例，但是也算用例拓展的一部分。项目负责人可以有选择地增加；
- 如果平时在手工测试时，需要构造一些复杂数据，或重复一些简单机械式动作，告诉自动化脚本，让他来帮你。或许你的效率因此又提高了。