自动化测试用例设计
手工测试用例与自动化测试用例
手工测试用例是针对手工测试人员，自动化测试用例是针对自动化测试框架，前者是手工测试用例人 员应用手工方式进行用例解析，后者是应用脚本技术进行用例解析，两者最大的各自特点在于，前者具有 较好的异常处理能力，而且能够基于测试用例，制造各种不同的逻辑判断，而且人工测试步步跟踪，能够 细致的定位问题。而后者是完全按照测试用例的方式测试，而且异常处理能力不强，往往一个自动化测试 用例运行完毕后，报一堆错误，对于测试人员来定位错误是一个难点，这样往往发现的问题很少。
手工测试用例与自动化测试用例对比
手工测试用例:
- 较好的异常处理能力，能通过人为的逻辑判断校验当前步骤的功能实现正确与否。
- 人工执行用例具有一定的步骤跳跃性。
- 人工测试步步跟踪，能够细致的定位问题。
- 主要用来发现功能缺陷：自动化测试替代不了手工测试，目的仅仅在于让测试人员从繁琐重复的机械式测 试过程解脱出来，把时间和精力突入到更有价值的地方，从而挖掘更多的产品缺陷。目前自动化测试更多 的时候是定位在冒烟测试和回归测试；冒烟测试执行的是主体功能点的用例。回归测试执行全部或部分的 测试用例。
自动化测试用例
- 执行对象是脚本，任何一个判断都需要编码定义。
- 用例步骤之间关联性强。
- 主要用来保证产品主体功能正确完整和让测试人员从繁琐重复的工作中解脱出来。
- 目前自动化测试阶段定位在冒烟测试和回归测试。
自动化测试替代不了手工测试，目的仅仅在于让测试人员从繁琐重复的机械式测 试过程解脱出来，把时间和精力突入到更有价值的地方，从而挖掘更多的产品缺陷。目前自动化测试更多 的时候是定位在冒烟测试和回归测试；冒烟测试执行的是主体功能点的用例。回归测试执行全部或部分的 测试用例。
用例选型注意事项：
1、 不是所有的手工用例都要转为自动化测试用例。
2、 考虑到脚本开发的成本，不要选择流程太复杂的用例。如果有必要，可以考虑把流程拆分多个 用例来实现脚本。
3、 选择的用例最好可以构建成场景。例如一个功能模块，分 n 个用例，这 n 个用例使用同一个场 景。这样的好处在于方便构建关键字测试模型。
4、 选择的用例可以带有目的性，例如这部分用例是用例做冒烟测试，那部分是回归测试等，当然， 会存在重叠的关系。如果当前用例不能满足需求，那么唯有修改用例来适应脚本和需求。
5、 选取的用例可以是你认为是重复执行，很繁琐的部分，例如字段验证，提示信息验证这类。这 部分适用回归测试。
6、 选取的用例可以是主体流程，这部分适用冒烟测试。
7、 自动化测试也可以用来做配置检查，数据库检查。这些可能超越了手工用例，但是也算用例拓 展的一部分。项目负责人可以有选择地增加。
8、 如果平时在手工测试时，需要构造一些复杂数据，或重复一些简单机械式动作，告诉自动化脚 本，让他来帮你。或许你的效率因此又提高了。
测试类型
测试静态内容
静态内容测试是最简单的测试,用于验证静态的、不变化的 UI 元素的存在性。例如:
•每个页面都有其预期的页面标题?这可以用来验证链接指向一个预期的页面。
•应用程序的主页包含一个应该在页面顶部的图片吗?
•网站的每一个页面是否都包含一个页脚区域来显示公司的联系方式,隐私政策,以及商标信息?
。每一页的标题文本都使用的标签吗?每个页面有正确的头部文本内吗?
您可能需要或也可能不需要对页面内容进行自动化测试。如果您的网页内容是不易受到影响手工对内 容进行测试就足够了。如果,例如您的应用文件的位置被移动,内容测试就非常有价值。
测试链接
Web 站点的一个常见错误为的失效的链接或链接指向无效页。链接测试涉及点各个链接和验证预期的 页面是否存在。如果静态链接不经常更改,手动测试就足够。但是,如果你的网页设计师经常改变链接,或者 文件不时被重定向,链接测试应该实现自动化。
功能测试
在您的应用程序中,需要测试应用的特定功能,需要一些类型的用户输入,并返回某种类型的结果。通常 一个功能测试将涉及多个页面,一个基于表单的输入页面,其中包含若干输入字段、提交“和”取消“操作, 以及一个或多个响应页面。用户输入可以通过文本输入域,复选框,下拉列表,或任何其他的浏览器所支持的 输入。
功能测试通常是需要自动化测试的最复杂的测试类型,但也通常是最重要的。典型的测试是登录,注册 网站账户,用户帐户操作,帐户设置变化,复杂的数据检索操作等等。功能测试通常对应着您的应用程序的描 述应用特性或设计的使用场景。
测试动态元素
通常一个网页元素都有一个唯一的标识符,用于唯一地定位该网页中的元素。通常情况下,唯一标识符 用 HTML 标记的’id’属性或’name’属性来实现。这些标识符可以是一个静态的,即不变的、字符串常 量
它们也可以是动态生产值,在每个页面实例上都是变化的。例如,有些 Web 服务器可能在一个页面实例 上命名所显示的文件为 doc3861,并在其他页面实例上显示为 doc6148,这取决于用户在检索的‘文档’。验 证文件是否存在的测试脚本,可能无法找到不变的识别码来定位该文件。通常情况下,具有变化的标识符的 动态元素存在于基于用户操作的结果页面上,然而,显然这取决于 Web 应用程序。
Ajax 的测试
Ajax 是一种支持动态改变用户界面元素的技术。页面元素可以动态更改,但不需要浏览器重新载入页 面,如动画,RSS 源,其他实时数据更新等等。Ajax 有不计其数的更新网页上的元素的方法。但是了解 AJAX 的最简单的方式,可以这样想,在 Ajax 驱动的应用程序中,数据可以从应用服务器检索,然后显示在页面上,而 不需重新加载整个页面。只有一小部分的页面,或者只有元素本身被重新加载。
断言 assert 与验证 verify
什么时候使用断言命令,什么时候使用验证命令?这取决于你。差别在于在检查失败时,你想让测试程序 做什么。你想让测试终止,还是想继续而只简单地记录检查失败?
这需要权衡。如果您使用的断言,测试将在检查失败时停止,并不运行任何后续的检查。有时候,也许是 经常的,这是你想要的。如果测试失败,你会立刻知道测试没有通过。TestNG 和 JUnit 等测试引擎提供在开 发测试脚本时常用的插件,可以方便地标记那些测试为失败的测试。优点:你可以直截了当地看到检查是否 通过。缺点:当检查失败,后续的检查不会被执行,无法收集那些检查的结果状态。
相比之下,验证命令将不会终止测试。如果您的测试只使用验证,可以得到保证是—假设没有意外的异 常—测试会被执行完毕,而不管是否发现缺陷。缺点:你必须做更多的工作,以检查您的测试结果。也就是说, 你不会从 TestNG 和 JUnit 得到反馈。您将需要在打印输出控制台或日志文件中查看结果。每次运行测试, 你都需要花时间去查看结果输出。如果您运行的是数以百计的测试,每个都有它自己的日志，这将耗费时间。 及时得到反馈会更合适,因此断言通常比验证更常使用。
