这里说一个开发流程很小的问题，标题取得有点吓人，所谓‘哗众取宠“，娱乐一下。

开发过程中，有一个名词叫缺陷曲线，就是指提交测试后，随着时间推移缺陷的严重性和数量分布问题。

很多不规范团队很少关注这个，反正有缺陷就解决呗，直到没有缺陷（或者有时间压力的会说有多少缺陷以下）就发布。

举个搞笑极端的例子，一个团队假如规定每月只允许某天发布一次，然后测试不愠不火的测着，每到发布当天突然就发现一个较大缺陷，发布自然延迟，这样一个开发10天的需求由于这种规定和测试方法，几个月都没上线。说这个例子极端，就是说假设开发自测也太不够。但抛开这个，一个这么小的需求，每次都在发布当天才提出一个大缺陷，每个月的前面20多天测试干嘛去了呢？

抄一张图先

这个图别人的，可能是统计缺陷数量，但也代表一个测试规范，就是提缺陷也是要有这个曲线的，假如一个月的测试时间，你得在前面十几天把原生缺陷全部找出来，否则就要承担延期责任，因为后面十几天需要回归和解决延生缺陷。你不能到29号还提出原生还重大缺陷（或者需求缺陷），要求开发在30号修复完成然后发布。

不规范团队容易忽视这个问题，而且容易把责任推到开发身上，作为一个开发人员，吃了太多这个亏，特此备注一下。愿天下可怜的程序员们周末愉快！