Selenium自动化实施方案

自动化测试框架与代码规范

自动化实施目的：

自动执行重复工作较大回归测试。

Web系统在不同环境下的兼容性测试(多操作系统和多浏览器)。

与CI服务集成，作为持续集成实践的一部分。

二Selenium自动化实施方案简介

实施方案：

自动化测试框架：python+unittest+Selenium2(WebDriver)+PageObject

用例管理系统:gitlab

脚本开发:Python语言

测试数据：P0数据驱动

脚本回放：lE/Chrome/FireFox

自运行方案:gitlab

测试报告：TestngReport

工具：pycharm+Selenium+unittest+gitlab

PageObject设计模式简介：PageObject将测试对象及单个的测试步骤封装在每个Page对象中，以page为单位进行管理。

在V/eb应用程序的用户界面中存在测试交互。PageObject可以简单的用测试代码将页面对象模型化，从而减少了重复的代码

量，如果UI发生变化，只需要在统一的地方变更。

方案特性:

支持多环境下的兼容性测试

支持数据驱动（PM）

对象库的分离和管理

自动化测试脚本的组织和管理

脚本的可重用（团队）和可配置

灵活的断言机制

便捷的后台服务

直观性的测试报告

方案不适用的情形:

定制型项目（一次性的）

项目周期很短的项目

业务规则复杂的对象

美观、声音、易用性测试

测试很少运行

软件不稳定

涉及物理交互

三自动化测试环境:

开发环境

硬件环境

普通开发用的PC即可。

软件环境

WindowsXP/7v

python3.61

seleniumserver2.25或以上

chrone（含Driver）、Firefox（含firebug插件）

运行环境

硬件环境

PCServer

双核或四

80G以上隧盘空间

100M或以上以太网卡

四自动化测试实施流程：

前置条件：软件需求变动不频繁.项目周期足够长。自动化测试脚本可重复使用。另外，在手工测试无法完成，需要投入大量时

间与人力时也需要考虑引入自动化测试。比如性能测试、配置测试、大数据量输入测试等。

流程图：

主要过程描述:

可行性分析：在进行项目自动化测试之前，第一步就是要确认其可行性性，是否可以实行测试自动化。

如果出现其中任何一种，自动化测试工作都是不应该展开的，项目常见不可吁因素如下：

项目时间紧迫

项目需求变幻无常

项目周期短

自动化测试工具对系统的有效性：举个例，假设你所在的公司购买了一款商业化的自动化测试工具，项目系统中全部是一些Java

控件，但是测试工具自带的插件中又不包含Java控件的识别插件，那么此时就算拥有这款自动化测试工具，但由于无法有效地

识别到项目中的控件，所以，对于项目来说是亳无作用的。

抽样demo分析：

把demo（是一个实体案例）看成更深层次的可行性分析，一且通过了抽样demo分析，自动化测试就可以展开了。关于demo

的选取，一般直接选择冒烟测试用例（大冒烟＞写成测试脚本后执行，检查脚本是否能够成功运行通过，己设计的测试点是否全

部执行到即可。

测试需求分析：

为下一阶段定制具体计划打下基础。测试需求其实就是测试目标，也可看做测试自动化的功能点，也就是自动化测试工程师想完

成的任务。优先考虑实现正向的测试用例后再去实现反向的测试用例，而且反向的测试用例大多都是需要进行分

析然后筛选出来的，因为反向的测试用例实在太多了。自动化测试是不需要也没有必要做到100%覆盖率的。所以，在测试需求

分析这个阶段，确定测试覆盖率以及自匆化测试粒度、测试用例上的筛选等都是重点工作。

制定测试计划：

与以前的测试计划过程•致，只是在原来的测试计划中，添加对项目实施自动化测

试所需的资源、测试范围、测试进度的描述。

自动化测试设计：

框架设计、开发与搭建

测试用例设计：筛选手工测试用例的过程。转换手上测试用例的过程。新增&补充自动化测试用例的过程。

测试脚本开发：

根据《软件需求规格说明书》、《自动化测试用例》、《系统原型》，录制、调试、编写各个功能点的自动化测试脚本，并添加

检资点，进行参数化。该过程的产出物是各个功能点的自动化测试脚本和其池公共处理脚本。

需要注意的是：自动化测试脚本代码必笈严谨、规范。

自动化测试脚本需参照自动化测试用例开发，测试用例即是开发参照物。

尽一切可能使自动化测试脚本更智能、高效、稔定、复用性高。

开发过程多利用注释+断点，检查业务组件是否存在缺陷或代码是否存在漏洞。

脚本开发完毕后，至少运行成功3次以上，方可认为脚本已经没有问题。

必须使用一款优秀的代码版本管理软件来管理好每一个测试版本的自动化测试

脚本，这也是H动化测试项目中非常重要的环节。

自动化测试数据设计：根据《软件需求规格说明书》、《自动化测试用例》设计出对各个功能点和相关业务规则进行测试的输

入数据和预期输出，填写入对应的数据文件中。该过程的产出物是各个功能点的数据文件。

自动化测试执行：测试脚本开发完成后就要对测试脚本进行管理，执行；测试脚本的执行主要包含如下内容：

测试环境的管理配置

测试脚本配置

测试脚本的执行

测试异常中断处理和恢复

自动化测试结果分析:

对测试结果文件中报告错误的记录进行分析，如果确实是由于被测系统的缺陷导致，则提交缺陷报告。对自动化测试的结果进行

总结，分析系统存在的问题，提交《测试报告》。

自动化测试脚本维护：如果系统发生变更时，对自动化测试脚本和相关文档包括《自动化测试用例》、《自动化脚本设计说明书》

进行维护，以适应变更后的系统。

自动化测试项目“标配”：自动化测试组长、测试工程师

五自动化测试实施规范：

用例选取标准：该测试是否包含核心业务流程

该测试是否覆盗了最关键的特性路径

该测试的重复执行率较高

该测试是否定期运行，比如，经常重用，还作为回归测试或构建测试的一部分

对于手动运行这个测试是否太昂贵而不可能或是禁止的，如并行，渗透，耐力测

试，内存泄漏等

是否有对时间敏感的组件而必须自动化

该测试是否覆盖了最复杂的领域（通常是最有可能出错的领域）

使用相同步骤时，该测试是否需要许多教据组合

期望的结果是常数吗，比如每一次测试时都不会改变或不同？即使结果不同，是

否可参数化（结果可预知）或可测出一个与期望结果的可接受的百分比（结果不

可预知

该测试是否非常耗时，如对成百上千的输出进行预期的分析

该测试是否运行在稔定的应用上

运行速度很慢的case不应该选取为自动化实现

自动化测试用例是否包含了手工测试的基线用例集

自动化的用例以正向用例为主，辅以个别重要的反向用例

验证点规范：

验证点选取标准：

要选1仅能莅盖当前case本质的主要验证点

尽量选取前台的明文验证点，即验证点在页面上可见，方便获取

前台无法验证的case,需要去后台验证的情况下