趕在多年難遇的對稱日20211202，項(xiàng)目V2.3版本上線了，急急忙忙，加班加點(diǎn)，終于按期交付，直呼不容易。
該項(xiàng)目是一個Web類型項(xiàng)目，分為前臺和后臺。本期主要是結(jié)算相關(guān)的功能，后臺給用戶設(shè)置各種結(jié)算規(guī)則，驗(yàn)證日收益，月收益，賬單數(shù)據(jù)是否正確。
訂單源頭在數(shù)據(jù)部，本后臺負(fù)責(zé)設(shè)置規(guī)則，將規(guī)則推送至數(shù)據(jù)部，數(shù)據(jù)部負(fù)責(zé)計(jì)算數(shù)據(jù)，最后將計(jì)算好的數(shù)據(jù)推送給后臺。
本次迭代人員安排是，前端1人，后端2.5人（后臺接口1.5人，數(shù)據(jù)部1人），測試1.5人，產(chǎn)品1人。
工期是開發(fā)8天，測試3天，總計(jì)Bug54個，測試前期1.5天幾乎都在配合聯(lián)調(diào)。
本次測試的重點(diǎn)在驗(yàn)證日數(shù)據(jù)的正確性，難點(diǎn)在于設(shè)置的規(guī)則和造數(shù)據(jù)的步驟，規(guī)則有三層（本后臺一層，其他后臺兩層），每層規(guī)則都有時(shí)間區(qū)間，三層規(guī)則可排列組合，就組合出了很多場景。
整個迭代，簡單總結(jié)下，一方面是記錄下自己的工作過程，另一方面也希望給大家提供一點(diǎn)參考價(jià)值，避免踩同樣的坑。
一、做得比較好的點(diǎn)
1、做到了按期交付
按道理，這個迭代的業(yè)務(wù)邏輯還是挺復(fù)雜的，規(guī)則復(fù)雜不說，還跟錢有關(guān)，測試起來需要更謹(jǐn)慎，萬一計(jì)算錯誤，就是大問題了。
而且項(xiàng)目負(fù)責(zé)人已經(jīng)跟業(yè)務(wù)部門承諾了12月初，上線本期的功能，本次迭代的估期并不是按實(shí)際情況來的，而是知道DDL，排除開發(fā)日期，剩下的就是測試日期了，沒有選擇，被迫營業(yè)的排期。
項(xiàng)目負(fù)責(zé)人的期望是，只要保證業(yè)務(wù)的主要計(jì)算流程沒有大問題，一些異常的計(jì)算規(guī)則以及場景可以不完全覆蓋，先上線，后續(xù)遇到問題再解決，因?yàn)檫@個迭代的結(jié)算數(shù)據(jù)還沒有開放給用戶，只是供內(nèi)部人員看，所以即使有問題，也不會造成任何經(jīng)濟(jì)損失，修復(fù)成本不大。
本著這個原則，覆蓋了主體計(jì)算流程，就上線了，項(xiàng)目負(fù)責(zé)人對上線結(jié)果還是挺滿意的。
2、及時(shí)調(diào)整測試策略
由于數(shù)據(jù)源在數(shù)據(jù)部，每次造數(shù)據(jù)，都得從源頭造起，而且造數(shù)據(jù)的步驟比較復(fù)雜，又不能自己去造，只能依賴于數(shù)據(jù)部同學(xué)，每次一個流程下來，都得15到20分鐘的樣子，效率很低。
持續(xù)了半天之后，發(fā)現(xiàn)除了日數(shù)據(jù)頁面，其他頁面例如月數(shù)據(jù)等，直接在后臺數(shù)據(jù)庫造就行了，因?yàn)橹恍枰?yàn)證從數(shù)據(jù)庫到頁面的展示邏輯，所以不必從源頭造。
后來的測試策略就是，在造源頭數(shù)據(jù)等待的過程中，自己去后臺數(shù)據(jù)庫造數(shù)據(jù)，驗(yàn)證月數(shù)據(jù)等其他頁面的功能，大大節(jié)省了測試時(shí)間。
在測試過程中，需要根據(jù)實(shí)際情況實(shí)時(shí)調(diào)整試策略，不斷提升測試效率。
二、需要改進(jìn)的點(diǎn)
1、提測質(zhì)量
本次迭代涉及的頁面共6個，產(chǎn)出Bug共計(jì)54個，測試前的1.5天都處于0進(jìn)度的狀態(tài)，可以說在配合聯(lián)調(diào)。
以前的項(xiàng)目流程，是在提測前，進(jìn)行冒演示，如果問題太多是會打回重做的。但是這次由于在周五晚上提測，就沒時(shí)間演示了，結(jié)果周末來加班，發(fā)現(xiàn)重點(diǎn)頁面即日數(shù)據(jù)頁面，按規(guī)則計(jì)算的邏輯大概70%是錯的。
前期就一直在造數(shù)據(jù)，驗(yàn)證，修復(fù)Bug，再次驗(yàn)證，時(shí)間成本是很高的。
后續(xù)即使遇到時(shí)間很趕的情況，也要按照流程來，否則，結(jié)果就是項(xiàng)目負(fù)責(zé)人以為正在測試階段，其實(shí)還處于聯(lián)調(diào)的階段，最后統(tǒng)計(jì)測試進(jìn)度，結(jié)果不忍直視。
2、原型的細(xì)粒度
本次的測試，在日數(shù)據(jù)頁面，有10個跟錢相關(guān)的字段，而且每個字段的計(jì)算規(guī)則不一樣，在需求評審階段，測試同學(xué)也沒有深入思考計(jì)算方式，以為只要按著數(shù)據(jù)庫的字段核對即可，結(jié)果發(fā)現(xiàn)，很多字段之間是有關(guān)聯(lián)的，比如字段A=由字段B*設(shè)置的某個規(guī)則比例計(jì)算來的。
后來又去找產(chǎn)品同學(xué)確認(rèn)，發(fā)現(xiàn)開發(fā)同學(xué)的很多計(jì)算方式與產(chǎn)品期望的不一致，中間也花費(fèi)了很多時(shí)間。
后續(xù)對于跟結(jié)算相關(guān)的字段，可以在需求評審階段，就將字段的算法確認(rèn)清楚，開發(fā)和測試過程中，按著需求來即可，而不是做了不對，推翻再來，時(shí)間成本太高了。
在項(xiàng)目前期，測試同學(xué)盡量將需求理解的細(xì)一點(diǎn)，將問題提前暴露，秉承測試左移的思想，將Bug扼殺在搖籃里。
3、新人對項(xiàng)目的熟悉度
在造數(shù)據(jù)的過程中，有個小插曲，由于數(shù)據(jù)部的同學(xué)是新人，首次參與我們這邊的項(xiàng)目，在測試中，由于需要支持其他項(xiàng)目，不能全力配合測試同學(xué)造數(shù)據(jù)。
于是找到他的師傅，經(jīng)過溝通后，發(fā)現(xiàn)有更簡單的方法，數(shù)據(jù)部同學(xué)與后臺開發(fā)同學(xué)將表做處理之后，測試同學(xué)可以直接在后臺造數(shù)據(jù)，從而可以完全釋放數(shù)據(jù)同學(xué)了。
所以，在有新同學(xué)負(fù)責(zé)的項(xiàng)目中，當(dāng)發(fā)現(xiàn)整個流程走得特別復(fù)雜的時(shí)候，可以多問問他的師傅或其他同學(xué)，是不是有更優(yōu)解。
三、與錢相關(guān)的兩個測試點(diǎn)
1、注意小數(shù)點(diǎn)
模擬真實(shí)的數(shù)據(jù)，注意小數(shù)點(diǎn)設(shè)置，不能只測試整數(shù)。
比如在設(shè)置某個比例的時(shí)候（一般的比例都是保留兩位小數(shù)），不要只設(shè)置整數(shù)的比例，需要覆蓋小數(shù)，曾經(jīng)在線上看到過一個未處理小數(shù)位的Bug。
其次就是結(jié)算金額，小數(shù)位數(shù)的保留，大多數(shù)情況下是保留小數(shù)點(diǎn)后兩位，而且進(jìn)行四舍五入。
2、數(shù)據(jù)重跑
結(jié)算系統(tǒng)的邏輯大多是本月發(fā)上個月的錢，但是對于上個月的錢有疑問的，會調(diào)整規(guī)則，重跑結(jié)算腳本，這個時(shí)候，就需要驗(yàn)證重跑后對系統(tǒng)的影響，是否影響已經(jīng)結(jié)算的數(shù)據(jù)，是否會出現(xiàn)重復(fù)數(shù)據(jù)等等。
不知不覺，這已經(jīng)是本項(xiàng)目的第三次復(fù)盤了，先立個Flag，這個項(xiàng)目每次中大型迭代都會出一個復(fù)盤，大家敬請期待~
ps：我是lc馨馨紫，全網(wǎng)名稱統(tǒng)一，期待優(yōu)秀的你關(guān)注我~
原創(chuàng)文章，轉(zhuǎn)載請注明出處~
