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

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

2、没有考虑到的场景

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

评审完成后

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

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

测试计划内容

1、新版本的功能

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

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

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

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

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

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

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

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

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

测试方案

1、背景描述

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

      具体实现的技术细节

      具体技术细节的demo

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

 

BUG 缺陷  issue

houfix（hotfix版本，也叫补丁）

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

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

BUG注意事项

1、提交BUG，必须有详细的测试步骤

2、最好有错误log

3、验证错误测试截图

缺陷状态

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

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

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

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

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

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

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

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

权限流程

 

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

2、提交给开发后，开发这边会进行确认，如果是bug，开发进行修改，如果不是bug，开发会反馈给测试

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

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

缺陷类型

 

 缺陷级别

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

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

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

建议：对产品的改进建议

 权限优先级