前言
手工测试用例与自动化测试用例对比如下。
1、手工测试用例特点：
① 较好的异常处理能力，能通过人为的逻辑判断校验当前步骤的功能是否正确实现
② 人工执行用例具有一定的步骤跳跃性
③ 人工测试步步跟踪，能够细致地定位问题
④ 主要用来发现功能缺陷
1、 自动化测试用例特点：
① 执行对象是脚本，任何一个判断都需要编码定义
② 用例步骤之间关联性强
③ 主要用来保证产品主体功能正确和完整，让测试人员从烦琐重复的工作中解脱出来
④ 目前自动化测试阶段定位在冒烟测试和回归测试
通过对比我们可以看到，手工测试用例与自动化测试用例之间存在较大的差异，所以，不能直接把手工测试用例“翻译”成自动化测试脚本。
通过它们之间的特点对比也可清晰地认识到，自动化测试不能完全地替代手工测试，自动化测试的目的仅仅在于让测试人员从烦琐重复的测试过程中解脱出来，把更多的时间和精力放到更有价值的测试中，例如探索性测试。而自动化测试更多的是用来进行冒烟测试和回归测试。
1、 自动化测试用例选型注意事项：
① 不是所有的手工用例都要转为自动化测试用例。
② 考虑到脚本幵发的成本，不要选择流程太复杂的用例。如果有必要，可以考虑把流程拆分成多个用例来实现脚本。
③ 选择的用例最好可以构建成场景。例如，一个功能模块，分多个用例，多个用例使用同一个场景。这样的好处在于方便构建关键字测试模型。
④ 选择的用例可以带有目的性。例如，这部分用例作冒烟测试，那部分用例作回归测试等，当然，会存在重叠的关系。如果当前用例不能满足需求，那么唯有修改用例来适应脚本和需求。
⑤ 选取的用例可以是你认为是重复执行，很烦琐的部分。例如，字段验证、提示信息验证这类，这部分适用于回归测试。
⑥ 选取的用例可以是主体流程，这部分适用于冒烟测试。
⑦ 自动化测试也可以用来做配置检查、数据库检查。这些可能超越了手工用例，但也算用例拓展的一部分，项目负责人可以有选择地增加。
⑧ 平时在手工测试时，如果需要构造一些复杂的数据或重复一些简单的机械式动作, 则告诉自动化脚本，让它来帮你，或许你的效率会因此而得到提高。
1.2 测试类型
1、测试静态内容
静态内容测试是最简单的测试，用于验证静态的、不变化的UI元素的存在性。例如：
① 每个页面都有其预期的页面标题？这可以用来验证链接指向一个预期的页面。
② 应用程序的主页包含一个应该在页面顶部的图片吗？
③ 网站的每一个页面是否都包含一个页脚区域来显示公司的联系方式、隐私政策以及商标信息？
④ 每一页的标题文本都使用<h1>标签吗？每个页面都有正确的头部文本吗？
你可能需要（也可能不需要）对页面内容进行自动化测试。如果你的网页内容是不易受到影响，则手工对内容进行测试就足够了。
2、测试链接
Web站点的一个常见错误为失效的链接或链接指向无效页。链接测试涉及各个链接和验证预期的页面是否存在。如果静态链接不经常更改，则手动测试就足够了。但是，如果你的网页设计师经常改变链接，或者文件不时被重定向，则链接测试应该实现自动化。
3、功能测试
在你的应用程序中，需要测试应用的特定功能，需要一些类型的用户输入，并返回某种类型的结果。通常一个功能测试将涉及多个页面，一个基于表单的输入页面，其中包含若干输入字段、提交和取消操作，以及一个或多个响应页面。用户输入可以通过文本输入域、复选框、下拉列表，或任何其他浏览器所支持的输入。
功能测试通常是需要自动化测试的最复杂的测试类型，但通常也是最重要的。典型的测试是登录、注册网站账户、用户账户操作、账户设置变化、复杂的数据检索操作，等等。功能测试通常对应着你的应用程序的描述应用特性或设计的使用场景。
2、 测试动态元素
通常一个网页元素都有一个唯一的标识符，用于唯一地定位该网页中的元素。通常情况下，唯一标识符用HTML标记的“id”属性或“name”属性来实现。
这些标识符可以是一个静态的（即不变的）字符串常量，也可以是动态生成值，在每个页面实例上都是变化的。例如，有些Web服务器可能在一个页面实例上命名所显示的文件为doc3861，而在其他页面实例上显示为doc6148，这取决于用户在检索的“文档”。通常情况下，具有变化的标识符的动态元素基于用户操作的结果页面上，然而，显然这取决于Web 应用程序。
1.3 自动化测试用例编写原则
在编写自动化测试用例过程中应该遵循以下原则：
1) 一个用例为一个完整的场景，从用户登录系统到最终退出并关闭浏览器。
2) —个用例只验证一个功能点，不要试图在用户登录系统后把所有的功能都验证一遍。
3) 尽可能少的编写负面逻辑用例。一方面因为负面逻辑的用例很多（例如，手机号输错有几十种情况）；另一方面自动化脚本本身比较脆弱，复杂的负面逻辑用例实现起来较为麻烦且容易出错。
4) 用例与用例之间尽量避免产生依赖。
5) 一条用例完成测试之后需要对测试场景进行还原，以免影响其他用例的执行。