急急忙忙，恍恍惚惚，项目C的2.2版本上线了，又是一次神级别的迭代。简单介绍下，该项目C是一个Web项目，分为前后台，前台供外部用户使用，后台供公司内部人员使用。这次迭代比上次2.0版本的功能多了一倍，但是排期反而被压缩。测试过程中，产品同学不断催进度，一再强调为了冲刺年底的KPI，本次迭代只需保证主体功能没问题，就算测试ok了。
于是测试同学直接提前两天，发完了测试报告，恍恍惚惚的上线了。这个版本明显的感觉就是时间特别紧，特别赶，但是也有很多复盘的地方，下面来趁热分析下，为后续的迭代留下些许的经验。这次迭代是两个同学进行测试，总共六个大模块，一人三个模块，一轮测试进行的很快，问题暴露的也很快。吸取上次迭代的教训，这次同样有与其他项目F的对接功能，优先测试了依赖于项目F的功能，两边配合很顺利，没有阻塞性的大问题，进展顺利。此次迭代的后期，产品同学做了一些关于交互的小修改，但是一般在群里通知，没有及时更新原型。由于群里的消息太多了，有Bug相关的，有确认需求的，消息刷的特别快，之前没有做统一的记录，后续回归起来非常麻烦，时不时就有漏掉的点，所幸的是，最后凭着记忆和聊天记录，确认都修改完毕了。后续有需求修改的，会催促产品同学更新原型，同时自己也会做记录，以便于最后的回归测试。在测试过程中，很多Bug都与字段的合法性相关，比如，没有限制字段的长度，用户填写的字段过长时，会导致页面变形，显示不友好，好多页面都有类似的问题。还有关于字段能否同名的问题，好多字段原型中没有明确说明，但是与产品同学确认的时候，又需要做去重处理。很多页面都有某个字段的搜索项，例如接入方式：PC，Web，但是前后台涉及了6个页面，几乎都不一致，有的选项是PC网页版，有的又是PC，产品同学要求统一起来，因此又修改了很多地方。
本次迭代有个上传功能，但是原型上只要求上传成功，没有要求很多功能细节。比如上传过程中是否能取消，上传过程中是否能替换文件，上传过程中刷新页面文件是否会继续上传等等，后来跟产品同学确认，全部都算Bug，需要修复。这些非功能性的Bug，后续在做需求评审的时候，会主动提出来，秉承 「测试左移 」的思想，让Bug在源头就被消灭。该项目是由我主测，另外一个测试同学辅测，刚好该同学有空，就一起测试了，平时配合的不多，还需要磨合。在测试过程中，提了多个重复的Bug，后来达成一致：各自提Bug前可以先看下禅道，或者直接群里询问是否有过重复Bug，否则提出来好多重复Bug，既浪费了测试同学提Bug的时间，也浪费了开发同学查看Bug的时间。严重等级并不高，91%的是3级Bug，不会阻塞整体流程，但是就是小问题很多。83%都是已解决，7%的是设计如此，3%的不予解决，总体来说，有效Bug占比还是很高的。激活次数为1和2的占比在10%左右，稍微偏高，被重新激活的Bug，开发再次修复，测试再次验证，其实是很影响效率的，而且会影响开发同学的KPI，所以在激活之前，也会很慎重。在代码错误和功能缺陷之间没有做很严格的区分，整体来看，这两个比例占了75%，功能优化的占16%，需求变更占1%，大多数都还是需要修复的影响功能的Bug。在提测前的冒烟演示中，只看了整体流程是否能走通，一些基本的问题都忽略了，后续在冒烟的过程中，会更严格点，争取改善下质量。
本次迭代中，有个页面，在线上验证时报错了，查原因，才发现，这个页面开发同学换了数据库表，但是没有通知测试同学，也没有在提测邮件中说明，导致测试过程中没有覆盖到。后续可以加强团队沟通，在一轮测试完成后，主动找开发同学再次确认，是否有其他模块的修改需要测试。最后，争取每个迭代来个复盘，不断精进，不断成长，见证项目从0到1的成长过程。
我是lc馨馨紫，『在看』、『点赞』、『转发』、『关注』就是最好的鼓励和认可，期待认识优秀的你~