对称日上线项目的日常复盘

上一篇 / 下一篇  2021-12-03 16:43:44

赶在多年难遇的对称日20211202,项目V2.3版本上线了,急急忙忙,加班加点,终于按期交付,直呼不容易
该项目是一个Web类型项目,分为前台和后台。本期主要是结算相关的功能,后台给用户设置各种结算规则,验证日收益,月收益,账单数据是否正确。
订单源头在数据部,本后台负责设置规则,将规则推送至数据部,数据部负责计算数据,最后将计算好的数据推送给后台。
本次迭代人员安排是,前端1人,后端2.5人(后台接口1.5人,数据部1人),测试1.5人,产品1人。
工期是开发8天,测试3天,总计Bug54个,测试前期1.5天几乎都在配合联调。
本次测试的重点在验证日数据的正确性,难点在于设置的规则和造数据的步骤,规则有三层(本后台一层,其他后台两层),每层规则都有时间区间,三层规则可排列组合,就组合出了很多场景。
整个迭代,简单总结下,一方面是记录下自己的工作过程,另一方面也希望给大家提供一点参考价值,避免踩同样的坑。

一、做得比较好的点

1、做到了按期交付

按道理,这个迭代的业务逻辑还是挺复杂的,规则复杂不说,还跟钱有关,测试起来需要更谨慎,万一计算错误,就是大问题了。
而且项目负责人已经跟业务部门承诺了12月初,上线本期的功能,本次迭代的估期并不是按实际情况来的,而是知道DDL,排除开发日期,剩下的就是测试日期了,没有选择,被迫营业的排期。
项目负责人的期望是,只要保证业务的主要计算流程没有大问题,一些异常的计算规则以及场景可以不完全覆盖,先上线,后续遇到问题再解决,因为这个迭代的结算数据还没有开放给用户,只是供内部人员看,所以即使有问题,也不会造成任何经济损失,修复成本不大。
本着这个原则,覆盖了主体计算流程,就上线了,项目负责人对上线结果还是挺满意的。

2、及时调整测试策略
由于数据源在数据部,每次造数据,都得从源头造起,而且造数据的步骤比较复杂,又不能自己去造,只能依赖于数据部同学,每次一个流程下来,都得15到20分钟的样子,效率很低。
持续了半天之后,发现除了日数据页面,其他页面例如月数据等,直接在后台数据库造就行了,因为只需要验证从数据库到页面的展示逻辑,所以不必从源头造。
后来的测试策略就是,在造源头数据等待的过程中,自己去后台数据库造数据,验证月数据等其他页面的功能,大大节省了测试时间。
在测试过程中,需要根据实际情况实时调整试策略,不断提升测试效率。

二、需要改进的点

1、提测质量

本次迭代涉及的页面共6个,产出Bug共计54个,测试前的1.5天都处于0进度的状态,可以说在配合联调。
以前的项目流程,是在提测前,进行冒演示,如果问题太多是会打回重做的。但是这次由于在周五晚上提测,就没时间演示了,结果周末来加班,发现重点页面即日数据页面,按规则计算的逻辑大概70%是错的。
前期就一直在造数据,验证,修复Bug,再次验证,时间成本是很高的。
后续即使遇到时间很赶的情况,也要按照流程来,否则,结果就是项目负责人以为正在测试阶段,其实还处于联调的阶段,最后统计测试进度,结果不忍直视。

2、原型的细粒度

本次的测试,在日数据页面,有10个跟钱相关的字段,而且每个字段的计算规则不一样,在需求评审阶段,测试同学也没有深入思考计算方式,以为只要按着数据库的字段核对即可,结果发现,很多字段之间是有关联的,比如字段A=由字段B*设置的某个规则比例计算来的。
后来又去找产品同学确认,发现开发同学的很多计算方式与产品期望的不一致,中间也花费了很多时间。
后续对于跟结算相关的字段,可以在需求评审阶段,就将字段的算法确认清楚,开发和测试过程中,按着需求来即可,而不是做了不对,推翻再来,时间成本太高了。
在项目前期,测试同学尽量将需求理解的细一点,将问题提前暴露,秉承测试左移的思想,将Bug扼杀在摇篮里。

3、新人对项目的熟悉度

在造数据的过程中,有个小插曲,由于数据部的同学是新人,首次参与我们这边的项目,在测试中,由于需要支持其他项目,不能全力配合测试同学造数据。
于是找到他的师傅,经过沟通后,发现有更简单的方法,数据部同学与后台开发同学将表做处理之后,测试同学可以直接在后台造数据,从而可以完全释放数据同学了。
所以,在有新同学负责的项目中,当发现整个流程走得特别复杂的时候,可以多问问他的师傅或其他同学,是不是有更优解。

三、与钱相关的两个测试点

1、注意小数点

模拟真实的数据,注意小数点设置,不能只测试整数。
比如在设置某个比例的时候(一般的比例都是保留两位小数),不要只设置整数的比例,需要覆盖小数,曾经在线上看到过一个未处理小数位的Bug。
其次就是结算金额,小数位数的保留,大多数情况下是保留小数点后两位,而且进行四舍五入。

2、数据重跑

结算系统的逻辑大多是本月发上个月的钱,但是对于上个月的钱有疑问的,会调整规则,重跑结算脚本,这个时候,就需要验证重跑后对系统的影响,是否影响已经结算的数据,是否会出现重复数据等等。

不知不觉,这已经是本项目的第三次复盘了,先立个Flag,这个项目每次中大型迭代都会出一个复盘,大家敬请期待~


TAG:

 

评分:0

我来说两句

lc馨馨紫

lc馨馨紫

公众号「lcxinxinzi」,测试工程师|待过大厂|带过创业团队,爱给开发提Bug的测试妹纸一枚,面试资料和大厂内推+V:Icxinxinzi01

日历

« 2024-03-17  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 9655
  • 日志数: 26
  • 建立时间: 2021-10-29
  • 更新时间: 2023-08-02

RSS订阅

Open Toolbar