求(si)论(bi),如何改进项目开发当中的部分环节，从而减少上线后的 Bug？

[kepenj]

上线后的产品出现Bug，一直都是每个团队或者公司头疼的事情。
Bug有可能出现在产品设计上、也有可能出现在程序开发中（不是黑，但是大多情况下都在这块...）、也有可能是测试的疏忽，总之这个Bug送到了用户手上，也让用户find的出来，这无疑是对公司或者团队的打脸。
“Bug是不可避免的”，“没有哪一款程序是没有Bug的” ...当然，po猪发这个帖子就是想咨询一下大家：如何改进项目开发当中的部分环节，从而减少上线后的Bug？

po猪现在能想到的是，开发加入TDD，测试阶段引入自动化； 增加开发和测试的周期； （当然TDD和自动化的加入成本比较高，所以更多的也是考虑到周期的增加.... - -|| ）

[moro]

bug是不可避免的，
可以增加一个线上测试版本。

[laoertongzhi]

开发前： 要求产品提供详细的PRD和流程图 ， 增加需求评审环节 。在需求评审之前至少提前一天将PRD和流程图发给研发，让研发消化，以便能够在评审会上提出所有有疑问的地方；

开发中： 不知道 …… （非程序猿）

测试ing：研发内部测试 —— 测试环境测试 ——预发布测试（线上真实数据）—— 正式上线

[kepenj]

@moro po猪团队规模较小，就公司而言无法发动内部的大规模测试；部分核心用户的测试量也较少。 po猪可能比较需求能在开发和测试这个阶段去定位或者覆盖，有没有好的一些平台或者工具或者方案去处理这些呢？

[lionyue]

灰度发布两三个版本，收集bug，解决bug，然后再发布

[kepenj]

@lionyue 我理解那就是快速迭代～缩短每个版本的周期。 but 个人认为这种方式有点适用于刚成型的产品。

[fangjinmin]

正确的做法是这样的，对每一个阶段的工作都做review。首先设计和构架完成后， 开发人员一起review，如果有问题，修改到没有为止。第二阶段，编码。规范编码的归程，大家都要遵守，编码后，代码也要review， 检查有没有明显逻辑上的错误或者误输入。第三阶段就是重中之重的测试了。测试分为几轮，unit测试，集成测试和系统测试。尽可能地测试出BUG。从软件工程学上来说，设计，编码和测试所要的时间应该接近于1：1：1，哪个环节少了，都会出问题。问题是越早暴露越好。如果设计的问题，到了系统测试才暴露出来，那改动将是非常之大。

[lionyue]

@kepenj 不是快速迭代，灰度发布是指小范围内发布，通过crash监测、用户反馈、用户回访等方式发现bug，灰度发布几次后，如果bug率降到你们能承受的范围，就可以正式发布了