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

　　上一篇我们简要分析了研发测试，这一篇，我们来重点关注一下测试的工作内容。
　　测试和产品经理有什么关系？
　　测试是最有可能发现产品问题的人，不管是功能Bug、还是设计问题。
　　测试前的准备工作决定了测试是否完备。或者说，测试之前，测试点的整理和测试用例的撰写决定了测试过程中是否会漏测、少测。
　　测试过程决定了产品的质量，而产品经理需要对整个产品负责。因此，测试工作和产品经理息息相关。
　　产品经理有时也需要参与测试过程，以保证产品的质量。之前纯银在做一罐的时候，他就说自己在整理测试用例。
　　嗯，明白了测试的重要性，那就和我一起了解测试吧。
　　什么是测试？
　　如果我说最初的产品开发并没有测试这个岗位，你会相信吗？哈哈，不管你信不信，这都是事实。因为最初的产品都比较简单，开发小哥哥自己就能搞定测试。慢慢地，产品越来越复杂，致使产品开发环节出现精细化分工，才导致了专职测试的出现。
　　测试这个岗位也被成为QA（qualityassurance），也就是质量保障，主要的工作是比较或者说审核开发小哥哥写的代码的实际输出和产品需求的预期输入。
　　测试的工作内容是什么？
　　Step1：理解需求
　　熟悉并理解需求是测试工作得以顺利进行的基础条件。如果一个测试人员不理解需求，那么之后所有的工作都有可能存在问题。举个简单的例子，我们以计算器的加法为例，看下测试的工作内容。
　　Step2：测试点整理
　　测试点可以简单理解为需要测试的地方，或者测试的框架。测试人员需要根据需求列出测试点，计算器加法需求的测试点如下所示：
　　（1）输入验证
　　零
　　小数
　　负数
　　最大数
　　输入。
　　（2）清除输入项验证
　　输入被加数时清除
　　输入加数时清除
　　计算完成之后清除
　　（3）运算结果验证
　　整数运算
　　小数运算
　　负数运算
　　（4）边界验证
　　最大值与最大值相加
　　空值数值操作
　　Step3：整理测试用例
　　（1）什么是测试用例？
　　测试用例testcase是为了实施测试而向被测的产品提供的一组集合。简单来说，就是让测试有章可循的方法。没有测试用例的测试，很可能会变成随机测试，而有测试用例之后，按照测试用例测试，会让测试变得正规起来。
　　（2）怎么整理测试用例
　　测试用例的集合包括以下几个：
　　用例编号：保证唯一。可以用数字字母组合，最好采用统一的规定，方便阅读和理解，管理起来也很方便，比如：可以采用产品编号测试点名测试点子项编号。
　　功能模块（测试点）：可以根据需求填写功能模块或者测试点。
　　重要程度：重要程度或者优先级均可。用高、中、低代表即可。高代表对产品非常重要（使用频率较高或者是产品的基本功能），低代表可有可无、不是很重要的模块或功能。
　　前置条件：执行当前测试用例的前提条件，比如：测试一部手机的功能，前置条件是手机开机。前置条件可以用文字说明，也可以用测试用例编号代替。
　　测试输入参数：可以理解为测试过程中输入的数据，比如：测试登录时，至少需要输入账号和密码两个参数才能验证。
　　操作步骤：测试人员是怎样一步一步执行这个测试用例的，需要给出完整的操作步骤。有的时候，测试输入参数和操作步骤也会合并为操作步骤，会写成输入0。
　　预期输出：执行操作用例时，期望的结果是什么。这个主要是用来和实际结果相比较，以判断该测试用例是否应该通过。输出可以说明：（1）界面的变化；（2）数据库的变化；（3）相关信息的变化。
　　备注：除以上信息之外的其它信息。
　　然后，再根据测试点将以上集合进行整理，就能得到测试用例，如下所示：
　　Step4：测试Bug管理
　　测试过程中，难免会遇到Bug，那为什么要叫Bug呢？
　　（1）为什么叫Bug？
　　据说，1945年的某一天，一只小飞蛾钻进了计算机电路里，导致系统无法工作，一位名叫格蕾丝赫柏的人把飞蛾拍死在工作日志上（见图），写道：就是这个bug（虫子），害我们今天的工作无法完成于是，bug一词成了电脑系统程序的专业术语，形容那些系统中的缺陷或问题。
　　来源：网络，如知晓来源，请告知。
　　以下内容摘自美国海军网站（NavalHHeritageCommand）：
　　Thefollowingimageshowsanorganismofgreathistoricsignificance，reportedlyfirstidentifiedandnamedbyLieutenantGraceMurrayHopperwhileshewasonNavyactivedutyin1947。
　　下面这张画展示了一个有伟大历史意义的生物，由格蕾丝穆雷霍波上尉首次确认并命名，1947年，格蕾丝正在海军服役。
　　（2）Bug的一生状态流转
　　当测试发现一个功能不满足需求的时候，需要判断是否为Bug，如果是Bug，就需要提交Bug。提交的时候需要通知研发或产品负责人，由负责人来将Bug分给对应的研发。
　　研发接到Bug之后，需要人为判断是否为Bug：如果不是Bug，则需要和测试、产品沟通，然后关闭Bug。如果是Bug，需要修复。修复完成之后，提交代码，并备注Bug编号，然后更改Bug状态为已修复。
　　接下来由测试人员验证Bug是否修复，如果修复，则测试人员需要关闭B如果未修复，则测试人员需要更改Bug状态为验证未通过，该Bug重新恢复到未修复状态。
　　（3）正确地提Bug
　　为什么要提Bug？
　　因为要让开发小哥哥亲眼看到错误。但是很多时候，做不到亲自做给他们看，那就只能给他们能使程序出错的详细的操作步骤，也就是提bug。提Bug时，需要清楚地描述以下几点：
　　1）Bug标题：【Bug所在模块】Bug简要描述
　　2）Bug相关信息：
　　测试设备：操作系统（PC端）手机型号（移动端）
　　测试环境：浏览器及版本号（PC端）WiFi、4G、5G（移动端）
　　产品版本：版本号。到底是1。1。0发现的问题，还是1。2。0发现的问题。
　　重现步骤：需要阐述发现Bug并复现Bug的步骤，如果一个Bug没法复现，研发大概率是无法修复的。
　　截图：如果有的画，需要填写。
　　复现概率：简单说，就是你试来几次，出错了几次。
　　预期结果：期望的结果是什么。比如，112，2就是预期结果。
　　实际结果：实际的结果是什么。比如，当前113，3就是实际结果。
　　3）Bug指派人：Bug指派人，也就是说，这个Bug是由谁来修复的。没有指派人的Bug，大概率是不会被修复的，因为责任人不明确。
　　4）Bug提交人：嗯，是的，这是一句正确的废话。如果是用软件来管理Bug的话，天然就会有Bug提交人。但如若不是使用软件的话，提Bug的时候千万不要忘记这一项。Bug提交人的存在，方便团队成员在对这个Bug有疑问的时候，能找到正确的人询问相关细节。
　　（4）提完Bug之后？
　　静待研发修复，然后逐个回归Bug，同时需要观察是否还有其它Bug。如果从Bug的角度来看测试，测试可以被描述为：无数Bug从被发现到被解决的过程。可悲的是，一些Bug会永远留在backlog（可以理解为待办事项）里无人问津。
　　总结
　　1。测试的分类
　　产品经理了解概念即可。
　　按测试所属的开发阶段分为：单元测试、集成测试、系统测试、验收测试。
　　按测试时是否需要查看代码分为：黑盒测试、白盒测试、灰盒测试。
　　按测试是否手动执行分为：手工测试、自动化测试。
　　按测试类型分为：功能测试、性能测试、部署测试、文档测试、安全测试、兼容性测试、易用性测试、本地化测试、无障碍测试、可靠性测试。
　　其它测试分类：回归测试、冒烟测试、Monkey测试、AB测试
　　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无法复现，此时，需要通过codereview来定位问题。
　　其次，如果以上方法都已经尝试过，但Bug仍无法复现。此时，需要评估Bug的重要性以及上线时间。如果Bug不重要且上线时间很紧，那么只能暂时挂起Bug。
　　也就是说，对Bug保持关注，如果历经多个版本仍没有出现这个问题，那么Bug就能关闭了。
　　什么？为啥要关闭这个Bug？你没有强迫症？看着不难受？觉得无所谓？如果这些都没有，难道你不担心Bug堆成山，领导误以为你的工作没完成？
　　什么，你不在乎，那只能说“大佬，打扰了～”
　　下一篇我们将继续关注上线，敬请期待。好的，今天这篇文章到这里就结束了，我们的《一个项目带你走进产品经理的世界》系列文章完成进度如下：
　　黄色为当前进度：
　　
　　相关阅读
　　一个项目带你走进产品经理的世界（1）：从收到一个需求谈起
　　一个项目带你走进产品经理的世界（2）：需求分析
　　一个项目带你走进产品经理的世界（3）：从用户需求到产品功能
　　一个项目带你走进产品经理的世界（4）：产品规划
　　一个项目带你走进产品经理的世界（5）第一个版本：MVP？MDP？
　　一个项目带你走进产品经理的世界（6）：设计确认
　　一个项目带你走进产品经理的世界（7）：研发测试