从测试人员那里我们时常听到一些意见，如这个bug的归属不明确、解决一个问题引进更多的bug、这个bug根本就没有解决。。。
首先我们要明确Bug的生命周期是什么？项目干系人在整个周期的角色是什么？这个问题在下一个话题中说明。在这里我简单说一下目前的现状。从能提交测试版本开始，开发人员在解决一个bug后没有充分的测试便提交了代码，甚至充分的测试后依然会产生意想不到的问题。
我认为对于bug不稳定要从主观和客观两个角度来看待， 既有主观上不认真不负责的问题；也有客观上软件本身复杂的问题，因为其复杂性，问题的根源是多方面的。举个例子当你解决了某一个bug时，你要跟踪所有扇入、扇出部分们的模块是否正常，而这些扇入扇出的模块也许你从来不知道分布在产品的哪一个位置，这些影响也只有在集成层面才会发现。
即使这个bug已经解决了，测试也没有问题，测试人员把它关闭了，他就真的没有问题了吗？早些年有报道Windows 2000操作系统的致命性bugs超过28000多了，我们不去考究数字是否真实，我只是想说我们的测试力度很不够
所以我依然坚持我的观点：
1. 开发人员必须向产品提供BVT和单元测试。 单元测试有效帮助你负责的模块的代码运行期质量；BVT有效帮助你验证产品集成时你的模块的运行期质量；
2. 测试人员必须向产品提供回归测试、集成测试、性能测试等一系列专业测试，只有这样才能全面深刻的发现、挖掘深层次的问题。
我尽所能向大家传播单元测试的思想并在项目中始终如一的贯彻执行，把自己的心得和大家分享，但始终没有在整个项目中推广开来，甚至我在项目的后期也没有办法继续做下去，这里的原因有开发人员自身的问题，也有管理和产品特点的问题，我简单地做了一些分析
测试驱动开发和BVT验证带来的难度分析
1. 执行力度不够
测试驱动开发的优势是多方面的，大家都认可，但是重视不够，执行力度欠缺。
2. 设计能力有待提高
一个问题不同的人有不同的理解，设计上的迥异也很大，我们衡量的标准根据需求的不同而不同，但是好的设计一定是那些权衡利弊的、最符合需求要求的最佳方案。设计能力是每一个开发人员必须面对的挑战。
3. 成本因素
测试代码往往不是直接提交给客户的产品代码，算是一种额外代码，所以常常不被作为一种成本核算范围考虑进来。但是它也是代码，需要人力和时间，与降低成本背道而行，所以在工时制定上有一定的取舍。
4. 计划的强制性
计划的制定是根据整个产品模块的数量、人员、工时、客户需要等来制定，通常来讲都是比较紧张的，如此便给开发人员带来一定程度的压力，直接后果是牺牲质量保进度。
5. 组织机构和历史时期
我举个例子，微软的产品是相当注重质量的，我接触的微软项目的测试比例是 1：1，也就是说开发团队和测试团队的数量一样，甚至还要多些。开发团队包括部署团队、Client团队、Server团队，要求每天至少出一个Build，每次提交代码都必须执行BVT验证；测试部门包括Client测试部、Server测试部、性能测试部。测试部门每天必须提交测试报告。另外我们的产品是一个不断探索、挖掘、稳定、优化、沉淀、再探索的过程，而这一过程会带来一定程度的资源浪费，比如你的核心资源模型推到重来，相应的你的架构设计、代码、单元测试都受到冲击。何时我们的产品形成了一套完善的产品架构、形成了一套稳定的核心资源库，基于此的单元测试、BVT等等质量保证手段才会完全发挥作用，达到事半功倍的效果。
综上所述，测试驱动开发和BVT验证工具研发就成为一个鸡肋，有它更好，没它也行。但我认为可以一步一步的做、先小范围实施再不断扩大。以下几点可以考虑：
1. 在组织机构层面提供支持；
2. 在制定计划时考虑一部分重要、复杂的模块实施单元测试并提供时间、人力的支持；
3. 考虑先在设计阶段和建模阶段实施测试驱动开发的方法；
4. 在项目告一阶段后总结实施的效果、投入的成本、解决问题的能力等，并优化和整理实施过程；
5. 在下一产品开发中复制、验证、调整实施过程；
6. 在下一产品开发中推广实施过程；
归属不明确的bug问题
问题根源参见：数据在上中下游各个层面的使用、协调和责任问题
我对疑难bug的理解是：
1. 归属不明确的bug；
2. 无法解决或解决难度大的问题；
3. 需求有争议的bug；
4. 难以重现的bug；
5. 由第三方引起的bug；
对于疑难bug，有必要通过例会方式，集思广益分析bug问题？