产品经理如何做测试?

本文不是教产品经理如何转行做测试,而是在团队没有测试人员的情况下,如何快速承担起测试的工作,以下是正文:

大公司有明确的职位分工:工程师、测试、设计、运营都由不同的人负责,测试自然就是测试工程师的事,而在中小型创业公司,人员匮乏,很多团队只有工程师和产品经理,工程师负责开发,开发以外的事情全都由产品经理承包,这其中自然包括测试。测试是产品上线前的质量检验,只有通过测试,产品才能放心的呈现到用户面前,本文就详细说说,产品经理该如何做测试。

我们不探讨测试究竟分多少种,每种类型又是如何定义,产品经理的测试任务基本只涉及一种:功能测试,测试的内容就是:工程师实现的产品,和 PM 最初定义的产品是否一致,如果一致,则测试通过,如果不一致,则测试不通过。

需求文档——测试的基础

需求文档定义了产品要实现的功能和具体的细节,工程师依据它进行开发,测试当然要依据相同的标准进行测试,如果缺少需求文档,测试就没了依据,就很难往下进行。比如有以下需求文档:

XX 博客系统发布文章页需求清单

  1. 文章标题为必填,最长 80 个字符,支持中英文和特殊符号,超出时即时提示 “标题不能超出 80 个字符”(原型见附件)
  2. 文章内容为选填,最长 8000 个字符,支持中英文和特殊符号,超出时即时提示 “文章内容不能超出 8000 个字符”

进行测试时,除了要考虑产品的常规使用流程,还要重点考虑产品中的边界问题,比如以上例子中标题和内容的字数限制。

测试用例

了解清楚需求之后就要设计测试用例了,测试用例就是一个个用户实际的使用场景,要求有设定好的输入条件和预期结果,比如针对上面的文章发布页设计以下用例:

编号 标题 内容 预期结果 测试结果
1 “测试标题” “测试内容” 无错误提示,正常发布文章
2 “测试标题” 无错误提示,正常发布文章
3 80个字符的标题 8000 个字符的内容 无错误提示,正常发布文章
4 错误提示,不能正常发布文章

上面的 4 个用例覆盖了常见的用户场景,如果实际测试结果符合预期,产品基本上是合格的,但不要忘记一些隐藏的陷阱:

  1. 标题或文章内容包含 html 标签等特殊字符时,系统能否正确保存?
  2. 文章内容为富文本编辑器,如果录入的有 8000 个字符,插入图片、添加格式后是否还能保存成功?

根据需求文档可以定义大多数情况的测试用例,还有很多特殊情况的用例,需要经验的积累来完善。还有一些特殊情况只有实际遇到才会想到,这时就需要把这种场景及时补充到用例中。

回归测试

在产品的正常迭代中,一般是新开发了什么功能,就重点测试什么功能,但也经常会遇到这种情况:这次项目的目的是开发 A 功能,但是在开发 A 功能的过程中导致了 B 模块出现了 bug,这就需要将和 A 功能相关的所有模块再测试一遍——即使之前这些模块都是测试通过的,这就是回归测试。在测试相对复杂系统的时候,测试的工作量会大很多,之前做过的用例还要重复测试一遍,这样测试的很大部分就变成了体力活。

如何避免重复劳动呢? 答案就是讲重复劳动交给程序来实现,这就是自动化测试。

自动化测试

自动化测试通过写程序的方式,把人在重复劳动中解脱出来。前文中提到的 4 种测试用例,假设每次程序有改动都要再测一遍,那么我就可以把预设的表单内容写在测试脚本中,通过指定元素的内容来判断是否符合预期,写好脚本后,测试框架会帮你自动完成那些操作。甚至可以自动生成测试报告。这些操作需要一定的编程基础,如果有困难,可以找工程师帮忙。自动化测试工具笔者目前只使用过 Selenium,大大解放过我的生产力。

测试报告

测试结束后,要将测试结果发布出来,让团队内所有人了解产品目前的状态,同时将 bug 分级,为它们排优先级,将修正 bug 的工作排到接下来的工作计划中。

功能测试是合格产品经理的必备素质,要求能够撰写完整的测试用例并实践,完成测试报告并敦促工程师团队改进产品,在这个过程中不断打磨改进产品,测试只是手段,打造用户喜爱的产品才是目的。