4.15 讲义：互联网开发/测试流程

首先简单地自我介绍一下~ （略）所以对于大公司、小公司的开发流程都比较了解。

今天我会先把整个开发流程讲一遍~ 看到报名的同学可能大部分都是对测试感兴趣，会多讲一些测试的东西。我会尽量多加入一些例子，有些网上找不到合适的图，用了自己公司的资料（打了马赛克），麻烦大家不要外传：）之后如果有时间的话再回答大家的问题~

下面我们开始吧：

从提出需求到功能上线的整个流程，我画了一张图：

设计、开发、测试流程图

这张图主要是按大公司比较完整的流程来画的，实际上小团队很可能会省去其中的一些步骤，同时各个阶段所占的时间比例也不一样。

大公司以一个月发一版为例：需求阶段是在上一版的时候就做好的，顶多占用这一版一两天时间；设计阶段1周；开发阶段1.5周；测试阶段1.5周。测试所用的时间基本能达到跟开发所用的时间近似的水平。

小公司以两周发一版为例：就按996算吧：）一共12天。需求+设计最多占用一两天，开发就必须开始了，来不及出的图后面再陆续出，流水线一样地往下开发；开发8天；测试3天。实际上，由于开发 delay、临时加需求、上线时间又不能改等等原因，测试的时间可能被一再挤压，但我的建议是必须要守住一定的红线。

第一个阶段是需求阶段，主要是确定这个版本干什么。

大公司一般会有个需求池，高层的想法、用户的反馈、市场运营等提出的需求全都会放在这个池子里，然后每版开始的时候，各个小组的产品经理会从池子里挑出自己要做的需求，写出PRD（Product Requirements Document 产品需求文档）。然后产品会先开需求讨论会（撕逼大会），争论这些需求到底有没有必要做、流程设计上有哪些漏洞，最后由产品老大排出这一期要做的需求。

而小公司往往没有这些流程，需求由老板拍板；产品经理只是帮忙完善。

一定要在写需求的同时就写好数据统计的需求，想好如何衡量这个功能是否有效，定出关键数据的提升指标。比如，开发某红包活动，预期在某个入口的转化率提升70%，如何埋点测量每一步的转化率，上线后再 review 实际提升多少，等等。测量、记录这些关键指标的优化数据，不仅能积累经验，同时也能在 PM 的晋升答辩中起到非常重要的作用。

接下来由技术老大对需求进行评审，砍掉没有可行性、开发资源不够的需求，并且对设计过于复杂的需求从技术的角度提出建议。比如：

PM：我们要做个用户调研的平台，还要做一个像QQ一样的收集用户意见反馈的聊天工具，最后为了回馈用户还要做一个抽奖平台。

技术老大：没时间做。用户调研用问卷星、麦客之类的吧，收集用户意见你们自己加用户微信聊吧，或者加个美洽，抽奖就在微博上抽吧。

小公司可能由具体的程序员进行估时，比如具体每个功能点估到 1 天、1.5天，然后按照一个周期的开发天数，比如总共 8 天开发，来排下一版的需求。

第二个阶段是设计阶段。PM 完善PRD，然后交互设计师根据PRD画出 UE 图，UI 设计师根据 UE 图再画 UI 图。

一个典型的大公司的 PRD 是长这样的：

（图略）

而小公司的 PRD 比较简略，可以是这样的：

（图略）

可以只是一个简单的 checklist。

写好 PRD 非常重要。所有的设计、开发、测试，都是围绕着 PRD 为核心进行的；切记：一旦功能出了问题，很可能会根据 PRD 来追究责任。PRD 上写了，设计或开发没有做好，就是开发的责任；PRD 上没写，那就是 PM 的责任。

在小公司沟通比较方便，PRD 可以简单一些；大公司的 PRD 是要写得非常详尽的，一个小功能也基本要写 10 页，比较大的功能很可能要三四十页。上面贴过的那张截图列出了 PRD 的大纲，可以作为参考。

UE 设计师会根据 PRD 来画 UE 图。一个典型的 UE 图是长这样的：

UE 图示例

UE 图基本就是线框图。小公司如果没有专业的 UE 设计师，往往由 PM 来画这个图。UE 图不需要美观，流程清楚即可，同时文字标注非常重要。跳转方式、关键动效也在这一步定型，比如页面是从底部滑入还是右侧滑入，弹窗是淡入还是弹簧放大效果。

而 UI 图就是根据 UE 图进行视觉上的美化。成果跟我们在手机上、网站上看到的页面一样，加上标注：

UI 图示例

标注要标出字体、颜色、间距、行距、圆角等。小公司的设计师可能来不及标注，需要程序员自己用马克鳗等工具测量。如果没时间标注的话，在此推荐一下 mac 的 sketch 工具，画好的图可以直接发给程序员，测量间距比马克鳗更方便。

第三个阶段是开发阶段。app端、web端、后端的程序员先分别写代码，再进行联调。大公司由开发 team leader、小公司往往由产品经理控制开发进度。而与此同时，负责测试的同事应该开始写测试用例了。

测试用例简单来说就是，描述在什么条件下，进行什么操作，预期得到什么结果。如下图：

测试用例示例

对于复杂的业务流程，比如付款退款、分享抽奖、点评领红包这一类的业务，写好 case 非常重要。QA新到一个公司，了解业务很好的方式就是看过去的 case。Case 应该要覆盖所有的主流程，以及主要的失败流程。不过像加载动画、网络错误提示这种细节，是没法完全覆盖到的。

第四个阶段是测试阶段。测试不只是QA的事，在一个好的团队里，在这个阶段所有人都需要出动。设计师要做 UI 走查，产品经理要测试功能流程、用户体验，QA要跑测试用例。开发也要投入测试，修改 bug。

UI 走查主要是把做好的 app、网站进行截图，然后跟最初的设计图进行对比。手头找不到例子了，大概就是检查一下颜色、间距什么的做得对不对。不对的，或者视觉效果不好的，要让程序员进行微调。

因为看到群里对测试感兴趣的同学比较多，我们下面多讲一些测试的内容。假如我们新上了一个点评领红包的功能，QA 应该做哪些测试呢？

1. 跑 case。上面说了，case 应该在开发的时候就写好。大公司都有自己的case管理工具，QA 要做的就是一个一个执行 case，记录是否通过，没通过的提交 bug。
   在这一步，我们要覆盖到提交点评、之后领红包、查看点评、修改自己的点评这些主流程，以及未登录不能点评、未点评不能领红包、红包过期等主要的失败流程。

2. 检查边界情况。有些边界情况是 case 里不会写得那么细，但是有经验的 QA 一定会注意检查。几个常见的问题：
   空字段：比如在显示折扣时，后端返回的是没有折扣，app 端是否能正确显示；
   流程中断：用户在点评的过程中选择返回，或者锁屏、按Home键等，此后该如何继续点评；
   异常流程：网络不好时，应该显示的加载动画、placeholder，网络错误是否会提示；各种内部、外部系统错误，比如银联的接口出问题了，应该如何提示用户；
   极端操作：页面快速上下滚动是否会 crash，连续点击是否会造成数据的不一致。

3. 兼容测试。各个系统版本、机型是否兼容。
   对于网站的页面，一般要支持几种主流浏览器，要支持页面缩放比例 80%~400% 不错乱等。
   对于 app，在 iOS 上一般要支持 3 个版本的系统，比如现在最新是 iOS 9，就要支持 7、8、9；等 iOS 10 出了，可以放弃支持 iOS 7。iPhone 各种屏幕一般都要支持，4s、5、6、6 plus。在 Android 上小公司一般要支持4.x以上的系统，大公司有些还要支持 2.x 的系统。各种主流机型如魅族、华为、oppo、小米、锤子都要支持。
   每个机型都过一遍，工作量是非常大的，在实际操作中也比较难以做到。但是这确实是很容易出问题的一环。从过往经验来看，我的建议是：各个屏幕尺寸下的各个界面都要看一遍，必不可少；发版之前，Android 最好能在几个主流品牌的手机上把主流程过一遍。

4. 对于 app 客户端还有另一种测试，应该也属于兼容测试，就是新、老版本的兼容。因为 app 如何更新，总有一些用户就是不升级。没办法，我们要保证这部分用户也基本能使用。
   后端接口如果是改动、不升级的话，我们就要考虑老用户是否会受影响，比如：产品描述里增加了促销的信息，老版本的 app 留的空够不够，能否完整显示？
   后端接口如果升级的话，我们要测试新、老两个版本的接口是不是都能正常维护。比如：feed 流接口升级了，那老版本用户还能看到新内容吗？会不会每天打开都没变化？这样用户很快就流失了。
   这种测试一般是在新版后端部署上线之后，用两个手机分别装新、老版本，一起测试。

5. 压力测试。压力测试都是针对接口来做的，与具体的 app、网页无关。压力测试很有用，不过并非所有的接口都有资源来做压力测试。我之前的经验是，像退款这种使用频率较低的接口，有时就不做压力测试了；像领红包这种功能，基本一定要做压力测试。
   压力测试有专用的工具，模拟短时间内大量请求，还能验证结果是否正确。

6. 回归测试。
   我们测出 bug 之后，并不是告诉开发一声就算使命完成了。大公司一般都有自己的 bug 管理工具，上面有bug的几种状态，还能指派对应的负责人。
   先简单科普一下 bug 的几种常见状态：open - 等待修复 fixed - 已修复 not repo - 重现不了 won't fix 或 by design - 设计就是如此，或者很不好修复，就不改了 closed - bug 的生命周期结束。
   修 bug 的流程一般是这样的：
   QA 建立 bug，状态为 open，指派给开发 -> 被指派的开发如果自己修复不了，再指派给别的开发 -> 能修复的开发把 bug 状态改为 fixed，当然也可能是 won't fix 等，之后指派给 QA -> QA 针对每个 bug 进行所谓的『回归』，也就是验证改对了没有，如果改对了，bug 状态改为 closed。

7. 最后一站，回归老功能。这也是回归测试的一种，这一步一般是在 app 发版之前进行。
   因为程序员写新功能的时候，其实很容易把老功能一不小心改坏了。所以这一步是必须要做的。不过，如果每次发版都把所有的老功能都测一遍，也不太现实。一般还是把主要流程过一遍。比如如果是淘宝客户端，就把下单购物的流程过一遍；知乎客户端，就把提问回答的流程过一遍等。再发动程序员一起来测测，就差不多了。

好啦，一个新功能的设计、开发、测试流程终于讲完了~ 下面回答几个同学之前提的问题吧：

产品经理和程序员怎么沟通

我想从程序员的角度为 PM 提几点建议，怎样做一个让程序员爱戴的产品经理：

1. 不随意变更需求。经常遇到这样的情况：产品做出来了，PM 突然发现某个流程有问题，比如新手引导忘了做了；或者收到上级的压力，比如『促销活动的提示不够强，给我做推送！弹窗！红点提醒！』。需要变更、增加需求的情况是难免的。
   然而此时一定要切记，正确的需求变更流程是：让开发、测试估时 -> 申请上线延期，或砍掉未做的功能，或者延期到下一版做。而不是：『哎呀这个能花多少时间，你就随手帮我改一下不行么~』
   其实这一点就是程序员恨 PM 的最主要原因：）
2. 跟程序员沟通时语气保持平静，就事论事。程序员喜欢别人一句话描述问题，比如『这个页面的标题文本显示不全』。不喜欢的行为包括：
   语气夸张：『哎？哎？？这个地方怎么这样？』『你看这里，「啪塔」跳动一下，你看，你看』；
   语气指责：『怎么推送总是有问题？』『这么简单的一个功能做多少天了？』
   站在程序员旁边不走，要看着他改。
3. 一起背锅。PM 一定要参与测试，与开发、QA一起为质量负责。而不要出了问题说：『我不是这么设计的呀？是他们理解不对/做的不对』。

能做到这些就已经很好啦~ 程序员也不会要求太高的。

好测试的评判标准是什么

1. 初级的测试就是像用户一样，在手机、网页上点点点。做到细心、沟通能力好就不错了。
2. 有经验的测试会利用各种开发工具，如压力测试、配置环境等。到这一步，最好能学一点简单的开发。
3. 再高一级的开发会编写自动化测试，以及各种测试脚本。这也就是所谓的『测试开发』，现在这种人才还是比较难得的。
4. 测试的老大是为产品质量整体负责的人。他们不仅知道怎么管理手下的测试工程师，同时对业务和系统架构的了解非常深，不亚于开发老大。