测试计划
测试计划
一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。
它确认了测试项、被测特征、测试任务、人员安排以及任何偶发事件的?险。
软件测试计划是指导测试过程的纲领性文档。
测试范围，测试策略，资源安排，进度安排，发布标准，风险预测
测试范围：
1、本次需要测试的内容
A、功能测试
B、兼容性的测试
C、性能测试
D、环境
2、已经已有的功能
测试策略 ：
1、通过什么样的方式来执行以及什么样的技术来实现
资源安排：
1、环境安排（阿里云服务器，数据库，其他组件）
2、人力安排
3、时间安排
进度安排：
1、task开始时间，和task结束时间
2、story开始，结束
发布标准：
1、开发的标准：单元测试通过率必须是大于60%才可以转测
2、上线标准：
1、新功能测试OK，没有严重的问题
2、系统已有功能也是OK的
3、必须测试的功能全部通过，也可以说是核心的流程
?险预防：
1、环境的风险
2、第三方的风险
依赖方清单
评审测试点
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、针对具体的工作内容列出详细的计划
1、提交BUG，必须有详细的测试步骤
2、最好有错误log
3、如果可以，最好有截图 1、在测试的过程中，发现的问题，我们进行提交
2、提交给开发后，开发这边会进行确认，如果是bug，开发进行修改，如果不是bug，开发会反馈给测试
3、如果开发确认是bug，那么开发修改完成后，再反馈给测试，测试这边进行回归验证BUG是否解决
4、如果BUG回归测试通过，关闭该问题，如果回归测试不通过，问题依然存在，那么继续反馈给开发
测试报告一般是在项目测试结束或一个迭代完成之后由测试负责人编写。
若不是项目，那就由该项目主导人来写，若只有你一个来测试，那就是由你来写。
测试报告主要内容大致可以分为测试范围、测试进度、缺陷管理、测试结论四大部分。
一、测试范围（需要测试的功能）
一般以新增功能和修改功能为主，以回归测试内容为辅，测试报告中的测试范围可以摘取测试计划中的测试范围，再根据本轮测试活动中实际测试的功能进行补充。
测试报告中测试范围与测试计划中的测试范围区别：
1、内容：测试计划中的测试范围是根据需求文档梳理出来的，而测试报告中的测试范围以实际测试内容整理出来的。
2、结果：测试计划中的测试范围没有测试结果，测试报告中的测试范围需要标明测试结果。
二、测试进度
测试报告中的测试进度由二部分组成：一个是时间进度安排（展示），另一个是人员测试时间花费。
1、时间进度安排
测试报告中的测试时间比测试计划中的测试时间多了每个阶段中实际开始时间和实际结束时间。
2、测试时间花费
测试时间花费的输出是测试计划中所没有的，测试报告中输出测试时间花费主要是反映本轮测试所花费总的单位人力时间，也从侧方面反映本轮软件质量。
三、缺陷管理
缺陷管理是测试报告中的核心内容，目的就是为了从缺陷分析中得出软件质量、修改bug的效率、开发质量等。
四、测试结论
测试结论中包含对本轮测试过程的总结，主要得出本轮测试之后项目是否达到了上线标准，所以测试结论有测试通过，可以上线，或者是测试不通过，建议不上线。
Bug表单组成
标题：阐述问题本质，需要写明在哪个页面执行什么操作出现什么现象。
设备及状态：如设备本身，操作系统版本、测试环境、网络类型等等。
出现条件：表明什么状态下出现，没有则写无。
测试步骤：分步骤描述操作（序号）。
如在特定情况下发生的问题，还需明确提供以下信息：
1、准确写出连续点击次数，点击时长与上下滑动屏幕时长。
2、对于特定数据产生的问题，提供具体数据。
3、精准描述bug产生的路径后，再描述现象。
特别提醒：测试步骤中的点击要用->符号连接
期望结果
按照测试步骤应当得到的正确结果，按照产品需求的期望清晰准确的填写预期结果。
实际结果
按照测试步骤实际出现的错误结果，避免模糊词汇，需要直接描述实际现象。
期望结果和实际结果要相互对应
复现步骤和概率
描述复现步骤，关于复现概率一定要在多次测试的基础之上填写，若必定复现则填写100%，若偶现，请执行多次后统计概率填写。
截图或附件
UI类型：Bug需要上传截图，并且增加相应的红框标识；
功能类型：问题必须上传视频文件，上传格式MP4为主；
崩溃类型：bug则需要上传视频和log。
提交Bug时将进行判断
1、对Bug分类提交
2、需求是否明确、前提条件是否满足、输入数据是否正确、操作步骤是否清楚、Bug是否唯一性；
3、避免提交操作错误、重复的、已知的Bug.
对部署后服务进行线上巡检
线上巡检：每隔XX分钟进行定时的自动扫描，验证服务对应的产品是否可用，如不可用的情况下，触发报警（短信，钉钉，企业微信）
混沌：在一定的可稳定性的秩序下，存在不确定性，所以就需要新的秩序来建设可确定性的东西
弹性计算（容器化）：可伸缩的架构 cpu ：大家都进行扫描二维码，以及查看自己的健康码内存：大家的健康码数据在进行大量的查询和写入
OOM（Java Lang Out Of Memory）：内存泄露 西安一码通崩溃排查 排查思路：
1、首先搞清楚这个服务是在那个阿里云机器上部署的
2、然后登录到这个阿里云的服务器上
3、然后到二维码服务的logs目录下
4、查看今天早上7:35至7:45的日志
A、日志文件疯狂的写
B、还是继续写，但是不是疯狂的写，查找关键字Out Of Memory，7:40
最直接的方式：服务重新启动，内存释放
健康码的数据，必须进行持久化的处理：
1、持久化的技术方案：redis 内存中的数据会进行备份的
2、数据存储的数据库，那么数据库里面的数据也会进行冷热备份