软件自动测试架构设计(3)

发表于:2014-12-17来源:uml.org.cn作者:Smilings点击数: 标签:自动测试架构
(7) 输出数据,也就是这个操作步骤的输出结果。 一个测试案例就是一个完整的测试流程,由不同的操作步骤组成,每个操作步骤就是一个操作指令,一个

  (7) 输出数据,也就是这个操作步骤的输出结果。

  一个测试案例就是一个完整的测试流程,由不同的操作步骤组成,每个操作步骤就是一个操作指令,一个完整的测试案例可能包括这些操作指令:

  (1) 预置测试环境,比如修改某些特殊的配置、设置模拟接口的返回值、检查某些数据等;

  (2) 测试步骤,一个测试案例可能有多个测试步骤,每个测试步骤为一个操作指令,操作指令的输入就是测试需要输入的数据,动作就是需要执行的测试操作,测试案例的测试就是由一系列的操作指令完成;

  (3) 检查测试结果,一个测试案例中可能存在多个检查点,每个检查点为一个操作指令,这操作指令的输入就是预期的测试结果,操作指令的动作就是获取测试结果并将测试结果与预期测试结果相比较,如果相等则测试通过,否则测试失败;

  (4) 恢复测试环境,测试完成后应该恢复测试环境的原始数据或相关的资源。

  为了提高测试的扩展性与灵活性,测试案例中的测试数据应该可以参数化,这样即使是测试数据发生了变化,只需要修改参数的值即可,而不必把所有的测试案例的某些数据逐个修改。这些参数以及参数的值可以存放在配置文件中,被测试案例引用,自动测试工具根据测试案例的参数的名称到相应的配置文件中读取这个参数的值。

  3.2.3 测试案例的存放

  对于不同的产品的测试案例,应该存放在不同的主目录中,对于同一个产品的测试案例,根据不同的功能存放于不同的子目录中。每个主目录或子目录应该有一个测试案例的ID文件,在这个文件中的测试案例会被自动测试工具执行自动测试。测试案例ID文件中,每一行为一个测试案例,每个测试案例由序列号、测试案例ID和该测试案例的描述组成。测试案例的存放位置,自动测试工具可通过配置文件获取。

  3.3 自动测试执行

  3.3.1 测试案例的编写与测试

  自动测试工具实现后,接下来很大部分的工作就是测试案例的编写和测试了,根据业务逻辑和自动测试案例的规范将测试案例系统中的测试案例转化成自动测试案例脚本,自动测试案例脚本编写完成后对这些脚本进行测试,确保自动测试案例脚本能够被正确地执行且正确地测试了测试案例所描述的功能。在利用自动测试工具进行测试之前,首先要测试自动测试工具和案例能否正确地进行相关功能的测试,否则自动测试的结果不可信,自动测试也就没有意义了。

  3.3.2 自动测试的执行

  自动测试案例编写完成后,自动测试就可以在无人干预的情况下进行测试了。

  (1) 需要进行自动测试的测试案例的ID写在一个文件中,自动测试工具只执行这个文件中的测试案例;

  (2) 自动测试案例的目录、数据库连接、模拟接口的IP和Port等参数写在配置文件中,自动测试工具会到配置文件指定的目录读取测试案例,也会读取自动测试工具所使用到的数据库连接信息和模拟接口信息;

  (3) 自动测试案例所使用到的参数写在参数配置文件中,自动测试工具根据自动测试案例的参数的名字到参数配置文件中读取该参数的值代替自动测试案例中的参数;

  (4) 指定测试结果的输出文件,自动测试工具在测试完一个测试案例之后,将这个测试案例的测试结果输出到测试结果文件中,测试结果文件每行表示一条测试案例,每条测试案例的输出结果包括测试案例的ID,测试案例的功能描述和测试案例的结果;

  (5) 自动测试工具在测试案例的过程中,需要记录测试日志,包括测试案例ID,读取测试案例的内容,测试步骤,各个测试步骤的测试结果,测试结果的比较等;

  (6) 自动测试工具自动执行所需要测试的案例,并记录测试结果,测试工程师在测试完成后查看测试结果,测试成功的测试案例意味着这个功能测试通过,对于测试失败的测试案例,需要根据日志分析原因,如果是测试环境或测试脚本引起的则修改环境或测试案例或自动测试工具,否则需要记录bug,通知开发修改测试失败的测试案例所发现的问题。

  第4章 自动编译与自动测试

  4.1.1 自动编译

  自动编译就是在源代码管理服务器上进行自动编译,对编译的结果进行分析,并将编译成功的并且是自动测试环境需要的文件更新到测试环境中。

原文转自:http://www.uml.org.cn/Test/200804257.asp