软件测试：基础篇

软件测试：基础篇

本节主要内容 

软件测试的生命周期

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

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

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

应包括以下部分： 

如何定义bug的级别

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

举例： 

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

bug 的生命周期

即从出现到消亡的过程。 BUG状态转换图 

• 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