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

原创 lc馨馨紫程序员馨馨

赶在多年难遇的对称日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，这个项目每次中大型迭代都会出一个复盘，大家敬请期待~

项目复盘系列参考文章：

欢迎扫码围观测试群：

继续滑动看下一个