软件测试的生命周期

软件测试贯穿软件的整个生命周期。

软件测试的生命周期是指测试流程，这个流程是按照⼀定顺序执行的⼀系列特定的步骤，去保证产品质量符合需求。在软件测试生命周期流程中，每个活动都按照计划的系统的执行。每个阶段有不同的⽬标和交付产物。

各阶段具体内容：

1. 需求分析：
   1. **用户角度：**评估软件需求是否合理，确保满足用户的真实需求
   2. **技术角度：**评估需求在技术上是否可行，是否还有优化空间
   3. **测试角度：**检查是否存在业务逻辑错误、冗余、冲突等问题
2. 测试计划：
   1. **制定测试计划：**确定测试的时间表，包括什么时候开发测试、什么时候结束测试、耗时多久
3. 测试设计与开发：
   1. 参考需求⽂档、技术⽂档等编写测试用例
   2. 写测试⽂档，明确标注使用到的测试方法，测试工具，测试形式等等
4. 测试执行：
   1. 充分利用测试用例和测试工具对项⽬尽可能做到全方⾯的测试覆盖
5. 测试评估：
   1. 测试是否通过，本次测试是否有遗留的 Bug，最终测试人员需要产出⼀个测试报告
6. 上线：
   1. 项⽬测试结束后，将项⽬发布到线上环境
   2. 测试人员需要跟踪上线，并测试线上环境下软件的运行是否正确
7. 运行维护：
   1. 测试人员需要参与项⽬的实施工作。测试人员对项⽬产品的业务和操作⾮常了解，加上测试人员的沟通表达能⼒⼀般都⽐较强，所以测试人员可以参与用户使用软件的培训，在试运行项⽬时收集问题并及时反馈给相关负责人

Bug

Bug 的概念

定义：⼀个计算机 Bug 指在计算机程序中存在的⼀个错误（error）、缺陷（flaw）、疏忽（mistake）或者故障（fault），这些 Bug 使程序⽆法正确的运行。Bug 产生于程序的源代码或者程序设计阶段的疏忽或者错误。准确的来说：

1. 当且仅当**规格说明（软件需求文档）**是存在的并且正确，程序与规格说明之间的不匹配才是错误。
2. 当需求规格说明书没有提到的功能，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误。

描述 Bug 的要素

为什么描述 Bug 还有要素要求？因为人们在编写⽂档的时候，经常会出现自己想表达的内容和写出来的内容南辕北辙的现象。

例如，Bug 描述为：浏览器打开链接失败。该描述下，没有明确说明哪个浏览器，失败的具体表现是什么，对于开发人员来说⽆法捕捉到更多有效的信息，会造成沟通效率低下，工作质量低下等问题。

**描述Bug的基本要素：问题出现的版本、问题出现的环境、问题出现的步骤、预期结果、实际结果。**

1. 问题出现的版本：

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

2. 问题出现的环境：

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

3. 问题出现的步骤：

描述问题重现的最短步骤。

4. 预期结果：

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

要相信：测试人员是最懂需求的。

5. 实际结果：

描述问题实际出现的现象。

注意：

• 某些公司会有一些其他的要求，例如故障的分类：功能故障，界面故障，兼容性故障等。有些有优先级的分类，严重影响测试需要开发人员优先修改的，可以设置优先级为高。
• 不要把多个 Bug 放到一起：在无法确认是同一段代码造成的故障时，不要将 Bug 放在一起提交。

案例

1. 问题出现的版本：⾕歌浏览器版本 133.0.6943.127（正式版本） （64 位）
2. 问题出现的环境：Windows 11 专业版
3. 问题出现的步骤：
   1. 打开谷歌浏览器
   2. 输入网址：https://www.101eduyun.com/sunrise/login/login.do
   3. 等待页面第一个背景图上的二维码渲染完成
4. 预期结果：小程序二维码不会被登录模块遮挡，二维码可以正常扫描
5. 实际结果：小程序二维码被登录模块遮挡，二维码不可以正常扫描

Bug 级别

通过定义 Bug 的级别，能够明确看出问题的严重程度。工作中开发人员通常需要按照 Bug 的级别来分配优先级来处理 Bug，除此之外，通过 Bug 级别也能够体现出开发人员的开发质量。

**Bug 级别的定义每个公司都不一致，在定义级别之前需要查看公司规范。**⼀般分为：崩溃、严重、⼀般、次要。

1. 崩溃：
   1. 阻碍开发或测试工作的问题；
   2. 造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。
   3. 如：代码错误、死循环、数据库发生死锁、重要的⼀级菜单功能不能使用等（该问题在测试中较少出现，⼀旦出现应立即中⽌当前版本测试）。
2. 严重：
   1. 系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。
   2. 功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。
   3. 如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。
3. 一般：
   1. 功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。
   2. 如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等。
   3. 该问题实际测试中存在最多。
4. 次要：
   1. 界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。
   2. 如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等。
   3. 此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理 。

Bug 的生命周期

测试人员在执行测试的过程中如有发现 Bug，需要在对应的 Bug 管理平台来创建 Bug（Bug 生命起源），创建好的 Bug 需要被开发人员修复，以及测试人员的持续跟踪和测试。

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

与开发产生争执怎么办？【高频面试题】

在测试工作中，最常遇到的是测试人员和开发人员的 PK，测试经理还会和项⽬经理、产品经理的 PK 进度、质量。作为⼀名测试人员，要理性处理与开发人员的冲突。

先检查自身，Bug 是否描述的不清楚

如果能正确地、⾼质量地录入⼀个 Bug，那么基本上已经成功地与开发人员沟通了⼀大半的关于 Bug 的信息。但是总会有“书难达意”的时候，这时就需要测试人员主动与开发人员进行沟通了。

如果测试人员发现在写完⼀个缺陷后，好像还有很多关于 Bug 的信息没有表达出来，或者很难用书⾯语言表达出来时，就应该在提交 Bug 后，⻢上找相关的程序员解释刚才录入的 Bug，确保程序员明⽩ Bug 描述的意思，而不要等到开发人员找自己了解更多的信息。

站在用户角度考虑并抛出问题

应该让开发人员了解到 Bug 对用户可能造成的困扰，这样才能促使开发人员更加积极地、⾼质量地修改 Bug。在争执时，可以问⼀句：如果你是用户，你可以接受么？

Bug 的定级要有理有据

Bug 定级时，不仅要参考 Bug 定级描述文档，还要考虑 Bug 是否会影响到流程，往往用户的 Bug 级别和我们的是有区别的，需站在用户的角度定考虑定位级别。

提⾼自身技术和业务水平，做到不仅能提出问题，还能构给出解决的思路或方案

能够提出问题，并给出解决问题的思路或方案，这样会让人更加信服。

在工作中，资深测试工程师和初级测试工程师提出的同⼀个 Bug，两者的结果完全不同，最大的差别是资深测试工程师往往会提出解决方案。而⻓此以往，权威性逐渐的建立起来，开发人员看到 Bug 的第⼀反应，就是这是⼀个 Bug，而不是这是⼀个 Bug吗？

注意：可以给出解决方案，但是不能喧宾夺主，命令式让开发人员按照自己的想法来修改。