今天给大家说说互联网公司的敏捷测试流程。
敏捷开发测试是现在互联网公司使用最多的，其大概解释为小步快跑，就是将一个项目或软件的开发分为多个模块迭代完成，再针对每个模块都能够独立的进行需求分析，开发和测试，能够将每个迭代交付给客户的软件是可以使用的。
其优势如下：
1.项目及产品可以在短时间迭代上线（一般为一周、快的几天、小改动一天），通过不断迭代尝试完善产品本身功能。
避免过长时间的需求分析及调研，可通过线上数据来看实际需求效果。
产品上线后根据客户时时反馈来跟踪使用等问题。
下图为软件研发测试流程：
这里要说明的几点：
分支开发指的是新功能或者模块的开发（会存在多个分支）。
RD 开发和 QA 用例设计并行，有的公司甚至能做到新需求的单元测试或自动化代码开发。
用例评审需要 PM、RD 共同参与。
基本上我们每天的工作也都是围绕这个流程来的，当然再好的流程也会存在问题，如遇到最多的几个常见问题：
- 迭代太快了，经常有一句话需求
2.RD 提测了，和需求实现不一致
- 紧急项目如何处理
针对第一种常见问题、如果遇到复杂的需求，RD、QA 一定要在需求阶段沟通解决，及时提出让 PM 整理好需求，重新发起需求评审，要坚决杜绝这种现象发生。（如需求不复杂，比如屏蔽、去掉某某功能，添加个文案这种的，改动极小的可以简单描述，但必须要有效果图，符合设计）
这里还要说明一种特殊情况，需求不一定必须是文档，可通过口头或简单纸搞的形式完成，前提是对应的 RD 和 QA 都理解清楚。
第二种问题，RD 提测前的测试用例评审环节必须邀请到 PM 和 RD 共同参加，如 PM、QA 发现 RD 设计有问题要当面提出，并且如果提测后，最好再和 RD 对下相关实现逻辑，这样 QA 能更好的了解 RD 设计，以便深入测试。
第三种对于紧急项目一般要简化流程，如果优先级最高的比如处理线上问题的话，基本上 RD 修改后 QA 根据修改点和RD 给出的风险点，代码 reivew（这两点非常重要）、测试列出测试点，然后立刻进行测试（功能、和单元、自动化测试相结合），测试没问题，RD 直接快速上线了，QA 再在线上灰度测试，确认没问题后就是全量上线。
以上就是今天给大家介绍的互联网测试流程。
声明：上述观点为个人经验总结和观察，如有不对的地方请随时指正或留言交流。
作者：小文（一个即将从业 10 年的软件测试行业工作者）