8.2.3 框架逻辑架构
图8-4 自动化测试框架的逻辑架构
1．定义层
定义层包括业务流定义、业务组件定义和测试数据定义。其中，业务组件是系统中一个独立的功能模块，业务流定义系统运行的流程；测试数据定义是完成被测项目中输入数据类型定义、业务流中数据依赖关系以及测试过程中输出的数据。
2．测试引擎驱动层
3．被测系统层
被测系统层支持对多浏览器、C/S架构及基于移动设备上的B/S架构系统的自动化测试。
8.2.4 框架工作流程
自动化测试框架使功能测试工程师和自动化测试工程师能够在平台协同办公。功能测试工程师登录测试框架编写测试用例，填写测试数据，配置业务流程和业务组件；自动化工程师根据测试用例编写调试脚本，上传测试脚本和关联测试用例；自动化测试框架根据定义好的执行策略执行测试并生成报告，然后发生报告给相关人员；最后根据测试报告分析测试结果，得出系统是否通过本次自动化测试的结论。如图8-5所示描述了自动化框架的工作流程。
图8-5 自动化框架的工作流程
8.3 框架开发
在开发测试框架的时候需要考虑测试用例如何维护，测试数据采用Excel还是DB来进行存储，还需要提供公共方法给测试工程师以简化脚本的编写。如果脚本运行出错，可以通过日志分析其原因。测试脚本运行结束需要生成测试结果报告，通过测试报告了解测试覆盖率。本节将通过以上几个方面来介绍自动化测试框架。
8.3.1 创建测试用例
通过平台创建测试用例，可以结合TestLink或TestRail做二次开发形成测试框架的用例管理。下面使用笔者自主研发的自动化平台作为测试用例，图8-6所示描述了创建测试用例的过程。
图8-6 创建测试用例的过程
功能测试人员登录平台，创建测试用例。平台提供两种输入方式，一种是在平台界面中输入，另一种由Excel批量导入，保存到数据库中。对于通过平台界面输入的用例，在保存之前，平台会对用例进行完整性检查，通过后方可保存。
创建测试用例需要遵守如下规则：
用例中体现的属性有用例名称、用例描述、系统子系统、产品大类子类、功能点编号、正例反例和备注。
业务流是测试用例的骨架，由相互独立的子模块组成。在测试用例里，业务流的顺序将体现功能点编号、实际结果和预期结果等信息。
回归测试人员在平台进行测试用例输入时，要注意测试用例分手工测试用例和自动化测试用例，需要在用例中添加检查点。
平台对用例进行完整性检查，而用例的合理性和有效性是需要回归测试人员进行检查的。
8.3.2 创建测试数据
由于Excel本身具有处理数据的优势，所以本项目使用Excel保存测试数据，这有利于数据的维护。新建Excel文件，内容如图8-7所示。
图8-7 Excel维护测试数据案例
各列说明如下。
（1）模块名称：用于定义模块名称。
（2）字段名：定义需要输入数据的名称，脚本中将根据定义的字段名获取测试数据。
（3）数据属性分为以下3种类型。
数据输入：输入基础数据，如用户名、密码等。
数据回写：这类数据是在脚本运行时产生的，如订单号、流水号等。
数据关联：这类数据是获取上一个业务组件运行结果的数据，如在运行过程中需要用到上一个业务组件生成的订单号。
（4）测试数据：1、2、3列为实际的测试数据。
然后开始配置业务流，业务流由各个模块和数据组成。新建一个Excel的Sheet页，业务流程配置如图8-8所示，其中定义了任务分配和流程监控两个业务流。
图8-8 测试业务配置流程
其中各列项含义如下。
业务流名称：定义业务流程名。
业务流循环次数：定义业务流程运行的次数。
模块名称：定义业务流由哪些模块组成。
数据列：定义每一次要运行的数据列。
是否运行：Enable表示运行该模块；False表示不运行该模块。
版权声明：51Testing软件测试网获电子工业出版社和作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
