首先简单地自我介绍一下~ (略)所以对于大公司、小公司的开发流程都比较了解。
今天我会先把整个开发流程讲一遍~ 看到报名的同学可能大部分都是对测试感兴趣,会多讲一些测试的东西。我会尽量多加入一些例子,有些网上找不到合适的图,用了自己公司的资料(打了马赛克),麻烦大家不要外传:)之后如果有时间的话再回答大家的问题~
下面我们开始吧:
从提出需求到功能上线的整个流程,我画了一张图:
这张图主要是按大公司比较完整的流程来画的,实际上小团队很可能会省去其中的一些步骤,同时各个阶段所占的时间比例也不一样。
大公司以一个月发一版为例:需求阶段是在上一版的时候就做好的,顶多占用这一版一两天时间;设计阶段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 设计师,往往由 PM 来画这个图。UE 图不需要美观,流程清楚即可,同时文字标注非常重要。跳转方式、关键动效也在这一步定型,比如页面是从底部滑入还是右侧滑入,弹窗是淡入还是弹簧放大效果。
而 UI 图就是根据 UE 图进行视觉上的美化。成果跟我们在手机上、网站上看到的页面一样,加上标注:
标注要标出字体、颜色、间距、行距、圆角等。小公司的设计师可能来不及标注,需要程序员自己用马克鳗等工具测量。如果没时间标注的话,在此推荐一下 mac 的 sketch 工具,画好的图可以直接发给程序员,测量间距比马克鳗更方便。
第三个阶段是开发阶段。app端、web端、后端的程序员先分别写代码,再进行联调。大公司由开发 team leader、小公司往往由产品经理控制开发进度。而与此同时,负责测试的同事应该开始写测试用例了。
测试用例简单来说就是,描述在什么条件下,进行什么操作,预期得到什么结果。如下图:
对于复杂的业务流程,比如付款退款、分享抽奖、点评领红包这一类的业务,写好 case 非常重要。QA新到一个公司,了解业务很好的方式就是看过去的 case。Case 应该要覆盖所有的主流程,以及主要的失败流程。不过像加载动画、网络错误提示这种细节,是没法完全覆盖到的。
第四个阶段是测试阶段。测试不只是QA的事,在一个好的团队里,在这个阶段所有人都需要出动。设计师要做 UI 走查,产品经理要测试功能流程、用户体验,QA要跑测试用例。开发也要投入测试,修改 bug。
UI 走查主要是把做好的 app、网站进行截图,然后跟最初的设计图进行对比。手头找不到例子了,大概就是检查一下颜色、间距什么的做得对不对。不对的,或者视觉效果不好的,要让程序员进行微调。
因为看到群里对测试感兴趣的同学比较多,我们下面多讲一些测试的内容。假如我们新上了一个点评领红包的功能,QA 应该做哪些测试呢?
跑 case。上面说了,case 应该在开发的时候就写好。大公司都有自己的case管理工具,QA 要做的就是一个一个执行 case,记录是否通过,没通过的提交 bug。
在这一步,我们要覆盖到提交点评、之后领红包、查看点评、修改自己的点评这些主流程,以及未登录不能点评、未点评不能领红包、红包过期等主要的失败流程。检查边界情况。有些边界情况是 case 里不会写得那么细,但是有经验的 QA 一定会注意检查。几个常见的问题:
空字段:比如在显示折扣时,后端返回的是没有折扣,app 端是否能正确显示;
流程中断:用户在点评的过程中选择返回,或者锁屏、按Home键等,此后该如何继续点评;
异常流程:网络不好时,应该显示的加载动画、placeholder,网络错误是否会提示;各种内部、外部系统错误,比如银联的接口出问题了,应该如何提示用户;
极端操作:页面快速上下滚动是否会 crash,连续点击是否会造成数据的不一致。兼容测试。各个系统版本、机型是否兼容。
对于网站的页面,一般要支持几种主流浏览器,要支持页面缩放比例 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 最好能在几个主流品牌的手机上把主流程过一遍。对于 app 客户端还有另一种测试,应该也属于兼容测试,就是新、老版本的兼容。因为 app 如何更新,总有一些用户就是不升级。没办法,我们要保证这部分用户也基本能使用。
后端接口如果是改动、不升级的话,我们就要考虑老用户是否会受影响,比如:产品描述里增加了促销的信息,老版本的 app 留的空够不够,能否完整显示?
后端接口如果升级的话,我们要测试新、老两个版本的接口是不是都能正常维护。比如:feed 流接口升级了,那老版本用户还能看到新内容吗?会不会每天打开都没变化?这样用户很快就流失了。
这种测试一般是在新版后端部署上线之后,用两个手机分别装新、老版本,一起测试。压力测试。压力测试都是针对接口来做的,与具体的 app、网页无关。压力测试很有用,不过并非所有的接口都有资源来做压力测试。我之前的经验是,像退款这种使用频率较低的接口,有时就不做压力测试了;像领红包这种功能,基本一定要做压力测试。
压力测试有专用的工具,模拟短时间内大量请求,还能验证结果是否正确。回归测试。
我们测出 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。最后一站,回归老功能。这也是回归测试的一种,这一步一般是在 app 发版之前进行。
因为程序员写新功能的时候,其实很容易把老功能一不小心改坏了。所以这一步是必须要做的。不过,如果每次发版都把所有的老功能都测一遍,也不太现实。一般还是把主要流程过一遍。比如如果是淘宝客户端,就把下单购物的流程过一遍;知乎客户端,就把提问回答的流程过一遍等。再发动程序员一起来测测,就差不多了。
好啦,一个新功能的设计、开发、测试流程终于讲完了~ 下面回答几个同学之前提的问题吧:
产品经理和程序员怎么沟通
我想从程序员的角度为 PM 提几点建议,怎样做一个让程序员爱戴的产品经理:
- 不随意变更需求。经常遇到这样的情况:产品做出来了,PM 突然发现某个流程有问题,比如新手引导忘了做了;或者收到上级的压力,比如『促销活动的提示不够强,给我做推送!弹窗!红点提醒!』。需要变更、增加需求的情况是难免的。
然而此时一定要切记,正确的需求变更流程是:让开发、测试估时 -> 申请上线延期,或砍掉未做的功能,或者延期到下一版做。而不是:『哎呀这个能花多少时间,你就随手帮我改一下不行么~』
其实这一点就是程序员恨 PM 的最主要原因:) - 跟程序员沟通时语气保持平静,就事论事。程序员喜欢别人一句话描述问题,比如『这个页面的标题文本显示不全』。不喜欢的行为包括:
语气夸张:『哎?哎??这个地方怎么这样?』『你看这里,「啪塔」跳动一下,你看,你看』;
语气指责:『怎么推送总是有问题?』『这么简单的一个功能做多少天了?』
站在程序员旁边不走,要看着他改。 - 一起背锅。PM 一定要参与测试,与开发、QA一起为质量负责。而不要出了问题说:『我不是这么设计的呀?是他们理解不对/做的不对』。
能做到这些就已经很好啦~ 程序员也不会要求太高的。
好测试的评判标准是什么
- 初级的测试就是像用户一样,在手机、网页上点点点。做到细心、沟通能力好就不错了。
- 有经验的测试会利用各种开发工具,如压力测试、配置环境等。到这一步,最好能学一点简单的开发。
- 再高一级的开发会编写自动化测试,以及各种测试脚本。这也就是所谓的『测试开发』,现在这种人才还是比较难得的。
- 测试的老大是为产品质量整体负责的人。他们不仅知道怎么管理手下的测试工程师,同时对业务和系统架构的了解非常深,不亚于开发老大。