软件测试基础概念二

Bertha 。 2024-04-05 05:26 53阅读 0赞

#### 文章目录 ####

*  1.软件测试的生命周期（软件测试的流程）
 *  2.描述软件缺陷的要素
 *   *  2.1问题出现的版本
     *  2.2问题出现的环境
     *  2.3操作步骤
     *  2.4实际结果
     *  2.5预期结果
 *  3.软件缺陷的级别
 *   *  3.1崩溃
     *  3.2严重
     *  3.3一般
     *  3.4建议
 *  4.软件缺陷的生命周期
 *   *  4.1New
     *  4.2Open
     *  4.3Fixed
     *  4.4Rejected
     *  4.5Delay
     *  4.6Close
     *  4.7Reopen
 *  5.解决冲突（重点）

--------------------

## 1.软件测试的生命周期（软件测试的流程） ##

需求分析——>测试计划——>测试设计、测试开发——>测试执行——>测试报告

## 2.描述软件缺陷的要素 ##

### 2.1问题出现的版本 ###

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

### 2.2问题出现的环境 ###

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

### 2.3操作步骤 ###

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

### 2.4实际结果 ###

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

### 2.5预期结果 ###

要让开发人员指导怎么样才是正确的，尤其是要以用户的角度来描述程序的行为是怎么样的。

## 3.软件缺陷的级别 ##

### 3.1崩溃 ###

阻碍开发或测试的问题，造成系统崩溃，死机，死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。

### 3.2严重 ###

系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。

### 3.3一般 ###

功能没有完全实现但不影响使用，功能菜单存在缺陷但不影响系统稳定性。

### 3.4建议 ###

界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。

## 4.软件缺陷的生命周期 ##

### 4.1New ###

新发现的BUG，未经评审决定是否指派给开发人员进行修改。

### 4.2Open ###

确认是BUG，并且认为需要修改，指派给相应的开发人员。

### 4.3Fixed ###

开发人员修改后标识为修改状态，由待测试人员的回归测试验证。

### 4.4Rejected ###

如果认为不是BUG，拒绝修改。

### 4.5Delay ###

如果认为暂时不需要修改或暂时不能修改，则延后修改。

### 4.6Close ###

修改状态的BUG如果由测试人员的回归测试验证通过，则关闭BUG。

### 4.7Reopen ###

如果验证BUG仍然存在，则需要重新打开BUG，开发人员重新修改。

## 5.解决冲突（重点） ##

场景题：如果因为一个BUG，与开发人员发生冲突，作为测试人员应该怎样处理？  
回答示例：  
1.首先，我会检查自身，即我对于BUG的描述是否清晰明了。  
2.检查BUG的定级是否有理有据，是否合理，每个公司应该都有一个BUG的定级标准。  
3.站在用户的角度思考问题，因为开发和测试最终的目的都是保证产品最终能满足用户的需求，保质保量的交付到用户的手中。那么我从这个角度和开发人员沟通，可以很大程度上让开发人员意识到这个BUG会给用户造成多大困扰，才能促使开发人员更加积极地高质量地修改BUG。  
4.如果这个BUG确实存在，而且必须要修改。可能与开发人员进行了多次沟通，但是开发人员就是不接受，拒绝修改。这个时候作为测试人员，不能着急，不能意气用事，我们可以走正规流程，即发起BUG评审。  
5.最重要的还是要在平时的工作过程中，不断提升自己的技术和业务水平，提升自己的核心竞争力，这样在与开发人员沟通的时候，才能有话语权和可信权威。