整理不易，希望对各位学习软件测试能带来帮助
本章将简单探讨自动化测试用例的设计，笔者认为不管是手工测试，自动化测试，还是性能测试都是
以测试用例为前提的。那么测试用例是测试人员综合自己人经验从需求中挖掘和提炼而来。所以不管什么类型的测试工作，我们都不能盲目开展。任何测试工作都应该以需求为基础，以测试用例为导向进行实施。
手工测试用例是针对手工测试人员，自动化测试用例是针对自动化测试框架，前者是手工测试用例人
员应用手工方式进行用例解析，后者是应用脚本技术进行用例解析，两者最大的各自特点在于，前者具有较好的异常处理能力，而且能够基于测试用例，制造各种不同的逻辑判断，而且人工测试步步跟踪，能够细致的定位问题。而后者是完全按照测试用例的方式测试，而且异常处理能力不强，往往一个自动化测试用例运行完毕后，报一堆错误，对于测试人员来定位错误是一个难点，这样往往发现的问题很少。
手工测试用例
在此笔者需要强调：自动化测试替代不了手工测试，目的仅仅在于让测试人员从繁琐重复的机械式测
试过程解脱出来，把时间和精力突入到更有价值的地方，从而挖掘更多的产品缺陷。目前自动化测试更多的时候是定位在冒烟测试和回归测试；冒烟测试执行的是主体功能点的用例。回归测试执行全部或部分的测试用例。
怎么编写自动化测试用例，如何将自动化测试用例和手工测试用例相辅相成。
1、 不是所有的手工用例都要转为自动化测试用例。
2、 考虑到脚本开发的成本，不要选择流程太复杂的用例。如果有必要，可以考虑把流程拆分多个用例来实现脚本。
3、 选择的用例最好可以构建成场景。例如一个功能模块，分 n 个用例，这 n 个用例使用同一个场景。这样的好处在于方便构建关键字测试模型。
4、 选择的用例可以带有目的性，例如这部分用例是用例做冒烟测试，那部分是回归测试等，当然，会存在重叠的关系。如果当前用例不能满足需求，那么唯有修改用例来适应脚本和需求。
5、 选取的用例可以是你认为是重复执行，很繁琐的部分，例如字段验证，提示信息验证这类。这部分适用回归测试。
6、 选取的用例可以是主体流程，这部分适用冒烟测试。
7、 自动化测试也可以用来做配置检查，数据库检查。这些可能超越了手工用例，但是也算用例拓展的一部分。项目负责人可以有选择地增加。
8、 如果平时在手工测试时，需要构造一些复杂数据，或重复一些简单机械式动作，告诉自动化脚本，让他来帮你。或许你的效率因此又提高了。
静态内容测试是最简单的测试,用于验证静态的、不变化的 UI 元素的存在性。例如: •每个页面都有其预期的页面标题?这可以用来验证链接指向一个预期的页面。
Web 站点的一个常见错误为的失效的链接或链接指向无效页。链接测试涉及点各个链接和验证预期的
页面是否存在。如果静态链接不经常更改,手动测试就足够。但是,如果你的网页设计师经常改变链接,或者文件不时被重定向,链接测试应该实现自动化。
在您的应用程序中,需要测试应用的特定功能,需要一些类型的用户输入,并返回某种类型的结果。通常
一个功能测试将涉及多个页面,一个基于表单的输入页面,其中包含若干输入字段、提交“和”取消“操作, 以及一个或多个响应页面。用户输入可以通过文本输入域,复选框,下拉列表,或任何其他的浏览器所支持的
输入。
功能测试通常是需要自动化测试的最复杂的测试类型,但也通常是最重要的。典型的测试是登录,注册网站账户,用户帐户操作,帐户设置变化,复杂的数据检索操作等等。功能测试通常对应着您的应用程序的描述应用特性或设计的使用场景。
通常一个网页元素都有一个唯一的标识符,用于唯一地定位该网页中的元素。通常情况下,唯一标识符
用 HTML 标记的’id’属性或’name’属性来实现。这些标识符可以是一个静态的,即不变的、字符串常量。
它们也可以是动态生产值,在每个页面实例上都是变化的。例如,有些 Web 服务器可能在一个页面实例上命名所显示的文件为 doc3861,并在其他页面实例上显示为 doc6148,这取决于用户在检索的‘文档’。验证文件是否存在的测试脚本,可能无法找到不变的识别码来定位该文件。通常情况下,具有变化的标识符的动态元素存在于基于用户操作的结果页面上,然而,显然这取决于 Web 应用程序。
下面是一个例子。
这是一个 HTML 标记的复选框, 其 ID (addForm:_ID74:_ID75:0:_ID79:0:checkBox) 是一个动态生成
的值。这个页面下次被打开时入框的 ID 将可能是一个不同的值。
Ajax 是一种支持动态改变用户界面元素的技术。页面元素可以动态更改,但不需要浏览器重新载入页
面,如动画,RSS 源,其他实时数据更新等等。Ajax 有不计其数的更新网页上的元素的方法。但是了解 AJAX的最简单的方式,可以这样想,在 Ajax 驱动的应用程序中,数据可以从应用服务器检索,然后显示在页面上,而不需重新加载整个页面。只有一小部分的页面,或者只有元素本身被重新加载。
什么时候使用断言命令,什么时候使用验证命令?这取决于你。差别在于在检查失败时,你想让测试程序做什么。你想让测试终止,还是想继续而只简单地记录检查失败?
这需要权衡。如果您使用的断言,测试将在检查失败时停止,并不运行任何后续的检查。有时候,也许是
经常的,这是你想要的。如果测试失败,你会立刻知道测试没有通过。TestNG 和 JUnit 等测试引擎提供在开发测试脚本时常用的插件,可以方便地标记那些测试为失败的测试。优点:你可以直截了当地看到检查是否通过。缺点:当检查失败,后续的检查不会被执行,无法收集那些检查的结果状态。
相比之下,验证命令将不会终止测试。如果您的测试只使用验证,可以得到保证是—假设没有意外的异
常—测试会被执行完毕,而不管是否发现缺陷。缺点:你必须做更多的工作,以检查您的测试结果。也就是说, 你不会从 TestNG 和 JUnit 得到反馈。您将需要在打印输出控制台或日志文件中查看结果。每次运行测试, 你都需要花时间去查看结果输出。如果您运行的是数以百计的测试,每个都有它自己的日志，这将耗费时间。及时得到反馈会更合适,因此断言通常比验证更常使用。
在实际的脚本开发中，我们需要用到 python 的异常处理来捕捉异常和抛异常，所以我们有需要学习
和使用 python 的异常处理。
>>> open('abc.txt','r')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
IOError: [Errno 2] No such file or directory: 'abc.txt'
打开一个不存在的文件 abc.txt 文件，当系统找不到 abc.txt 文件时，就会抛出给我们一个 IOError 类型的错误，No such file or directory：abc.txt （没有 abc.txt 这样的文件或目录）
Try…except…
假如，我们已经知道这种类型的错误，那么就可以通过一个异常扑捉来扑捉这个错误。我们可以通过
try… 来接收这个错误。打开文件写入：
try:
open("abc.txt",'r')
except IOError:
pass
再来运行程序就会看不到任何错误，因为我们用 except 接收了这个 IOError 错误。pass 表示实现了
相应的实现，但什么也不做。
假如我不是打开一个文件，而是输出一个没有定义的变量呢？
try:
print aa
except IOError:
pass
显然，在上面的代码中我并没有对 aa 赋值&#x