测试计划,缺陷管理.
一,测试计划
一,基础知识
⼀个叙述了预定的测试活动的范围、途径、资源及进度安排的⽂档。它确认了 测试项、被测特征、测试任务、⼈员
安排以及任何偶发事件的⻛险。
测试范围：测试的边界，也就是说本次迭代（2周）测试需要干的具体的事，测试范围里面需要明确的指出这么几点：
A、本次新迭代需要测试的内容
B、本次迭代是否需要测试性能测试
C、本次迭代是否需要系统之前的功能，如果测试，时间是多少？(系统已有功能是每个迭代必须要进行测试的，但是不会给太多的测试时间)。
测试技术手段：
1、自动化测试
2、精准测试（开发修改了哪些代码，测试这边很准确的知道修改了哪些代码，以及自动化的验证这些被修改的代码）
3、流量回放（把线上所有的请求在线下执行）
4、混沌工程（Netfix和阿里巴巴）(通过科学试验的手段技术来模拟生产环境中出现故障后的技术解决方案)
测试策略：在测试范围清晰的定义测试的边界之后，那么测试团队需要考虑的是使用什么样的测试策略来进行测试，也就是说通过什么样的解决思路以及测试技术，能够在有限的资源上完成产品的交付
资源安排：
两个维度：
1. 人力资源（已经清晰的知道测试的边界以及测试的范围，思考的是通过几个人，以及多少天来完成这件事）
2. 硬件资源（在测试的过程中是否需要服务器，如果没有服务器，那么就需要采购）
进度安排：
1、针对测试的边界（范围），会把任务拆分成很多的story
2、给每个story完成任务的具体时间范围，需要精确到小时（每个任务具体开始的时间和具体结束的时间）
⻛险控制：在测试计划里面，关于风险控制，不是非必要的，但是是必须考虑的，所以说的测试风险，指的是事实上大家可见的风险，不能主观意愿强加的风险以及凭自己的猜想强加的风险
测试计划注意的事项：
1、针对本次迭代需要测试的对象，任务必须要拆分，而且拆分后的任务都是可独立的测试
2、针对分配给你的story（任务），测试时间由自己规划
测试计划注意的事项：
1、针对本次迭代需要测试的对象，任务必须要拆分，而且拆分后的任务都是可独立的测试
2、针对分配给你的story（任务），测试时间由自己规划
3、一般测试计划是每个人去梳理，最后测试计划进行整合
4、风险控制方面如果存在，需要列的非常详细，以及针对每个风险控制的点，需要给出具体的跟踪人，以及负责人
A、没有服务器，运维工程师
B、你负责测试的模块依赖于别人（自己造数据测试）
C、关于风险，如果涉及到自己，一定要把风险反馈出来，不能由着开发的意思来，也不能说自己能够解决
5、你负责的任务由于太大，分配了另外一个测试和你共同来测试这部分
A、你的负责人和对方的负责人，明确任务的边界
B、每天早上反馈的时候，反馈下任务进度，各自反馈各自
二,缺陷管理
一,缺陷概述
二,缺陷状态
三,缺陷级别
致命：系统崩溃、数据丢失、数据毁坏、安全性被破坏。
致命： 1、系统崩溃 2、数据丢失 3、系统雪崩
严重：操作性错误、结果错误、功能遗漏。
严重问题： 1、逻辑问题 2、影响流程功能
⼀般：⼩问题、拼写错误、UI布局、罕⻅错误。
一般： 1、页面交互 2、浏览器兼容性 3、错误提示信息不合理
建议：对产品的改进建议。
四,缺陷修复优先级
优先级表示修复缺陷的重要程度和紧迫程度。
紧急：影响进⼀步测试，需要⽴即修复。
⾼：必须在版本发布前修复。
中：必须要修复，不⼀定⻢上修复，可以讨论确定在某个时间节点修复好。
低：对产品影响⽐较少，不修复也不影响产品的发布。在时间不允许的情况下可以暂时不修复。
五,提bug的要素有哪些
原则：
1、是问题必须反馈（提交BUG），这是一个价值观的问题
2、如果像这样的问题，大家都认为没有必要（包含测试负责人也是这样认为），那么你以后提单就需要注意：
A、不管后面是否遇到同样的问题，即使遇到也是提单，修改不修改问测试负责人
B、针对每次这样的事最好有记录 3、质量是公司所有的人来负责的，但是现实生活中，遇到问题，测试肯定得有责任
面试官问我「当你提了一个 bug，开发认为这不是 bug」该怎么处理？
1、首先明确开发说不是bug的理由。
2、如果是需求变更， 那就找产品经理确认是否是需求变更。
3、如果开发说测试环境问题， 让他说明清楚测试环境问题是什么，按照他说的验证一遍， 如果确实如他所说， 关闭bug，但是不是他说的那样，继续激活bug给开发解决，确保产品质量。
4、如果开发说用户不存在这种使用场景， 但是我们不认可他说的，把这个bug 知会到测试经理，让测试经理去判定。
新功能晚上上线，结果上线后就有了问题，此时你会？
1、先在测试环境验证问题是否存在（排查是开发的责任还是测试的责任）
2、测试环境验证问题存在，那么就说明测试环境测试这边没测试出来，那么在群里面反馈给大家，然后再次评估今天晚上上线是否继续？
3、测试环境验证问题不存在，也需要反馈出来，下一步@开发，让开发检查各个中间件(RabbitMQ,Kafka,Redis等)的配置参数以及其他的配置
4、开发在3的基础上更新代码解决问题后，测试协助开发验证，然后把验证的结果反馈出来
复盘：
1、测试问题，复盘怎么说？
A、这个问题首先测试这边是责任的，之前设计测试用例不仅仅测试没考虑到，评审的时候大家也没考虑到，所以导致这个场景没有测试到
B、所以下次编写测试用例，测试这边会增加XX维度的测试点，评审的时候大家也需要沿着这个维度来考虑
2、开发问题，复盘怎么说？
A、建议开发这边每次上线前专门写一个关于上线的checklist，这样防治下次也犯同样的问题
序号 检查项 负责人 1 Redis参数修改为... 赵四
从测试开始到测试结束，测试总共测试几轮？ 在一个迭代中，你是怎么保障质量的？你是怎么测试保障本次迭代是没问题的？
1、第一轮的测试：主要是测试本次迭代转测的所有功能，包含了正常，异常，性能，容错，等等（周一）
2、第二轮的测试：先回归验证所有的问题单，问题单验证完毕后，再针对本次迭代的核心流程再次测试（周二）
3、第三轮的测试：再次回归问题，以及进行系统测试（周三）
4、下来接着就是验收测试以及探索性的测试
版本合并后，测试还需要测试吗？为什么？
1、版本代码合并后，测试需要针对系统的所有功能（新的功能+系统之前已有的功能）都需要进行测试 为什么需要测试？2、开发在合并代码的时候，可能会出现冲突，也可能会出现代码的丢失
