每日构建和冒烟测试

转载自 http://blog.sina.com.cn/s/blog_493a845501000566.html

谈每日构建都会连带谈冒烟测试这个词。每日构建不是简单的指每日编译,编译和构建完成后必须对增加的新功能点进行系统测试,对已经测试过的功能点进行冒烟测试。每日构建是微软比较推荐的最佳实践,强调测试的早期介入和持续的版本集成。
     
每日构建和冒烟测试的优点主要有:
1.进度可见并可以控制到1-2天的细粒度,很容易看到进度的偏差
2.及早的发现开发BUG和缺陷并分析解决,对开发人员的一种监督和促进,提高软件质量
3.由于将大集成分解到每日构建中的小集成,避免了传统产品集成或集成测试时候出现的严重问题的可能。
4.在项目中宣灌质量意识,强调第一次就把事情做好,而不是等测试来帮你发现问题
 
每日构建和冒烟测试也存在一些风险和缺陷,具体主要有
1.给开发人员太大压力,开发每天都在较紧张环境中工作
2.需要额外的测试人力资源和每日构建硬件环境的投入
3.开发人员不能专注,既要分心去修改BUG,又要开发新的功能点
4.对开发负责人要求更好,需要将功能细化到1-2天的有明确输出的功能点
5.开发需要投入额外的精力来保证每日构建顺畅
 
适用场景
1.对进度偏差控制和要求很高的项目
2.开发检查点和里程碑制定的很细致的项目
3.采用增量和迭代开发的项目,快速和敏捷开发的项目
 
每日构建提前需要进行的准备工作
1.对开发进度计划的要求,需要细化出每1-2天的开发进度计划,可以到一个很小的功能点。
2.对每日构建测试计划的要求,需要根据开发进度计划来安排冒烟测试和系统测试进度计划。
3.需要提前准备好每日构建的环境(每日构建必须是独立的环境)
 
每日构建和冒烟测试工作的实现可以人工来实现,但更多的需要借助些自动化的工具来完成。对于每日构建一般要提前编写好每日够建的脚本,可以借助Ant或NAnt构建工具来完成。每日构建脚本的复杂性跟项目或系统本身复杂性相关,对于简单的只有一个项目的解决方案,可能构建脚本会很简单,而对于较复杂的系统或项目构建脚本将会教复杂。NAnt是一个强大的通过构建脚本自动编译的工具,像我现在的项目在NAnt里面会做如下事情,而这个即使打开解决方案来编译也无法做到。

1.调用批文件重新自动生成数据访问层组件
2.创建相关的部署需要的cs_client,bs_client,server,service相关目录并拷贝公用文件
3.按照公用项目->逻辑层->界面层顺序和项目间依赖关系对各个项目逐一编译
4.调用外部工具soapsuds生成数据访问dll的代理类文件,逻辑层重新引用代理类进行编译(分布式部署需要)
5.引用3,4步需要的dll对Web项目进行编译
6.拷贝编译结果到相关的输出目录
 
每日构建和每日编译的最大区别就在于是否进行了冒烟测试,系统必须通过了冒烟测试才能够算每日构建成功。而测试人员人工介入的测试是基于冒烟测试通过的基础上面的。这里很简单一个例子,如我们NAnt配置文件忘记拷贝一个公共文件到server目录了,这个时候每日编译可能是通过的,但如果把这个版本部署出去测试无法进行测试的。或者说冒烟测试的一个重要作用就是要彻底解决由于构建自身原因引起的各种缺陷或Bug。
 
冒烟测试由于要验证整个编译的正确性,因此冒烟测试必须是针对整个系统进行冒烟测试。但冒烟测试只需要关注系统的主体功能即可,通过冒烟测试并不是说系统没有BUG,只是说通过了冒烟测试后可以说系统是一个稳定的版本,说系统的每日构建是成功了,代表系统可以转交专门的测试人员进行测试了。冒烟测试工作一般要采用自动化来进行,可以借助如LoadRunner等工具来录制自动化测试脚本,冒烟测试的脚本应该由专门的测试人员来维护,而且随着测试的进展冒烟测试脚本也应该是不断增加和补充的。
 
对于每日构建失败,直接责任的开发人员需要程度责任并付出代价。微软顾问经常爱举的一个例子就是凌晨2,3点开发人员被叫到公司解决每日构建失败的问题的案例。实际操作可能很难,但对构建造成影响的必须要承担应有的责任。
 
每日构建一般要配合使用源代码管理工具,而构建时间一般安排在每天下班后或晚上进行。开发人员需要保证每天检入的代码是能够顺利编译通过的,并保证在本机已经做了相关测试。每日构建并不是一定要要求每天都有新的功能点完成,如果今天开发完成的东西不是一个独立的可以提交测试的功能点,这个时候当天的源代码最好不要检入。代码的检入周期一般要在2-3天内,如果周期再长基本上就达不到每日构建的作用了。
 
每日构建必须有独立和专门的构建服务器和构建环境。构建服务器和构建环境与测试环境的最大区别在于构建环境是完全Copy开发环境,单独出构建环境目的是保证构建过程不和开发环境和过程冲突。如果条件不允许的话可以将构建环境和测试环境合并,但构建环境必须和开发环境分离。
 
每日构建的成功要素
1.每天都进行编译和冒烟测试
2.冒烟测试脚本随着测试的进度不断完善和补充
3.构建成功在项目中拥有较高的优先级
4.通过过程的制定保证构建失败更多的是因为异常因素而非规则不清
5.在压力下不要抛弃过程


<think>好的,我现在需要回答用户关于冒烟测试接口测试区别及应用场景的问题。首先,我得回忆一下这两种测试的基本概念,然后找出它们的不同之处,再结合应用场景进行说明。 冒烟测试,我之前学的好像是用来验证软件的主要功能是否正常,通常是在构建之后立即执行,确保没有严重的缺陷,让后续测试可以进行。比如每次开发提交新代码后,跑一遍主要的测试用例,确认系统没大问题。这有点像“健康检查”,快速反馈基本功能是否正常。 接口测试,主要是测试系统组件间的接口,特别是API接口,验证数据传输、参数正确性、错误处理等。比如用Postman或JMeter发送HTTP请求,检查返回结果是否符合预期。接口测试更关注各个模块之间的交互数据正确性,属于集成测试的一部分。 接下来需要区分两者的区别。首先,测试对象不同:冒烟测试针对整个系统的主要功能,而接口测试针对模块间的接口。其次,测试阶段不同,冒烟测试构建后第一时间执行,属于初步测试,而接口测试可能在开发过程中持续进行,特别是在持续集成环境中。再者,测试目的不同,冒烟测试确保系统基本可用,接口测试确保模块间交互正确。此外,执行频率覆盖范围也不同,冒烟测试频率高但覆盖广而不深,接口测试则更深入每个接口的细节。 应用场景方面,冒烟测试常用于每日构建、版本发布前,快速验证;接口测试在模块开发完成后,持续集成阶段频繁执行,保证接口稳定性。比如新功能合并后,先做冒烟测试,再针对新增接口做详细测试。 还要参考用户提供的引用内容,引用[4]提到冒烟测试属于系统测试的一部分,而接口测试属于集成测试。引用[3][5]说明接口测试关注响应时间、并发等,而冒烟测试更关注主要功能是否正常。结合这些信息,可以更准确地描述区别应用场景。 最后,生成相关问题,帮助用户深入理解,比如测试策略、执行方法等。</think>### 冒烟测试与接口测试的区别及应用场景 #### 一、核心区别 1. **测试目标** - **冒烟测试**:验证系统**核心功能是否可运行**,属于**基础验证**。例如:用户登录、支付流程是否正常[^4]。 - **接口测试**:验证**模块间数据交互的准确性**,关注参数传递、状态码、错误处理等。例如:检查API返回的JSON数据结构是否符合预期[^5]。 2. **测试范围** - **冒烟测试**:覆盖**端到端的主要业务流程**,例如电商系统中“搜索商品→下单→支付”的全流程[^4]。 - **接口测试**:聚焦**单个接口或接口链路的逻辑**,例如验证用户注册接口的输入校验数据库写入[^2]。 3. **执行阶段与频率** - **冒烟测试**:在**每日构建或版本发布前**执行,频率较低(通常每日1次)[^4]。 - **接口测试**:在**持续集成(CI)环境**中自动触发,频率高(每次代码提交后)。 4. **技术实现** - **冒烟测试**:可能通过**UI自动化或手动操作**完成,依赖用户界面。 - **接口测试**:直接通过**HTTP请求工具**(如Postman、JMeter)或代码模拟调用,无需依赖前端。 #### 二、典型应用场景 | **场景** | **冒烟测试** | **接口测试** | |------------------------|--------------------------------------|--------------------------------------| | **新版本发布前** | 验证核心业务流程是否崩溃 | 检查新增接口的兼容性性能 | | **持续集成流程** | 作为流水线的“准入检查” | 自动化验证接口逻辑边界条件 | | **第三方系统对接** | 不适用 | 验证外部API的鉴权机制数据格式 | | **性能问题排查** | 不适用 | 分析接口响应时间并发瓶颈[^3] | #### 三、实际案例对比 - **冒烟测试案例**: 某社交App更新后,测试团队通过5条核心用例(如发布动态、发送消息)确认版本可测性,耗时10分钟[^4]。 - **接口测试案例**: 支付系统中,对“订单创建接口”进行参数组合测试(如金额为负数、超长订单号),发现数据库写入异常,共设计20条用例[^2]。 #### 四、协同关系 两者在研发流程中**互补**: 1. 冒烟测试通过后,接口测试可深入验证细节逻辑。 2. 接口测试发现的底层问题(如参数校验缺失)可能导致冒烟测试失败。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值