【学习笔记】测试基本流程

测试基本流程

冒烟测试

冒烟测试是指在正式进入测试之前，先把待测试的主要功能检查一遍的操作。

流程

1 选择测试用例

• 选择主干流程的正向用例    从P1、P2中选择
• 每个模块都覆盖到
• 30%  20% 10%
  根据项目实际情况。比如1个测试人员面对的开发越多，冒烟测试用例的占比就可以更高，由于开发人员自测也是使用冒烟用例，这样做就可以保证代码质量更高，测试花费时间更少。
• 冒烟测试和回归测试
  -冒烟测试可以在一定程度上保证代码质量，只有在达到了一定的条件时，开发才可以提测；回归测试的目的是保证产品的原有功能是正确的。
  -由于两者目的不同，在选择用例时也有所不同。对于新功能，冒烟用例和回归用例都应该覆盖到，对于老功能，冒烟用例可以不必覆盖，而回归测试则要覆盖到。

2 冒烟测试通过标准

• 冒烟用例通过率达到100%

3 冒烟测试的意义

• 减少重复执行，提高测试效率
• 开发和测试对提测质量达成一致

新需求测试

新需求测试就是选择新增或者修改的功能进行测试。新需求测试完成的标准是新需求开发全部完成，bug收敛到一定标准，对于传统项目，标准是指没有major级别的bug，只有少数normal级别的bug；在敏捷开发中，标准至少要达到没有critical级别的bug，并且每个测试版本，bug呈收敛状态，而不是发散状态。

回归测试

回归测试旨在检验软件原有功能是否保持完整，验证的既包括这次改动的功能，也包括这次没有改动的其他功能。

1 回归测试用例选择

• 与这次项目新需求相关的模块的用例
  -调用修改模块的模块；
  -被修改模块调用的模块；
  -通过函数调用关系来判断有哪些相关模块，这就需要与开发详细沟通修改的函数以及相关关系。
• 产品所有功能的主干用例
  -一般由P1、P2级别选择。这样至少可以保证产品主干不会出问题。
• 版本兼容、系统兼容等兼容性用例
• 遗留bug的相关用例

回归测试通过标准

• 开发完成停止后进行一轮回归测试
• 回归测试后产品基本无bug
  -例如：无major、无normal、minor<5

Bug管理

标题

简洁、具体

描述

1 详细的重现步骤
2 提供平台信息

• 操作系统：Windows 7、Windows 8、Windows 10
• 手机机型：iPhone X、华为 P30
• 手机版本：Android 8.1、iOS12
• 浏览器：ie 10、Firefox 44

3 最好有截图

严重级别

Block
一般对应P1级别用例
崩溃的、致命的
Critical
一般对应P1级别用例
主干功能出错
Major
一般对应P1、P2级别用例
次要的功能出错
重要功能的分支出错
Normal
一般对应P2级别用例
非重要分支出错
Minor
一般对应P3级别用例
样式、细节问题

bug流程图

Invalid
无效的bug。例如开发环境中没有问题，测试环境中出错是由于测试数据有误。
Duplicate
重复提交的bug。两个bug的导致原因相同，第二个bug就被设置为Duplicate状态。
Later
bug对用户影响不大，延后处理。
WorksForMe
无法重新，需要测试来重现。

Bug分析

举例：

对Bug引入原因进行分析
1 由于需求不明确造成的Bug可通过需求评审阶段共同review交互稿避免，有待提高
2 开发考虑不周导致的Bug数占比较高，开发提测质量有待提高，建议通过细化冒烟测试用例，督促开发自测
对不同阶段期望和实际发现Bug数对比
1 预期在开发自测阶段可以避免的低级bug有x个，但是未发现
2 回归测试阶段，预期bug数比实际bug数多x个，是可以提前发现的，测试人员有改进和提升的必要及空间

质量报告

质量报告的目的是跟项目组沟通项目过程，总结项目上线的质量风险。

1 测试基本情况

• 测试时间和测试功能模块情况介绍

2 主要结论及关键风险

• 测试的总体结论
  测试内容和发现的问题介绍，版本质量如何，是否建议上线。
• 遗留bug风险
  对遗留的、没有修复的Bug重点说明。
• 其他风险分析
  对其他质量风险进行说明，比如回归测试范围不够、某模块Bug太多等。

3 测试执行情况分析

• 冒烟情况
  进行轮次、时间、总用例数、通过用例数、通过率、冒烟结果。
• 测试版本情况
  各次新需求测试、回归测试的情况。功能测试、兼容性测试、性能测试等执行了哪些用例，发现了多少Bug。

Bug统计及分析

• Bug所有者分布图
• Bug级别分布图
• Bug模块分布图
• Bug进度图