软件自动测试架构设计

　　第1章 前言

　　目前市场上已经有了不少自动测试工具，不过满足自己需求的测试工具却很难找到或者是难以支付其昂贵的费用，对于在Linux/Unix后台运行的软件产品，自己开发一个自动测试工具，不但可以满足软件的测试需求，还可以节省一大笔费用。

　　这个自动测试系统架构的设计，是基于Linux/Unix后台运行的软件产品，架构的思想，源于主流测试工具与前辈的实践经验。

　　软件的自动测试，其实就是一种思想，不管是市场上的主流测试工具，还是自主开发的测试工具，都只是工具，关键的是怎样去组织一个工具，怎样将工具应用于软件测试中。

　　第2章 系统架构

　　2.1 设计思想

　　1. 自动测试的组成：自动测试主要有几部分组成：(1)、自动测试工具(2)、测试案例(3)、模拟接口(4)被测试软件(5)自动编译与安装

　　2. 自动测试工具：自动测试工具的主控程序不需要理解业务，所有的业务逻辑和测试数据都写在测试案例中，主控程序执行每个测试案例中的指令完成每个测试案例的测试，测试结果记录在指定的文件中。

　　3. 测试案例：业务逻辑和测试数据体现在测试案例中，一个完整的测试案例应该包括测试条件预置、测试步骤、每个测试步骤的输入与输出、预期结果、实际测试结果的获取、实际测试结果与预期测试结果的对比。每个测试动作为一个操作指令，每个操作指令包括指令的ID、输入与输出，主动测试工具就是通过执行测试案例的这些指令来完成自动测试的。

　　4. 黑盒测试：被测试软件对于自动测试工具来说，是一个黑盒子，自动测试工具不关心被测试软件的内部逻辑和业务流程，关心的被测试软件的接口以及每个接口的输入和输出。自动测试工具向被测试软件输入测试数据，在相应的接口获取测试结果，如果测试结果与预期结果相一致则测试通过，否则测试失败。

　　5. 模拟接口：与被测试软件打交道的各个接口，需要模拟，在必要时可以设置模拟接口给被测试软件的返回值，以达到测试的目的。

　　6. 自动编译与测试：自动编译就是自动到源代码管理服务器编译软件，将软件上传到测试服务器。自动测试就是自动更新或安装被测试软件，启动自动测试工具执行自动测试案例，记录测试结果并将测试结果以邮件的方式发送给相关的人员。

　　7. 测试环境的恢复：在某个测试案例执行完成后，不管测试是成功还是失败，都需要恢复被该测试案例特殊化后的测试环境。

　　8. 重用策略：公用的模块提取出来，被别的模块或功能调用，提高模块的公用性，减少程序冗余代码。

　　9. 自动测试工具模块组成：

　　(1) 主控程序：读取测试案例以及每个测试案例的操作指令，根据不同的操作指令调用不同的指令接口执行每个测试案例的指令，记录测试结果。

　　(2) 指令接口：是测试案例操作指令与具体测试步骤实现之间的桥梁，与测试案例的操作指令相对应，指令接口就是实现测试案例的操作指令所需要做的事情，动作完成之后将该动作的操作结果返回给主控程序。

　　(3) 驱动程序：驱动程序是实现具体的指令操作的程序，被指令接口调用完成具体的测试工作，并将测试结果返回给指令接口。

　　(4) 辅助功能：实现系统的辅助功能，比如案例文件的处理，底层socket处理，文件处理或者数据库操作。

　　2.2 系统架构

　　2.3 系统流程图

　　第3章 自动测试核心设计

　　3.1 系统组成

　　自动测试工具由主控程序、指令接口、驱动程序和辅助功能组成。

　　3.1.1 主控程序

　　控制模块不理解业务，把业务逻辑和测试数据全部写在案例里，控制模块读取所有需要测试的测试案例以及每个测试案例的每一个操作项的动作，调用不同的接口处理模块来实现整个测试流程。

　　控制模块处理流程：

　　1. 读取命令，获得需要执行的命令以及配置文件。

　　2. 分析命令以及命令的参数，比如如果命令是想查看帮助，则打印帮助提示;如果命令是执行测试案例，则开始执行自动测试的测试案例。

　　3. 分析配置文件，获取测试案例存放目录，需要执行的案例的ID文件，数据库连接信息，测试案例所使用到的参数。 (注：因为在测试案例的执行中，未必执行完整个测试案例，测试案例中的某些动作可能不需要执行，可在配置文件或测试案例中进行配置)

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