SMOKETEST

最初定义

Smoke Testing是从电路板测试得来的,当电路板做好以后，首先会加电测试，如果电路板没有冒烟再进行其它测试，如果冒烟了就说明这个电路板基本的功能(加电)都没达到，其他功能不必再继续测试。

软件领域

软件领域引入冒烟测试，是对软件基本的功能进行测试，目的是确认软件基本的功能正常，保证软件系统正常运行，所以测试人员测试的版本必须首先通过冒烟测试的考验。

Smoke Test被认为是最先由微软提出的概念，与微软一直提倡的每日构建（build）有密切联系。

冒烟测试就是开发人员在个人版本的软件上执行目前的冒烟测试项目，确定新的程序代码不出故障。

——《微软项目求生法则》之“构建过程”

测试对象

冒烟测试的对象是每个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，执行者是版本的编译人员。不通过时需要重新编译，到成功为止，冒烟测试的执行者是版本编译人员。

测试优缺点

冒烟测试的作用就是保证系统的主流程和新模块的基本功能能用，保证希望集成测试能正常开展，优点是节省测试时间，防止build失败。缺点是覆盖率还是比较低。

如果冒烟测试失败，会导致测试进度延期，成本和进度风险增大，因此冒烟测试失败是一个很大的项目失误，所以一般的，在发布前，开发人员会内部执行一次冒烟测试，来保证提交的版本的质量。

一般测试流程

第一步：确定冒烟测试用例

第二步：执行冒烟测试（人选是测试人员）

BVT VS Smoke Testing

　　BVT 所做的测试内容很浅，这一特征似乎符合 Smoke Testing 的定义；但是 BVT 只验证 build 的构建情况，这一点与 Smoke Testing 截然不同，因此二者是完全不同的测试。另外：

BVT 只在 build 构建完成时进行；Smoke Testing 是各个阶段都有的测试。

尽管 BVT 可以加入自动测试脚本并执行少量固定的自动化测试，但 Smoke Testing 与 build 的验证无关。

BVT 的结果直接决定新构建的 build 是否交付后续测试；Smoke Testing 不影响其他日常测试工作。

当前公司冒烟测试内容

1. db connection

2. redis connection

3. rabbitmq connection

4. dependencies rvice is working

当然，以上是最基本的环境测试，其他的还包括单元测试，feature测试，自动化测试等。

写在最后

良好的公司应该是：

1. 具有测试视角的研发团队

2. 兼具研发能力的测试工程师

3. 具有用户视角的产品经理

4. 测试和开发，只是视角不同，能力上并不应该有差别，测试不应该成为研发的阻碍，敏捷测试强调的是持续集成测试，测试和开发是密不可分的一个整体