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

APP

起点课堂会员权益

职业体系课特权

线下行业大会特权

个人IP打造特权

30+门专项技能课

1300+专题课程

12场职场软技能直播

12场求职辅导直播

12场专业技能直播

会员专属社群

荣耀标识

发布

jason

2017-09-21

6 评论 7366 浏览 65 收藏

11 分钟

《老王与小明的日常》系列马上就要收尾了。而这篇文章，会介绍如何进行产品测试，同时也是本系列的一个总结。

太多的产品新人，甚至于工作一两年的产品汪，在开发阶段往往出现很多对接问题，影响上线进度。在此，我将程序开发阶段总结为一下4个阶段，并以故事的形式，分流程介绍我们该如何与开发对接。因内容较多，且需要与实际工作结合进行考虑，所以建议大家收藏下来，慢慢看。

下图为此系列内容的大纲：

（此系列内容的大纲）

今天我们说说第4部分，产品测试。如果没有看过前三篇文章的同学，请点击下面的传送门：

产品测试在很多公司，都会有专门的部门进行负责。而此篇文章主要介绍的是在没有测试人员的情况下，产品经理如何兼任测试岗位，进行产品测试。文章主要包含三部分：

确定测试介入时间

在瀑布流开发过程中，通常在开发完成后才进行产品测试。这时候，测试人员拿到的版本通常是经过程序猿初步测试的版本。

而在现阶段大部门的互联网公司中，大家通常将开发的功能按模块划分好，并确定模块的开发顺序（具体可以查看第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修改过程进行跟踪。通常修改人由项目经理进行分配。修改情况与备注由程序猿记性填写，最终需要测试人员进行确认。