同理心:从测试的角度来总结分析产品设计

发表于:2018-5-11 09:43

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:产品范    来源:51Testing软件测试网采编

  在苏杰大神的博客文章中有这样一个观点:
  产品新人如何快速上手的方法之一是写测试用例
  测试用例是从测试的视角写的产品描述。测试与产品的逻辑不同,产品抓大放小,测试就是要想清楚各种边边角角。
  所以,如果团队正好没有TC,你来写一遍,保证对产品的各种细节都很熟悉,也会知道背后用的技术,因为各种限制而造成的各种坑。
  一、关于软件测试
  从测试方法来分:软件测试分为黑盒测试白盒测试、灰盒测试、静态测试、动态测试、手工测试、自动化测试
  从测试阶段来分:软件测试分为需求测试、单元测试、集成测试、系统测试、验收测试。
  黑盒测试也叫功能性测试,在软件测试过程中大多采用此方式。我所说的产品经理懂测试,针对的即是功能性测试,从功能性的角度做产品的需求文档,遍历尽可能多的功能场景。一定不能让开发和测试找到你的漏洞,那将是产品经理最尴尬的时刻。
  有数据表示:
  在许多失败的项目中,70%~85%的返工是由于需求方面的错误导致的。
  二、限制边界值
  如果没有限制输入框的长度,专业的测试分分钟可以把开发认为没问题的程序搞挂。
  因此对输入框的长度限制,是一个产品最底层的功能,我想这也是产品经理的基本素养。进一步的要求是对可输入字符类型的限制,此项不至于影响到功能,但属于产品最基本的友好性需求。
  下图是作者好不容易找的一个反面例子:
  数值「0」是开发容易忽视的边界值,在很多场景中0值其实是没有意义的,比如金额为0元、数量为0等。自己的亲身经历:之前做过一个资金分配的功能,由于PRD没有说明字段的规则(以为开发小哥哥用脚想想都会明白),然而在做功能验收的时候,我成功给好友分配了0元。。。
  对于这些字段的规则,其实没有必要在文档上一一标注,因为很多页面的字段其实是重复的,这个方法也很容易漏掉一部分字段。一个很好的工作方法是:在全局规范中建立字段规则表。这个方法让我想起了:大学编程的时候,会统一将全局变量的定义集中放置。
  作者抛出一个输入框对空格的处理的测试用例供大家思考:
  1.前面存在空格
  2.后面存在空格
  3.前后都存在空格
  4.中间存在空格
  二、遍历异常逻辑
  正常流程只有一个,异常流程却异常的多。在很多PM的PRD中,仅仅陈列了正常的业务流程。
  很少有开发是会替产品考虑异常逻辑的,所以为了不给自己挖坑,在写PRD的时候,就要将所有的异常流程都描述清楚,我想在需求评审的时候会更容易通过,也会在开发的眼里树立权威。
  有人说,无反馈是产品大忌。我想说,反馈不完全也是产品不专业的体现。对于特定事件的反馈,既然有成功的结果,必然会存在对立面——失败。对于这些事件的总结其实很容易找到规律,很多优秀的PM都会整理一份交互设计自查表,然后会不断的更新迭代。
  善于总结是一个优秀学习者的必要品质,在项目经历中总结积累遇到的异常情况。有句话这样说:
  “你现在经历的每一件事,都会在未来某一时刻用上”。
  登录注册可能是大多数PM童鞋的处女级产品功能,根据我个人的经验:如果没有从零到一将这个需求落地,一定是存在认知漏洞的。
  我说一个场景,看大家有没有考虑到:手机号验证码输入框在同一个页面,在手机号无误、验证码输入正确的情况下,然后更改手机号(手机号格式合法),提交之后应该如何反馈?
  三、关联性的问题
  在项目中,大多数功能模块往往不是独立的,一般存在交集或者需要进行模块间的数据交互。因此一个模块如果发生了需求变更或者数据丢失,就会影响到相关联的功能模块。
  曾经做过一个项目,由于平台新增了直营店功能,之前设计的订单详情就不适用了,需要融合新需求,财务管理模块也要做字段的扩展。
  关联信息不允许删除,比如商品类别,假如商品类别是商品的必要属性,此时就应该禁止正使用的类别被删除。还有一个很重要的关联性问题是,正在生效的规则是不能被删除。
  四 、性能的问题
  性能无止境,性能的优化伴随着产品的整个生命周期。测试过程,性能测试处于功能测试之后,也就是说功能大于性能。翻越异常逻辑的大山,从性能角度设计产品,是产品经理进阶的又一指标。
  作者分别从数据加载、信息的筛选跨度、图片处理三个方面总结,希望可以抛砖引玉。
  关于数据加载其实是一个很大的话题,不仅涉及产品的性能,还影响用户的使用体验。我在这里只是蜻蜓点水,想要突出对产品性能的重视。
  这个问题主要在数据列表等相关的信息流模块,如果没有做数据加载条数的限制,一个经验不足的开发童鞋很可能一下子请求所有的历史数据,结果可以预见:轻则加载缓慢,严重的话直接导致应用崩溃。
  对于信息流页面的数据加载,一般都会限制单次加载10-20条。
  与此相关的另一个问题就是:数据筛选的请求限制。像支付宝这样大体量的产品,在筛选账单的时候,也仅仅支持查找6个月跨度的账单。
  图片是影响产品性能的又一大因素,在前端上传图片注意做图片大小的限制,即使上传之后技术也要做压缩处理。图片的压缩分为分辨率的压缩和大小的压缩,根据业务需求,如果需要展示缩略图,要在服务端自主生成。
  五、写在最后
  说了这么多,作者并没有误导大家把产品重心向测试的角度偏移,毕竟产品还有很多重要的事要做。
  一个好的产品经理既不能技术化,也不能业务化,掌握好工作中的「度」,做好「中庸的」连接者。
  当然,懂测试,能从测试的角度设计产品只是优秀产品的一个方面。产品经理这个岗位之所以吸引人正是因为它的定位不明确,它的「难」与「坑」我想也是这个原因。
  持续不断的学习,时刻都在拓宽自己的边界。懂技术、懂心理、懂设计、懂运营才能更好的连接。



上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号