冒烟测试

1. 提测质量差 　　问题描述：第一个提测版本差，有些均未通过 冒烟测试 　　问题分析 　　A. 版本提测质量差，但基于发布时间已在，因此，在提测差时就开始测试 　　提测质量差的点：- 基于上每项功能的完成度都不高 - 有些功能均未实现 - 　　B. 新的团队，团队处于磨合期 　　C. 在提测时，对提测要求不明确，在时间点到后，匆忙提测 　　解决方式： 　　明确版本提测要求，并且开发得到了足够的时间。 2. 版本控制 　　问题描述： 　　最初阶段，每天出一个版本，基于新版本测试，记录每个版本上测试的功能。版本过于频繁，质量把控不好 　　问题分析： 　　A. 基于版本提测质量差，而且每天出一个版本，差上加差， 　　B. 虽然记录每个版本上测试的功能，但仍然无法把控当前版本的质量状况。 　　解决方式：暂停每天发布一个版本 　　前期：将全功能版本作为下一个版本发布目标，但由于一些功能并没有完成，因而，全功能版本分成了好几个阶段 　　后期：以测试一轮周期，发布最新版本 3. 功能反复 　　问题描述：在上一个版本是OK的功能，在新版本中功能失常 　　功能反复分两点：一是大功能反复， 二是小功能（如：某个bug）反复 　　问题分析： 　　大功能反复：情况主要发生成项目前期和中期 　　A. 功能未完成，在完善功能时，未考虑到与该功能相关的点 　　B. 在提测之后，发现一些问题，导致了整个模块重构

1，B/S和C/S架构的区别？ 从测试的角度来讲。B/S架构需要重点考虑系统在不同的浏览器中的兼容性问题；C/S 架构需要考虑系统在不同平台的安装、卸载、升级 B/S 即Browser/Server(浏览器/服务器)结构,指浏览器和服务端，在客户机端不用装专门的软件，只要一个浏览器即可。 C/S 即Client/Server(客户机/服务器)结构,指客户机和服务端，在客户机端必须装客户端软件后才能访问服务器。 2，对HTTP协议怎么理解的？ http协议是应用层的一个数据传输协议，由请求和响应构成， 主要的请求方式有get和post两种，get请求的请求数据在请求头，post请求的请求数据在请求体 响应的数据也包含响应头和响应体。 3，常见的http状态码？ 200 请求成功 用于get/post请求 301 永久移动 302 临时移动 404 服务器无法找到资源，网页丢失 500 服务器内部错误 4，http请求头包含哪些信息？ content-type （作用：定义网络文件的类型和网页的编码 ） accept （作用：发送端（客户端）希望接受的数据类型） 5，get和post的区别？ get 请求数据参数放在请求头传送，请求地址长度有限制，一般用在获取数据。 post请求数据参数放在请求体传送，请求地址没有长度限制，一般用在提交数据。 6，什么是软件测试？ 软件测试就是使用软件

软件测试分类 1. 按照阶段进行划分 1.1 单元测试(Unit Testing) 单元测试是对软件组成单元进行测试。其目的是检验软件基本组成单位的正确性。测试的对象是软件设计的最小单位：模块。 测试阶段：编码后 测试对象：最小模块 测试人员：白盒测试工程师或开发工程师 测试依据：代码和注释+详细设计文档 测试方法：白盒测试 测试内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试 1.2 集成测试(Integration Testing) 集成测试也称联合测试、组装测试，将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。主要目的是检查软件单位之间的接口是否正确。 测试阶段：一般单元测试之后进行 测试对象：模块间的接口 测试人员：白盒测试工程师或开发工程师 测试依据：单元测试的模块+概要设计文档 测试方法：黑盒测试与白盒测试相结合 测试内容：模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响 补充说明： 单元测试是一个模块内部的测试，集成测试是在模块之间进行测试（至少两个） 1.3 系统测试(System Testing) 将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试。时间大部分在系统测试执行阶段,包括回归测试和冒烟测试 测试阶段

1. 按照阶段进行划分 1.1 单元测试(Unit Testing) 单元测试是对软件组成单元进行测试。其目的是检验软件基本组成单位的正确性。测试的对象是软件设计的最小单位：模块。 测试阶段：编码后 测试对象：最小模块 测试人员：白盒测试工程师或开发工程师 测试依据：代码和注释+详细设计文档 测试方法：白盒测试 测试内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试 1.2 集成测试(Integration Testing) 集成测试也称联合测试、组装测试，将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。主要目的是检查软件单位之间的接口是否正确。 测试阶段：一般单元测试之后进行 测试对象：模块间的接口 测试人员：白盒测试工程师或开发工程师 测试依据：单元测试的模块+概要设计文档 测试方法：黑盒测试与白盒测试相结合 测试内容：模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响 补充说明： 单元测试是一个模块内部的测试，集成测试是在模块之间进行测试（至少两个） 1.3 系统测试(System Testing) 将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试。时间大部分在系统测试执行阶段,包括回归测试和冒烟测试 测试阶段：集成测试通过之后 测试对象

敏捷项目测试策略文档模板 　　在一个敏捷工作环境种，我们的研发工作以冲刺期和高度迭代的形式展开。每一个迭代周期都关注少数的需求或者用户故事，所以在文档在敏捷项目种的数量和内容方面都倾向于轻量化。 　　对于测试计划这样的文档也是如此，不过我们也确实需要为敏捷团队去提供一个概要的敏捷测试策略，以供指导。 　　敏捷测试策略文档是为了给团队提供一个最佳的测试实践和一些形式的测试体系。记住，敏捷并不意味着没有体系。 　　下面我们来看一个敏捷测试策略文档，看看我们都应该包含些什么内容。 1.　　 一份测试策略中通常都会对于更宽泛的商业目的和目标做出任务说明。 　　 一个典型的任务说明可以是： 　　“通过快速反馈和缺陷预防，持续的交付可工作的，满足用户需求的软件，而不仅仅是缺陷发现” 　　细化以后： 　　“● 在定义完需求的接收条件/测试之后，代码才能进行编写。 　　 ● 接收测试不通过，一个需求就不能被判断为完成。” 　　在敏捷项目中，通常还会包含关于质量保证的提示： 　　● 质量保证是系统和可靠的保证产品满足用户需求的一系列活动。 　　● 在SCRUM（敏捷）中，质量保证是所有人的责任，而不单单是测试人员。在我们开发新产品的过程中，我们通过质量保证活动来确保正确的质量。　 　 2.　　 测试级别 　　 2.1　　单元测试 　　WHY : 确保代码被正确开发 　　WHO : 开发工程师

由于冒烟测试特别关注更改过的代码，因此必须与编写代码的开发人员协同工作。必须了解以下内容： ·代码中进行了什么更改。若要理解该更改，必须理解使用的技术；开发人员可以提供相关说明。 ·更改对功能有何影响。 ·更改对各组件的依存关系有何影响。 注意：冒烟测试就是把整个系统或者网站运行测试一次，重点是需要测试的覆盖率。 来源： https://blog.csdn.net/qq_30020875/article/details/102393458

本文链接：https://blog.csdn.net/zjuxsl/article/details/79364811 软件测试是软件工程当中不可或缺的一个过程。在软件工程中，测试者充当“虚拟用户”对软件产品进行检验。只有经过严格测试的软件产品，才能发布给用户使用。 只要有软件的地方，就有软件测试。 软件测试是一个包罗万象的话题。这种“包罗万象”的具体表现之一就是软件测试的分类：多样化的观察角度，多样化的衡量标准，造就多样化的分类方法。软件测试的分类可谓是“百花齐放，百家争鸣”。 例如，根据测试手段，软件测试既可以分为手动测试和自动化测试，也可以分为静态测试和动态测试，还可以分为白盒测试、黑盒测试和灰盒测试。 例如，根据测试目标，软件测试可以分为功能测试和非功能测试。功能测试可以根据业务类型做二次分类；非功能测试可以分为性能测试、安全测试、可用性测试、稳定性测试等。 例如，在软件生产的不同阶段，有单元测试、集成测试、系统测试、冒烟测试、alpha测试、beta测试等。 例如，根据测试执行频率，软件测试可以分为回归测试和非回归测试。 例如，根据测试自由度，软件测试可以分为预定义测试和探索性测试。 ..... 面对如此纷繁多样的测试分类，有没有一个主线方法能够让我们拨云见日，理清思绪呢？ 笔者认为，基于测试分级的分类方法，可以回答这个问题。 那么，什么是测试分级？

软件测试的基本流程（重点） 软件测试的基本流程（重点） 测试需求分析阶段：阅读需求，理解需求，主要就是对业务的学习，分析需求点，参与需求评审会议 测试计划阶段：主要任务就是编写测试计划，参考软件需求规格说明书，项目总体计划，内容包括测试范围（来自需求文档），进度安排，人力物力的分配，整体测试策略的制定。风险评估与规避措施有一个制定。 测试设计阶段：主要是编写测试用例，会参考需求文档（原型图），概要设计，详细设计等文档，用例编写完成之后会进行评审。 测试执行阶段：搭建环境，执行冒烟测试（预测试）-然后进入正式测试，bug管理直到测试结束 测试评估阶段：出测试报告，确认是否可以上线 Plan-Do-Report 总结 开发流程：了解用户需求--》进行需求分析--》得知功能组成及设计软件结构--》开发设计计划--》概要设计--》详细设计--》进行软件编码--》单元测试--》代码审查--》打包提交给测试部--》测试部返回bug--》更新修复bug--》再次进入测试部测试-。。。直到bug解决--》版本上线--》面向用户使用 测试流程：了解用户需求--》参考需求规格说明书--》测试计划（人力物力时间进度的安排）--》编写测试用例--》评审用例--》搭建环境--》测试包安排预测（冒烟测试）-正式测试-bug-测试结束出报告--》版本上线--》面向用户 常见面试笔试题： 1

目录 测试基础 1 测试类型划分 2 根据阶段划分的测试类型 3 根据性质划分的测试类型 4 根据是否看代码划分的类型 5 根据是否运行程序划分的类型 6 高级测试 测试教学大纲 测试基础 1 测试类型划分 IEEE说软件工程是： 1.将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件； 2.在1中所述方法的研究 比较认可的一种定义认为： 软件工程是研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来。 2 根据阶段划分的测试类型 按照测试阶段划分 单元测试---集成测试---系统测试---验收测试 举例：2周一次发布的系统 3 根据性质划分的测试类型 app，web界面测试 主要负责PC端web,移动端android和ios测试。 后端接口测试 主要在后端接口，数据库方面的测试。 4 根据是否看代码划分的类型 黑盒 白盒 灰盒 黑盒白盒都会有涉及到的。目前这个类型的岗位实用。 5 根据是否运行程序划分的类型 静态测试 不运行程序的测试，就是静态测试。 动态测试 运行程序的测试，就是动态测试。 程序动起来了就是动态，程序不动的话就是静态。 6 高级测试 回归测试，冒烟测试，探索性测试，随机测试，安全性测试 冒烟测试和回归测试的联系与区别

手工测试用例 PK 自动化测试用例 首先，需要区分手工测试和自动化测试用例的不同。 1.手工测试用例： 关注某个功能点 可考虑多种异常情况并做出相应的处理，通过人为的逻辑判断当前步骤的功能实现正确与否 人工执行具有一定的步骤跳跃性 人工测试步步跟踪，能够细致的定位问题 主要用来发现功能缺陷，适用于测试阶段 2.自动化测试用例： 关注的是流程，多个功能点 用例步骤关联性强 保证产品主题功能能正确完成和让测试人员从繁琐重复的工作中解脱出来 自动化测试的每个用例的起始页面和退出页面一般是同一个页面，从哪里开始，到哪里结束（为了保证每次测试的初试环境是一样的） 目前自动化测试主要用于冒烟测试和回归测试（冒烟测试执行的是主体功能点的用例。回归测试执行全部或部分的测试用例） 自动化测试用例设计原则： 不需要将所有的手工测试用例转化为自动化测试用例 选择功能较为稳定的功能模块进行测试。当功能变动大时，脚本的维护需要花费更多的精力 选择的用例如为主体流程，可用于冒烟测试 自动化测试也可以用来做配置检查，数据库检查等。也算用例拓展的一部分。 如果平时在手工测试时，需要构造一些复杂数据，或重复一些简单机械式动作，就可以使用自动化脚本创造 准备复杂的测试数据。对于大的应用系统，数据之间的关系和准备过程都会很复杂，甚至有其他外部系统导入、传输或计算出来的数据