软件自动测试架构设计

第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处理，文件处理或者数据库操作。 [Page]
　　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） 恢复测试环境，测试完成后应该恢复测试环境的原始数据或相关的资源。
　　为了提高测试的扩展性与灵活性，测试案例中的测试数据应该可以参数化，这样即使是测试数据发生了变化，只需要修改参数的值即可，而不必把所有的测试案例的某些数据逐个修改。这些参数以及参数的值可以存放在配置文件中，被测试案例引用，自动测试工具根据测试案例的参数的名称到相应的配置文件中读取这个参数的值。