测试执行_1测试基本流程

冒烟测试

一、测试基本流程

开发完成 -> 冒烟测试 -> 新需求测试 -> 回归测试 -> 上线

测试执行期间，进行用例执行管理和bug管理，测试过程产出数据并生成质量报告，质量报告完成才能上线。

二、冒烟测试

1 什么是冒烟测试？

1.1 冒烟测试由来

来源于电路板，新电路板焊接完成，先通电检查，若电路板出现短路等大问题，电路板会冒烟；

之后，将其类比为软件主干功能的测试。

1.2 什么是冒烟测试？

在正式进入测试前，先把待测试的主要功能检查一遍；

若主要功能都无法实现，就认为该软件是未完成品，马上反馈给开发重新做。

2 如何判断冒烟通过？

冒烟用例通过率达到100%，因为冒烟用例选取的是主干用例，一旦失败，意味着主干功能走不通，这样的版本不适合进入正式测试；

如，云课堂的课程详情页面的”立即参加“用例若走不通，后续的”课程学习”用例都无法执行，阻碍正式测试。

3 冒烟测试流程

测试人员选择冒烟用例 -> 测试人员与开发人员沟通冒烟用例 -> 开发人员完成开发后对照冒烟用例进行自测 -> 自测完成后提交给测试人员进行冒烟测试 -> 若冒烟测试通过，接收版本进入正式测试；若不通过，把版本回退给开发，开发人员修改后再次提交给开发人员进行冒烟测试。

下图是WY内部采用的冒烟测试流程，其他互联网公司也有这样执行，也有省略开发自测这一步；

但自测试至关重要的，也符合互联网敏捷开发的原则。

1’ 选择冒烟用例

选择标准：

选择主干流程的正向用例，一般从P1、P2的用例中选择，建议在版本测试用例的10%~20%左右。

冒烟测试执行时长：

这些用例能尽快执行完，一般在半天内执行完（超过两周的大版本一般在半天内完成，小版本一般在1、2小时完成）

以云课堂的冒烟用例为例：

对于”参加课程“功能点，选择”已登录后参加课程“用例作为冒烟用例：

对于”学习课程“功能点，选择如下7个用例作为冒烟用例：

挑选出来并简单调整前提条件，最终组成8个冒烟测试：

2‘ 跟开发沟通冒烟用例

将冒烟用例发给开发，让开发事先知道，便于开发完成后进行自测；

3’ 完成开发和自测

完成自测后，开发发邮件给项目组，告知版本开发冒烟自测全部通过，请QA进行冒烟测试；

4‘ 冒烟测试

根据测试用例执行，若符合期望结果，则在实际结果一栏填写”通过“，若不符合，则填写”不通过“并描述实际现象，报bug。

5’ 冒烟不通过

将冒烟测试情况以邮件形式发给项目组；

6‘ 第二次冒烟测试通过

将冒烟测试情况以邮件形式发给项目组；

7’ 接收版本，进入正式测试

4 冒烟测试意义

4.1 减少重复执行，提高测试效率

若没有冒烟测试，直接进入测试，测试人员根据最全的测试用例进行测试，执行一段时间检测到一个bug，由于这个bug存在，导致很多用例无法执行，只能把版本回退给开发，之前执行测试都白费了，浪费时间，因为开发再次提交给测试，还是需要从头开始执行测试用例。

4.2 开发和测试就版本质量标准达成一致

若没有冒烟测试，开发可能提交质量较差的版本给测试，测试可能执行很多轮仍不能完成所有用例的执行；有冒烟测试，开发了解应该提交给测试怎样的版本。

新需求测试与回归测试

一、新需求测试

1 新需求测试一般包括功能、兼容性、性能需求测试等，这里主要讲解功能和兼容性需求测试，对于性能需求测试，在后续课程专门讲解。

以云课堂为例，根据交互稿，云课堂项目主要涉及课程详情页、课程学习页、播放页三个模块；

2 新需求测试怎么选择测试用例？一般选择这次新增或修改的功能进行详细测试；

根据测试用例执行第一轮新需求测试，按照顺序一个模块一个模块进行测试，若发现bug，立即上报；测试完一个版本后，等到开发修改bug结束，进行下一个版本的测试；一次重复。

在新需求测试和回归测试阶段，测试人员每天编写测试日报以同步测试进度，让项目组了解目前进行到第几轮测试以及还有哪些问题。

Hi all,

【跨境项目】冒烟测试于今天全部执行完毕，现进入第一轮测试阶段。

一、冒烟测试结果
冒烟测试于今天全部执行完毕，比原计划延迟一天。
开发执行结果：
	当前总共29个case，通过29（100%）个，未执行0（0%）个，失败0（0%）个，忽略0（0%）个。

QA执行结果：
	当前总共29个case，通过29（100%）个，未执行0（0%）个，失败0（0%）个，忽略0（0%）个。
	QA冒烟通过率为：100%

二、第一轮测试进度
测试计划如下：
	第一轮测试预计3天（8/10~8/12）
	第二轮测试预计3天（8/13~8/17）
	回归测试3天（8/18~8/20）

当前进度：
	当前总共236个case，通过85个（36.0%），未执行145（61.4%）个，失败5（2.1%）个，忽略1（0.4%）个。

遇到的问题：
	... ...

目前bug及task情况：
	48 issues in version
	32 issues done
	0 issues in progress
	16 issues to do

3 新需求测试完成标准

新需求开发全部完成

bug收敛到一定标准

注意：

传统标准是无major bug（重要分支出错），少normal bug（非重要分支出错）

敏捷开发的互联网中追求快速上线，测试人员根据项目情况判断进入回归测试的条件，一般无critical bug（主干功能出错），每个版本bug呈收敛状态

4 新需求测试要执行几轮？

理想情况：1轮

不理想情况：多轮，如项目开发和测试时间紧张，测试尽早开始以加快进度，采用分步提测方式，第一个版本测试模块一，第二个版本测试模块二，第三个版本测试全部模块；开发新不熟悉产品，不了解函数调用，导致开发不断修改，测试不断进行新需求测试，bug数量才收敛。

二、回归测试

1 定义

是软件测试的一种，旨在检验软件原有功能在修改后是否保持完整。

验证整体功能的正确性，不仅包括这次改动的功能，还包括这没有改动的其他功能，因为模块之间是相互关联的。

2 用例选择

2.1 项目新需求功能模块的相关模块

方法1：模块调用分析

以云课堂项目为例，下图是云课堂功能模块图，这次项目主要修改的是“课程详情页”、“课程学习页”、“播放页”；

下图是课程页面，显示课程学习进度，点击课程后进入“课程详情页”，可以说“我的课程页”调用了”课程详情页“；

若”课程详情页“的功能修改，可能造成”我的课程页“显示出错，如课程学习进度；

因此，重点关注调用修改模块的模块和被修改模块调用的模块。

通过整体模块分析，“课程详情页”、“课程学习页”、“播放页”的主流程是登录页面 -> 课程列表页 -> 课程详情页 -> 课程学习页 -> 播放页，说明课程列表页调用课程详情页；

另外，我的课程页、我的微专业、我的订单、微专业详情页也调用课程详情页。则重点选择调用课程详情页的模块用例。

方法2：函数调用分析

跟开发详细沟通了解修改的函数及相关的函数，比模块分析精确；

经验丰富的测试人员可自行查看代码来确定测试范围，即通过代码提交的log查找修改的函数，在开发集成环境中可查看函数调用关系，从而确定需要测试哪些功能。

如下图，函数A1、B1调用函数B2，函数B2调用函数B3、C3；

2.2 产品全功能主干用例

一般从P1、P2级别的测试用例中选择；覆盖这些用例，保证产品主干功能的正确性。

2.3 版本兼容、系统兼容等兼容性用例

对于web产品，需要测试产品在各个浏览器的表现；

对于Android/IOS产品，需要测试产品在各个Android/IOS手机的表现；

对于APP产品，新版本发布以后，不更新到最新版本的用户是否正常使用老版本。

2.4 遗留bug的相关用例

这部分一般在验证bug时直接测试，不一定以文字形式写到回归用例中。

3 执行回归测试

按照回归用例开始执行；测试执行过程中，每天写测试日报以同步进度。

4 回归测试完成标准

4.1 开发完全停止后进行一轮回归测试

4.2 基本没有Major bug、Normal bug，Minor bug < 5

5 回归测试自动化

回归测试轮次较多，回归用例一般是产品的主干用例，相对来说比较稳定，适合做自动化测试。

Bug管理

一、bug的定义

程序错误bug，又漏洞，是程序设计中的术语，是指在软件运行中因为程序本身有错误而造成的功能不正常、死机、数据丢失、非正常中断等现象。

二、bug管理工具

Redmine是开源的项目管理和缺陷追踪工具，网址：https://www.redmine.org

三、新建bug

1‘ 登陆后点击页面左上角“项目”按钮进入项目列表，点击项目名称进入对应项目页面

2’ 点击“新建问题”按钮，选择跟踪bug、填写主题、描述，选择状态、优先级，选定指派给谁

a 主题：

遵循“简洁、具体”原则，即文字少但信息多

差的标题	好的标题
在进行“推荐课程”列表测试时，发现课程有重复的现象	“推荐课程”列表中《Java入门》课程重复
浏览器兼容性测试，视频显示不全	Chrome 48.0.2564.116版本，视频上半部分显示不全
点击“立即学习”按钮出错	点击“立即学习”按钮报500错误

b 描述：

● 详细的复现步骤

● 详细的平台信息

——操作系统：Windows 7/8/10

——手机机型：小米5、iPhone 6S、华为P8

——手机版本：Android 5.0/5.1、IOS8/9

——浏览器：IE 10/11、Firefox 44

● 最好有截图——比文字信息直观

c 状态：

d 优先级：

● Block (P1)：崩溃的、致命的

如访问首页出现错误页面；

● Critical (P1)：主干功能出错

如无法进入视频播放页、点击“立即参加”出错；

● Major (P1/P2)：次要功能出错、重要分支出错

如“继续学习”按钮无法点击；

● Normal (P2)：非重要分支出错

如课时学完后空心圆没变；

● Minor (P3)：样式、细节问题

如错别字、样式问题等；

e 指派给：

四、简化的bug流程图

五、经典的bug流程图

测试先把bug报给开发负责人，由开发负责人将bug分配给某个开发人员；但在互联网的测试流程中，测试人员一般直接分给配某个开发人员，因此Assign环节省略；

在已解决环节中，包含fixed、invalid、duplicate、later、worksforme，现在使用已解决替代了所有状态，而在评论中标注。其中，fixed是最常见的，invalid是指开发人员发现在自己环境下是好的，是因为在测试环境中数据出错导致bug；duplicate是指测试人员报了两个bug，开发人员认为是同样原因造成的；later是指开发人员认为不影响用户使用，不需要在这个版本修复；worksforme是指开发人员无法复现bug，请测试人员复现；

测试人员将开发人员修复的bug进行验证，通过并产品上线后将bug关闭；现在将Verified和Closed合并。若新需求测试人员和回归测试人员不是一个人，则新需求测试人员验证后，由回归测试人员统一关闭。

六、bug分析

bug是测试人员的重要产出，可挖掘很多信息；

质量报告

1 测试基本情况

测试时间段、测试功能模块情况介绍

2 主要结论及关键风险

2.1 测试总体结论

测试内容和发现的问题介绍，能否上线

2.2 遗留bug风险

对遗留的、没有修复的bug重点说明

2.3 其他风险分析

对其他质量风险进行说明，如回归测试范围不够、某模块bug太多等

3 测试执行情况分析

3.1 冒烟情况——每次冒烟测试的情况

版本、执行时间、总用例数、通过用例数、结果、备注

3.2 整体测试情况——每次新需求测试、回归测试的情况

测试类型、计划执行用例数、实际执行用例数、发现bug数、备注

4 产品bug统计及分析

bug所有者分布图、bug级别分布图、bug模块分布图、bug进度图