【测试开发】基础篇 · 专业术语 · 软件测试生命周期 · bug的描述 · bug的级别 · bug的生命周期 · 处理争执

【测试开发】基础篇

文章目录

• 【测试开发】基础篇
• • 1. 软件测试生命周期
  • • 1.1 软件生命周期
    • 1.2 软件测试生命周期
  • 2. 描述bug
  • 3. 如何定义bug的级别
  • • 3.1 为什么要对bug进行级别划分
    • 3.2 bug的一些常见级别
  • 4. bug的生命周期
  • 5. 产生争执这么怎么办（处理人际关系）
  • 6. 如何开始第一次测试
  • 7. 测试的执行和bug管理
  • 8. 如何发现更多bug

【测试开发】基础篇

1. 软件测试生命周期

1.1 软件生命周期

1. 需求分析
2. 计划
3. 设计
4. 编码
5. 测试
6. 运行维护
7. 停服

博文链接：【测试开发】概念篇 · 测试相关基础概念 · 常见开发模型 · 常见测试模型_s:103的博客-CSDN博客

1.2 软件测试生命周期

1. 需求分析

   • 需求是否完整，需求是否正确

2. 测试计划

   • 确定软件由谁测试，什么时候测试，什么时候结束测试，测试哪些模块

3. 测试设计、测试开发

   • 写测试用例（手工测试用例，自动化测试用例），编写测试工具

4. 测试执行

   • 执行测试用例

5. 测试评估

   • 测试人员产生一个测试报告

   测试报告：

   

没有这个报告，项目是不能上线的，如果上线出了问题，一定是上线的那个人背锅！

2. 描述bug

博文链接：【测试开发】概念篇 · 测试相关基础概念 · 常见开发模型 · 常见测试模型_s:103的博客-CSDN博客

bug的描述是很重要的，如果你只是指出开发人员的代码的一个bug，让他现在就改，他不得骂死你，所以你应该描述清清楚楚这个bug

具体描述bug：

1. 在哪个版本下发现问题
   • 开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障
   • 并且版本的表示也有利于统计和分析每个版本的质量
2. 在哪个环境下发现问题

• 博客系统 => 127.0.0.1访问，但是别人访问不了，我们要部署到服务器上，这样别人就访问到了，这就是两个不同的环境

3. 重现故障

   • 要求测试人员描述好，bug的出现流程，否则开发可能会找不到bug，说你乱提bug
   • 描述问题重现的最短、最清楚的步骤

   例如以下bug描述：

   1. 在短信列表中，选择短信，进行删除，删除失败了！
   2. 在短信列表中，选择一条短信，进行查看，在查看页面，进行删除，删除失败 √

   显然，后者的描述更加精准，因为列表页和详情页删除是不一样的地点！

   我们要准确描述bug如何出现的！

4. 预期行为的描述

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

5. 错误行为的描述

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

6. 其他

   • 某些公司会有一些其他的要求，例如故障的分类：功能故障，界面故障，兼容性故障等
   • bug复现的前置条件、bug给谁…
   • 有些有==优先级的分类==，严重影响测试需要开发人员优先修改的，可以设置优先级为高

7. 不要把多个bug放到一起

   • 在无法确认是同一段代码造成的故障时，不要将bug放在一起提交

3. 如何定义bug的级别

不同公司可能不一致~

3.1 为什么要对bug进行级别划分

现在有一个项目要在9点上线

此时还有三个bug，但是来不及了，三个bug不能都修复好，所以我们需要给bug进行级别划分，影响更严重的我们要优先处理~

3.2 bug的一些常见级别

1. Blocker（崩溃）

   • 阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题
   • 如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）。

2. Critical（严重）

   • 系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试
   • 功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等
   • 如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。

3. Major（一般/主要）

   • 功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性
   • 如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多）

4. Minor（次要）

   • 界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等
   • 如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）

强调：

• 如果发现崩溃级别的bug，那么此时我们就需要停止测试，测试打回，测试打回特别恶劣！
  • 写一个报告，打回给开发，开发就需要进行修复，修复完之后自己得仔细地测试一下，不然想着再次被打回吗

4. bug的生命周期

bug状态转换图:

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

5. 产生争执这么怎么办（处理人际关系）

背景：某一天萌新测试人员（QA-- 测试(QUALITY ASSURANC）发现一个bug，提交给老油条开发人员（RD），但是开发脸皮很厚，一直没处理

前提：一定不能吵架

1. 先从自身出发，测试人员要保证自己操作没有问题，确保自己对需求理解的没有问题
2. 沟通层面，好好说话，高情商礼貌去交流
3. 站在用户角度考虑问题
   • 应该让开发人员了解到Bug对用户可能造成的困扰，这样才能促使开发人员 更加积极地、高质量地修Bug。在争执时，可以问一句：如果你是用户，你可以接受么？
   • 例如，删除某一篇文章，但是却把所有的文章都删了，用户直接炸毛了呀！
4. 不光要发现问题，提出解决问题的方案

如果你都做到这份上了，开发人员还是不好好处理，就可以这样：

5. 拉上相关人（那个开发和他的领导、我的领导、产品经理PM…）开一个第三方会议
   • 开会之前：但是我(测试)一定要明确问题产生原因，问题是什么，解决方案是什么
   • 开会之后：问题要不要解决，如果要解决，何时解决，谁去解决，知道这些才能散会
   • 有时确实不得不开，否则自己的领导就要追责你了~

6. 如何开始第一次测试

能自己解决就尽量自己解决！

1. 充分理解需求
   • 文档（产品文档+ 技术文档）
   • 项目功能问题可以去问产品，模块底层如何实现问开发
   • 尽可能多地参加各种项目会议
   • 阅读已有地测试方案和测试案例
   • 熟悉项目所使用的测试管理工具、配置管理工具、获取对应的地址和登录方式
   • 阅读旧有的bug库，了解系统功能，尤其是团队保持一致的bug优先级规定
   • 了解公司的规范要求，特别是用例编写，用例执行规范…
2. 确定测试计划
3. 执行测试
   • bug开发修复了之后一定要验收！
4. 项目上线+ 维护

7. 测试的执行和bug管理

8. 如何发现更多bug

1. 软件测试同样存在二八原则，80%的故障集中于20%的模块
   • 如果某部分问题较多，加强测试广度和深度！
2. 开发人员也存在二八原则，80%的故障集中于20%的开发人员
   • 如果某些开发人员的bug较多，加强他开发模块的测试广度和深度！
3. 多进行逆向思维和发散性的思维
   • 依赖测试人员的经验，多去写测试用例，多看优秀的人写的测试用例
4. 不要局限于用例和需求文档
5. 尽早介入项目, 不要等到开发的差不多了再介入项目
   • 尽早介入需求，就会尽早理解需求

和深度！

3. 多进行逆向思维和发散性的思维
   • 依赖测试人员的经验，多去写测试用例，多看优秀的人写的测试用例
4. 不要局限于用例和需求文档
5. 尽早介入项目, 不要等到开发的差不多了再介入项目
   • 尽早介入需求，就会尽早理解需求

---

文章到此结束！谢谢观看
可以叫我 小马，我可能写的不好或者有错误，但是一起加油鸭🦆！
重点：软件测试生命周期 · bug的描述 · bug的级别 · bug的生命周期 · 处理争执

---