ECMBoss企业内容解决方案项目系列之（六）那些不得不说的Defect

       Defect，中文翻译为缺点；不足之处。是指在项目开发过程中隐藏着的一些未被发现的缺陷或问题，又名Bug。Defect存在于软件整个生命过程中，从软件创建开始，到软件生命周期结束，Defect会一直存在。我们平时所说的没有Defect，是指消除了已经发现的Defect。

       Defect的数量会随着软件开发过程，由少到多，再由多到少。软件创建初期，各个功能模块主要搭建框架，重点在于流程的可行性，此时Defect粒度较大，数量较少。在软件创建中期，各个模块主体流程基本开发完毕，开发重点由框架转移到数据准确性上，开发任务细化到需求跟踪矩阵上，此时Defect粒度最细，从而发现的数量也最大。在软件开发末期，软件开发基本进入尾声，随着开发人员不断修复Defect，Defect的数量越来越少。直至已测试出的Defect全部消灭掉。

       在软件开发初期，软件的开发重点在于框架的搭建，以及流程的可行性，此时Defect的粒度最大，主要针对1级功能点。软件测试人员主要根据各个模块的流程是否可正常运行，来开相应的Defect。此时的Defect数量较少，但是工作量都较大，开发的Defect通常都是由需求不明确而引起的。

       在软件开发前期，软件的开发主要在于各功能菜单的实现，这里不单单指菜单的实现，而是指各功能模块包含的一系列的菜单的功能的集合。此时的开发任务较明确，软件开发人员主要工作任务在于流程的细化，主要是对流程进行详细的控制，用大众化的语言来讲，就是为流程添加限制条件。此时的Defect相对于前期粒度较细，数量更多，主要针对对象是二级功能点。修复这些Defect的工作量通常要比软件开发初期少一些，但是比软件中期要多些。

       在软件开发中期，软件开发除了要流程上可行，功能上可用之外，还要确保数据的正确性。此时软件开发任务的详细程度都是根据需求跟踪矩阵进行的，某个功能点是否开发，限制条件有哪些，都要严格按照需求跟踪矩阵来进行。这时的开发粒度最细，从而提出的Defect粒度也最细，主要针对三级功能点。因为标尺的衡量粒度细，所以网出的Defect也最多。但是这些Defect的修复速度却是最快的，每天修复20~30个Defect，是轻而易举的事情。

       在软件开发末期，软件的测试由测试人员转移到客户手中，这时候才是衡量一个功能点是否真的可用的时候。有些功能我们觉得细化了好，但是客户不喜欢用，只好将原来修复的Defect再转换为“Defect”，以供客户使用，谁让客户是上帝呢！

       在软件开发整个过程中，Defect的提出以需求测试为主，因为软件开发人员发现了Defect就直接处理掉了，不会留给需求测试人员来抓小鞭子的。但是通常一组功能在软件开发人员未完全开发完毕，需求测试组就介入其中，一是防止开发人员走偏；二是抓紧项目的上线。所以，Defect在软件开发过程中，会经常高频率的出现在软件开发人员手中。