上一篇我们简要分析了研发测试，这一篇，我们来重点关注一下测试的工作内容。
测试和产品经理有什么关系？
嗯，明白了测试的重要性，那就和我一起了解测试吧。
什么是测试？
如果我说最初的产品开发并没有“测试”这个岗位，你会相信吗？哈哈，不管你信不信，这都是事实。因为最初的产品都比较简单，开发小哥哥自己就能搞定测试。慢慢地，产品越来越复杂，致使产品开发环节出现精细化分工，才导致了“专职测试”的出现。
测试这个岗位也被成为 QA（quality assurance），也就是质量保障，主要的工作是比较或者说稽核开发小哥哥写的程式码的实际输出和产品需求的预期输入。
测试的工作内容是什么？ Step 1：理解需求
熟悉并理解需求是测试工作得以顺利进行的基础条件。如果一个测试人员不理解需求，那么之后所有的工作都有可能存在问题。举个简单的例子，我们以计算器的 “加法”为例，看下测试的工作内容。
Step 2：测试点整理
测试点可以简单理解为需要测试的地方，或者测试的框架。测试人员需要根据需求列出测试点，计算器加法需求的测试点如下所示：
（1）输入验证
（2）清除输入项验证
（3）运算结果验证
（4）边界验证
（1）什么是测试用例？
测试用例“test case”是为了实施测试而向被测的产品提供的一组集合。简单来说，就是让测试有章可循的方法。没有测试用例的测试，很可能会变成随机测试，而有测试用例之后，按照测试用例测试，会让测试变得“正规”起来。
（2）怎么整理测试用例
测试用例的集合包括以下几个：
然后，再根据测试点将以上集合进行整理，就能得到“测试用例”，如下所示：
Step 4：测试 + Bug 管理
测试过程中，难免会遇到 Bug，那为什么要叫 Bug 呢？
（1）为什么叫“Bug”？
据说，1945 年的某一天，一只小飞蛾钻进了计算机电路里，导致系统无法工作，一位名叫格蕾丝·赫柏的人把飞蛾拍死在工作日志上（见图），写道：就是这个 bug（虫子），害我们今天的工作无法完成——于是，bug 一词成了电脑系统程式的专业术语，形容那些系统中的缺陷或问题。
—— 来源：网络，如知晓来源，请告知。
以下内容摘自美国海军网站（Naval History & Heritage Command）：
The following image shows an organism of great historic significance, reportedly first identified and named by Lieutenant Grace Murray Hopper while she was on Navy active duty in 1947.
下面这张画展示了一个有伟大历史意义的生物，由格蕾丝·穆雷·霍波上尉首次确认并命名，1947年，格蕾丝正在海军服役。
（2）Bug 的一生——状态流转
当测试发现一个功能不满足需求的时候，需要判断是否为 Bug，如果是 Bug，就需要提交 Bug。提交的时候需要通知研发或产品负责人，由负责人来将 Bug 分给对应的研发。
研发接到 Bug 之后，需要人为判断是否为 Bug：如果不是 Bug，则需要和测试、产品沟通，然后关闭 Bug。如果是 Bug，需要修复。修复完成之后，提交程式码，并备注 Bug 编号，然后更改 Bug 状态为已修复。
接下来由测试人员验证 Bug 是否修复，如果修复，则测试人员需要关闭 Bug；如果未修复，则测试人员需要更改 Bug 状态为“验证未通过”，该 Bug 重新恢复到未修复状态。
（3）正确地提 Bug
为什么要提 Bug？
因为要让开发小哥哥亲眼看到错误。但是很多时候，做不到亲自做给他们看，那就只能给他们能使程式出错的详细的操作步骤，也就是提 bug。提 Bug 时，需要清楚地描述以下几点：
1）Bug 标题：【Bug 所在模组】Bug 简要描述
2）Bug 相关资讯：
3）Bug 指派人：Bug 指派人，也就是说，这个 Bug 是由谁来修复的。没有指派人的 Bug，大概率是不会被修复的，因为责任人不明确。
4）Bug 提交人：嗯，是的，这是一句正确的废话。如果是用软件来管理 Bug 的话，天然就会有 Bug 提交人。但如若不是使用软件的话，提 Bug 的时候千万不要忘记这一项。Bug 提交人的存在，方便团队成员在对这个 Bug 有疑问的时候，能找到正确的人询问相关细节。
（4）提完 Bug 之后？
静待研发修复，然后逐个回归 Bug，同时需要观察是否还有其它 Bug。如果从 Bug 的角度来看测试，测试可以被描述为：无数 Bug 从被发现到被解决的过程。可悲的是，一些 Bug 会永远留在 backlog（可以理解为待办事项）里无人问津。
总结 1. 测试的分类
产品经理了解概念即可。
Bug 分类每个公司的要求时不一样的，找到适合自己的就行。常见的 Bug 分类有按优先级分类（高、中、低）、按功能模组分类（登入注册、订单、UI、许可权、资料等）、按 Bug 产生原因（编码、其它、理解偏差、需求变更、需求遗漏）等。
3. 测试用例有什么用？
测试用例是测试过程的参考手册，方便测试人员理清测试过程及测试步骤，为后续的测试提供参考依据。
试想如果没有整理测试用例，是不是测试人员想测什么就测什么，毫无章法可言、也没办法向别人解释你为啥需要这么久。同时，提供完备的测试用例，还能在你被调离或者新测试加入的时候，方便别人快速投入工作。当然，测试用例的编写是很消耗人力和时间的。但即便如此，我还是建议花时间编写，毕竟“磨刀不误砍柴工”。
测试人员每执行一个测试用例，都需要更新测试用例的状态，如下表所示：
至于测试用例要不要关联 Bug，因团队而异。
4. 写测试用例的时候发现测试点写漏了，怎么办？
在不熟悉产品或者经验不足的测试人员身上经常会出现，不过，不用担心，这都是小事！直接把测试点补上就行。随着对产品越来越熟悉或者经验越来越丰富，这种情况就应该减少。
什么？做为一个工作 N 年以上的“老测试”，你还经常出现？那我只能说，前面有堵墙，你去墙前边站站吧。怎样才能不漏测试用例，在理解需求的基础上检查，检查，再检查。
5. 部分 Bug 未解决，能上线吗？
首先，问自己：
最后，再做决定。如果 Bug 不重要，修复很耗时且不确定是否会引起其它 Bug，离上线时间很近，且不能延期，那只能下次改。其它没有规则，只能产品经理自己判断。判断错了怎么办，总结经验下次不要再做错决定就行。
6. Bug 未解决，测试的工作算完成吗？
这个就牵扯到“工作完成的定义”，测试的工作如果从产品的角度来看，一个版本上线就算这个版本的工作完成。换句话说，如果这个 Bug 未解决，并且产品经理决定这个版本不解决，那这个 Bug 就不属于当前版本的管理范围。
也就是说，这个 Bug 解决与否，只要产品按时上线，测试这个版本的工作就算完成，但是如果从 Bug 的角度来看，测试需要跟踪 Bug 修复直至上线甚至是使用者反馈过程这个完整的流程，测试的工作才算完成。
7. Bug 无法复现怎么办？
首先我们来看下，哪些原因会导致 Bug 无法复现：
其次，如果以上方法都已经尝试过，但 Bug 仍无法复现。此时，需要评估 Bug 的重要性以及上线时间。如果 Bug 不重要且上线时间很紧，那么只能暂时“挂起 Bug”。
也就是说，对 Bug 保持关注，如果历经多个版本仍没有出现这个问题，那么 Bug 就能关闭了。
什么？为啥要关闭这个 Bug？你没有强迫症？看着不难受？觉得无所谓？如果这些都没有，难道你不担心 Bug 堆成山，领导误以为你的工作没完成？
什么，你不在乎，那只能说“大佬，打扰了～”
下一篇我们将继续关注“上线”，敬请期待。好的，今天这篇文章到这里就结束了，我们的《一个专案带你走进产品经理的世界》系列文章完成进度如下：
黄色为当前进度：
#专栏作家#
佐珥，微信公众号：产品碎月（ID：pm_lab），人人都是产品经理专栏作家，专注互联网产品，乐于通过幽默诙谐、图文并茂、结合实际的文字分享自己的产品经验，期望同大家一起快乐成长
题图来自Unsplash，基于CC0协议
