软件测试《基础篇》

客官°小女子只卖身不卖艺 2024-03-17 15:08 171阅读 0赞

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

> **需求分析→测试计划→ 测试设计、测试开发→ 测试执行→ 测试评估**

> **需求分析：分析需求是否完整和正确，并根据需求得出测试需求**
> 
> **测试计划：规划执行测试的计划，包括什么时候开始测试，由谁来测试，什么时候结束测试，什么时候项目上线等等**
> 
> **测试设计：根据软件需求设计测试用例**
> 
> **测试开发：开发测试工具，开发自动化测试用例**
> 
> **测试执行：执行测试用例，如果测试过程中发现BUG则进行BUG提交，开发人员对BUG修改后要验收BUG**
> 
> **测试评估：产出测试报告**
> 
> **测试报告实例**
> 
> ![9274514775994c85990e11d7d3600eed.png][]

### 如何描述一个bug ###

### 为什么要描述一个BUG？ ###

> **测试人员与开发人员对bug的沟通主要是通过bug描述，如果不生成bug描述信息，测试人员与开发人员不得不进行面对面交流，但在实际的生产环境中，大家的时间不一定恰好不冲突，所以通过对bug的描述，使开发人员理解bug,并解决bug**

### 如何描述一个bug ###

> **1、发现问题的版本** 
> 
> **开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障。并且版本的标识也有利于 统计和分析每个版本的质量。** 
> 
> **2、问题出现的环境** 
> 
> **环境分为硬件环境和软件环境，如果是web项目，需要描述浏览器版本，客户机操作系统等，如果是 app项目，需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。** 
> 
> **3、错误重现的步骤** 
> 
> **描述问题重现的最短步骤。** 
> 
> **4、预期行为的描述** 
> 
> **要让开发人员指导怎么样才是正确的(结果正常时操作的步骤)，尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需 求提出的故障，能写明需求的来源是最好的。** 
> 
> **要相信：测试人员是最懂需求的。** 
> 
> **5、错误行为的描述** 
> 
> **描述错误的现象。crash等可以上传log，UI问题可以有截图。（对问题的产生进行描述，UI层面我们可以直接截图）**
> 
> **6、其他** 
> 
> **某些公司会有一些其他的要求，例如故障的分类：功能故障，界面故障，兼容性故障等。有些有优先级 的分类，严重影响测试需要开发人员优先修改的，可以设置优先级为高**
> 
> **实例**
> 
> ![88c4abb79dfb4492b34c6be5b08f84dd.png][]

## 如何定义bug的级别 ##

> **Blocker（崩溃）：** 
> 
> **阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错 误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单 功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）。** 
> 
> **Critical（严重）：**
> 
> **系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他 功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用 冲突，安全问题、稳定性等。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序 接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）**
> 
> **Major（一般）：** 
> 
> **功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询 时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多）** 
> 
> **Minor（次要）：** 
> 
> **界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格 式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置 不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）**

## bug生命周期 ##

![a90c9297f7d64344805f8203223224c6.png][]

> **New:新发现的Bug，未经评审决定是否指派给开发人员进行修改。** 
> 
> **● Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。** 
> 
> **● Fixed:开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。** 
> 
> **● Rejected：如果认为不是Bug，则拒绝修改。** 
> 
> **● Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。** 
> 
> **● Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。** 
> 
> **● Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。** 
> 
> **无效的bug：open->closed open-rejected-closed**

## team产生争执怎么办-不要争吵 ##

### 1.排除自身原因 ###

> **检查自己是否存在误操作，或者对软件需求的理解有误**

### 2.排除自己工作方式的问题 ###

> **检查自己对bug的描述是否清楚，如果不够清楚则完善bug描述，如果用文字描述不清楚，在提交bug之后要找到相关开发人员对bug描述进行解释**

### 3.提供给开发解决问题的思路/方式 ###

> **提高自身的业务和技术水平，不但要做到能提出问题，还能够提出解决问题的思路。这样才能更让人信服。**

### 4.站在用户角度考虑问题 ###

> **站在用户角度考虑问题 应该让开发人员了解到Bug对用户可能造成的困扰，这样才能促使开发人员**  **更加积极地、高质量地修改Bug。在争执时，可以问一句：如果你是用户，你可以接受么？**
> 
> ![69153cf8c9cf451cb0b0197b553f4b4e.png][]

### 5.第三方会议 ###

> **将项目涉及的相关人员全部拉入会议，包括测试领导，开发领导，此时你要对bug进行详细描述，并提出自己解决bug的思路，最后拿到一个结果：此bug是否要修复**

## 如何进行第一次测试 ##

> **作为一个菜鸟在进入测试团队开始第一次测试的时候，我们需要做很多的准备：** 
> 
> **1、阅读所有项目有关的文档，包括：需求文档、设计文档、用户手册** 
> 
> **2、尽可能参加各种项目会议，了解项目的背景、人员组成、尽可能的了解需求和业务。特别针对业务** **专业性较强的项目，例如银行业务，需要了解各种业务知识，如高低柜、一二三类账户等、存款、贷款**  **等。** 
> 
> **3、熟悉项目所使用的测试管理工具、配置管理工具，获取对应的地址和登录方式** 
> 
> **4、阅读已有的测试方案和测试案例** 
> 
> **5、阅读旧有的bug库，了解系统功能。尤其重要的是和现有的测试团队保持一致的故障定级原则** 
> 
> **6、了解公司的规范要求，特别是用例编写规范、用例执行规范、bug提交规范、测试工具工具使用规** **范等，**  **在进行了以上的准备工作之后，第一次测试工作到来了，我们需要与测试组长确认具体的工作内容：** 
> 
> **1、测试的计划是什么？** 
> 
> **2、测试的内容是什么？test case有多少？安排了几天执行？有没有自由测试的时间？** 
> 
> **3、我要测试的内容开发人员是谁？需求人员是谁？** 
> 
> **4、分配给我的测试内容是否需要特殊的测试资源？资源是否满足需要？** 
> 
> **在我们确认了以上内容之后，就可以开始测试的执行了**

[9274514775994c85990e11d7d3600eed.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/34f17c5f33b247b19e57a398d46bd623.png
[88c4abb79dfb4492b34c6be5b08f84dd.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/c12f1d59ef0647dcaeab15808c8b52fe.png
[a90c9297f7d64344805f8203223224c6.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/fbdc2d80031f43b788fbe6ccceccee90.png
[69153cf8c9cf451cb0b0197b553f4b4e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/f1479e5ee3374b398141b21978eb3672.png