背景介绍
做过一段时间测试的人来说都会有一个共同的感受，测试是一个涉及面广、繁琐细碎的事，我刚开始接触测试行业的时候测试已经发展了很多年了，所以测试相关的很多东西都已经汗牛充栋了，对于不是软件工程出身的测试人来说从大量的资料里汲取有效的信息是一件很费力的事，而且很多都是指向测试的某一个点，这会让我们感觉无论是测试学习还是做测试都像一团浓雾一样迷惑，下面通过自身的经验和学习总结了一套比较使用的测试流程，带大家从大方面上重新理解测试。
测试流程
大家都知道测试的目的是为了保证产品质量，为此很多人愿意把测试流程归结为三个阶段，分别是研发阶段、测试阶段、线上发布阶段，但是个人认为测试还是要从项目的开始入手即需求阶段，并且这一理论的价值已经在我所有的项目中得到认证。测试流程主要分为以下几个流程：
- 需求分析
- 测试分析与设计
- 测试用例设计与执行
- 测试报告与总结
需求分析
需求分析发生在项目流程的需求评审前期，在需求评审之前测试人员的主要工作就是根据需求文档通过一些业务流和产品形态进行分析，我一般在这个过程中会围绕
- 需求的目的
- 需求的实现
- 需求业务逻辑
- 需求的可行性
这几个方面考虑，这个过程对于需求评审无客户参与时效果异常明显。能够很好的把我产品，同时也能在源头上规避一些不必要的工作。
测试分析和设计
测试分析阶段是承接需求评审这一阶段的基础上对已确定的需求进行测试实现的模拟分析，在该阶段一般测试负责人会多一份考量用于在项目周期的基础上作测试周期评估。对于测试设计很多测试人员在项目紧急的情况下是不会做的甚至有些测试人员始终都未做过测试设计，接到需求就开始写用例，其实这是一个很不好的习惯，而且也容易出现遗漏，真正实践中测试设计和测试执行的过程并不会比拿到需求直接测试要耗时很多有时甚至更加便捷且覆盖率高。
该阶段推荐使用一些辅助工具，如xmind等能很好的帮我们梳理
测试用例设计与执行
不同的端测试用例设计有所不同，这里简单归纳了一套测试用例模版
测试执行的伊始，一般都会进行冒烟测试，对版本及主要功能点进行测试，这个阶段通常会出现版本错误的问题或者是出现一些严重的阻断性bug,对于提测质量很低的需求测试人员可以对其打回，从而提高测试效率，当然这在一定程度上说明了开发没有自测过程同时也说明了开发的开发质量很低，在后续的工作交互中需要对此类开发人员的提测加强关注。
测试报告和总结
测试结束都要写测试报告和进行测试总结，测试报告中可以涵盖测试内容、测试结果、bug量及处理状态、风险分析、项目干系人及审核人员等信息，其中风险分析环节是我自己加入的，这在一定程度上可以提醒产品也保障了测试的工作体现测试的工作力度。
以上内容仅为个人经验总结，如有异议欢迎下方留言哦～