软件自动测试架构设计

第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文件，数据库连接信息，测试案例所使用到的参数。 (注：因为在测试案例的执行中，未必执行完整个测试案例，测试案例中的某些动作可能不需要执行，可在配置文件或测试案例中进行配置)
4． 根据测试案例存放目录以及测试测试的ID文件获取具体需要测试的测试案例。
5． 获取每个测试案例需要执行的动作指令以及输入数据。
6． 逐个执行测试案例，根据测试案例的动作指令调用不同的接口执行不同的动作。
7． 某个测试案例测试完成后，获取该测试案例的测试结果，并将测试结果输出到结果记录文件中。
8． 继续执行下一个案例，直到所有的测试案例都被测试完为止。
3.1.2 指令接口
是测试案例操作指令与具体测试步骤实现之间的桥梁，与测试案例的操作指令相对应，指令接口就是实现测试案例的操作指令所需要做的事情，动作完成之后将该动作的操作结果返回给主控程序。接口模块负责与接口的数据处理，包括输入和输出，同时必须包括数据处理的结果。主控程序在读取了测试案例的操作指令之后，调用这些操作指令所对应的指令接口执行相应的操作，如果该接口执行操作成功则主动程序继续下一步操作，否则测试终止，只有所有的测试步骤的指令都被成功之行，测试案例才通过。
为了方便管理与调用，所有的接口都实例化都一个接口工厂中，在实现了相应的指令接口后，需要将这些指令接口增加到接口工厂中，接口工厂根据案例中的接口类型来调用不同的接口实例。
指令接口，事实上就是执行测试案例中的每个指令要求做的事情，比如输入测试案例的测试数据、执行相应的测试步骤、获取测试结果、对比测试结果，指令接口完成一个指令之后将这个指令的操作结果返回给主控程序。
比如，话单检查指令接口，指令接口需要做的事情就是初始化要监听的话单文件，获取话单文件，把获取到的话单文件同期望话单进行比较，返回比较结果给主控程序。
又如：短信接收发送指令接口，指令接口的工作就是实现发送MT，收取状态报告并把收到的状态报告的状态值与期望的状态值进行比较，返回比较结果给调用者；收到本地MO，并把收到到的本地MO与期望的MO进行比较，返回比较结果给调用者。
3.1.3驱动程序
驱动程序是实现具体的指令操作的程序，被指令接口调用完成具体的测试工作，并将测试结果返回给指令接口。驱动程序是具体操作的完成者。
比如，话单检查驱动程序，用于对特定话单格式的话单文件进行跟踪，并且能够把跟踪结果解析成话单，话单检查指令接口会调用话单驱动程序完成具体的每条话单的各个子段的比较，驱动程序完成检查后将结果返回给指令接口。
3.1.4 辅助功能
实现系统的辅助功能，比如案例文件的处理，底层socket处理，文件处理或者数据库操作。
3.2 测试案例
3.2.1 测试案例的组成
测试案例包括了业务逻辑、测试步骤以及输入与输出，使用XML存储测试案例，可以提高测试案例的可读性、通用性以及可维护性。不过这样有一个不好的地方就是测试案例看起来会比较庞大，不够轻盈，但是非常清晰，即使是对测试案例完全不熟悉的人，只要看了也自然很快就对业务流程有了一个大致的了解；而且，业务逻辑体现在测试案例，也会增强系统的扩展性，如果需要增加某些测试步骤或修改测试数据，只需要修改测试案例即可。
测试案例主要由测试案例ID、测试案例描述、以及测试操作指令所组成。测试案例ID就是测试系统的案例ID，测试描述包括测试案例的简要描述、测试产品名称、测试功能点、测试版本、测试类型以及测试案例的作者，测试操作指令是测试案例的核心，每个测试步骤就是一个操作指令，操作指令的顺序与业务逻辑或测试步骤相关。每个操作指令包括：
（1） 操作指令ID，在Test Case中唯一；
（2） 操作指令接口名称，自动测试工具所提供的指令接口名称，在一个Test Case中可以出现多次；
（3） 操作指令接口动作名称，自动测试工具所提供的指令接口的具体操作的名称，在一个Test Case中可以出现多次，自动测试工具操作指令接口名称和操作指令接口动作名称调用不同的指令接口的功能完成相关的动作；
（4） 操作指令的描述；
（5） 模拟接口的信息，如果需要使用到模拟接口，需要将模拟接口相关的信息再测试案例中输入，模拟接口相关信息应该参数化；
（6） 输入数据，也就是执行这个操作步骤所需要输入的测试数据或是预期的结果或延时等待时间等。
（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 自动编译
自动编译就是在源代码管理服务器上进行自动编译，对编译的结果进行分析，并将编译成功的并且是自动测试环境需要的文件更新到测试环境中。
自动编译的过程可分为：
（1） Update源代码服务器上的需要编译的所有相关代码，需要编译的代码的路径在配置文件中读取；
（2） 自动编译需要编译的源代码；
（3） 分析源代码编译结果，只有编译成功了的执行文件用于自动测试才有意义，将编译结果上传到测试服务器并发送给相应的人员；
（4） 将需要更新的文件打包并上传到测试服务器，并将上传结果发送给相关人员。
自动编译，可以写一个脚本交给crontab去调用自动编译程序，实现无人干预下的编译自动化。
4.1.2 自动测试
这里所说的自动测试，就是自动更新或安装被测试软件，自动启动被测试软件，然后跑自动测试案例进行自动测试，并将自动测试的结果发送给相关的测试或开发人员。
自动测试的过程可分为：
（1） 到自动编译结果上传目录获取自动编译结果，分析自动编译结果，如果自动编译失败则自动测试结束，发送测试结果给相关人员，否则进行一步；
（2） 到FTP被测试软件的安装文件上传目录获取FTP上传结果，分析ftp上传结果，如果ftp失败则自动测试结束，发送测试结果给相关人员，否则进行下一步；
（3） 到被测试软件的安装文件上传目录获取安装文件；
（4） 停止原正在运行的被测试软件，如果是全新安装的测试环境，不需要执行这一步；
（5） 进行软件安装或更新：如果是一个全新的测试环境则进行软件的安装，如果是已经存在的测试环境则更新被测试软件；
（6） 启动被测试软件；
（7） 调用自动测试工具进行自动测试，记录测试结果；
（8） 所有自动测试案例都测试完成之后，分析测试结果，将测试结果发邮件通知相关的测试和开发人员。
自动编译，可以写一个脚本交给crontab去调用自动测试程序，实现无人干预下的测试自动化。
配置文件应该包括以下信息：
（1） 自动编译的结果文件和FTP的结果文件的路径、文件名；
（2） 被测试软件的安装文件或更新文件的路径；
（3） 存放自动测试结果的路径和文件名；
（4） 停止原测试软件的脚本的路径和文件名；
（5） 启动被测试软件的脚本的路径和文件名；
（6） 启动自动测试软件进行自动测试的脚本的路径和文件名；
（7） 测试结果发送的邮件地址。

参考视频资料：http://ke.qq.com/cgi-bin/courseDetail?course_id=86005