小明与老王的日常学会做这件事让你的产品提前上线

　　《老王与小明的日常》系列马上就要收尾了。而这篇文章，会介绍如何进行产品测试，同时也是本系列的一个总结。
　　太多的产品新人，甚至于工作一两年的产品汪，在开发阶段往往出现很多对接问题，影响上线进度。在此，我将程序开发阶段总结为一下4个阶段，并以故事的形式，分流程介绍我们该如何与开发对接。因内容较多，且需要与实际工作结合进行考虑，所以建议大家收藏下来，慢慢看。
　　下图为此系列内容的大纲：
　　（此系列内容的大纲）
　　今天我们说说第4部分，产品测试。如果没有看过前三篇文章的同学， 请点击下面的传送门：
　　《小明与老王的日常：学会做这4件事，让你的产品提前上线（1）》
　　《小明与老王的日常：学会做这4件事，让你的产品提前上线（2）》
　　《小明与老王的日常：学会做这4件事，让你的产品提前上线（3）》
　　产品测试在很多公司，都会有专门的部门进行负责。而此篇文章主要介绍的是在没有测试人员的情况下，产品经理如何兼任测试岗位，进行产品测试。文章主要包含三部分：
　　确定测试介入时间
　　在瀑布流开发过程中，通常在开发完成后才进行产品测试。这时候，测试人员拿到的版本通常是经过程序猿初步测试的版本。
　　优势：开发与测试的时间节点可控，且测试前有充足的时间进行测试准备工作。
　　劣势：劣势非常明显，会大大延长了产品上线时间。
　　而在现阶段大部门的互联网公司中，大家通常将开发的功能按模块划分好，并确定模块的开发顺序（具体可以查看第2篇文章）。当完成某个模块的开发，便对该模块进行单元测试。这时候测试人员拿到的版本通常是一个产品雏形。
　　优势：
　　可以将减少一部分产品测试的时间。
　　时刻跟进产品开发方向，避免程序猿开发出来的东西不是原先想要的产品。
　　缺点：
　　对程序猿能力要求较高，需要确保每个模块开发出来的主流程必须是可用于测试的。
　　增加了产品在开发阶段的工作量。（如果公司没有安排测试人员的话）
　　以上的两种方式，我更倾向于第2种，并且在自己日常工作中，也采用第2种方式。可大大缩短项目的开发周期。每个模块测试一遍，上线前再完整测试一遍，基本上不会出现太大问题。当然了，每种方式均不是完美的，这需要产品经理根据项目的不同，进行选择。
　　测试前的准备工作
　　在确定了介入时间之后，接下来我们就要做测试前的准备，测试前的需要准备的东西通常包括：测试用例、测试人员、测试环境（系统、浏览器等）
　　测试用例：测试人员为测试某一个功能是否满足既定的要求，而编写的一组测试输入、执行与结果展现的标准文档。目的是为了让测试更加标准。通常情况下，一份详细的PRD文档也可以用来做测试用例，不需要在编写测试用例上花费时间。
　　测试人员：大公司都有专门的测试部门用来进行产品测试工作。小公司的大多数都交给产品经理或产品助理来完成，在这个时候，我们就要协调好测试人员，保证在测试阶段，有专人负责。当然在产品经理亲自上阵的时候，也需要考虑到自己的手头工作，做好工作安排。
　　测试环境：App测试的环境主要是各种手机系统与系统版本，web主要是各种浏览器。Pc软件主要是操作系统。所以在进行测试前，需要将这些必要的环境搭建好
　　测试准备阶段，根据产品的性质不同，可能还需要准备不同身份的测试账号、材料（阅卷系统的答题卡）等物品。在此推荐大家在准备阶段，列举一个测试准备清单，并在测试前反复确认，保证测试工作的正常进行。
　　随手画的一个清单，不一定适用于大家所有的项目，仅提供参考。
　　测试报告产出
　　在测试过程中，我们需要将发现的bug记录在测试报告中，而为了方便程序猿们的查看，我们的测试报告需要包含以下几个要素：
　　严重程度：严重主要描述bug可能造成的影响，我们通常将严重程度分为4级。1为最强、4为最弱。具体的划分1为主流程bug；2为辅助流程bug；3为交互bug；4为样式bug。方便项目经理安排bug修复的任务。
　　修改优先级：优先级主要是为了方便指导程序猿的bug修改顺序。通常我们将bug修改为3级。1代表紧急bug，需要立即修改。2代表需要上线前修改完成的bug。3代表可放在上线后进行修改的bug。
　　Bug内容：主要用来描述产品bug的内容，例如＂点击登录按钮无反应＂。问题不宜长篇大论，突出重点就可以。
　　重现步骤：标注好问题重现步骤，方便程序猿快速找出问题的原因。对上述的bug内容我们可以这样描述＂将浏览器内核设置为为ie9，进行账号登录，点击登录按钮无反应＂。
　　需求描述：主要描述bug需要修改成什么样子，方便程序猿制定修改方案。例如＂登录功能需要兼容ie9内核＂。结果描述要有具体的结果，不宜模棱两可。
　　注：在一部分情况下，我们会将bug内容、重现步骤、结果描述写在一起，统一叫做bug内容。
　　修改人、修改情况、备注说明
　　明确bug的修改人，修改情况与备注，可方便我们对bug修改过程进行跟踪。通常修改人由项目经理进行分配。修改情况与备注由程序猿记性填写，最终需要测试人员进行确认。
　　当1份报告需要多个用户同时查看，excel无法实现多用户同时在线编辑的弊端就非常明显了。这时候如果有一款专门的协同开发工具是不是更好？
　　关于产品测试阶段，就介绍这么多了，下面主要会将《老王与小明的日常》这个系列做一个总结。
　　系列总结
　　老规矩，先把图亮出来，下面这张图就是此系列文章的大纲：
　　下面这些都是此系列文章的重点总结，有疑问的小伙伴可以参考对应的文章进行查看。
　　需求传达阶段
　　传达项目背景，让程序猿认为他们是在做一款改变世界的产品。
　　有节奏的介绍需求，当然了，这里的节奏不是＂啪啪啪＂的节奏，而是要分清介绍的主次
　　确定关键性目标，让程序猿对开发结果有个明确的目标。
　　制定开发进度与关键节点阶段
　　给足程序猿评估项目周期的时间，目的是让程序猿充分了解需求，需求了解后，评估时间自然而然就出来了。
　　适当的接受程序猿的建议，需要砍需求的时候，不要犹豫。
　　确定开发顺序，为后期开发跟进与测试打好基础。
　　明确关键时间节点，为项目管理提供依据。
　　跟进开发阶段
　　模块开发前，做好相应模块的需求变更与需求确认。
　　明确站立会与周例会的工作职责。
　　做好支持与协调工作，为开发摆平一切困难
　　产品测试阶段
　　确定好测试的介入时间
　　用清单的形式，做好测试准备工作
　　提交切实可用的测试报告。
　　感谢
　　一周多的时间将此系列写完，时间确实有点紧。导致了每篇文章中都有很多地方表达不是很清楚，所以在此非常感谢小伙伴们的支持。希望这4篇文章对您的工作有一定的帮助。
　　相关阅读
　　《小明与老王的日常：学会做这4件事，让你的产品提前上线（1）》
　　《小明与老王的日常：学会做这4件事，让你的产品提前上线（2）》
　　《小明与老王的日常：学会做这4件事，让你的产品提前上线（3）》