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