手工测试用例 PK 自动化测试用例
首先，需要区分手工测试和自动化测试用例的不同。 1.手工测试用例：
- 关注某个功能点
- 可考虑多种异常情况并做出相应的处理，通过人为的逻辑判断当前步骤的功能实现正确与否
- 人工执行具有一定的步骤跳跃性
- 人工测试步步跟踪，能够细致的定位问题
- 主要用来发现功能缺陷，适用于测试阶段
2.自动化测试用例：
- 关注的是流程，多个功能点
- 用例步骤关联性强
- 保证产品主题功能能正确完成和让测试人员从繁琐重复的工作中解脱出来
- 自动化测试的每个用例的起始页面和退出页面一般是同一个页面，从哪里开始，到哪里结束（为了保证每次测试的初试环境是一样的）
- 目前自动化测试主要用于冒烟测试和回归测试（冒烟测试执行的是主体功能点的用例。回归测试执行全部或部分的测试用例）
自动化测试用例设计原则：
- 不需要将所有的手工测试用例转化为自动化测试用例
- 选择功能较为稳定的功能模块进行测试。当功能变动大时，脚本的维护需要花费更多的精力
- 选择的用例如为主体流程，可用于冒烟测试
- 自动化测试也可以用来做配置检查，数据库检查等。也算用例拓展的一部分。
- 如果平时在手工测试时，需要构造一些复杂数据，或重复一些简单机械式动作，就可以使用自动化脚本创造
- 准备复杂的测试数据。对于大的应用系统，数据之间的关系和准备过程都会很复杂，甚至有其他外部系统导入、传输或计算出来的数据。此时我们可以使用自动化工具或使用SQL语句直接导入需要的数据。注意：要写到你单独的测试数据准备文档， 而不是分散到所有使用到他的case中去描述。
- 自动化的测试用例需要更多的关注功能逻辑的实现，而不必纠结于某个字段的限制。字段限制等需要在测试分析阶段来手工确定的。
- 自动化测试用例上下文必须有一定的顺序行， 要能够互相链接起来；且前置条件清楚，包括显式、隐式的前置条件
自动化测试用例测试方法：
- 当前测试用例前置条件和数据要求写清楚
- 每一个步骤设计衔接好，容易出现脚本报异常错误的情况
- 脚本直接不要有关联性，自动化测试开发同样也是软件开发工程
- 不需要每个步骤都要检查点，结合实际项目判断
- 重复的验证可独立为函数，调用即可
- 当你设计自动化测试用例时，难免对一个用例的功能点加加减减。不要因此而剪掉了一些验证点。因为手工用例+自动化用例=1。
额外的一些话：
- 自动化测试只能确认脚本内囊括流程没有问题，无法帮你找缺陷
- 自动化测试人员进入项目的时间可能不是最早的，对需求的理解并不是在第一时间就很容易做到的。测试用例作为测试需求的载体、测试执行的依据和工作量的评估，它设计和表达的优劣直接影响到自动化测试开展的前几个阶段，如：需求学习、筛选适合自动化测试的用例以及提取公司级或项目的可重用脚本等方面的工作效率。
参考博客链接：
来源：oschina
链接：https://my.oschina.net/u/1417325/blog/632123