冒烟测试

在我们工作中，创业公司或是需要抢占市场的项目都采用敏捷开发的方式。最快上线投入市场，可是随着公司的成长，项目的变大项目流程就显得越来越重要了。于是就会在项目开发的过程中引入项目流程控制，以保证项目周期和质量。此是可能是由公司高层制定，也可能与我们测试人员商量，对于我们测试人员，应该如何制定项目流程呢？ 一， 国际性工业化流程 软件项目工程有标准的流程，也就是国际化标准流程，当然我们可以从书上或是网上获得相。如下所示，是我在网上查找到的一个流程： 在实际的公司项目流程中，发现如果完全按标准的流程来走会有很多问题，关键原因就是这个标准的项目流程是有适应条件的： （1）项目周期长，有充足的时间；而公司的项目往往周期比较短，一周的项目周期就算长的了，所以根本无法按正规的周期来执行。 （2）相关标准和文档比较完善，而且要求高。而现在公司很多开发人员不愿意写文档，或是项目历史包袱较重，没有办法整理相关的文档。 （3）领导重视项目流程，严格按标准执行。大型的公司比较重视流程，而现在关注点比较多，如收入，客户，市场等等，造成流程无法完全按标准执行。 二， 个性化的项目流程 针对标准化的流程执行起来比较困难，所以需要根据自己业务和团队特点来制定个性化的项目流程。简化标准流程，加强自己需要的部分，下面我们举个例子，以下面四个阶段做相应的流程控制： （1）需求阶段流程控制 需求是一个项目最早的阶段

一、 冒烟测试 和回归测试的区别 1，测试阶段不同： 冒烟测试 描述的是在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程 。回归测试是指漏洞由开发人员修改之后再次测试的过程。 2，测试稳定性不同：在检查了代码后， 冒烟测试 是确定和修复软件缺陷的最经济有效的方法。冒烟测试设计用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性。回归测试需要验证之前的漏洞是否解决完成。 3，测试目的不同： 冒烟测试是代码开发完成后进行的功能完整性测试 。但是回归测试为了验证漏洞是否正确修改且其他功能是否正常。 4，测试性质不同： 冒烟测试中发现问题然后反馈给开发人员进行修改，而回归测试是修改完之后进行验证再进行的工程 。 5，测试周期不同：冒烟测试只集中考虑了一开始的那个问题，而忽略其它的问题，这就可能引起了新的Bug。SmokeTest优点是节省测试时间，而回归测试作为软件生命周期的一个组成部分，在整个 软件测试 过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。 来源： CSDN 作者： 战斗，然后凯旋 链接： https://blog.csdn.net/qq_41893274/article/details/103984978

按开发阶段分: 单元测试 单元测试是对软件组成单元进行测试。其目的是检验软件基本组成单位的正确性。测试的对象是软件设计的最小单 位：模块。又称为模块测试 测试阶段：编码后或者编码前（TDD） 测试对象：最小模块 测试人员：白盒测试工程师或开发工程师 测试依据：代码和注释+详细设计文档 测试方法：白盒测试 测试内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试 集成测试 集成测试也称联合测试（联调）、组装测试，将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的 功能进行正确性检测的测试工作。集成主要目的是检查软件单位之间的接口是否正确。 测试阶段：一般单元测试之后进行 测试对象：模块间的接口 测试人员：白盒测试工程师或开发工程师 测试依据：单元测试的模块+概要设计文档 测试方法：黑盒测试与白盒测试相结合 测试内容：模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系 统的影响 系统测试 将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试。时间大部分在系统 测试执行阶段，包括回归测试和冒烟测试。 测试阶段：集成测试通过之后 测试对象：整个系统（软、硬件） 测试人员：黑盒测试工程师 测试依据：需求规格说明文档 测试方法：黑盒测试 测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 【Alpha测试】 Alpha测试是由用户在开发环境下进行的测试，也可以是开发机构内部的用户在模拟实际操作环境下进行的测试 测试环境受开发方控制 用户数量相对较少 时间比较集中 先于Beta测试 【Beta测试】 Beta测试是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。 测试环境不受开发方控制 用户数量较多 测试时间比较长 【验收测试】 验收测试是以用户为主的测试，软件开发和QA人员也应该参加，测试一般在用户所在地进行，由用户验证软件产品是否满足了所有的需求的一系列的验收测试工作 验收测试的目的是为了以发现”未实现的需求”为目的，以评估”适合使用”为目标，该类测试的不是以发现缺陷为主要目的。 【灰度测试】 灰度测试，也叫灰度发布或金丝雀发布，就是在某项产品或应用正式发布前，选择特定人群试用，逐步扩大其试用者数量，以便及时发现和纠正其中的问题。 灰度发布能及早获得用户的意见反馈，完善产品功能，提升产品质量，让用户参与产品测试，加强与用户互动，降低产品升级所影响的用户范围。 在其上可以进行A/B testing，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来 灰度发布可以保证整体系统的稳定

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 冒烟测试，是微软首先提出来的一个概念，和微软一直提倡的每日build（构建版本）有很密切的联系。具体说，冒烟测试就是在每日build（构建版本）建立后，对系统的基本功能进行简单的测试。这种测试强调程序的主要功能进行的验证，也叫版本验证测试，提交测试。 冒烟测试 这个名称的来历，是从电路板测试得来的。因为当电路板做好以后，首先会加电测试，如果板子没有冒烟在进行其它测试，否则就必须重新来过。类似的如果冒烟测试没有通过，那么这个build也会返回给开发队伍进行修正，测试人员测试的版本必须首先通过冒烟测试的考验。 冒烟测试的说法据说是：象生产汽车一样，汽车生产出来以后，首先发动汽车，看汽车能否冒烟，如果能，证明汽车最起码可以开动了。说明完成了最基本的功能。 冒烟测试一般用于每日构建(Nightly build)，构建服务器首先从CVS服务器上，下载最新的源代码，然后编译单元测试，运行单元测试通过后，编译可执行文件，可执行文件若可运行，并能执行最基本的功能，则认为通过了冒烟测试，这时，构建服务器会把程序打包成安装文件，然后上传到内部网站，第二天一早，测试人员来了以后，会收到构建服务器发来的邮件提示昨晚是否构建成功。若构建成功，则测试人员进行相关的功能测试。所有这些功能的完成，一般是靠编写脚本完成的

测试流程规范 编写 ：XXX 1. 测试流程 1. 目标 2. 主要流程 3. 自动化测试在测试流程中的作用 4.一般的项目测试流程 5. 需求评审 6. 设计评审 7. 测试计划 8. 测试用例 9. 冒烟测试 10. 测试执行 11. 测试报告 12. 验证发布 1.1. 目标 目标： 为了更好的保证产品质量，提高测试效率，沉淀积累测试流程，特制定该流程，并在一段时间内推动并落实： 1.2. 主要流程 1.3. 自动化测试在测试流程中的作用 1.4. 一般的项目测试流程 1 、需求阶段：需求熟悉、需求评审 2 、设计和代码阶段：设计评审、准备测试计划（评审）、测试用例（评审） 3 、测试环境搭建、测试工具准备 4 、测试执行（代码走查、冒烟测试、安全扫描、性能测试、易用性测试、回归测试） 5 、生产环境验收测试。 1.5. 需求评审 对于任意的项目，都需要进行需求评审，充分了解需求，目的。在需求评审中发现需求的不足，遗漏等，尽量把问题消灭在萌芽阶段，这个阶段发现问题是效率最高的，能够节约大量项目时间。在需求评审之前，请各位仔细阅读需求说明，做好充分准备，避免会议上才开始阅读需求，或者需求评审的时候不能及早提出异议。 1.6. 设计评审 通过参与设计评审，了解设计架构，对了解系统的设计，逻辑处理等有很大的帮助，能帮助我们设计测试计划，测试用例 1.7. 测试计划 测试开始之前

前面学习了参数的传递和调用，下面研究一下根据参数作为条件执行不同的stage 使用叫when 和expression控制某一个stage的运行， 运行场景例如写了多个stage，这个pipeline脚本执行执行冒烟测试，和集成测试。有时候，希望快速执行冒烟测试，想根据结果看看，不一定一上来就执行集成测试。为了达到这种控制效果，我们就需要使用逻辑控制。在pipeline中就使用when 和expression两个命令。例如，如果json文件中冒烟测试变量为true，我就只执行冒烟测试的stage,其他和冒烟测试无关的stage我就不去执行。如果冒烟测试变量值为false，也就是默认要跑集成测试（不跑冒烟测试）。下面分两个类型测试就好 1 修改json文件 { "NAME":"Lucy", "AGE":"18", "PHONE_NUMBER":"13912345678", "ADDRESS":"Haidian Beijing", "EMAIL":"lucy@demo.com", "GENDER":"male", "SMOKE":"false"， "IS_MARRY":"false" } test.json文件基础上加了一个变量 SMOKE， 默认值是false。 2 使用的jenkinsfile文件 import hudson.model.*; pipeline{ agent any

冒烟测试是自由测试的一种，由开发人员与测试人员共同进行。在测试过程中发现问题，测试人员找到了一个Bug，然后开发人员会来修复这个Bug， 冒烟测试是否通过 决定了下一轮系统测试是否可以执行。 冒烟测试与回归测试的区别 冒烟测试，是版本验证测试，主要确认新的版本是否存在致命性bug，功能可以正常运行（不会出现跑不通的状况），不会影响下一轮测试的进行，如果上述都符合那么这个版本就可以进行下一轮测试。个人理解冒烟测试最大的优点在于节约测试的时间成本，减少测试轮数。 而回归测试，是软件维护阶段对软件修改后进行的测试，指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。 来源： https://www.cnblogs.com/itplay/p/11881482.html

冒烟测试： 　　冒烟测试的由来是电路板测试，电路板焊接完成之后会插电进行测试，如果电路板冒烟了，说明它是不合格的。 　　在软件测试过程中对主功能进行测试，如果测试通过，可以进行系统测试。把它理解为一次流程的开关，通过了就继续，不通过就返工。 回归测试： 　　测试提出的bug被修改后再次验证的过程。 　　参考链接：https://www.jianshu.com/p/46a2fc4a1d00 来源： https://www.cnblogs.com/pcyu/p/11806704.html

一、软件开发阶段 需求分析 ①根据客户的要求，清楚了解客户需求中的产品功能、性能、界面和具体规格等，然后进行分析，确定软件产品索要达到的目标 ②要形成规则说明书 概要设计 ① 系统分析员审查软件计划、软件需求分析提供的文档，提出候选的最佳推荐方案，确定模块结构，划分功能模块，将软件功能需求分配给所划分的最小单元模块，确定模块间的联系，确定数据结构、文件结构、数据库模式等 ② 概要设计说明书 详细设计 ① 将每一个模块确定使用的算法，并用适当的工具（如流程图）表示算法的过程，写出模块的详细过程性描述；确定每个模块使用的数据结构；确定模块接口的细节，包括用户界面、数据输入输出等全部细节。 ② 详细设计说明书 编码 通过编程语言实现 哪个阶段引入的缺陷最多？ 二、软件测试阶段 单元测试 ①依据：详细设计文档 ②以黑盒测试（功能测试）为主，重点核心模块可以进行白盒测试（检查代码） ③可能需要编写驱动模块或桩模块【因为一个模块，可能不会单独存在，需要调用别的模块或者被别的模块调用】 驱动模块：模拟被测模块的上一级模块（调用被测模块的哪个模块） 桩模块：模拟被测模块的下一级模块（被被测模块调用的模块） ④在实际工程中，为了节约成本，单元测试经常只由开发人员完成，有悖于测试测试思想（测试必须由第三方来完成） 一个好的单元测试将会在产品开发的阶段发现大部分的缺陷，并且修改它们的成本也很低。