测试基础篇II--软件测试生命周期及bug相关知识

软件测试的生命周期（软件测试的流程）?

• 需求分析（对需求进行验证和细化，为后续的写测试用例做准备工作）
• 测试计划（范围、时间、人员、工具)
• 测试设计/开发（根据需求写测试用例）
• 测试执行（软件基本开发完成，测试人员测试用例，发现BUG，并记录BIG。执行测试用例，补充测试用例）
• 测试评估（评估覆盖范围【测试了哪些功能，哪些没有测试】，bug的情况的统计，以测试报告的形式展示）

1）测试需求分析阶段：阅读需求，理解需求，主要就是对业务的学习，分析需求点，参与需求评审会议。

2）测试计划阶段：主要任务是编写测试计划，参考软件需求规格说明书，项目总体计划，内容包括测试范围（来自需求文档），进度的安排，人力物力的分配，整体测试策略的制定，和风险的评估与规避措施有一个制定，一般由测试负责人编写，当然我们可能也会参与相关的评审工作。

3）测试设计阶段：主要任务是编写测试用例，会参考需求文档（原型图），概要设计，详细设计等文档，有不明确的也会及时和开发，产品经理沟通，用例编写完成后会进行评审。

4）测试执行阶段：首先搭建测试环境，执行预测（冒烟测试），以判定当前版本可测与否，如果预测通过，正式进入系统测试，遇到问题提交bug到缺陷管理平台，并对bug进行跟踪，直到被测软件达到测试需求要求，没有重大bug，测试结束----（完善测试用例）

5）测试评估阶段：出测试报告，对整个测试的过程和版本质量做一个详细的评估，确认是否可以上线。

软件开发流程、测试流程梳理

6）开发人员的工作流程：需求分析-得知功能组成及设计软件结构、数据结构（概要设计、详细设计）-编写代码单元测试-代码审查-打包提交测试部-等待测试提交bug-修复bug-等待测试回归bug-……N轮-版本上线-面向用户使用

7）测试人员的工作流程：需求分析–编写测试用例-评审测试用例-搭建测试环境-等待开发研发完成，提交测试包进行测试（酱油期）-部署测试包-冒烟测试（预测）-执行测试用例-bug跟踪处理（提交及回归bug）……N轮-版本上线

回顾什么是bug?

• 当我们的规格说明（软件需求）存在且合理，如果软件功能和需求规格不符合，说明是软件错误
• 当规格说明不存在，如果用户的需求存在并且合理，如果功能和用户需求不匹配，说明是软件错误

---

如何描述一个bug?

• 测试版本：当前测试的系统所在的代码版本
• 测试环境：系统所在的环境
  1. web系统
     （1）Chrome Firefox IE edge
     （2） 浏览器的版本号
  2. APP
     （1） iOS 系统
     （2）Android系统
     （3）系统的版本号
     （4）机型
• 测试步骤 ：引起bug的操作步骤
• 测试数据：引起bug的输入信息或者数据
• 测试预期结果
• 测试实际结果
• 其他 例如错误截图，错误日志等附件

例：
1.故障发现版本：VPS20210405-01
2.故障类别：兼容性
3.故障优先级：中
4.故障标题：IE下界面显示异常，页面文字有重叠
5.故障描述：

• 测试环境：window10 + IE8
• 测试步骤：打开首页，点击通知链接，进入页面
• 预期结果：通知页面显示正确，一页显示10条消息，按时间顺序倒序排序
• 实际结果：页面显示10条消息，通知顺序正确，但页面文字有重叠

6.附件：上传截图

---

bug的级别？

1. 崩溃：系统崩溃、死机、死循环，无法正常运行，如果线上出现这种情况，立马回退版本到一个系统稳定的状态
2. 严重：系统还可以运行，但是不稳定，如果继续运行，会产生严重的后果
3. 一般：系统可以稳定运行，但是一些功能没有实现，或者实现有问题，不影响用户使用，但是影响用户操作
4. 次要：建议性的bug，例如界面、排版、字体大小等问题

【注】：对于bug的级别，每个公司会有不一样的标准

---

bug的生命周期？

bug状态的记录：bug管理系统，jira，tapd，禅道等

测试人员提了一个BUG，开发人员修复了，但是测试人员验证回归的时候发现BUG依然存在，这是什么原因导致的？

1. 可能因为开发人员没有正确修复
2. 测试人员没有拉取最新的代码进行发布测试

若是因为一个BUG和开发人员产生冲突怎么办？

• 先检查自身，看BUG的描述是否清楚
• 从用户的角度去劝说开发人员
• BUG定级要有理有据
• 不断提高自己的业务水平和技术水平
• 可以和产品经理商量开BUG评审，讨论这个BUG有没有修改的必要及他的解决方案