1.测试计划的定义和目标
一个叙述了预定的测试活动的范围、途径、资源以及进度安排的文档。它确认了测试项、被测特征、测试任务、人员安排以及任何偶发事件的风险。软件测试计划是指导测试过程的纲领性文件
测试计划的内容
1.测试内容
1、本次需要测试的内容
A.功能测试
B.兼容性的测试
C.性能测试
D.环境
2、已有的功能测试
2.测试策略
1、通过什么样的方式来执行以及什么样的技术来实现
3.资源安排
1、环境安排（阿里云服务器，数据库，其他组件）
2、人力安排（人不够，找人）
3、时间安排
4.安排进度
1、task开始时间，和任务结束时间
2、story 任务
5.发布标准
1、开发的标准：单元测试通过率必须是大于60%才可以转测
2、上线标准：
1、新功能测试OK，没有严重的问题
2、系统已有功能也是OK的
3、必须测试的功能能全部通过，也可以说是核心的流程
6.风险预防
1、环境的风险
2、第三方的风险
软件测试计划的具体内容包含了
1.测试概述
2.测试目的
3.测试范围
测试的对象
测试的资源
测试风险
依赖方清单
注意：移动测试的兼容性测试需要单独测试
评审用例的时候要考虑的点
1、某些测试场景考虑的期望结果信息不合理
2、某些测试场景没有考虑到位
3、某些测试场景我们也不确定结果信息，那么现在说出问题，大家一起讨论，然后按照大家讨论的结果来执行，那么这个结果我们需要记录
测试用例评审完成要说的话
1、最后和大家针对前面说的几点做总结性的发言和总结性的结论
2、根据大家前面提的意见，完善测试用例，然后再发出来，让大家再次查看下
总结：关于新浪邮箱的验证
1、新版本的功能
2、系统已有的功能（忽略时间）
3、系统测试（端到端的测试）
12.17-12.17:编写测试点以及评审
12.18-12.18:测试登录错误提示信息以及不同登录的方式验证，注册
12.19-12.19:发送邮件的业务链的验证
12.20-12.20:造性能测试的数据以及进行性能测试
12.21-12.21:梳理测试报告，进行系统测试，产品进行验收测试
测试方案
主要体现在性能测试
1、背景描述
2、整体思路（需要包含具体的工作内容）
具体实现的技术细节
具体技术细节的demo
3、针对具体的工作内容列出详细的计划
hotfix
线上出现的问题，该问题需要立刻解决或者下个版本解决，需要提交一个issue，这个过程，从版本角度而言，叫hotfix
bug场景
开发转测扣，我们在测试过程中发现测试的结果与编写的测试用例期望结果不一致，那么久需要提单（提交bug）
bug注意事项：
1、提交BUG，必须有详细的测试步骤
2、最好有错误log
3、如果可以，最好有截图
缺陷的类型
缺陷的状态
缺陷的流程
可以理解成在测试的过程中，发现的问题，我们会提交bug单 由开发的同事来判定bug是否存在，如果存在进行bug修复之后交给我们从新测试，我们测试成功，关闭该bug提交单，如果修复了我们经过测试还是存在bug就要修改bug单的状态，从新修改 直至测试通过为止
如果遇到bug，程序员不管的解决方案
1、如果开发不承认，那就可以再次进行测试，如果还出现问题，那就可以去找开发解决
2、如果碰到不承认的，可以申请产品经理开会进行讨论
缺陷的优先级
标签：测试计划,提交,理论,安排,功能测试,测试,bug 来源： https://www.cnblogs.com/jiachao/p/15702183.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。