您的位置:网站首页 > 产品信息 > 正文

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

类别:产品信息 日期:2019-7-9 9:39:40 人气: 来源:

  官员与三女子滚床单测试前的准备工作决定了测试是否完备。或者说,测试之前,测试点的整理和测试用例的撰写决定了测试过程中是否会漏测、少测。

  测试过程决定了产品的质量,而产品经理需要对整个产品负责。因此,测试工作和产品经理息息相关。

  产品经理有时也需要参与测试过程,以产品的质量。之前纯银在做「一罐」的时候,他就说自己在整理测试用例。

  如果我说最初的产品开发并没有「测试」这个岗位,你会相信吗?哈哈,不管你信不信,这都是事实。因为最初的产品都比较简单,开发小哥哥自己就能搞定测试。慢慢地,产品越来越复杂,致使产品开发环节出现精细化分工,才导致了「专职测试」的出现。

  测试这个岗位也被成为 QA(quality assurance),也就是质量保障,主要的工作是比较或者说审核开发小哥哥写的代码的实际输出和产品需求的预期输入。

  熟悉并理解需求是测试工作得以顺利进行的基础条件。如果一个测试人员不理解需求,那么之后所有的工作都有可能存在问题。举个简单的例子,我们以计算器的 「加法」为例,看下测试的工作内容。

  测试点可以简单理解为需要测试的地方,或者测试的框架。测试人员需要根据需求列出测试点,计算器加法需求的测试点如下所示:

  测试用例「test case」是为了实施测试而向被测的产品提供的一组集合。简单来说,就是让测试有章可循的方法。没有测试用例的测试,很可能会变成随机测试,而有测试用例之后,按照测试用例测试,会让测试变得「正规」起来。

  :唯一。可以用数字 + 字母组合,最好采用统一的,方便阅读和理解,管理起来也很方便,比如:可以采用「产品编号_测试点名_测试点子项_编号」。

  :重要程度或者优先级均可。用「高」、「中」、「低」代表即可。「高」代表对产品非常重要(使用频率较高或者是产品的基本功能),「低」代表可有可无、不是很重要的模块或功能。

  :执行当前测试用例的前提条件,比如:测试一部手机的功能,前置条件是「手机开机」。「前置条件」可以用文字说明,也可以用测试用例编号代替。

  :可以理解为测试过程中输入的数据,比如:测试登录时,至少需要输入「账号」和「密码」两个参数才能验证。

  :测试人员是怎样一步一步执行这个测试用例的,需要给出完整的操作步骤。有的时候,「测试输入参数」和「操作步骤」也会合并为「操作步骤」,会写成「输入 0 」。

  :执行操作用例时,期望的结果是什么。这个主要是用来和实际结果相比较,以判断该测试用例是否应该通过。输出可以说明:(1)界面的变化;(2)数据库的变化;(3)相关信息的变化。

  据说,1945 年的某一天,一只小飞蛾钻进了计算机电里,导致系统无法工作,一位名叫格蕾丝·赫柏的人把飞蛾拍死在工作日志上(见图),写道:就是这个 bug(虫子),害我们今天的工作无法完成——于是,bug 一词成了电脑系统程序的专业术语,形容那些系统中的缺陷或问题。

  下面这张画展示了一个有伟大历史意义的生物,由格蕾丝·穆雷·霍波上尉首次确认并命名,1947年,格蕾丝正在海军服役。

  当测试发现一个功能不满足需求的时候,需要判断是否为 Bug,如果是 Bug,就需要提交 Bug。提交的时候需要通知研发或产品负责人,由负责人来将 Bug 分给对应的研发。

  研发接到 Bug 之后,需要人为判断是否为 Bug:如果不是 Bug,则需要和测试、产品沟通,然后关闭 Bug。如果是 Bug,需要修复。修复完成之后,提交代码,并备注 Bug 编号,然后更改 Bug 状态为已修复。

  接下来由测试人员验证 Bug 是否修复,如果修复,则测试人员需要关闭 Bug;如果未修复,则测试人员需要更改 Bug 状态为「验证未通过」,该 Bug 重新恢复到未修复状态。

  因为要让开发小哥哥亲眼看到错误。但是很多时候,做不到亲自做给他们看,那就只能给他们能使程序出错的详细的操作步骤,也就是提 bug。提 Bug 时,需要清楚地描述以下几点:

  3)Bug 人:Bug 人,也就是说,这个 Bug 是由谁来修复的。没有人的 Bug,大概率是不会被修复的,因为责任人不明确。

  4)Bug 提交人:嗯,是的,这是一句正确的废话。如果是用软件来管理 Bug 的话,天然就会有 Bug 提交人。但如若不是使用软件的话,提 Bug 的时候千万不要忘记这一项。Bug 提交人的存在,方便团队在对这个 Bug 有疑问的时候,能找到正确的人询问相关细节。

  静待研发修复,然后逐个回归 Bug,同时需要观察是否还有其它 Bug。如果从 Bug 的角度来看测试,测试可以被描述为:无数 Bug 从被发现到被解决的过程。可悲的是,一些 Bug 会永远留在 backlog(可以理解为待办事项)里无人问津。

  Bug 分类每个公司的要求时不一样的,找到适合自己的就行。常见的 Bug 分类有按优先级分类(高、中、低)、按功能模块分类(登录注册、订单、UI、权限、数据等)、按 Bug 产生原因(编码、其它、理解偏差、需求变更、需求遗漏)等。

  测试用例是测试过程的参考手册,方便测试人员理清测试过程及测试步骤,为后续的测试提供参考依据。

  试想如果没有整理测试用例,是不是测试人员想测什么就测什么,毫无章法可言、也没办法向别人解释你为啥需要这么久。同时,提供完备的测试用例,还能在你被调离或者新测试加入的时候,方便别人快速投入工作。当然,测试用例的编写是很消耗人力和时间的。但即便如此,我还是花时间编写,毕竟「磨刀不误砍柴工」。

  在不熟悉产品或者经验不足的测试人员身上经常会出现,不过,不用担心,这都是小事!直接把测试点补上就行。随着对产品越来越熟悉或者经验越来越丰富,这种情况就应该减少。

  什么?做为一个工作 N 年以上的「老测试」,你还经常出现?那我只能说,前面有堵墙,你去墙前边站站吧。怎样才能不漏测试用例,在理解需求的基础上检查,检查,再检查。

  最后,再做决定。如果 Bug 不重要,修复很耗时且不确定是否会引起其它 Bug,离上线时间很近,且不能延期,那只能下次改。其它没有规则,只能产品经理自己判断。判断错了怎么办,总结经验下次不要再做错决定就行。

  这个就牵扯到「工作完成的定义」,测试的工作如果从产品的角度来看,一个版本上线就算这个版本的工作完成。换句话说,如果这个 Bug 未解决,并且产品经理决定这个版本不解决,那这个 Bug 就不属于当前版本的管理范围。

  也就是说,这个 Bug 解决与否,只要产品按时上线,测试这个版本的工作就算完成,但是如果从 Bug 的角度来看,测试需要 Bug 修复直至上线甚至是用户反馈过程这个完整的流程,测试的工作才算完成。

  A 版本上的 Bug 在 B 版本或者 C 版本上很有可能导致无法复现,但如若该 Bug 在 B 版本上已被解决,应当关掉这个 Bug。

  产品里的某些数据会导致 Bug 的存在,如果这些数据条件不具备,导致 Bug 无法复现。尽可能还原数据,以测试 Bug 是否仍存在。

  编码过程中会因为各种因素导致 Bug 无法复现,此时,需要通过 code review 来定位问题。

  其次,如果以上方法都已经尝试过,但 Bug 仍无法复现。此时,需要评估 Bug 的重要性以及上线时间。如果 Bug 不重要且上线时间很紧,那么只能暂时「挂起 Bug」。

  也就是说,对 Bug 保持关注,如果历经多个版本仍没有出现这个问题,那么 Bug 就能关闭了。

  什么?为啥要关闭这个 Bug?你没有症?看着不难受?觉得无所谓?如果这些都没有,难道你不担心 Bug 堆成山,领导误以为你的工作没完成?

  下一篇我们将继续关注「上线」,敬请期待。好的,今天这篇文章到这里就结束了,我们的《一个项目带你走进产品经理的世界》系列文章完成进度如下:

  佐珥,微信号:产品碎月(ID:pm_lab),人人都是产品经理专栏作家,专注互联网产品,乐于通过幽默诙谐、图文并茂、结合实际的文字分享自己的产品经验,期望同大家一起快乐成长

  

0
0
0
0
0
0
0
0
下一篇:没有资料

相关阅读

网友评论 ()条 查看

姓名: 验证码: 看不清楚,换一个

推荐文章更多

热门图文更多

最新文章更多

关于联系我们 - 广告服务 - 友情链接 - 网站地图 - 版权声明 - 人才招聘 - 帮助

CopyRight 2002-2016 木工设备网 技术支持 FXT All Rights Reserved