本周，给大家分享的还是项目复盘，本次是项目V2.4版本的复盘。
项目背景：该项目是一个Web类型项目，分为前台和后台。本期主要是数据报告相关的功能，其实逻辑很简单，验证从数据库表到页面的展示逻辑，主要是根据多个字段进行分组求和，验证数据展示正确即可。
本次涉及6个页面，后台的3个页面，每个页面有18个字段，前台3个页面，每个页面大概5个字段。
人员和工期安排：1.5个后端人员，1个前端人员，1个测试人员，1个产品人员，开发3个工作日，测试4个工作日，产生Bug共计45个，质量有点堪忧。
从项目负责人的角度来分析下：
一、测试工期偏长
理论上，大多数情况下，测试时间是开发时间的1/3即可，从这个项目来看，逻辑也不复杂，唯一费时的可能就是造数据和核对字段花费点时间。
但是实际情况并不是这样，测试同学几乎一直在提Bug，验证Bug，激活Bug。这里在项目复盘的时候，测试人员需要提出来，时间到底花在哪里了。
否则，项目管理人以为质量还行，测试同学多估了时间，再说，抛出问题之后，项目管理人也可以有针对性的解决问题，让团队处于一个比较良性的循环状态。
二、质量惨不忍睹
没有复杂逻辑，主要的功能就是列表展示，查询，汇总和下载数据。6个页面，可以产出45个Bug，而且重新激活的Bug多达5个，Bugfix引入的也有5个，这个质量，可以说是比较差的了。
分析了下Bug，主要集中在字段显示不全，字段取值错误，下载数据错误，搜索结果错误，分页问题，小数点位数处理问题，默认字段展示错误，字段显示顺序与原型不一致，缺少搜索和排序功能等等。
上面是Bug数量的问题，其次，关于Bug修复质量的问题也不乐观，重新激活和Bugfix引入的数量，可以间接考察开发同学修复Bug的质量，小tips：很多公司将这两个指标纳入开发同学的KPI考核指标中。
思考了下里面的原因：
1、每个页面长的很像，而且字段太多了，开发同学改代码出错在所难免
中间出现过一个很懵的现象，就是第一版显示表头的字段正确，但是值不正确，第二版值和字段都正确了，第三版改其他页面，把这个页面的所有字段全改了，表头字段和值全不对，结果推翻再来，重新再修复一遍。
2、提测确实有点草率
本次迭代，没有进行冒烟演示就直接开始测试了，结果就是，随便一点就是Bug，下期得反馈下，冒烟流程还是得走，而且还得走的细一点，否则走了也就是个形式，提升质量的目的还是没有达到。
这个小版本就说这么多了，期待下一次版本的新风貌~
ps：我是lc馨馨紫，全网名称统一，期待优秀的你关注我~
原创文章，转载请注明出处~
