1. 软件测试的生命周期

需求分析 → 测试计划 → 测试设计/测试开发 → 测试执行 → 测试评估
类似软件开发的生命周期（需求 → 计划分析 → 设计→ 编码 → 测试 → 运行）

需求分析：对需求进行验证和细化，为后续写测试用例做准备工作。
测试计划：时间，人员，工具。
测试设计：根据需求写测试用例。
测试执行：软件基本开发完成，测试人员执行测试用例，发现Bug，并且记录Bug。
测试评估：把本次迭代的测试情况形成测试报告，总共有多少测试用例，执行了多少测试用例，产生的Bug和修改的Bug数，遗留的Bug数以及处理方式。

2. 如何描述一个Bug

一个合格的bug描述应该包括以下几个部分：

1. 发现问题的版本
开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障。并且版本的标识也有利于统计和分析每个版本的质量。

2. 问题出现的环境
环境分为硬件环境和软件环境，如果是web项目，需要描述浏览器版本，客户机操作系统等，如果是app项目，需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。

3. 错误重现的步骤
描述问题重现的最短步骤。

4. 预期行为的描述
要让开发人员指导怎么样才是正确的，尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需求提出的故障，能写明需求的来源是最好的。要相信：测试人员是最懂需求的。

5. 错误行为的描述
描述错误的现象。crash等可以上传log，UI问题可以有截图。

6. 其他要求
某些公司会有一些其他的要求，例如故障的分类：功能故障，界面故障，兼容性故障等。有些有优先级的分类，严重影响测试需要开发人员优先修改的，可以设置优先级为高。

7. 不要把多个bug放到一起
在无法确认是同一段代码造成的故障时，不要将bug放在一起提交。

（1）发现Bug的版本（代码所在的版本号）
（2）测试平台（系统运行的平台）
如：web、浏览器、Chrome、FireFox 、IE 、edge、360等；APP、ISO 、Android （具体到手机的系统版本、机型）
（3）测试步骤，测试数据
（4）测试实际结果
（5）预期结果
（6）附件（如错误截图，log日志）

3. Bug的级别

bug的定义每个公司都不一致，在定义级别之前需要查看公司规范。
（1）崩溃（Blocker）
系统无法正常运行，已经严重阻碍了开发人员或者测试人员的工作。如果线上出现这种情况，立刻回退版本到一个系统稳定的状态。
（2）严重（Critical）
系统还可以运行，但是已经不稳定了，如果继续运行下去，会产生严重的后果。
（3）一般（Major）
系统可以稳定地运行，但是会影响用户的操作。
（4）次要（Minor，建议性的）
建议型的Bug，页面问题，排版，字体大小，有弹出框但是没有确定按钮，图片显示等问题。

4. Bug的生命周期

每个公司、每一个工具对bug生命周期的定义都是不一致的。
下面仅是一个常见的例子。
测试人员应该跟踪一个Bug的整个生命周期，从Open到Closed的所有状态。
Bug状态转化：

● New：新发现的Bug，未经评审决定是否指派给开发人员进行修改。
● Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。
● Fixed：开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
● Rejected：如果认为不是Bug，则拒绝修改。
● Delay：如果认为暂时不需要修改或暂时不能修改，则延后修改。
● Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。
● Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。
无效的bug：open —> closed open — rejected — closed

缺陷状态变更流程每个项目团队的实际做法可能不大一样。并且需要结合实际的开发流程和协作流程来使用。

Bug的跟踪以及状态变更应该遵循一些基本原则：
●测试人员对每一个缺陷的修改必须重新取一个包含更改后的代码的新版本进行回归测试，确保相同的问题不再出现，才能关闭缺陷。
●对于拒绝修改和延迟修改的Bug，需要经过包含测试人员代表和开发人员代表、用户方面的代表（或代表用户角度的人）的评审。

5. 如何发现更多的Bug

软件测试同样存在二八原则，80%的故障集中于20%的模块，如果某部分问题较多，加强测试广度和深度！
开发人员也存在二八原则，80%的故障集中于20%的开发人员，如果某些开发人员的bug较多，加强他开发模块的测试广度和深度！
多进行逆向思维和发散性的思维。
不要局限于用例和需求文档。
尽早介入项目, 不要等到开发的差不多了再介入项目。

6. 冲突问题

能让开发人员解决最多Bug的测试人员是最优秀的测试人员。

如果因为一个Bug和开发人员产生冲突怎么办？

（1）首先检查自身，看Bug的描述是否清楚；
（2）和开发人员进一步沟通，了解原因，并且尽量从用户的角度去劝说开发人员；
（3）Bug定级要有理有据，查看Bug的定级有没有符合公司的规范；
（4）要不断提高自己的业务水平和技术水平；
（5）可以和产品经理商量开Bug评审，讨论这个Bug有没有修改的必要以及它的解决方案。

【软件测试】（三）软件测试的生命周期以及如何描述一个Bug相关推荐

软件测试（基础）· 软件测试的生命周期 · 如何描述一个 Bug · Bug 的级别 · Bug 的生命周期 · 争执 · Bug 评审
一.软件测试的生命周期软件测试的生命周期 & 软件开发的生命周期二.如何描述一个 Bug 三.如何定义 Bug 的级别四.Bug 的生命周期五.发生争执了怎么办? Bug 评审一.软 ...
软件测试（软件测试生命周期，描述一个bug，定义bug级别，bug生命周期，如何开始第一次测试，测试执行和bug管理，测试工作中的人际关系处理）
一.软件测试的生命周期对比软件的生命周期和bug的生命周期 · 软件的生命周期:需求分析--计划--设计--编码--测试--运行维护 · 软件测试的生命周期:需求分析--测试计划--测试设计.测试开 ...
深圳软件测试培训：软件生命周期(SDLC)的六个阶段
深圳软件测试培训:软件生命周期(SDLC)的六个阶段 1.问题的定义及规划此阶段是软件开发方与需求方共同讨论,主要确定软件的开发目标及其可行性. 2.需求分析在确定软件开发可行的情况下,对软件需要 ...
戏说三种项目生命周期
三种项目生命周期对比: 一.预测性预测型生命周期,即大家平日里说到瀑布模型.适用于在早期能够确定范围.时间和成本的项目.通过整体计划,按部就班的实施以及最终的验收来进行项目. 比如一个厨师负责一个婚 ...
Vue 生命周期篇探索-第三篇：生命周期-更新流程
文章目录探索学习 Vue 生命周期篇第三篇:生命周期-更新流程生命周期-更新流程 1. mounted(挂载后) 2. beforeUpdate (更新前) 3. Virtual DOM re- ...
如何描述一个BUG以及BUG级别的定义、生命周期
目录一.如何描述一个BUG? 二.BUG级别的定义 1.崩溃 2.严重 3.一般 4.次要三.BUG的生命周期一.如何描述一个BUG? 1.版本号(代码版本号) 2.测试环境/平台不同的浏览器 ...
软件测试培训分享：做软件测试工作如何清楚的描述一个bug
一名合格的软件测试工程师是需要清楚的交代自己的工作任务的,必须要清楚的告诉技术员出现的bug,那么做软件测试工作如何清楚的描述一个bug呢?来看看下面的详细介绍. 软件测试培训分享:做软件测试工作如何 ...
5. 如何描述一个bug / 如何定义bug的类型级别 / bug的生命周期
1. 描述一个bug 提交了如下bug: 1.在短信列表,选择一条短信,进行删除,删除失败 2.在短信列表,选择一条短信,进行查看,在查看页面,进行删除,删除失败故障发现版本:VPS20180226 ...
软件测试的分类及生命周期，你了解多少？
前言: 大家好,我是一菲,岁岁年年花相似,年年岁岁题不同.到了2020年的2月初了,还有1.2个月又到了每年找工作的金三银四季,这几天我翻阅资料和书籍,给大家搜集了软件测试分类和软件测试周期的内容,我 ...

【软件测试】（三）软件测试的生命周期以及如何描述一个Bug

文章目录