1、 需求分析
· 跟同事之间探讨客户需求
· 对需求文档进行 测试 互相交换想法
2、需求评审
如何评审？
首先提前一天发邮件给格个参会人员，准备参与XXX项目需求评审。
参与人员：产品经理，项目经理，研发负责人，研发小组成员，测试负责人，测试小组成员。
然后开始会议，主要分析产品需求的合理性，开发考虑这个需求可不可以实现，测试考虑能不能给用户带来更好的使用体验。
3、根据需求编写测试计划
· 确定需求分析说明书是制订测试计划的基本依据
· 测试计划的定义 软件测试 计划是指导测试过程的纲领性文件
测试计划包含的内容：
· 概述（测试目的、参考文档、缩略语)
· 测试范围(测试范围，要测试哪些模块)
· 测试组网图(系统架构图、组网图)
· 资源需求(硬件资源需求、软件资源需求、人员需求)
· 测试条件(测试版本启动、测试版本停止、测试版本挂起的准则
· 测试进度(测试所有活动的时间安排，是测试需求分析、 测试用例 、测试轮次的时间安排)
· 测试准则（测试用例通过、测试用例失败、回归的准则、培训计划）
人力风险
1. 人力资源不够 ?解决方式；按照项目计划，测试计划准备好测试需要的人力
2. 测试用例未被完全执行 ??解决方式:在测试留存中严格控制测试的执行.抽查,责任归个具体的人
3. 人员流动，测试人员对业务不熟悉 ?解决方式:做好人员流动的准备,加大业务培训
需求风险
1. 需求人员,测试人员,开发人员对需求的理解不一致
解决方式：加强需求评审和沟通。
2. 后期需要小的变更点,没有引起重视,未知会到测试
解决方式:项目流程控制,所有变更必须知会测试进行测试和分析。
3. 需求变动大导致测试工作量增加,可能导致的测试不充分
解决方式:通过加班延长测试时间,加大测试人员投入,保证测试充分。
开发风险
1. 开发提测的时间晚于原计划，导致测试时间被压缩
解决方式：开发把握好计划送测的时间，做好晚送测的测试准备，加班或加入人力等。
2. 开发修复 bug 考虑不周全，带入新的缺陷
解决方式:bug验证要考虑好相应的场景，回归相关的功能。
环境风险
测试环境与线上环境差异过大，导致环境问题。
解决方式：尽量使用和线上环境差异少的测试环境，条件允许可模拟一套与线上相近的测试环境，来做项目最后的回归测试或安装测试。
测试计划的目的
粗略地估计测试大致需要的周期和最终测试报告递交的时间。
4、编写测试要点
根据需求编写测试点，一个需求点包含N个测试点。
5、编写测试用例 （部分公司有要点也有用例，大部分公司有测试要点就没有 ?????测试用例，没有测试要点就写测试用例，二取其一）
什么是测试用例测试用例是一份测试文档，它描述输入、操作步骤、和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作，是测试执行的依据。
测试用例的组成内容：
· 所属产品
· 所属模块
· 用例编号
· 用例名称
· 前置条件
· 操作步骤
· 预期结果
· 实际结果
· 测试人员
6 、用例评审
评审分类
1. 部门评审，测试部门全体成员参与的评审。
2. 公司评审，这里包括了项目经理、需求分析人员、架构设计人员、开发人员和测试人员。
3. 客户评审，包括了客户方的开发人员和测试人员。这种情况在外包公司比较常见。
评审内容
1. 用例设计 的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。
2. 优先极安排是否合理。
3. 是否覆盖测试需求上的所有功能点。
4. 用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；期待结果是否有明显的验证方法。
5. 是否已经删除了冗余的用例。
6. 是否包含充分的负面测试用例。充分的定义，如果在这里使用2?8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件，其中80%的代码都是在“保护”20%的功能实现。
7. 是否从用户层面来设计用户使用场景和使用流程的测试用例。
7、是否简洁，复用性强。 例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。
· 搭建测试环境
· 等待开发转测试（提测）提测的准则：冒烟测试通过
· 据用例来执行测试
· 测试不通过的应在缺陷报告当中 记录
· 缺陷报告的内容
· 所属产品
· 所属模块
· 影响版本
· Bug类型
· Bug标题
· 严重程度
· Bug状态
· 优先级
· 重现步骤
· 附件
· 提交bug后还需对bug进行跟踪
8、测试完毕编写测试报告
· 一直反复测试2-3轮过后才确认测试结束
· 测试报告的内容
· 简介 (产品名称、版本号、参考文档)，
· 测试资源描述 (地点、人物，软件测试环境、硬件测试环境，测试组网图，测试仪器)
· 测试时间统计 (测试任务的时间，这里面的时间是详细的每个版本的细分时间统计)
· 测试用例分析 (测试用例执行情况分析，哪些用例通过了，哪些发现问题了),
· 缺陷情况分析 (分布情况、严重程度、遗留问题)，
· 测试版本质量分析 (测试版本的质量怎么样，描述一下)
· 测试活动评估 (测试活动及写测试用例，脚本方面的质量方面描述一下)
· 测试过程改进 (改进的建议)
感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【 软件测试 】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你! 有需要的小伙伴可以点击下方小卡片领取
