01 第一步：需求分析
1.1 需求分析说明
- 在软件项目的开发过程中，软件需求规格说明书的编写是必不可少的
- 他能够使用户和软件开发者双方对该软件的初始规定有一个共同的理解，这是整个项目开发工作的基础
- 提取测试点是通过对需求的细化和分解，形成可测试的内容
- 测试内容应全部覆盖系统的业务流程，以及功能和非功能方面的需求
- 非功能的需求，包括：用户体验，性能等其他需求
1.2 业务流程图
1.3 注册功能
1.4 需求如下
1.5 需求分析的结果
02.第二步：需求评审
1、需求评审会议：
- 在需求分析之后，会进行一个需求评审的会议
- 整个项目的成员会聚集再一起讨论一下各自对需求的理解
- 看看需求的理解是否出现不一致的地方，是否出现可遗漏的地方
2、评审的内容：
1、完整性审查
- 应保证测试需求能充分覆盖软件需求的各种特征
- 重点关注功能要求、数据定义、接口定义、系统约束等方面
- 同时还已应关注是否覆盖开发人员遗漏的、系统隐含的需求
2、准确性审查
- 应保证所描述的内容能够得到相关各方的一致理解
- 各项测试需求之间没有矛盾和冲突，各项测试需求在详尽程度上保持一致
- 每一项测试需求都可以作为测试用例设计和依据
03 第三步:测试计划
3.1 测试计划介绍
1、在评审完成之后，会完成一个测试计划的编写，安排一下测试的进度与内容。
2、为什么要编写测试计划？
- 软件测试是有计划、组织和有系统的软件质量保证活动，而不是随意地、松散地、杂乱地实施过程
- 为了规范软件测试内容、方法和过程，在对软件进行测试之前，必须创建测试计划
3、什么时间开始编写测试计划
- 需求分析后编写测试计划，在整个测试工作过程中，不断修改
4、由谁来编写测试计划？
- 具有丰富经验的项目测试负责人
5、测试计划的内容
- 测试项目的背景、测试范围和测试策略、测试环境、测试开始和结束
- 进度安排，测试组织，以及与测试有关的风险等方面的内容
6、测试项目的背景
- 对测试对象及其目标进行简要说明，包含的信息有
- 主要的功能和性能，测试对象的架构和项目的作用
- 通常，项目的背景可以从需求文档中获取
7、测试范围
- 简单的列出本次测试的主要模块
8、测试方法/策略
- 功能测试
- 界面测试（UI测试）
- 安全测试
- 安装测试
- 兼容性测试
- 负载测试
- 压力测试
3.2 测试环境
1、从软件的编写、测试道用户实际使用，存在者：开发环境、测试环境和生产环境
- 开发环境：开发环境是程序员们专门用于开发的服务器，配置可以比较随意，为了开发调试方面，一般打开全部错误报告
- 测试环境：一般是克隆一份生产环境的配置，一个程序在测试环境工作不正常，那么肯定不能把它发布到生产机上
- 生产环境：是指正式提供对外服务的，一般会关掉错误报告，打开错误日志
2、环境：指的是被测试软件所运行的软件环境和硬件环境
3、测试环境
- 测试环境是测试人员为进行软件测试而搭建的环境，根据不同的测试阶段
- 测试环境可以分为冒烟测试环境，SIT测试环境，UAT测试环境等；
- 根据不同的测试类型，测试环境可以分为功能测试环境，自动化测试环境，性能测试环境
04：第四部测试用例
05 第五步：测试执行
根据已有的测试用例，按照步骤一步一步的执行，查看预期结果与实际结果是否一致。
5.1 测试执行过程中注意事项
1、搭建测试环境事项
- 测试用例执行过程前，成功搭建测试环境是第一步。
- 一般来说，软件产品提交测试后，开发人员应该提交一份被测试软件产品的详细安装指导书
- 如果开发人员拒绝提供相关的安装指导书，搭建测试中遇到问题的时候
- 测试人员可以要求开发人员协助，这时候，一定要把开发人员解决问题的方式记录下来
- 避免同样的问题再次请教开发人员，这样会导致开发人员的反感，也降低了开发人员对测试人员的认可程度。
2、测试环境怎样搭建的？
- 搭建环境前，开发都会给带我们一份系统发布手册，我们会根据这个手册来搭建
- 比如，我这个xx系统，是搭建在Unix系统下的，web服务器用的是Tomcat8,MYSQL版本5.7，程序是JAVA编写的
- 首先我们向开发拿到编译好的安装包，然后用xshell远程连接上Unix系统，把tomcat服务器停掉
- 把程序包放到webapps目录下，然后再启动tomcat服务器就可以。
5.2 偶然性问题的处理
- 在测试执行过程中，一旦系统出现异常信息，我们第一时间要做的是截图，保存证据；
- 确定是偶然性的bug之后，收集相关的日志，连同截图一并提交过单位开发
- 如果缺陷在当前版本无法复现，且缺陷的影响程度比较低，我们会跟踪三个版本，如果后三个版本都无法复现，就可以关闭该缺陷；
- 如果很严重的Bug,除了要及时反馈给上级之外，最后还要写到测试报考中，说明出现了什么现象，但无法再现！
- 详细记录预期与实际的不一致，如果不一致，要从多个角度多测试几次，尽量详细的定位软件出错的位置和原因，并测试出因为这个错误会不会导致更严重的错误出现，最后把详细的输入和实际的输入，以及对问题的描述写到测试报告中。因为在一个项目组中，项目的开发时间是有效的，如果我们测试时能把问题描述详细一些，那么开发人员就会很容易的重修这个问题，也就能更快的解决问题，节省项目时间。
- 提交缺陷时与开发的关系处理
- 坚持原则
- 对事不对人，拿证据说话
- 尊重对方的劳动成果，平时和开发人员打好关系，不要把关系搞僵。
06 缺陷的定义（bug）
07 测试报告主要内容