测试计划
1、定义
一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。它确认了测试项，被侧特征、测试任务、人员安排以及任何偶发事件的风险。软件测试计划是知道测试过程的纲领性文档。
2、测试计划内容
测试范围
1.1 本次需要测试的内容
1）功能测试
2）兼容性的测试
3）性能测试
4）环境
1.2 已经已有的功能
测试策略：通过什么样的方式来执行以及什么样的技术来实现
进度安排
1、task开始时间和task结束时间
2、story
发布标准
1、开发的标准：单元测试通过率必须是>60%才可以转测
2、上线标准：
1）新功能测试OK，没有严重的问题
2）系统已有功能也是OK的
3）必须测试的功能全部通过，也可以说是核心的流程
风险预测
1、环境的风险
2、第三方的风险
测试对象
外观界面测试、功能性测试、易用性测试、兼容性测试、安全性测试、性能测试
测试资源
测试风险
依赖方清单
兼容性测试与功能测试可以同一时间进行，性能测试在功能之后
开发转测后先评审测试用例，之后开会现场直接讨论
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布局、罕见错误
建议：对产品的改进建议
权限优先级
