冒烟测试的名称可以理解为该种测试耗时短，仅用一袋烟功夫足够了。也有人认为是形象地类比新电路板基本功能检查。任何新电路板焊好后，先通电检查，如果存在设计缺陷，电路板可能会短路，板子冒烟了。
近期在和一些研发团队沟通时，发现许多同学对于冒烟测试有一些理解的误区，CC先生就想来捋一捋这个概念。
通常一提到冒烟测试，大家都习惯性的把关注点放在后面两个字: 测试 ,开发的同学一听这个活动，很开心，这不是我们的活儿，应该是测试人员来完成的。真的是这样么？
先来看看维基百科上对冒烟测试的解释:
smoke testing is preliminary testing to reveal simple failures severe enough to, for example, reject a prospective software release. Smoke tests are a subset of [test cases] that cover the most important functionality of a component or system, used to aid assessment if main functions of the software appear to work correctly. [1][2] When used to determine if a computer program should be subjected to further, more fine-grained testing, a smoke test may be called an intake test . [1] Alternately, it is a set of tests run on each new build of a product to verify that the build is testable before the build is released into the hands of the test team. [5] In the DevOps paradigm, use of a BVT step is one hallmark of the continuous integration maturity stage.
冒烟测试这个名称的来历，最初是从电路板测试得来的。因为当电路板做好以后，首先会加电测试，如果板子没有冒烟再进行其它测试，否则就必须重新来过。
而在软件研发中，冒烟测试其实是微软首先提出来的一个概念，和微软一直提倡的每日build（构建版本）有很密切的联系。具体说，冒烟测试就是在每日build（构建版本）建立后，对系统的基本功能进行简单的测试。这种测试强调程序的主要功能进行的验证，而不会对具体功能进行更深入的测试。
冒烟只是这类测试活动更形象化一些的叫法，直接叫做BVT（Build Verification Testing）其实CC先生个人觉得更为贴切。
有些团队在定制流程时会有一个阶段叫冒烟测试，但是就算不通过也会继续做后面其它部分的测试。就像平时进机场的时候机场口都会有个小哥哥或者小姐姐拿一个不知名的物体对你扫一次，大多数情况下旅客们都是面无表情的走过他们身边，扫就扫呗，又不少两斤肉。
实际上什么打火机啊，充电宝啊会在之后的安检过程才会被一一挑出来。
我们反过头来看当时微软提出来的这个概念，它的重点其实在于 daily build ，也就是说冒烟测试是随着每一次构建而走的，它应该是一个开关而不是一个研发流程中的测试阶段。
过，你可以继续后面的测试。
不过，直接返工等待下一次的构建。
这才是冒烟测试应有的态度。
一些团队通常为了督促开发人员提高研发质量而把冒烟通过率作为一个衡量指标。CC先生认为出发点是极好的，实现手段上经常会有一点点小偏差。
冒烟测试主要是测试系统的主流程是否可用，如果这次的需求不涉及到太多主流程上面的更改，那真的有必要把这些案例都加入到冒烟测试中么？
最后，冒烟测试的最佳实践还是最好被自动化，在CI中每一个Build都自动的去执行主流程的测试，确保其是一个基本可用的版本。手工测试这事儿吧，西部世界都第二季完结了，你们还没醒悟么？
冒烟测试和回归测试的区别回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的。
冒烟测试冒烟测试( *** oke test)在测试中发现问题，找到了一个Bug，然后开发人员会来修复这个Bug。这时想知道这次修复是否真的解决了程序的Bug，或者是否会对其它模块造成影响，就需要针对此问题进行专门测试，这个过程就被称为Smoke Test。在很多情况下，做Smoke Test是开发人员在试图解决一个问题的时候，造成了其它功能模块一系列的连锁反应，原因可能是只集中考虑了一开始的那个问题，而忽略其它的问题，这就可能引起了新的Bug。Smoke Tes穿优点是节省测试时间，防止build失败。缺点是覆盖率还是比较低。
冒烟测试是自由测试的一种。
什么是软件冒烟测试，希望有个实际例子说明
冒烟测试，是对软件基本的功能进行测试，测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本的功能正常，保证软件系统能跑的起来，可以进行后续的正式测试工作。
举个简单的例子：新开发一个加法软件，答错后会显示正确答案。测试者故意输错答案后却没有显示正确答案，就直接退回给开发人，不必去考虑其他原因。这个就是冒烟测试。
冒烟测试是什么
冒烟测试是指对一个硬件或硬件组件进行更改或修复后，直接给设备加电。如果没有冒烟，则该组件就通过了测试。在软件中，“冒烟测试”这一术语描述的是在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程。在检查了代码后，冒烟测试是确定和修复软件缺陷的最经济有效的方法。冒烟测试设计用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性。
什么是冒烟测试及实际工作中如何操作
在水管系统应用中，冒烟测试是指在水流经管路系统之前，先用实际的烟雾穿透整个管路系统，从而检查出是否存在渗水的地方。在木制乐器的修理应用中，做冒烟测试时先堵住乐器的未端,然后把烟从另一端吹入检测是否有渗漏（这种检测方法不常用）。在电子工程领域的应用中，冒烟测试是指当电路设计好，第一次加电自检时检测在设计或线路上是否存在缺陷，如果存在缺陷常会出现板子冒烟的现象。在娱乐业应用领域，冒烟测试时使用大量的演习烟雾，以确保在事件发生期间在案发现场的烟雾探测器不会被引发爆炸。软件工程中的tt应用：冒烟测试是指对提交测试的软件在进行详细深入的测试之前而进行的预测试，这种预测试的主要目的是暴露导致软件需重新发布的基本功能失效等严重问题。冒烟测试可以由开发人员执行，也可以由测试人员来执行。即，在版本编译后正式提交测试之前由开发人员执行；或开发发布版本后，测试人员在接受这个版本作为正式版本进一步测试前执行。微软提出在审查了变更的代码后，冒烟测试是确认修复的缺陷及功能变更是否有效的最经济有效的方法。冒烟测试能手动执行，也可以在版本编译后自动化执行，它是对基本功能的确认，非深入测试，但要覆盖到面，即所有的更改点都要进行确认。采用自动化执行是，可以结合每日构件后进行自动化的每日 *** oking test，如果测试通过，则把更改后的代码自动合并到主干代码仓库中，作为正式提交测试的版本。对于 *** oking test在软件开发过程中的应用，下面提出一种可实施的步骤：1. 根据软件的变更，包括新需求的实现、bug修复，设计出更改满足预期的功能级checklist。2. 准备好测试环境。如：软件的运行环境是嵌入式产品，如手机，数码相机，医疗仪器等，需准备好用户使用的真实运行环境。如果是windows平台运行环境，请准备干净的操作系统。3.执行checklist，确认基本功能有效，足以支持更进一步的详细、全面测试。文章来源于领测软件测试网
冒烟测试又叫什么
冒烟测试是指对一个硬件或硬件组件进行更改或修复后，直接给设备加电。如果没有冒烟，则该组件就通过了测试。在软件中，“冒烟测试”这一术语描述的是在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程。在检查了代码后，冒烟测试是确定和修复软件缺陷的最经济有效的方法。冒烟测试设计用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性。
软件测试的冒烟测试一般在哪个阶段测试呢
冒烟测试在刚开发完的时候进行的。
关于冒烟测试，应该是微软首先提出来的一个概念，和微软一直提倡的每日build有很密切的联系。具体说，冒烟测试就是在每日build建立后，对系统的 基本功能进行简单的测试。这种测试强调功能的覆盖率，而不对功能的正确性进行验证。
冒烟测试和回归测试的区别
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的。
冒烟测试冒烟测试( *** oke test)在测试中发现问题，找到了一个Bug，然后开发人员会来修复这个Bug。这时想知道这次修复是否真的解决了程序的Bug，或者是否会对其它模块造成影响，就需要针对此问题进行专门测试，这个过程就被称为Smoke Test。在很多情况下，做Smoke Test是开发人员在试图解决一个问题的时候，造成了其它功能模块一系列的连锁反应，原因可能是只集中考虑了一开始的那个问题，而忽略其它的问题，这就可能引起了新的Bug。Smoke Test优点是节省测试时间，防止build失败。缺点是覆盖率还是比较低。
冒烟测试是自由测试的一种。
软件测试方法的测试分类
β测试，英文是Beta testing。又称Beta测试，用户验收测试（UAT）。β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。当开发和测试要完成所做的测试，而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员完成，不能由程序员或测试员完成。α测试_Alpha测试α测试，英文是Alpha testing。又称Alpha测试.Alpha测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由该系统的程序员或测试员完成。在系统开发接近完成时对应用系统的测试测试后，仍然会有少量的设计变更。这种测试一般由最终用户或其他人员来完成，不能由程序员或测试员完成。可移植性可移植性测试，英文是Portability testing。又称兼容性测试。可移植性测试是指测试软件是否可以被成功移植到指定的硬件或软件平台上。 用户界面测试，英文是User interface testing。又称UI测试。用户界面，英文是User interface。是指软件中的可见外观及其底层与用户交互的部分（菜单、对话框、窗口和其它控件）。用户界面测试是指测试用户界面的风格是否满足客户要求，文字是否正确，页面是否美观，文字，图片组合是否完美，操作是否友好等等。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。用户界面测试用户分析软件用户界面的设计是否合乎用户期望或要求。它常常包括菜单，对话框及对话框上所有按钮，文字，出错提示，帮助信息 (Menu 和Help content)等方面的测试。比如，测试Microsoft Excel中插入符号功能所用的对话框的大小，所有按钮是否对齐，字符串字体大小，出错信息内容和字体大小，工具栏位置/图标等等。 冒烟测试，英文是Smoke testing。冒烟测试的名称可以理解为该种测试耗时短，仅用一袋烟功夫足够了。也有人认为是形象地类比新电路板基本功能检查。任何新电路板焊好后，先通电检查，如果存在设计缺陷，电路板可能会短路，板子冒烟了。冒烟测试的对象是新编译的每一个需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。 随机测试，英文是Ad hoc testing。随机测试没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试。主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行用例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试样例(TestCase)没有覆盖到的部分。另外，对于软件更新和新增加的功能要重点测试。重点对一些特殊点情况点、特殊的使用环境、并发性、进行检查。尤其对以前测试发现的重大Bug，进行再次测试，可以结合回归测试(Regressive testing)一起进行。
软件测试的目标和准则是什么？有哪些测试方法？测试步骤有哪些
具体地讲，测试一般要达到下列目标：
1、确保产品完成了它所承诺或公布的功能，并且所有用户可以访问到的功能都有明确的书面说明------在某种意义上与ISO9001是同一种思想。
产品缺少明确的书面文档，是厂商一种短期行为的表现，也是一种不负责任的表现。所谓短期行为，是指缺少明确的书面文档既不利于产品最后的顺利交付，容易与用户发生矛盾，影响厂商的声誉和将来与用户的合作关系；同时也不利于产品的后期维护，也使厂商支出超额的用户培训和技术支持费用。从长期利益看，这是很不划算的。领测认为接触过的软件产品，很少有向方正这样大大的产品、薄薄的文档。
当然，书面文档的编写和维护工作对于使用快速原型法(RAD)开发的项目是最为重要的、最为困难，也是最容易被忽略的。
最后，书面文档的不健全甚至不正确，也是测试工作中遇到的最大和最头痛的问题，它的直接后果是测试效率低下、测试目标不明确、测试范围不充分，从而导致最终测试的作用不能充分发挥、测试效果不理想。
2、 确保产品满足性能和效率的要求
使用起来系统运行效率低(性能低)、或用户界面不友好、用户操作不方便(效率低)的产品不能说是一个有竞争力的产品。
用户最关心的不是你的技术有多先进、功能有多强大，而是他能从这些技术、这些功能中得到多少好处。也就是说，用户关心的是他能从中取出多少，而不是你已经放进去多少。
3、 确保产品是健壮的和适应用户环境的
健壮性即稳定性，是产品质量的基本要求，尤其对于一个用于事务关键或时间关键的工作环境中。
另外就是不能假设用户的环境(某些项目可能除外)，如：报业用户许多配置是比较低的，而且是和某些第三方产品同时使用的。
测试的原则---Good Enough
对于相对复杂的产品或系统来说，zero-bug是一种理想，good-enough是我们的原则。
Good-enough原则就是一种权衡投入/产出比的原则：不充分的测试是不负责任的；过分的测试是一种资源的浪费，同样也是一种不负责任的表现。我们的操作困难在于：如何界定什么样的测试是不充分的， 什么样的测试是过分的。目前状况唯一可用的答案是：制定最低测试通过标准和测试内容，然后具体问题具体分析。最明显的例子就是FIT3.0中文报版的产品测试。
测试的规律----木桶原理和80-20原则
1、木桶原理。
在软件产品生产方面就是全面质量管理(TQM)的概念。产品质量的关键因素是分析、设计和实现，测试应该是融于其中的补充检查手段，其他管理、支持、甚至文化因素也会影响最终产品的质量。应该说，测试是提高产品质量的必要条件，也是提高产品质量最直接、最快捷的手段，但决不是一种根本手段。反过来说，如果将提高产品质量的砝码全部押在测试上，那将是一个恐怖而漫长的灾难。
2、 Bug的80-20原则。
一般情况下，在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的Bug，而系统测试又能找出其余Bug中的80%，最后的5%的Bug可能只有在用户的大范围、长时间使用后才会曝露出来。因为测试只能够保证尽可能多地发现错误，无法保证能够发现所有的错误。
软件测试的方法：
1、按是否查看程序内部结构分为：
（1）黑盒测试（black-box testing）：只关心输入和输出的结果
（2）白盒测试（white-box testing）：去研究里面的源代码和程序结构
2、按是否运行程序分为：
（1）静态测试（static testing）：是指不实际运行被测软件，而只是静态地......
跪求“冒烟测试”具体步骤
冒烟测试
冒烟测试 ( *** oke testing)，据说是微软起的名字。在《微软项目求生法则》一书第 14 章“构建过程”关于冒烟测试，就是开发人员在个人版本的软件上执行目前的冒烟测试项目，确定新的程序代码不出故障。
冒烟测试的名称可以理解为该种测试耗时短，仅用一袋烟功夫足够了。也有人认为是形象地类比新电路板功基本功能检查。任何新电路板焊好后，先通电检查，如果存在设计缺陷紶电路板可能会短路，板子冒烟了。
冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。
在一般软件公司的软件编写过程中，内部需要编译多个版本 (Build)，但是只有有限的几个版本需要执行正式测试（根据项目开发计划），这些需要执行的中间测试版本，在刚刚编译出来后，软件编译人员需要进行基本性能确认测试，例如是否可以正确安装/卸载，主要功能是否实现，是否存在严重死机或数据严重丢失等 Bug。如果通过了该测试，则可以根据正式测试文档进行正式测试。否则，就需要重新编译版本，再次执行版本可接收确认测试，直到成功。
新版本的基本功能确认检查的测试，有的公司称为版本健康检查 (Build Sanity Check)。对于编译的本地化软件新版本，除了进行上面提到的各种测试检查，还要检查是否在新的本地化版本中正确包含了全部应该本地化的文件。可以通过采用文件和目录结构比较工具，首先比较源语言版本和本地化版本的文件和目录中的文件数目、文件名称和文件日期等，这个过程称为版本镜像检查 (Build Image Check)。其次，分别安装源语言版本和本地化版本，比较安装后的文件和目录结构中的文件数目、文件名称和文件日期等，这个过程称为版本安装检查 (Build Installing Check)。
随机测试
在软件测试中除了根据测试样例和测试说明书进行测试外，还需要进行随机测试 (Ad-hoc testing)，主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行样例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。
随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试样例 (TestCase) 没有覆盖到的部分。另外，对于软件更新和新增加的功能要重点测试。须注意针对一些特殊情况点、特殊的使用环境和可能并发性问题进行检查。尤其对以前测试发现的重大 Bug，进行再次测试，可以结合回归测试 (Regressive testing) 一起进行。
理论上，每一个被测软件版本都需要执行随机测试，尤其对于最后的将要发布的版本更要重视随机测试。随机测试最好由具有丰富测试经验的熟悉被测软件的测试人员进行测试。对于被测试的软件越熟悉，执行随机测试越容易。只有不断的积累测试经验，包括具体的测试执行和对缺陷跟踪记录的分析，不断总结，才能提高。
