【测试开发篇3】软件测试的常用概念

目录

一、软件测试的生命周期(5个步骤)

①需求分析(两个角度)

用户角度：

开发人员的角度：

②测试计划 

③测试设计、测试开发

④执行测试

⑤测试评估

二、软件测试贯穿项目的整个生命周期的体现

需求分析阶段

计划阶段

设计阶段

编码阶段

测试阶段

运行维护阶段

三、关于bug

如何描述一个bug(5个内容)

标题 

发现bug的版本

发现bug的环境

发现bug的具体步骤

期望结果&实际结果

bug的级别是什么

      NO.1崩溃(非常严重，并且比较少见)

      NO.2严重(主要的功能与预期存在严重不符)

      NO.3一般(很常见)

      NO.4次要(很常见)

bug的生命周期

发现bug

收到bug

修复bug

bug回归验证

如果测试人员认为是bug，开发人员不认为是Bug，怎么处理

一、反思自己

二、提bug一定要有理有据

三、合理友好地沟通

四、提出问题，最好可以提出解决方法(优秀)

五、提出评审(一定是最后的最后才作出这样的决定)

---

一、软件测试的生命周期(5个步骤)

①需求分析(两个角度)

需求分析需要站在两个角度进行分析：

用户角度：

检查需求的逻辑是否正确，是否符合用户的需求和习惯等；

---

开发人员的角度：

思考需求是否可以实现/实现的难度大小。

---

②测试计划 

 针对一个项目具体的测试计划（例如测试的工时、人力的安排等等）

---

③测试设计、测试开发

      测试设计阶段：设计测试用例。

      测试用例就是测试人员向待测试的软件提供的一组测试数据，包括以下的内容：

  测试环境、

  测试数据、

  测试步骤、

  预期结果

     每一个步骤是干什么的，已经在这一篇文章当中提到了。  【测试开发篇2】软件测试常用概念_革凡成圣211的博客-CSDN博客https://blog.csdn.net/weixin_56738054/article/details/129493584?spm=1001.2014.3001.5502

       在这两个阶段，经验丰富的白盒测试人员就可以开始进行单元测试了（关于什么是白盒测试、什么是黑盒测试，已经在这一篇文章当中提到了）

---

④执行测试

参考测试用例来执行测试。计划好了测试的计划，那么在这一个步骤就需要来具体地执行测试了。

---

⑤测试评估

测试人员需要记录测试、做好缺陷管理（例如记录bug、评估风险） 

---

二、软件测试贯穿项目的整个生命周期的体现

       之前我们提到了，软件测试是贯穿整个软件的生命周期的。那么，下面我们来回顾一下软件的生命周期是什么。

 需求阶段：产品经历根据用户需求转化为软件需求；

 计划阶段：进行软件开发的计划，包括项目的开发工时、人力等，产出计划文档；

 设计阶段：设计具体的开发步骤；产出设计文档；

 编码阶段：开发人员根据需求文档和设计文档来进行软件开发；

 测试阶段：测试人员对于软件进行测试；

 运行维护阶段：发现项目当中旧的问题、对于当前项目的维护、以及预防可能发生的问题。

下面，我们具体来聊一下，在每一个阶段，软件测试人员需要做什么事情。

---

需求分析阶段

       在这个阶段，测试人员也需要了解用户的需求、软件的需求等等。分析需求是否合理，站在开发人员的角度思考技术如何实现，针对技术难度来合理调整需求。

---

计划阶段

       在测试人员了解到具体的需求之后，就需要进入到计划阶段了。根据需求来编写测试计划、测试方案。

---

设计阶段

根据项目的设计细节，搭建测试框架，并且根据项目的计划编写一部分的测试用例。

---

编码阶段

       测试人员一般不需要编码的。

       在这个阶段，白盒测试人员就可以参与进来进行测试了。同时，在这个阶段也需要完善、细化测试用例以及调整测试计划和方案

---

测试阶段

测试人员根据测试用例来进行测试，在执行的过程当中记录并且管理缺陷。

并且还需要在这一个阶段进行

总结：

---

运行维护阶段

     在这一个阶段：

①测试人员可以参与用户使用软件的培训；

②收集运行时候项目的问题并且反馈给相关的负责人。

---

三、关于bug

关于什么是bug,也已经在前面的文章当中提到了：

当软件需求正确的时候，软件的实际运行效果和软件需求不一致的时候，那么这就是bug。

---

如何描述一个bug(5个内容)

标题 

对于一个bug的简单描述：一般是bug的现象是什么。

---

发现bug的版本

对于用户使用的版本，我们称之为"线上包"或者"正式包"。

那么测试使用的版本就是"测试包"。因此，需要描述好是哪一个测试的版本发现的bug。

---

发现bug的环境

例如是在什么操作系统下面发现的bug，是移动端还是微信端还是pc端等等。

---

发现bug的具体步骤

指的是测试人员具体操作了哪些步骤，才发现了bug。

例如是：

用户登录之后，退出到首页的情况发现了bug

还是打开浏览器，进入首页的情况发现了bug

---

期望结果&实际结果

例如：期望的结果是什么，但是实际的结果又是什么，以及具体的描述。

bug类型：前端问题,bug等级...

(最好配有截图)

---

bug的级别是什么

       关于bug的级别，不同的公司有不同的规定，在定义级别之前首先需要查看公司的规范。一般分为以下几个级别：

---

      NO.1崩溃(非常严重，并且比较少见)

       这种bug，可以说是会直接导致系统崩溃的。例如：

  死循环、死机、数据库内容丢失等等，在测试的环节非常少遇见

---

      NO.2严重(主要的功能与预期存在严重不符)

       例如在一个博客系统当中，用户点击了保存草稿，但是还是没办法保存成功一样。

       或者用户点击了登录，账号密码都输入正确了，但是还是没办法正常登录。

---

      NO.3一般(很常见)

       功能没有完全实现，但是不影响使用。

        主要功能存在缺陷，但是不影响系统的稳定性。

---

      NO.4次要(很常见)

       一些建议优化的措施。(例如调整前端页面的字段大小等等) 

---

bug的生命周期

发现bug

测试人员发现了新的Bug，同时测试人员要新建一个bug，这个bug的状态就是new。

---

收到bug

       开发人员收到了bug，查看测试人员提出的bug是否是bug。如果是bug，就把这个bug的状态设置为open。

       如果开发人员认为这不是一个bug，那么开发人员就把这个bug修改为rejected(拒绝)，然后就直接进入closed状态。

---

修复bug

开发人员认定了bug之后，就需要采取修复的工作。

但是，就算是修复，也有两种措施：

delay：现在暂时不需要修复，于是采取的措施是：延迟修复。

fixed：立刻进行bug修复。

---

bug回归验证

把这一个bug的状态修改为reopen，重新交给开发人员。

---

画个图总结一下bug的生命周期流程图(圆圈为bug的状态)：

---

如果测试人员认为是bug，开发人员不认为是Bug，怎么处理

一、反思自己

具备批判性的思维，先考虑一下：自己是不是对于bug描述地不清楚。

这个bug是不是无效的bug

---

二、提bug一定要有理有据

      不单止对于bug的描述，还需要有明确的依据（包括是在什么样的环境下面发现的bug，测试的版本、运行的截图等等）

      并且要严格规定bug的等级，不可以过低或者过高。

---

三、合理友好地沟通

       如果开发人员并不太认可，可以站在用户的角度进行沟通。如果你是用户，那么可以接收这样处理嘛？

---

四、提出问题，最好可以提出解决方法(优秀)

如果bug太多的话，最好可以提出解决方案，帮助开发人员快速进行修正。

---

五、提出评审(一定是最后的最后才作出这样的决定)

邀请产品代表、开发代表、测试代表一起对这个bug进行评估。

包括以下的内容：

  (1)如何解决bug；

  (2)如何预防类似的bug。