软件测试:基础篇

软件测试:基础篇本节主要内容 软件测试的生命周期软件测试的生命周期生命周期 每个测试阶段的分析 编写测试用例的同时也是对需求进行的一个测试。 编写测试报告是为了

软件测试:基础篇

本节主要内容 

软件测试的生命周期

软件测试的生命周期生命周期 

每个测试阶段的分析 编写测试用例的同时也是对需求进行的一个测试。 编写测试报告是为了对缺陷进行分析。 

一个合格的 bug 描述应包括哪些部分

应包括以下部分: 

如何定义bug的级别

bug的定义每个公司都不一致,在定义级别之前需要查看公司规范。

举例: 

最后,测试人员将出现的以上缺陷全部提交到缺陷管理系统上。 

bug 的生命周期

从出现到消亡的过程。 BUG状态转换图 640?wx_fmt=png

  • New:新发现的Bug,交给指派的开发人员进行相应的修改。

  • Open:开发负责人确认是Bug,并且认为需要修改,指派给相应的开发人员。

  • Fixed:开发人员进行修改后标示成修改状态,有待测试人员的回归测试验证。

  • Rejected:如果认为不是Bug,则拒绝修改。

  • Delay:如果认为暂时不需要修改或暂时不能修改,则延后修改。

  • Closed:修改Bug的状态经测试人员的回归测试通过后,关闭Bug。

  • Reopen:如果经验证的Bug仍然存在,则需要重新打开Bug,开发人员重新修改。

如何开始第一次测试

准备工作 

确认具体的工作内容(向测试组长) 

测试执行和BUG管理

开始测试 

发现bug 

产生争执怎么办

在测试过程中,最常遇到的是和开发人员的PK, 

遇到争执时不要怕,做法有: 

    - 决定如何处理bug。
    1. 参加该评审不可或缺的是测试代表、开发代表、产品代表。
    测试代表主要从Bug的具体表现、严重程度等方面提供信息,并提出自己对Bug的处理意见。
    2. 开发代表开发代表主要从修改缺陷的难度和风险出发,考虑缺陷修改需要付出的代价,以及可能影响的范围、可能引发的风险等,如果决定要修改,还要讨论出修改的初步方案。
    3. 产品代表主要从产品的整体计划、用户的要求等方面对缺陷的修改必要性、缺陷修改的时间和版本提出自己的意见。
    - 分析缺陷产生的原因,制定出预防的对策。
  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

本文转自:https://blog.csdn.net/bit666888/article/details/81061007

标签: 软件测试