前言
　　在我的上一篇文章《如何提高送测版本的质量？》中，简单概括了从全局应该如何考虑，以及我们测试人员对于送测版本质量的提升能做些什么，再说一下作为开发人员，从哪些方面进行考虑。以下的看法是基于我所在公司的业务现状而发，如果您有更好的看法，欢迎来探讨。
　　公司背景
　　我所在的公司是青岛一家本地公司，不过版本管理流程来讲，我想业内很少有公司能有我们公司这么清晰地流程和规范，下面附了一张图。但目前公司里版本相关的问题仍然很多（下面会举一些例子）。目前公司使用SVN管理源码。所做的项目是软硬件集成，有几个大项目（由多个子项目集成），项目是迭代开发模式。　　版本发布过程中存在的一些问题
　　① 带风险上线：版本送测后，测试人员发现了一些一般和轻微的bug，但项目经理考虑到客户对版本中的主要功能需求比较急，带着这些bug上线了。之后因为各种各样的原因，导致这部分bug一直没有修改，长期遗留。
　　② 代码合并时没有正确处理冲突，版本冒烟测试不通过。
　　③ 打增量包时遗漏了部分打包项（如jar包）。
　　④ 测试环境跟用户使用环境有差异，导致部分问题无法在测试环境发现。
　　⑤ 在部分bug上花费大量时间排查原因，或者在某个技术研究上花费超过预期的时间。
　　⑥ 当多个子系统相互依赖，可能导致某个子系统发版本时，需要等待另一个子系统也发出对应版本，这样版本间形成等待关系，后可能导致上线延迟。
　　⑦ 版本质量差，每次发版本都发现改出新问题，导致版本迟迟不能上线。
　　针对以上问题的分析和应对措施
　　① 上线前，项目经理明确哪些bug需要处理，哪些需要遗留，如果遗留要做原因说明，并给出解决时间。测试部将遗留的bug在测试报告中说明，并定期跟踪遗留缺陷。
　　刚来公司的时候，bug管理工具中遗留了大量的bug，有些甚至是两三年之前的。发现这个问题后，我初的想法是每周发个bug状态跟踪邮件，引起项目经理重视，也希望通过引起他们的重视来推动遗留bug的解决。但操作了一段时间后发现这种方式收效甚微。考虑了一下，觉得这种工作方式本身缺乏推动性，所以换了一个方式，即内部先将bug又验证了一遍，然后每个项目都找到项目经理，逐条bug核对，把bug分成要解决（要给出解决时间）、不解决（说明原因）、测试和开发不能达成一致（需要分别列出开发和测试的理由，之后让领导决定）。。。这种方式更有目标导向，也更能真正推动问题的解决。
　　② 版本合并时出问题，多数原因都是某个开发合并时不仔细导致，出现冲突后大概浏览了一下别人的代码，觉得好像没问题合并了，从而导致合并出现问题。——也许让一个不懂代码的人来符合代码合并效果都会比程序员效果好得多。这样的问题，项目经理可以考虑专人负责合并代码，并且在模块分工时尽量保持一致（即自己开发的模块自己修改），还可以根据需要，制定配置管理的指南，定期培训。
　　③ 明确打包的内容。对于复杂的项目，可以召集相关的人一起沟通确认。并且打包完成后进行冒烟测试（这需要留给开发充足的时间进行自测）
　　④ 针对这种问题，没有特别有效的预防措施。不过在问题出现后需要进行分析总结，在以后开发时进行注意。 有条件的话还可以用客户的环境进行验证。
　　⑤ 这个问题上，如果短时间内没有思路，不妨多找公司里技术大牛沟通一下，也许别人已经有过类似的经验或者技术研究了呢。
　　⑥ 做好沟通。虽然设计文档写清楚也是一种方法，不过这种方法效率过低，并不是每个公司都适用。
　　⑦ 问题分级，有时候我们不得不做出牺牲。
　　总结
　　出现问题不可怕，重要的是多进行分析，分析的时候不要浮于表面。然后根据分析的结果来制定对应的措施。比如有的问题需要通过制定指南、完善流程来解决，那去做，把它们作为解决问题的参考，并在工作中固话下来；也有的问题是个人意识方面的问题，比如有的人工作经验较欠缺，那通过多做培训多指导来提升意识；或者有的问题需要公司EPG明确版本应怎么做，流程应怎么走，那么EPG需要制定明确的流程规范来指导大家怎么做。