本节书摘来自华章出版社《移动App测试实战》一 书中的第1章，第1.1节，作者：邱鹏　陈吉　潘晓明，更多章节内容可以访问云栖社区“华章计算机”公众号查看。

1.1　互联网产品常见的研发流程

对于每个研发组织，因为产品的特性、组织的特点和一些历史原因，对于产品研发流程的理解和设定都有不同的考虑。但是以我们工作过的几家互联网来说，因为互联网产品的一些共同点，大致的产品研发流程其实大同小异，或者是做类似的事情但叫法不同。考虑到本书的读者可能当前的工作范围不一定是互联网产品，或者还没有机会了解整个研发流程，这里先做一些基本的介绍，也便于后面章节关于质量提升方面的讨论。
为了了解流程，首先需要介绍一下互联网产品研发相关的分工，主要的角色如下：
产品经理。负责产品方向和具体需求的规划，需求文档的编写。是待开发需求的提出方，或者代理方（来自业务部门等第三方的需求，由产品经理转化成研发团队的需求形式）。通常对于较大规模的产品，产品经理是一个团队，每个人分工负责部分功能模块的需求细节。
项目经理（以下简称PM）。负责项目的立项和时间安排，并跟进项目研发的进展、变更和风险，以及各种跨团队的协调工作。在一个大的项目中，通常也会有多位项目经理分工协作。
设计师。负责产品的交互设计、视觉设计等方面。主要的产出是产品的交互原型和设计稿。
开发人员。负责产品的技术架构设计和代码编写，产出是可运行的实际产品。通常根据专业领域也进一步划分为架构师、后台开发、Web前端开发、Android开发、iOS开发等多个岗位。
测试人员。负责产品的质量把关，包括功能、性能和稳定性等多方面的测试内容。进一步细分包括业务功能测试、测试工具和平台开发、专项技术测试等岗位。部分组织里面也将质量管理放在测试团队。
运维人员。负责产品的服务端运行环境的建设和维护，以及日常的配置管理、容量规划、网络和设备故障处理等工作，常常也包含监控平台的建设和管理。取决于研发组织是采用自建IDC，租用IDC或者采用第三方云计算平台，运维团队的工作可能有所不同。
运营人员。负责业务和产品的推广和拓展。对于移动互联网产品，常见的工作范围包括App的推广，各类运营活动的规划和推动，同第三方一起开展的市场活动，以及运营平台的规划等方面。
在前面各个角色分工的基础上，图1-1展示了一个基于研发阶段和角色分工的流程图。也是在互联网研发中比较常见的一个流程，可以看出每个阶段要做的主要工作，以及对应角色在该阶段的产出物。
图1-2给出了一个以主要研发活动为线索的流程图，从中可以看出各个参与角色对应的研发活动的衔接。比如在需求评审完之后PM组织大家排期；开发自测完成之后交给产品经理体验；测试完成并发布测试报告，以及发布策略确定后进行发布上线。

为了适应互联网快速迭代的节奏，整个流量相对比较轻量。以上流程描述的是单个需求的处理过程，实际中，对于同一个App或者后台版本，一般是有多个需求并行的，而且不同版本的需求是有交叉重叠的。在一个版本研发的后期，通常会进行下一个版本需求的讨论和评审。
在本章的后续部分，以及后面关于质量管理和推动的章节，会对其中的多项重要流程实践做进一步深入的讲解。在这里我们讨论需求评审和技术方案评审。需求评审是一个比较常见的研发流程实践，但是实际上大部分人还是低估了其价值，执行的过程中也做得不够充分。对于互联网产品快速迭代的节奏，固然需求评审会花去一些宝贵的时间，但是事后来看，无论正面的案例还是反面的案例，这个时间花得还是非常值得的，正所谓磨刀不误砍柴功。需求评审，特别是现场会议形式的评审，是一个非常难得的多方沟通的机会。多个角色可以统一对需求的理解，有疑问的地方可以及时讨论。
从测试人员的角度，需求评审的价值主要在以下几个方面：
充分理解需求，为后续的测试用例编写打下基础。
基于对需求细节的了解，可以更准确地评估测试的要点和工作量。
发现需求中模糊不清的地方。从质量管理的角度，这也是一个非常好的缺陷预防的方法。
为了现场评审有更好的效果，并提高评审的效率，建议评审组织者在评审会召开之前将需求文档提前发给评审专家进行预审，在预审结束之前评审专家预先将发现的问题发给评审组织者，这样可以在会上针对问题进行评审，使评审更充分、更有效，否则需求评审会有可能会演变成一个需求讲解会，从而达不到预想的效果。
除了需求评审，对于一些偏技术性的需求，或者一个全新开发的功能，很有必要做技术方案方面的评审。请对应的开发人员来讲解一下准备采用的技术方案。一方面可以请其他资深的开发人员帮助评审，另一方面从测试人员的角度，了解基本的技术实现也有助于设计测试用例，并提前为可测性做一些准备。
下面这个例子可以帮助我们理解技术方案评审的价值。下面是一个偏技术类需求的例子，是一个自行开发的App端的SDK，用于将App遇到的一些异常问题汇总上报，包括crash和各种错误，其他运营类数据的上报也是类似的逻辑。在第8章关于监控埋点的部分也会做相关的介绍。
图1-3是针对这个需求的一些测试用例。
从以上用例可以看出，如果不了解一些技术实现的细节，很多测试场景根本无法覆盖，比如：
未上报的临时数据是通过本地数据库来存储，就会有相关的测试场景。其中数据库文件大小需要有一个上限，这个其实也是评审过程中测试提出来的，避免在一些极端情况下占用过多的存储空间。

上报进程是基于接口下发的策略来控制上报逻辑的。这个部分也会引起一系列可能出现的问题。
对于一些可能遇到的异常情况，设计上是如何考虑的，这些其实在技术方案评审的时候就可以考虑到。
类似的例子很多，对于一个全新的功能也是如此，不同的开发人员会有不同的设计上的考虑，哪些逻辑放在App端？哪些放在后台？同步的机制如何做？有哪些新增的接口？这些都是技术方案上的考虑，不同的设计会带来不同的测试场景和测试点。
不覆盖这些场景就会有很多质量问题的死角，而这些都是App性能和安全性的隐患。
关于流程，我们的观点会更偏向实用主义，并不在乎是否是纯粹或者经典的某种模式。比如上面的技术方案评审，也是来自于项目运作中实际的需求，讨论下来觉得部分功能有必要开展就加到流程里面。
另外在工作中我们发现一个特点，在我们了解的几个大的互联网公司里面，不太经常谈敏捷概念，而更多是根据业务运作的特点，以及团队不断的磨合，整理出一套相对有一定适应性的流程。
另外，还有一个观点，对于一个用户量很大的网站或者App，当版本有大量的需求迭代，比较频繁地来做发布（网站更明显），每个需求的开发周期比较短，同时又是多个角色大量的人员合作，经历了几个版本，一段时间以后，大家就逐渐磨合出了一套适应这个需求的流程，并在过程中不断优化调整。所以，所谓的互联网的做法也并不是因为它比传统的软件流程先进，而是它更适互联网产品的运作方式而已，本质上还是产品形态和需求驱动的。