冒烟自动化测试介绍（1）

本篇文章将从冒烟测试简介、冒烟测试需求、冒烟测试实现、冒烟测试效果、冒烟测试小结，5个方面给大家解释冒烟测试的知识

1冒烟测试简介

所谓冒烟测试（Smoke Testing），即冒烟自动化测试，它是WEB界面自动化测试方式之一。一种说法，在硬件测试中，它源于测试硬件是否发生冒烟；另一种说法，在软件测试中，它意谓着测试软件只用了一袋烟的功夫。

冒烟测试就是一种基础的、先行及高效的测试，在短时间内，花费较小的代价，起到相对较大的作用。

冒烟测试作为自动化测试，通常应该遵循的原则如下：

1、简捷高效，以简为上；

2、以低代价获取高收益；

3、手动与自动互动互补。

在WEB应用领域里，一般来说，冒烟测试主要用来测试登陆、菜单和功能主页面。本文以VerisCRM自动化测试为例，简要介绍冒烟测试的实现。

VerisCRM是基于AppFrame开发的电信业务支撑系统产品。

2冒烟测试需求

在WEB界面自动化测试中，首先需要冒烟测试，其次进行功能测试。冒烟测试在功能测试之先。冒烟测试之所以必要，主要基于以下需求：

1、应用需求不断变化，软件版本频繁发布，需要频繁测试；

2、同一软件，需要部署在多个测试环境中；

3、加载菜单、功能页面往往存在各种各样的问题；

4、集中统一自动测试，比多人手动测试具有更高的效率；

       5、全面自动化测试，为其它手工或自动测试铺平道路。

3冒烟测试实现

1、测试思路

冒烟测试的关键，在于如何获取需要测试的菜单，然后测试菜单及功能页面。冒烟测试主要设计思路如下：

(1)  冒烟测试获取的菜单来源于被测系统加载的菜单

 冒 烟测试和业务应用系统（被测系统）共用一个菜单数据源，即被测试系统从哪里、怎样读取菜单，冒烟测试就同样怎样获取菜单。根据被测系统的实现，一般从数据库获取菜单，不是机械地从界面获取。既不需要额外的数据库或文件保存菜单，又能够把增加的菜单作为测试目标，大大降低维护工作量，系统增加、修改和删除菜单，不需要增加脚本和配置，对于开发和维护人员来说，这几乎是透明的。

(2)  参数化数据源菜单，或采用数据驱动的方式配置数据源和脚本

冒烟测试的测试思路，可以采用数据驱动测试（Data-drive Testing）的形式实现，也可以采用参数化的形式。数据驱动测试，是将测试数据与测试脚本分离，在不修改测试脚本的情况下，通过更新测试数据完成对测试用例的增加、更改和删除。

(3)  菜单采用按名字进行界面操作

操作菜单，按XPATH菜单名字实现而不是按照菜单ID实现。按名字点击操作，最直接，最统一，也最简单。按名字点击操作，是最简洁的编程方式，代码关键字与界面关键字一致，没有用页面对象静态ID和动态ID，不累赘，可读性强，易维护。

(4)  冒烟测试需要测试功能界面的统一功能

在打开每个功能主页面后，搜索并点击统一的查询按钮，然后判断查询是否正常。由于各种原因，各页面开发标准并不完全一致，因此，有的功能没有输入查询条件，采用缺省值，就可执行查询；有的功能，不输入查询条件，查询会提示请输入查询条件，在没有必要为维持测试统一性而支持个性输入时，可以过滤掉这类提示。个别功能需要输入条件，才能查询结果，可以留到功能测试时，一并测试。如果一定要测试个例，那就采用数据驱动的方式，根据不同的菜单数据，执行不同的功能测试了。

(5)  冒烟测试需要完备的异常窗口捕捉、判断机制

一个界面之上意外出现弹出框时，再操作此界面上的控件就是无效的。这是自动化测试过程中经常遇到的问题，这个问题，一般是因为不知道系统此处会有弹出框，或系统意外出现其它功能界面，或测试异常未关闭应该关闭的弹出框。

那应该怎么办哪？

在点击菜单之后、点击按钮之前，应做相应的异常判断，判断有异常发生，在处理异常弹出框后， 再进行点击按钮操作。在连续点击菜单时，应补充清理现场，也就是处理异常弹出框，否则，前次点击异常遗留的弹出框，会导致当前点击无效。

冒烟测试的实现流程、效果和测试小结将在后续的文章中给你慢慢道来，不要心急喔~~