产品经理如何做测试？

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