Auction网上拍卖项目纪实--Day 33-39

前情回顾:Auction网上拍卖项目纪实—Day 26-32用户身份认证,交付定金,退定金等功能模块在Day32通过了正常使用流程的测试,剩下的未测试未上线功能只有拍卖叫价部分流程与使用定金抵消部分订单消费的流程(以下简称抵扣消费流程),一切依然在控制中。

Day33,将用户身份认证,交付定金,退定金等功能正式上线后p.tiebaoebi.com,赶紧安排测试小妹在正式环境验证所有流程的测试用例,测试没有问题后接着准备其他非正常操作的测试用例继续测试,其他人都在处理还在继续更改的没完没了的各种需求点,弱爆的产品经理B因为缺乏经验,无法把控项目需求入口,前期没有做好完善成体系的需求设计造成大量的工作无法衡量与量化。

Day34-35,与测试小妹简单过了下非正常操作的测试用例没什么问题,经过测试小妹一轮测试后发现了很多管理后台操作流程上的漏洞,于是组织A君,B君跟我一起增加管理后台操作上的一些逻辑限制避免各种流程交叉操作造成的坏数据,接着根据产品经理A,B的需求点把一些网站前台用户体验不好的地方都做了修整。接着又是一轮测试,上线终于让线上版本可以稳定正常使用。

Day36-37,线上的功能稳定后,我接着把上线分出的正式发布分支上相关的修改合并到目前的trunk上,安排B君处理一些各种小需求点和小bug,然后跟A君,测试小妹讲抵扣消费的流程的各种逻辑的处理方法,安排A君完成管理后台的相关功能、测试小妹准备抵扣消费的测试用例,最后跟总监核对成功产生订单后触发产生抵扣消费的处理方式,让总监在产生订单后帮忙一并处理掉。到这里所有的主要功能逻辑已经贯通,心里一阵轻松。所有工作准备就绪后找总监帮忙分担一些压力,这时候总监还有一些比较麻烦的技术方案未确定:处理拍卖倒计时的时间同步,cometd服务部署方案,拍卖大厅的卖品、卖品叫价数据查询性能的问题。

分别提供以下的方案并投入使用:
处理拍卖倒计时的时间同步。本地倒计时时间,需要服务器的推送数据每次带上最新的服务器时间以矫正,同时如果倒计时时间偏差太大(本地时间与服务器时间的差值,对比,倒计时与服务器时间的计算差值)定时判断来主动请求服务器时间。
cometd服务部署方案。1分布式部署,每个单台服务器直接通过网关对外网推送。2主备部署,当服务主机发生故障服务转移到备机。(目前的服务压力不会成为瓶颈作为前期方案比较合适,被使用)。
拍卖大厅的卖品、卖品叫价数据查询性能。所有元数据从数据库获取,并缓存,所有叫价信息与卖品的最高价,状态等显示要强一致性的数据需要在redis中存储最新的版本,每次与缓存的元数据组装成需要的数据。

Day38,大家解决了前面的所有bug,需求,流程漏洞,技术难点,所有的功能都开发完毕,总监实现叫价部分的核心功能也妥妥的可以投入测试。公司内部组织了一次内测拍卖,模拟所有的功能没有大问题,一共成交1029元,有一种修成正果的感觉。

Day39,技术部今天只有总监,A君,B君和我,产品与测试人员收集了内测中的所有问题都需要处理,因为问题不多也不大很快处理完了。经过最后一轮处理后,整个项目的功能开发基本完成,后面的一周准备安排几轮所有功能的测试以保证功能稳定,然后准备一个新的线上环境测试,切换域名到测试无误的新环境。

Day39,下午六点多,市场人员还在忙碌线下的工作,技术部都找到了合适的借口默契地陆续地低调地早早走了。



本作品采用知识共享署名 4.0 国际许可协议进行许可,欢迎转载内容并请注明出处
《Auction网上拍卖项目纪实--Day 33-39》 http://io97.com/2014/11/02/10016.html