今天给大家说说互联网公司的敏捷测试流程。

敏捷开发测试是现在互联网公司使用最多的，其大概解释为小步快跑，就是将一个项目或软件的开发分为多个模块迭代完成，再针对每个模块都能够独立的进行需求分析，开发和测试，能够将每个迭代交付给客户的软件是可以使用的。

其优势如下：

1.项目及产品可以在短时间迭代上线（一般为一周、快的几天、小改动一天），通过不断迭代尝试完善产品本身功能。

1. 避免过长时间的需求分析及调研，可通过线上数据来看实际需求效果。

2. 产品上线后根据客户时时反馈来跟踪使用等问题。

下图为软件研发测试流程：

这里要说明的几点：

1. 分支开发指的是新功能或者模块的开发（会存在多个分支）。

2. RD 开发和 QA 用例设计并行，有的公司甚至能做到新需求的单元测试或自动化代码开发。

3. 用例评审需要 PM、RD 共同参与。

基本上我们每天的工作也都是围绕这个流程来的，当然再好的流程也会存在问题，如遇到最多的几个常见问题：

1. 迭代太快了，经常有一句话需求

2.RD 提测了，和需求实现不一致

1. 紧急项目如何处理

针对第一种常见问题、如果遇到复杂的需求，RD、QA 一定要在需求阶段沟通解决，及时提出让 PM 整理好需求，重新发起需求评审，要坚决杜绝这种现象发生。（如需求不复杂，比如屏蔽、去掉某某功能，添加个文案这种的，改动极小的可以简单描述，但必须要有效果图，符合设计）

这里还要说明一种特殊情况，需求不一定必须是文档，可通过口头或简单纸搞的形式完成，前提是对应的 RD 和 QA 都理解清楚。

第二种问题，RD 提测前的测试用例评审环节必须邀请到 PM 和 RD 共同参加，如 PM、QA 发现 RD 设计有问题要当面提出，并且如果提测后，最好再和 RD 对下相关实现逻辑，这样 QA 能更好的了解 RD 设计，以便深入测试。

第三种对于紧急项目一般要简化流程，如果优先级最高的比如处理线上问题的话，基本上 RD 修改后 QA 根据修改点和RD 给出的风险点，代码 reivew（这两点非常重要）、测试列出测试点，然后立刻进行测试（功能、和单元、自动化测试相结合），测试没问题，RD 直接快速上线了，QA 再在线上灰度测试，确认没问题后就是全量上线。

以上就是今天给大家介绍的互联网测试流程。

声明：上述观点为个人经验总结和观察，如有不对的地方请随时指正或留言交流。

作者：小文（一个即将从业 10 年的软件测试行业工作者）