测试流程
软件开发模式
瀑布型
从需求到设计，从设计到编码，从编码到测试，从测试到发布，每一个阶段都完成做好之后再进入下一个阶段
敏捷型
采用迭代、循序渐进的方法进行软件开发，把一个大项目分为多个相互联系又可以独立运行的小项目，分别完成，实现快速开发的目的
敏捷测试
敏捷测试随着敏捷型开发而出现，更注重人的主观参与，伴随着产品快速迭代而快速的对质量进行验证
- 强调测试的速度和适应性，测试计划会根据需求的变化而不断变化
- 测试人员更早介入测试，并且贯穿整个项目开发过程
- 快速的迭代，问题修改之后，快速的验证，之后再将产品推给用户，再收集问题，如此反复
- 敏捷测试需要良好的自动化测试手段与持续集成CI/CD的支撑
- 在敏捷测试中，更需要整个团队都参与到产品质量建设中
测试启动阶段
- 参与软件需求调研，以测试的角度分析需求的可测性，可构思将来对测试进行的方法、原则等，更重要的是对不可测或难以测试性问题要及时与项目人员协调解决
- 全面了解需求，从客户角度考虑软件测试需要达到的验证的状态，即哪些功能需要重点测试，哪些则无需，以便将来制定测试计划
- 测试人员参与研发人员项目需求会议，明确需求及任务完成时间，研发人员需向测试人员提供产品需求文档、详细设计说明书、数据库设计说明书等，明确测试任务，确定测试周期
制定测试计划
根据产品需求分析，制定测试计划目标、测试内容、测试工具，给出测试参考文档、测试风险分析，对测试人员进行分工，测试人员根据项目大小及项目紧急度商讨是否需要写测试计划
设计测试用例
- 根据产品需求文档以及详细设计文档提炼出测试要点，形成一个测试要点的文档（提取测试需求）
- 在拿到产品功能列表和测试版本之后，参考测试要点文档，测试人员开始设计测试用例，测试人员根据产品功能列表后尽量多的设计测试用例，尽可能多的覆盖所有的测试需求
- 由评审组对测试用例进行评审--修改--再次评审--初步定稿，测试用例需要录入到管理系统，以便跟踪执行测试用例
搭建测试环境
研发人员需告知搭建好的测试环境的服务器，如需测试人员搭建环境，研发人员需提供测试环境搭建文档或者手册，准备测试数据，尽量按照真实有效的数据来测试系统，这样更加的符合业务场景
执行冒烟测试
- 列出冒烟测试的主要功能、测试点， 运行主要流程测试用例与测试数据
- 检查主要功能是否已经基本正确实现，初步运行主要功能的性能测试，是否存在明显的性能缺陷
- 对测试发现的问题定时进行归纳与总结，预测以后测试可能会存在的风险，需要每天进行一次对当天的测试情况回顾
执行测试用例
- 当测试用例设计完后，测试人员就开始全力实施每一条测试用例，当预期结果和实际结果不符时，这时就产生了bug
- 测试人员要争取每个bug都能够重现，便于开发修改，测试人员将bug记录到BUG管理平台反馈给相关开发人员，开发人员进行修复
- 测试人员对已修复的bug进行再次验证，直到bug解决为止，把状态置为关闭，并将测试结果记录下来
- 在测试的过程中，如果出现了bug但研发人员不认为这是bug，这时应该与需求负责人或者产品经理一起讨论判定是否属于bug
- 对于测试过程中发现的不在测试用例范围的问题应补充到测试用例中，不断地完善测试用例，提高测试覆盖率
Bug跟踪处理
- 测试人员提交bug => 开发人员解决bug => 测试人员验证关闭
- 测试人员提交bug => 开发人员解决bug => 测试人员验证未通过 => 激活bug => 重新解决 =>验证关闭
测试报告输出
在约定的测试周期内，在所有的用例都执行完，所有的bug都修复完，测试人员需要针对本次测试项目编写测试总结报告，将测试结果反馈，以及容易出现bug的模块给予建议，相关负责人在下次开发中予以借鉴，避免类似错误的出现，测试报告输出后，可通过邮件形式，让相关项目人员知晓
测试结束条件
- 当所有的用例都被执行完，所有的bug都被修复，编写测试总结报告
- 基本功能都已实现，一些建议性的bug可以再下一版本中修复
- 测试周期结束
- 如遇项目紧张，急于上线，测试部测试基本功能没问题，对于用户后续发现的bug可以进行跟踪，可与用户的项目对接人保持不定期的联系，询问客户使用软件的情况，这种情况也可与公司售后直接联系
备注：测试流程在测试项目中需要慢慢的修正和完善，一旦进入测试过程中，不接受任何大模块更改，如需更改需求请走需求流程