一个项目带你走进产品经理的世界你真的了解测试吗

　　上一篇我们简要分析了研发测试，这一篇，我们来重点关注一下测试的工作内容。
　　测试和产品经理有什么关系？
　　测试是最有可能发现产品问题的人，不管是功能 Bug、还是设计问题。
　　测试前的准备工作决定了测试是否完备。或者说，测试之前，测试点的整理和测试用例的撰写决定了测试过程中是否会漏测、少测。
　　测试过程决定了产品的质量，而产品经理需要对整个产品负责。因此，测试工作和产品经理息息相关。
　　产品经理有时也需要参与测试过程，以保证产品的质量。之前纯银在做「一罐」的时候，他就说自己在整理测试用例。
　　嗯，明白了测试的重要性，那就和我一起了解测试吧。
　　什么是测试？
　　如果我说最初的产品开发并没有「测试」这个岗位，你会相信吗？哈哈，不管你信不信，这都是事实。因为最初的产品都比较简单，开发小哥哥自己就能搞定测试。慢慢地，产品越来越复杂，致使产品开发环节出现精细化分工，才导致了「专职测试」的出现。
　　测试这个岗位也被成为 QA（quality assurance），也就是质量保障，主要的工作是比较或者说审核开发小哥哥写的代码的实际输出和产品需求的预期输入。
　　测试的工作内容是什么？
　　Step 1：理解需求
　　熟悉并理解需求是测试工作得以顺利进行的基础条件。如果一个测试人员不理解需求，那么之后所有的工作都有可能存在问题。举个简单的例子，我们以计算器的 「加法」为例，看下测试的工作内容。
　　Step 2：测试点整理
　　测试点可以简单理解为需要测试的地方，或者测试的框架。测试人员需要根据需求列出测试点，计算器加法需求的测试点如下所示：
　　（1）输入验证
　　零
　　小数
　　负数
　　最大数
　　输入「.」
　　（2）清除输入项验证
　　输入「被加数」时清除
　　输入「加数」时清除
　　计算完成之后清除
　　（3）运算结果验证
　　整数运算
　　小数运算
　　负数运算
　　（4）边界验证
　　最大值与最大值相加
　　空值数值操作
　　Step 3：整理测试用例
　　（1）什么是测试用例？
　　测试用例「test case」是为了实施测试而向被测的产品提供的一组集合。简单来说，就是让测试有章可循的方法。没有测试用例的测试，很可能会变成随机测试，而有测试用例之后，按照测试用例测试，会让测试变得「正规」起来。
　　（2）怎么整理测试用例
　　测试用例的集合包括以下几个：
　　用例编号：保证唯一。可以用数字 + 字母组合，最好采用统一的规定，方便阅读和理解，管理起来也很方便，比如：可以采用「产品编号_测试点名_测试点子项_编号」。
　　功能模块（测试点）：可以根据需求填写功能模块或者测试点。
　　重要程度：重要程度或者优先级均可。用「高」、「中」、「低」代表即可。「高」代表对产品非常重要（使用频率较高或者是产品的基本功能），「低」代表可有可无、不是很重要的模块或功能。
　　前置条件：执行当前测试用例的前提条件，比如：测试一部手机的功能，前置条件是「手机开机」。「前置条件」可以用文字说明，也可以用测试用例编号代替。
　　测试输入参数：可以理解为测试过程中输入的数据，比如：测试登录时，至少需要输入「账号」和「密码」两个参数才能验证。
　　操作步骤：测试人员是怎样一步一步执行这个测试用例的，需要给出完整的操作步骤。有的时候，「测试输入参数」和「操作步骤」也会合并为「操作步骤」，会写成「输入 0 」。
　　预期输出：执行操作用例时，期望的结果是什么。这个主要是用来和实际结果相比较，以判断该测试用例是否应该通过。输出可以说明：（1）界面的变化；（2）数据库的变化；（3）相关信息的变化。
　　备注：除以上信息之外的其它信息。
　　然后，再根据测试点将以上集合进行整理，就能得到「测试用例」，如下所示：
　　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 相关信息：
　　测试设备：操作系统（PC 端）/ 手机型号（移动端）
　　测试环境：浏览器及版本号（PC 端）/ Wi-Fi 、4G、5G（移动端）
　　产品版本：版本号。到底是 1.1.0 发现的问题，还是 1.2.0 发现的问题。
　　重现步骤：需要阐述发现 Bug 并复现 Bug 的步骤，如果一个 Bug 没法复现，研发大概率是无法修复的。
　　截图：如果有的画，需要填写。
　　复现概率：简单说，就是你试来几次，出错了几次。
　　预期结果：期望的结果是什么。比如，1+1 = 2，「2」就是预期结果。
　　实际结果：实际的结果是什么。比如，当前 1+1 =3，「3」就是实际结果。
　　3）Bug 指派人：Bug 指派人，也就是说，这个 Bug 是由谁来修复的。没有指派人的 Bug，大概率是不会被修复的，因为责任人不明确。
　　4）Bug 提交人：嗯，是的，这是一句正确的废话。如果是用软件来管理 Bug 的话，天然就会有 Bug 提交人。但如若不是使用软件的话，提 Bug 的时候千万不要忘记这一项。Bug 提交人的存在，方便团队成员在对这个 Bug 有疑问的时候，能找到正确的人询问相关细节。
　　（4）提完 Bug 之后？
　　静待研发修复，然后逐个回归 Bug，同时需要观察是否还有其它 Bug。如果从 Bug 的角度来看测试，测试可以被描述为：无数 Bug 从被发现到被解决的过程。可悲的是，一些 Bug 会永远留在 backlog（可以理解为待办事项）里无人问津。
　　总结
　　1. 测试的分类
　　产品经理了解概念即可。
　　按测试所属的开发阶段分为：单元测试、集成测试、系统测试、验收测试。
　　按测试时是否需要查看代码分为：黑盒测试、白盒测试、灰盒测试。
　　按测试是否手动执行分为：手工测试、自动化测试。
　　按测试类型分为：功能测试、性能测试、部署测试、文档测试、安全测试、兼容性测试、易用性测试、本地化测试、无障碍测试、可靠性测试。
　　其它测试分类：回归测试、冒烟测试、Monkey 测试、A/B 测试
　　2. Bug 分类
　　Bug 分类每个公司的要求时不一样的，找到适合自己的就行。常见的 Bug 分类有按优先级分类（高、中、低）、按功能模块分类（登录注册、订单、UI、权限、数据等）、按 Bug 产生原因（编码、其它、理解偏差、需求变更、需求遗漏）等。
　　3. 测试用例有什么用？
　　测试用例是测试过程的参考手册，方便测试人员理清测试过程及测试步骤，为后续的测试提供参考依据。
　　试想如果没有整理测试用例，是不是测试人员想测什么就测什么，毫无章法可言、也没办法向别人解释你为啥需要这么久。同时，提供完备的测试用例，还能在你被调离或者新测试加入的时候，方便别人快速投入工作。当然，测试用例的编写是很消耗人力和时间的。但即便如此，我还是建议花时间编写，毕竟「磨刀不误砍柴工」。
　　测试人员每执行一个测试用例，都需要更新测试用例的状态，如下表所示：
　　至于测试用例要不要关联 Bug，因团队而异。
　　4. 写测试用例的时候发现测试点写漏了，怎么办？
　　在不熟悉产品或者经验不足的测试人员身上经常会出现，不过，不用担心，这都是小事！直接把测试点补上就行。随着对产品越来越熟悉或者经验越来越丰富，这种情况就应该减少。
　　什么？做为一个工作 N 年以上的「老测试」，你还经常出现？那我只能说，前面有堵墙，你去墙前边站站吧。怎样才能不漏测试用例，在理解需求的基础上检查，检查，再检查。
　　5. 部分 Bug 未解决，能上线吗？
　　首先，问自己：
　　这个 Bug 重要吗？影响核心流程或者核心用户吗？
　　改这个 Bug 需要多久？（修 Bug 时间 + 测试时间）* 系数。文案 Bug 的系数为 1，其它 Bug 需要视情况而定。
　　上线时间是什么时候？
　　最后，再做决定。如果 Bug 不重要，修复很耗时且不确定是否会引起其它 Bug，离上线时间很近，且不能延期，那只能下次改。其它没有规则，只能产品经理自己判断。判断错了怎么办，总结经验下次不要再做错决定就行。
　　6. Bug 未解决，测试的工作算完成吗？
　　这个就牵扯到「工作完成的定义」，测试的工作如果从产品的角度来看，一个版本上线就算这个版本的工作完成。换句话说，如果这个 Bug 未解决，并且产品经理决定这个版本不解决，那这个 Bug 就不属于当前版本的管理范围。
　　也就是说，这个 Bug 解决与否，只要产品按时上线，测试这个版本的工作就算完成，但是如果从 Bug 的角度来看，测试需要跟踪 Bug 修复直至上线甚至是用户反馈过程这个完整的流程，测试的工作才算完成。
　　7. Bug 无法复现怎么办？
　　首先我们来看下，哪些原因会导致 Bug 无法复现：
　　版本：A 版本上的 Bug 在 B 版本或者 C 版本上很有可能导致无法复现，但如若该 Bug 在 B 版本上已被解决，应当关掉这个 Bug。
　　数据：产品里的某些数据会导致 Bug 的存在，如果这些数据条件不具备，导致 Bug 无法复现。尽可能还原数据，以测试 Bug 是否仍存在。
　　代码：编码过程中会因为各种因素导致 Bug 无法复现，此时，需要通过 code review 来定位问题。
　　其次，如果以上方法都已经尝试过，但 Bug 仍无法复现。此时，需要评估 Bug 的重要性以及上线时间。如果 Bug 不重要且上线时间很紧，那么只能暂时「挂起 Bug」。
　　也就是说，对 Bug 保持关注，如果历经多个版本仍没有出现这个问题，那么 Bug 就能关闭了。
　　什么？为啥要关闭这个 Bug？你没有强迫症？看着不难受？觉得无所谓？如果这些都没有，难道你不担心 Bug 堆成山，领导误以为你的工作没完成？
　　什么，你不在乎，那只能说＂大佬，打扰了～＂
　　下一篇我们将继续关注「上线」，敬请期待。好的，今天这篇文章到这里就结束了，我们的《一个项目带你走进产品经理的世界》系列文章完成进度如下：
　　黄色为当前进度：
　　相关阅读
　　一个项目带你走进产品经理的世界（1）：从收到一个需求谈起
　　一个项目带你走进产品经理的世界（2）：需求分析
　　一个项目带你走进产品经理的世界（3）：从用户需求到产品功能
　　一个项目带你走进产品经理的世界（4）：产品规划
　　一个项目带你走进产品经理的世界（5）第一个版本：MVP ？MDP ？
　　一个项目带你走进产品经理的世界（6）：设计确认
　　一个项目带你走进产品经理的世界（7）：研发测试