扫码关注公众号

常见模块测试之两级评论逻辑分析
11-12
7观看
01

评论排序规则有哪些?

主流排序规则有:按热门程度、按发布时间、混合式排序。按热门程度主要是根据所有评论的点赞数量、回复数量进行排序(同时应该考虑“点踩数”、“举报数”等负面维度),通过权重进行线性求和计算。尤其是“知乎”类产品,本身是超低频工具类(不像音乐类工具型),但现在又已经存在了巨大的头部评论马太效应,建议在热门排序的同时针对一些具有时效性的内容排序,还要考虑加入时间衰减因子等等优化推荐算法。按评论时间按照发布时间正序或倒序排列,注意考虑是否提供用户选择正序、倒序排序方式的功能。值得注意的是,对主题式评论,如果一级评论采用默认倒序(为了让用户看到最新评论),一级评论下的二级评论则可以考虑采用正序来让用户更好的理解讨论进展;且需要注意的是一级评论倒序排序的情况下一级评论的倒序排序考虑是否根据其下的二级评论的最新发布时间来进行(这样能保证一级评论的排序是按评论本身的讨论进展来更新的,参考“贴吧”)。混合式排序该模式是“热门排序”和“评论排序”的综合,比较典型的是网易云音乐。网易云音乐通过设定前5条评论为“热门排序”的前5名,后面的评论按时间展示来同时提供给用户的良好评论观感和评论的参与性(用户既能感受到热评的趣味性又能有机会、有意愿参与到评论中来)。

来自:测试方案-测试用例分析
02

简述一下评论模块的细节功能?

主要功能评论模块的主要功能涉及:点赞、回复、复制、举报、删除、分享点赞:要考虑点赞、取消点赞后的赞数变更逻辑,是否需要服务端同步更新,点击后的动效,点赞后的消息提醒机制等。回复:要考虑回复弹窗的出现、收起时机,回复字符限制,回复是否支持换行符,是否支持键盘提交,是否允许空字符提交,回复页面弹窗大小,按钮布局等。复制:要考虑可复制区域,复制交互(长按/点击),复制后的提示效果等。举报:要考虑是举报文字还是举报人,举报后的提示,举报后的数据审核等。删除:要考虑发布人支持删除功能,删除时的弹窗提醒,删除后状态何时同步,删除是硬删除还是软删除,一级评论删除对二级评论的影响等等。分享:要考虑可分享平台,分享后的打开样式,是分享成网页还是分享成截图等。内容运营评论加精:支持运营挑选优质评论,在前端给予“精华”的标记。评论置顶:将评论置顶。评论屏蔽:通知发布评论人其内容被屏蔽,要求其修改后申请解除屏蔽,经审核后评论可重新出现。评论删除:违反平台相应规则,直接从后台将评论删除,不可恢复。评论人封禁:通常是和“举报”关联,对于频繁发布垃圾评论者予以封禁,令其不可再发评论。当然也应该允许其申请解封。敏感词替换:通常做法是构建敏感词库,如果评论某些文字命中词库,则将敏感词替换为“*”。被删除/屏蔽后显示逻辑:当某条评论被删除,或屏蔽后,可以有两种做法,要么是直接删除,要么是当前区块保留,被删除文字变成“该评论已删除”。尤其是主题式评论,由于某条一级评论可能关联多条二级评论,如果一级评论被删除,其二级评论是否需要全部删除,需要根据评论价值来决策。建议这种情况还是保留二级评论。内容控制字数限制:对评论内容进行字数控制;符号限制:可设置特殊符号的限制(注意提示用户);便捷操作部分产品设计了快速评论的功能,比如:踩、一般、赞、太棒了等等(有些也有表情、图片),用户直接点击即可,类似投票行为。但是便捷操作也会导致内容重复、效果低下等副作用,建议谨慎考虑(当然如果运营能对不同时期给出评论的一些热点文案,便捷操作也是可以考虑的)。保留草稿用户在评论未发送前如果误触取消按钮,自动替用户保存当前输入文字,而再次出现评论框时,还能将之前文字恢复;或在用户取消输入框时,弹框告知用户是否要取消(两者结合亦可)。超链接支持根据产品属性,考虑评论是否要支持外部的超链接。这里需要考虑超链接的识别逻辑(需要头部是http或https,或者通过要求用户加入特殊标记),超链接的字数计算(对于限制字数的输入框,超链接可以统一计算为10个字符),超链接发布后的显示样式(简单的可以直接显示链接地址;好一点的显示为“链接地址”四个字;再好一点的取链接地址对于网址的title显示,如知乎)键盘设置发评论时,键盘设置问题:评论框输入评论时,需要考虑是否将“发布”按钮设置在键盘上。如果需要考虑评论换行,那“完成”键应该作为换行键,否则点击“完成”应该是直接提交。

来自:测试方案-测试用例分析
03

接口测试怎么做的?

接口测试其实是比较简单的,开发会给一个接口文档,根据接口文档编写测试用例,考虑接口正常场景跟异常场景。测试用例编写完成后,用python+request去执行,查看返回的结果是否跟用例的一致,不一致有bug。需要注意的是参数之间是不是组合关系,如果是组合关系就需要同时考虑,如果不是组合关系就要单独考虑。也需要考虑正常和异常的场景,多一个参数和少一个参数以及参数为空的情况。比如用python+request做的一个前端注册接口,首先我们把每条用例定义成一个函数模块,再把需要组合的参数编写进用例里面。比如用户名跟密码这是组合关系就要同时对这两个参数进行考虑。当用户名与密码正确的情况下,返回的是一个正确的注册成功的信息。当用户名为空和两个密码一至的情况下返回的提示应该是一个用户名不能为空的信息。当用户名正确和两个密码不一至的情况下返回的提示应该是一个密码不一至的信息,当用户名正确和两个密码都为空的情况下返回的提示应该是一个密码不能为空或密码过弱的信息。当用户名重复,手机号码重复,勾选了协议和没勾选了协议的情况,还有同时也需要用等价类边界值对参数的长度、特殊符号的输入和类型进行考虑。最后再加assert来断言判断返回的参数是否正确接口测试的主要好处是,在后端测试接口,覆盖更加全面,测试时间可以提前在接口过程,发现问题最多的,来源于格式的校验这块,比方说,原来申请借款,利率设置成5000,也可以申请成功,功能测试,界面已经做了校验,只能在接口中才能测试出这个问题,还有申请借款时候,需要勾选,同意,协议,接口中不没有勾选,也表示成功

来自:测试方案-测试用例分析
课程
专栏
【校招VIP】软件测试用例∣朋友圈点赞以及评论测试用例
知乎
评论模块
【校招VIP】APP产品研习——“评论模块”
知乎
评论模块
【校招VIP】Django 博客单元测试:测试评论应用
知乎
评论模块
测试技术-测试方案-测试用例分析
3专栏
1课程
3 试题