背景
用例，是指具有一定目标的一系列活动的集合。我们可以把用户在系统中执行的一个动作看成一个用例，也可以把用户采用系统完成的一系列工作称为一个用例。用例驱动开发，就是指在软件开发的过程中，以用例为单位，进行需求、实现、测试以及部署的开发模式。此类开发模式的实现方法，实现原则以及优缺点此文不作任何描述。
本人在以前的工作经历中接触过用例驱动开发，同样也接触过其它类似的开发模式，对于开发中经常出现的一些问题略有一些心得，对于测试中出现的缺陷或者BUG的问题觉得我们目前需要解决，所以写此文发表个人意见。
公司现在采用用例主导开发的模式，由于电源排查系统是第一个采用这种模式开发的系统，所以难免会有很多问题。下面我将通过这一段时间自己的所见所想总结的一些个人看法进行表述，完全出自为了把工作做的更好，不带有任何个人攻击。
问题
经过一段时间的研究和总结，个人认为我们目前的问题主要存在两个方面。
第一，问题定义不清晰。
目前我们在测试过程中将测试人员认为有问题的部分都定义为“缺陷”，没有明确指出这个问题到底是缺陷还是BUG，当然在英文中缺陷也可以翻译成BUG，在软件中缺陷也可以理解成为一种特殊的BUG。但是我们在开发过程中有必要明确缺陷和BUG的区别。
缺陷在汉语词典中的定义“瑕疵，缺点，欠缺，不完美。”在软件开发中通常意义上，缺陷是指软件中存在的一些非功能性功能的不完美。也就是说，缺陷是指并不影响软件的功能实现，只是把一些非功能性功能的实现的不是最完美。那么因为没有明确的“完美”定义，所以缺陷可以理解为具有模糊性的特点。然而，BUG的定义则是指软件中存在确定性的问题，没有按照需求用例实现或者是不能圆满完成需求用例等等问题。BUG具有明确的依据，所以BUG具有明确性的特点。
软件中存在的BUG需要无条件及时需改，但是缺陷的处理则需要考虑项目成本，开发时间以及客户资源等等一系列问题而定。
第二，确认流程不合理。
目前我们的流程是测试人员将所有的“缺陷”录入到Scarab上，由SA来确定缺陷是否要修改以及提出需改意见，然后再由开发人员进行修改。这样的话，SA在开发过程中牵扯的精力过多。一个SA可能会跟踪多个项目，主要负责前期的需求调研、整理以及业务架构的设计，后期主要负责客户需求的变更和管理。当SA完成一个项目的前期工作后，就可以接手下一个项目了。在项目实现阶段尽量的减少SA的工作有利于其它项目的开展。
如果第一个问题能够解决，那么在测试中直接区分缺陷和BUG，对于BUG直接由TA领导解决，对于缺陷则是由SA领导进行解决，这样可以减轻SA的部分工作，并且能够明确开发流程。
解决方式
1、测试先行
在开发开始的环境，让测试人员提前介入项目，在需求讨论或者SA在需求整理和业务逻辑设计时就有测试人员跟进，这样的话测试人员能够更准确的把握需求，从而为BUG和缺陷的划分打下基础。
对于目前测试不能明确BUG和缺陷的原因主要就是上面的原因造成。除此之外我们需要加强测试人员整理技能。
2、明确定义缺陷和BUG
对于现有的“缺陷”进行划分，明确指出那些是BUG那些是缺陷，让TA只关注BUG，让SA只关注缺陷。
3、缺陷的等级制度
建立缺陷等级制度，就是说针对不同的缺陷在确认过程中，根据项目的总体成本，进度，以及时间安排等等对缺陷进行等级处理。
缺陷可以分为一二三级，一级为对项目影响比较大的，修改这个缺陷需要投入一定量的人力和时间成本，所以需要和客户进行沟通的，考虑增加项目额或者重新立项，此类缺陷主要表现在功能性上；二级为对项目影响比较小，能够快速修改完成，可以通过协助TA进行修改，此类缺陷主要表现在操作性上；三级为对项目基本上没有影响，可以直接修改完成，此类缺陷主要是表现上的。
优缺点分析
当然任何事情都是一把双刃剑，既有优点同时也会带来缺点，但是如果从优缺点的对比去衡量的话，才能够真正确定事情的好与坏。
以下前两条为“缺陷”明确划分为BUG和缺陷带来的好处，最后一条是存在的弊端。
1、提高开发效率
通过对缺陷进行分类，做到不同的问题不同对待，简化开发流程，减轻SA的开发中的工作，让SA能够抽出更多的精力完成其他向的开发。
通过对缺陷进行分类，可以让TA在迭代中明确当前的问题，明确迭代的界限，提高开发的效率。
2、明确各个角色的职责
通过对缺陷的分类可以让开发中的每个角色更好的完成自己的工作。可以让SA更专注于业务和需求以及客户，让TA更关注与开发实现。而测试人员则更好的把精力投入到软件功能性和稳定性的测试活动中来。
3、对测试人员的要求比较高
需要测试人员明确BUG和缺陷的界定，这样对于测试人员的经验和技能都有一定的要求，需要好的测试人员完成测试工作。
总结
总之，现在我们实行的“缺陷”模式是具有一定的问题的，需要我们尽快解决，这样才能让我们的开发流程更加完善，才能让软件开发更上一层。
