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