BUG与测试计划

一、BUG 缺陷  issue

houfix（hotfix版本，也叫补丁）

线上出现的问题，该问题需要立刻解决或者下个版本解决，需要提交一个issue，这个过程从版本角度而言叫hotfix

场景：开发转测后，我们在测试过程中发现测试的实际结果与编写的测试用例期望结果不一致，那么就需要提单（提BUG）

1、缺陷状态

建议：建议不能说问题，建议表达的是更加完善

优化：指的是产品不是那么很好，优化下更加好，例如提示信息

BUG：指的是程序存在的缺陷

需求：客户有了新的想法，增加到产品里

2、缺陷级别(与优先级一一对应）

致命：系统崩溃、数据丢失、数据毁坏、安全性被破坏

严重：操作性错误、结果错误、功能遗漏

一般：小问题、拼写错误、UI布局、罕见错误

建议：对产品的改进建议

3、缺陷优先级

优先级：表示修复缺陷的重要程度和紧迫程度

紧急：影响进⼀步测试，需要立即修复

高：必须在版本发布前修复

中：必须要修复，不⼀定⻢上修复，可以讨论确定在某个时间节点修复好

低：对产品影响比较少，不修复也不影响产品的发布。在时间不允许的情况下可以暂时不修复

4、缺陷状态

主要描述缺陷当前的状态，状态如下：

新建：测试人员新提交的bug、优化或者建议的状态

进行中：开发人员确认时bug，在修复bug过程中的状态

已解决：开发人员已修复bug的状态

已关闭：测试人员验证修复的bug，确定已解决问题的状态

不解决：开发人员认为不是bug，拒绝解决问题的状态或是无法解决问题的状态

重开：测试人员验证修复的bug，发现没有完全修复好bug，重新打回开发的状态

暂缓：开发人员认为该bug不急于修复，可以放置一段时间再修复的状态

5、缺陷流程

1、在测试过程中发现的问题，我们进行提交

2、提交给开发后，开发会进行确认，如果是bug，开发进行修改；

如果不是bug，开发会反馈给测试，测试回归验证确认不是BUG，可以直接关闭；

需要到下个版本进行修改的BUG是需要全部参与人员确认，确认延迟的话，不要关闭先放着等下一个版本修改

3、如果开发确认是bug，那么开发修改完成后，再反馈给测试，测试进行回归验证bug是否解决

4、如果bug回归测试通过，关闭该问题，如果回归测试不通过，问题依然存在，那么继续反馈给开发

6、BUG注意事项

1、BUG标题一定要表达出问题的核心，看了标题就知道是什么问题

2、BUG步骤要清晰明了，通俗易懂，步骤要非常详细 

3、提交BUG最好有问题截图

4、提交BUG最好有详细的日志信息(主要针对的是后台服务)

二、测试计划

1、定义

一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。它确认了测试项，被侧特征、测试任务、人员安排以及任何偶发事件的风险。软件测试计划是知道测试过程的纲领性文档。计划可以统一认识，可以规划过程。测试计划包含了产品概述、测试区域/测试范围（测试项）、 测试⽬标（被测特征）、测试优先级、测试配置/测试资源<硬件、软件、人力、技术等>、测 试周期、进度安排（测试任务、人员安排）、 测试策略、测试方法/途径、测试交流、风险分析、测试标准、需交付文档等内容

2、测试计划内容

1.1、测试范围——明确测什么

1.1.1、本次需要测试的内容

     1）功能测试

     2）兼容性的测试

     3）性能测试

     4）环境

1.1.2、已经已有的功能

1.2、测试策略：明确怎么测

1.3、进度安排

在明确测试范围、⽅法和⼈员之后，我们要考虑什么时候开始测试，预计要测试多久？以便和开发计划、上线计划衔接

一般是以天为单位

1、task开始时间和task结束时间

2、story

1.4、发布标准

测试完成和产品上线需要满足的条件，以便项目内所有角色都有一致认可的目标

1、开发的标准：单元测试通过率必须是>60%才可以转测

2、上线标准：

     1）新功能测试OK，没有严重的问题

     2）系统已有功能也是OK的

     3）必须测试的功能全部通过，也可以说是核心的流程

1.5、风险预测

最后，我们需要对整个测试过程中可能存在的⻛险，以及当这些⻛险发⽣时的应对措施提前进⾏⼀些考虑和准备，并在测试计划中体现出来

1、环境的风险

2、第三方的风险

 

实战演练——测试计划

 

 

 

1.6、测试对象

外观界面测试、功能性测试、易用性测试、兼容性测试、安全性测试、性能测试

测试资源

1.7、测试风险

 

1.8、依赖方清单

 

兼容性测试与功能测试可以同一时间进行，性能测试在功能之后

 

开发转测后先评审测试用例，之后开会现场直接讨论

1、遇到测试用例中期望的结果不合理

2、没有考虑到的场景

3、测试逻辑或者场景不确定，现场说出问题后进行讨论，之后按照讨论的结果来执行

 

评审完成后

1、针对之前有异议的问题总结性发言并确定执行情况

2、按照提出的问题，完善测试用例，修改后@参会人员查看确认

 

3、测试计划内容

1、新版本的功能

2、系统已有的功能(一般会忽略这个时间）

3、系统测试（端到端的测试）

如：新浪网登录与注册的测试（16日开发完成，转测试）

12.17-12.17  编写测试点以及评审

12.18-12.18  测试登录、注册错误提示信息以及不同的方式验证

12.19-12.19  发送邮件的业务链的验证

12.20-12.20  造性能测试的数据以及进行性能测试

12.21-12.21  梳理测试报告，进行系统测试，产品进行验收检测

测试计划中出现提前完成计划时，在工作汇报时，提出与计划时间一致的内容完成情况。出现测试过程中甲方需要更改内容，问题较小可以自行消化，问题比较大的话，需要延迟时间进行处理

 

4、测试方案

1、背景描述

2、整体思路（需要包含具体的工作内容）

      具体实现的技术细节

      具体技术细节的demo

3、针对具体的工作内容列出详细的计划