文章目录
Smoke Test
一、概述
冒烟测试是在软件开发过程中的一种针对软件版本包的快速基本功能验证策略，是对软件基本功能进行确认验证的手段，并非对软件版本包的深入测试。冒烟测试也是针对软件版本包进行详细测试之前的预测试，执行冒烟测试的主要目的是快速验证软件基本功能是否有缺陷。如果冒烟测试的测试例不能通过，则不必做进一步的测试。进行冒烟测试之前需要确定冒烟测试的用例集，对用例集要求覆盖软件的基本功能。这种版本包出包之后的验证方法通常称为软件版本包的门槛用例验证。
冒烟测试属于HLT(highleveltest)测试，HLT通常指SDV(系统设计验证)/SIT(系统集成测试)/SVT(系统验证测试)等测试活动。HLT是站在系统的角度对整个版本进行测试，测试对象是一个完整的产品而不是产品内部的模块，常见的HLT测试包括系统测试和验收测试。
冒烟测试可以手动执行，也可以自动化执行。稳定的系统适合自动化冒烟测试，集成过程中的系统适合手工冒烟测试，因为冒烟测试内容在动态变化，变化中的自动化脚本维护工作量比较大。
冒烟测试（smoke testing）,据说是微软起的名字。在《微软项目求生法则》一书第14章“构建过程”关于冒烟测试，就是开发人员在个人版本的软件上执行的冒烟测试项目，确定新的程序代码不出故障。冒烟测试的名称可以理解为该种测试耗时短，仅用一袋烟功夫足够了。也有人认为是形象地类比新电路板基本功能检查。任何新电路板焊好后，先通电检查，如果存在设计缺陷，电路板可能会短路，板子冒烟了。
二、分类
冒烟测试的对象是每一个新编译的需要正式测试的软件版本。通过冒烟测试，在软件代码正式编译并交付测试之前，先尽量消除其表面的错误，减少后期测试的负担。冒烟测试的执行者是版本编译人员。因此可以说，冒烟测试是预测试。在实际的软件测试工作中，冒烟测试在软件研发的不同阶段有所不同。大体可以分为三类：
1）形成集成测试版本以前：验证各个单元能够成功执行，并保证测试版本能够顺利集成；
2）形成集成测试版本：以保证新的或者更改过的代码不破坏集成版本的完成性和稳定性；
3）后期预测试缺陷的修正：针对每个缺陷所做的缺陷修正都要先在干净的链接环境中进行冒烟测试，测试通过后才能更新相关软件版本。
三、应用
冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。
在一般软件公司，软件在编写过程中，内部需要编译多个版本(Builds)，但是只有有限的几个版本需要执行正式测试（根据项目开发计划），这些需要执行的中间测试版本，在刚刚编译出来后，软件编译人员需要进行基本性能确认测试，例如是否可以正确安装/卸载，主要功能是否实现，是否存在严重死机或数据严重丢失等Bug。如果通过了该测试，则可以根据正式测试文档进行正式测试。否则，就需要重新编译版本，再次执行版本可接收确认测试，直到成功。
四、意义
冒烟测试，在软件生命周期中所占有的时间比例较低，同时具有注重通过性轻细节的特点，因此经常被开发、测试人员所忽视。事实上，冒烟测试是软件测试过程中一个不可或缺的节点，一个好的冒烟测试过程，对于软件测试效率的提升具有重要意义。
（1）冒烟测试是对软件质量的总体检验。
通过冒烟测试，能够快速确认软件是否具备测试准入条件，避免出现正式测试阶段全面开展后甚至到测试中后期才才发现阻塞型缺陷等严重影响测试进度浪费人力物力的情况。
（2）冒烟测试是测试人员对测试流程的熟悉。
通过冒烟测试，测试人员可以迅速熟悉测试总体流程，这一方面有助于测试人员准确制定测试时间计划，合理安排工作进度；另一方面也有助于测试人员提前做好相关设备、数据的准备，为正式测试的开展奠定基础。
五、注意事项
冒烟测试执行，与正式测试的区别在于二者侧重点不同，冒烟测试关注的是阻塞型缺陷，包括但不限于流程不通、主要功能未实现等，而正式测试则属于全面、细致的测试，需要尽可能的发现全部缺陷并按其严重性进行区分。冒烟测试过程中，需要注意的是：
1、开发协同
冒烟测试阶段有几个特点，一是该阶段软件可能存在较多缺陷，特别是阻塞型缺陷，测试工作随时可能陷入停滞状态；二是该阶段测试人员对软件的流程、功能等熟悉程度较低，难免会出现找不到合适的测试方法甚至是找不到功能模块的情况从而延迟测试进度；三是该阶段的时间一般仅占整个软件生命周期的极小部分，这就需要开发人员实时响应，尽快解决各类问题。因此，在冒烟测试阶段，测试人员与开发人员的协同工作十分重要。
2、注重效率
冒烟测试应以效率为先，尽量缩短测试时间提高测试效率。要在关注主流程、重点功能的前提下，抓关键缺陷验数据准备，对于诸如页面不美观、用户体验不佳等缺陷可在冒烟阶段有选择的予以过滤。例如：测试系统登录，关注点应针对用户名、密码、校验码的输入及提交完成，对于非法字符的校验、登录框是否美观、错误提示是否准确等均属于次要关注点，不纳入冒烟测试范围。
3、评估用例
冒烟测试过程同时也是对测试用例进行评估的一个过程，要充分利用这一阶段，对前期形成的测试案例进行检验，及时对案例进行补充、删减和修订，使案例更贴合实际，更具有可执行。
Ad hoc Test
一、概述
随机测试是没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试。主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行测试用例的重要补充手段，是保证测试覆盖完整性的有效方式和过程。
随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试样例(TestCase)没有覆盖到的部分。另外，对于软件更新和新增加的功能要重点测试。重点对一些特殊点情况点、特殊的使用环境、并发性、进行检查。尤其对以前测试发现的重大Bug，进行再次测试，可以结合回归测试(Regressive testing)一起进行。
理论上，每一个被测软件版本都需要执行随机测试，尤其对于最后的将要发布的版本更要重视随机测试。随机测试最好由具有丰富测试经验的熟悉被测软件的测试人员进行测试。对于被测试的软件越熟悉，执行随机测试越容易。只有不断的积累测试经验，包括具体的测试执行和对缺陷跟踪记录的分析，不断总结，才能提高。
二、客户端随机测试思想
随机测试是根据测试者的经验随机的选取功能点对软件进行有针对性的测试。 这种测试没有用例的指导，完全根据测试员自己的经验和相关知识来测试。
1、作随机测试之前的一些前提条件
1)熟悉产品的各项功能和产品的逻辑结果
2)熟悉测试用例
3)完整的执行过测试用例
4)熟悉在用例测试阶段所发现的缺陷和缺陷的分布情况
5)测试人员具备一定的测试经验，对缺陷有敏锐的洞察力。
2、随机测试功能点的选取
1)根据用例测试阶段对产品的了解选取缺陷比较密集的功能模块。在发现很多缺陷的地方，一定可以发现更多的缺陷。我们在做随机测试的时候，首先会先统计一下，之前哪些模块被发现的缺陷最多，那么接下来一定要重点的在那个模块里发掘一下缺陷。
2)根据发现的一次性缺陷或重现率比较低的缺陷涉及的功能点选取随即测试功能点。
缺陷产生的过程一定可以重现，重现率比较低的缺陷是隐藏比较深的缺陷，这些缺陷可能正是导致软件无法上线的原因。因此重现这些隐藏缺陷是十分重要的工作。
3)与开发人员沟通了解软件的缺陷。
首先可以了解到程序本身哪些地方最复杂，最薄弱，这些地方最容易发生什么错误，其次可以了解程序员最容易在哪些地方犯哪些错误。前者通过对程序的熟悉可以比较好的掌握，后者可以通过对缺陷的分析得到。
4)根据经验选取功能点。积累了一定的测试经验以后，有时测试就是一种感觉。
5)随机选取功能点。经过上述四种情况对功能点进行筛选后，剩下的功能点可以随机的选取。随机选取功能点只是在随机测试中选取功能点的一个方面，更多的时候还是要有针对行的选取功能点。
3、功能点的随机测试
1)以测试用例为基础。
首先要明确随机测试是对功能点进行随机测试而不是随机测试功能点。因此每一个功能点都是测试对象，依照测试用例可以有效地覆盖所有的功能点。
2)考虑操作前的状态
3)操作过程中的状态改变
4)考虑到其他功能对该功能点的影响
5)考虑该功能点直接对其他功能点的影响
6)考虑该功能点间接对其他功能点的影响
7)操作步骤地追踪。
在测试中常常会出现这样的情况，进行一系列复杂的操作之后缺陷突然呈现在眼前。这个时候如果能清晰地描述出具体的操作过程对于缺陷的重现是十分有利的，这也对最后的缺陷定位和简化缺陷的重现步骤提供了保障。交互性的模块追踪步骤主要考虑自己操作步骤地最终和对方操作步骤地追踪。有时缺陷的出现并不是完全是由自己的操作而发生的，别人的操作也有可能导致缺陷，只有综合自己和对方的操作才能是完整的过程追踪。