扒一扒我测试时遇到的那些“神坑”

发表于:2020-5-28 08:44

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

 作者:邵永恰    来源:51Testing软件测试网原创

#
Bug
#
bug
分享:
  2020刚刚开始就被新冠按了暂停键,新一年的新项目大概要等春暖花开才好开动了,最近在给2019尚未完结的项目收尾,干脆趁机总结一下2019测试时候遇到的稀奇古怪、哭笑不得的缺陷or非缺陷,一点经验教训仅供大家参考。
  2019年作为主力参与了一个网页端应收账款融资平台建设项目,陆续投产了10个批次,基本上维持在半个月或一个月一次左右,由于是新功能新交易,相对优化类项目,问题明显比较多,且项目前期工期极为紧张,集成测试相对简化,项目推进磕磕绊绊,业务、开发、测试三方吵吵闹闹,磨合了很久。今天要讲的问题大多都在这个项目里出现过。应收账款确权与融资均基于上下游企业间的赊销合同,其中,下游企业负责每笔应收账款的还款,双方共同确认赊销合同的有效性,两个确权流程和融资流程均需银行方面进行审核,银行审核流程在以下流程图中已经省略,确权流程分为两个方向,一是由下游企业发起,二是由上游供应商发起,其中,赊销合同的相关证明材料包括发票、合同等相关信息由发起方提供,两个流程中各类影印件均由上游供应商提供。以下即为基本流程图,流程图中双方企业均有录入和复核两个角色,其中复核用户负责对本企业发起、接收的各个交易流程进行复核与确认,涉及需要进行数字签名确认的流程也由复核用户进行勾选确认。
  1.数据字典翻译问题
  无论是单纯的查询交易还是交易流程中的详细信息展示,几乎每一个从数据库表获取信息并在前台进行展示的交易都有遇到数据字典翻译问题,很多情况下,从数据库表查回来的信息直接展示在了用户看到的前台网页上,没有经过筛选,于是客户看到的就是处于状态01、02或者A001、B010之类的信息,但是并不清楚当前状态的含义。
  相关问题最后是通过公共函数解决的,涉及数据字典状态翻译的交易或界面自行调用相关函数,后续新增界面或修改流程等情况时,可以直接修改数据字典实现相关需求,可以减少前端或后端逐一添加或者修改函数的繁重工作量和可能的遗漏。其实每个投产批次中几乎都会遇到数据字典未翻译的情况,通常需要联系开发或修改数据字典或给页面增加相关函数调用。
  2.空值展示问题
  当需要上传文件中某些字段为空时,出现过前台展示页面上个别字段无内容,个别字段显示为NULL,还有金额相关字段显示为0.00的情况,同为空值同一页面展示存在差异,或同一字段为空时在不同页面上的展示不同,导致用户体验较差,部分场景下有误导用户的可能。
  一般在测试过程中,发现非缺陷但是可以优化的场景我会尽量提交建议给开发同事,在时间资源等条件允许且不会使当前场景和程序复杂化的情况下,会尽量沟通开发和业务进行优化。
  3.版本控制问题
  在本次项目中,确权流程1在第一批次投产,确权流程2投产几乎是最后一批次,两个流程要素基本一致,只不过交易顺序颠倒,基本上是两个对称的流程。以上流程里,所有复核不通过的交易都会退回上一环节,置为待修改状态,由各上下游企业的录入用户进行修改,确权流程2测试后期对全部流程进行回归时发现,确权流程1中下游企业录入用户待修改界面查询返回的应收账款信息是确权流程2中上游供应商录入用户对应的待修改应收账款信息。
  本次问题在测试过程中得以发现,避免缺陷逃逸进入投产环节,但是整体问题还是比较严重的。当时问题出现后,一方面联系开发紧急修改,另一方面也与开发确认了出现该问题的原因,主要是由于1、2两个确权流程是完全对称的,负责相关界面代码编写的同事直接复用了原有界面,但是在过程中不慎修改了原有界面。相关问题的产生主要是开发版本控制问题,但是对于测试而言,在测试过程中,对重点交易进行适当回归也是有必要的。
  4.金额输入与展示问题
  在测试过程中,出于界面美化及用户体验考虑,应业务方需求,开发对界面上金额的展示进行了一定调整,例如,输入2000,在界面上展示的是2,000.00,在相应转换过程中需要对金额进行一定处理。本次发现的问题在于,当金额高于一百万时,需要加入2个千分位符,转换代码中未充分考虑,导致金额大于999,999.99时会转换失败导致无法输入相应金额。除此以外,部分页面金额为0时,系统认为输入了空值,会展示为null。
  在今年的另外一个涉及外设测试的项目中,也出现了与金额输入相关的问题。在利用某外设生成动态口令的过程中,以金额9900.01为例,需要输入的是9-9-0-0-0-1,即需要输入到小数点后2位且不输入小数点,生成动态口令后,在动态口令校验的过程中,由于解密过程出现差错,所有金额为一位小数的数字均校验失败。该缺陷之所以暴露,主要是由于遇到一位小数时报错校验失败,但是该报错和密码输入错误时的报错又不相同,报错不一致的问题基本上在项目开始就已经发现了,但是一直到测试将近结束的才能确定是一位小数金额校验出现了问题,且该问题在现有运行的系统上一直存在,直至本次项目改造才被发现。
  这两个金额相关的报错尤其是后者,是我自己在2019年的测试中发现的最有成就感也最觉得神奇的缺陷。一方面,提示我们在遇到金额尤其是输入内容需要进行一定转换的时候,一定要充分测试各类金额,从最小到最高,从最普通整齐的金额到各种奇奇怪怪的小数位数,所有你觉得值得考虑的场景一定要充分考虑;另一方面,当遇到不同寻常的不能完全确定原因的报错时一定要保持求知探索精神,充分挖掘已有信息和场景背后的各类原因。
  测试是需要时间和资源成本的,完全测试并不现实,但是通过合理的案例和场景设计,在既定的资源条件下挖掘尽可能多的缺陷,最大限度减少缺陷逃逸的可能,正是测试的意义。以上或者普普通通,或者奇奇怪怪的问题,仅供大家参考,希望能对大家的测试工作有所帮助。

       版权声明:本文出自51Testing会员投稿,51Testing软件测试网及相关内容提供者拥有内容的全部版权,未经明确的书面许可,任何人或单位不得对本网站内容复制、转载或进行镜像,否则将追究法律责任。
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

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

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

沪ICP备05003035号

沪公网安备 31010102002173号