本文不是教产品经理如何转行做测试，而是在团队没有测试人员的情况下，如何快速承担起测试的工作，以下是正文：
大公司有明确的职位分工：工程师、测试、设计、运营都由不同的人负责，测试自然就是测试工程师的事，而在中小型创业公司，人员匮乏，很多团队只有工程师和产品经理，工程师负责开发，开发以外的事情全都由产品经理承包，这其中自然包括测试。测试是产品上线前的质量检验，只有通过测试，产品才能放心的呈现到用户面前，本文就详细说说，产品经理该如何做测试。
我们不探讨测试究竟分多少种，每种类型又是如何定义，产品经理的测试任务基本只涉及一种：功能测试，测试的内容就是：工程师实现的产品，和 PM 最初定义的产品是否一致，如果一致，则测试通过，如果不一致，则测试不通过。
需求文档——测试的基础
需求文档定义了产品要实现的功能和具体的细节，工程师依据它进行开发，测试当然要依据相同的标准进行测试，如果缺少需求文档，测试就没了依据，就很难往下进行。比如有以下需求文档：
XX 博客系统发布文章页需求清单
- 文章标题为必填，最长 80 个字符，支持中英文和特殊符号，超出时即时提示 “标题不能超出 80 个字符”（原型见附件）
- 文章内容为选填，最长 8000 个字符，支持中英文和特殊符号，超出时即时提示 “文章内容不能超出 8000 个字符”
- ...
进行测试时，除了要考虑产品的常规使用流程，还要重点考虑产品中的边界问题，比如以上例子中标题和内容的字数限制。
测试用例
了解清楚需求之后就要设计测试用例了，测试用例就是一个个用户实际的使用场景，要求有设定好的输入条件和预期结果，比如针对上面的文章发布页设计以下用例：
| 编号 | 标题 | 内容 | 预期结果 | 测试结果 |
|---|---|---|---|---|
| 1 | “测试标题” | “测试内容” | 无错误提示，正常发布文章 | |
| 2 | “测试标题” | 空 | 无错误提示，正常发布文章 | |
| 3 | 80个字符的标题 | 8000 个字符的内容 | 无错误提示，正常发布文章 | |
| 4 | 空 | 空 | 错误提示，不能正常发布文章 |
上面的 4 个用例覆盖了常见的用户场景，如果实际测试结果符合预期，产品基本上是合格的，但不要忘记一些隐藏的陷阱：
- 标题或文章内容包含 html 标签等特殊字符时，系统能否正确保存？
- 文章内容为富文本编辑器，如果录入的有 8000 个字符，插入图片、添加格式后是否还能保存成功？
- ...
根据需求文档可以定义大多数情况的测试用例，还有很多特殊情况的用例，需要经验的积累来完善。还有一些特殊情况只有实际遇到才会想到，这时就需要把这种场景及时补充到用例中。
回归测试
在产品的正常迭代中，一般是新开发了什么功能，就重点测试什么功能，但也经常会遇到这种情况：这次项目的目的是开发 A 功能，但是在开发 A 功能的过程中导致了 B 模块出现了 bug，这就需要将和 A 功能相关的所有模块再测试一遍——即使之前这些模块都是测试通过的，这就是回归测试。在测试相对复杂系统的时候，测试的工作量会大很多，之前做过的用例还要重复测试一遍，这样测试的很大部分就变成了体力活。
如何避免重复劳动呢？ 答案就是将重复劳动交给程序来实现，这就是自动化测试。
自动化测试
自动化测试通过写程序的方式，把人在重复劳动中解脱出来。前文中提到的 4 种测试用例，假设每次程序有改动都要再测一遍，那么我就可以把预设的表单内容写在测试脚本中，通过指定元素的内容来判断是否符合预期，写好脚本后，测试框架会帮你自动完成那些操作。甚至可以自动生成测试报告。这些操作需要一定的编程基础，如果有困难，可以找工程师帮忙。自动化测试工具笔者目前只使用过 Selenium，大大解放过我的生产力。
有奖众测
毕竟个人的精力是有限的，即使有专门的测试团队，也很难发现产品中所有的问题。在正式发布前，可以将内测中的产品发给公司同事试用，采用 ”提 bug 有奖“ 的策略调动大家的积极性，只需花可乐、零食的钱就能获取很多有价值的反馈。
笔者参与过的一个 Android APP 的项目，项目初期 Android 测试机只有 3 台，项目又要赶着上线，我们采取这种方式把公司使用 Android 手机的同事调动起来，在正式发布前修正了一些重要的兼容性问题。
测试报告
测试结束后，要将测试结果发布出来，让团队内所有人了解产品目前的状态，同时将 bug 分级，为它们排优先级，将修正 bug 的工作排到接下来的工作计划中。
功能测试是合格产品经理的必备素质，要求能够撰写完整的测试用例并实践，完成测试报告并敦促工程师团队改进产品，在这个过程中不断打磨改进产品。测试只是手段，打造用户喜爱的产品才是目的。
