关于测试的规范性与重要性，结合以往经验，做了几点简单的思考，现记录如下
1、BUG修改之后，在转测试回归之前，开发内部要自行验证。
这个是传统了，不过建议不要只依赖现有的readmine系统（公司的一个BUG管理系统），因为其内置的流程，只支持一个人审核问题，这样往往不够准确，有可能回归不通过。所以建议自行用EXCEL进行跟踪，关键是进行两轮甚至多人审核，这样可以降低回归不通过的概率。
这里有2点值得总结，首先是2轮审核的流程，其次是不依赖现有的BUG管理系统。这个是有道理的，如果没有BUG管理系统，BUG是否不跟踪了呢？所以任何系统只是工具，起到辅助的作用，关键还是对BUG进行跟踪管理的意识
2、BUG修改之后，在DTS中填问题单处理过程，要注意规范。
这点我有些不是很认可，因为我还没有认识到规范填写问题单的价值。不过从另外一个角度想，对于已经比较成熟的团队，可能可以不依赖这种管理手段。但是鉴于目前我们开发团队还比较年轻，这些管理手段是必要的。姑且不论规范填写问题单，给BUG管理本身可以带来多大价值，至少通过要求员工规范填写问题单，可以培养员工的执行力，这对促进团队的成熟是很有帮助的。
团队越成熟，配合越默契，管理成本就越小，所需的管理手段就越少。反之，当团队还不成熟，员工普遍能力较弱的时候，这些管理手段也就是必要的
3、关于转测试
测试文档，包括“版本说明书”、“安装/升级指导书”、“测试建议”、“冒烟测试结果”、“遗留问题说明”
这些文档，涉及到转测试流程的管理，请看测试驱动开发——我们要的不仅仅是“质量”（转51testing）
4、版本发布规范
版本规范中提到一点，未经测试的版本，不允许发出。这点很关键，值得单独记下来。
未经测试的版本不能发布，这个原则是很简单的，但是可以引申
4.1、版本A已经转测试了，测试过程中发现了一个问题，这个时候能不能用xxx.class替换掉呢？
肯定不行，所谓的版本，应该是一个完整的包。如果直接替换文件，那么已经不能保证包的完整性，这个替换后的版本，就等于是一个新的未经测试的版本。在替换之前的测试，严格来说等于是无效的。要发出去，就要重新测一遍。
正确的做法，是把这个问题作为一个遗留问题，评估其影响，写在遗留问题列表中。版本还是正常发出去，这个问题可以在之后修改，合入下一个版本进行测试。如果问题很严重，是版本的严重缺陷，不能外发，那么可以增加一轮测试，回归之后再发布
4.2、版本A转测试，测试结束之后，测试可以找开发要一个新的包，发布出去吗？
不可以，因为这个新的包，不能保证和测试的版本完全一致，那么这个新的包，也就是一个未经测试的版本
正确的做法，应该是把测试的版本发出去。即：转测试时是什么版本，测试结束之后就发什么版本
4.3、现场发现了几个问题，开发提供的补丁只有几个文件而已，可以不打标签，直接发出去吗？
不可以，所谓的版本，除了“完整性”之外，还需要一个“可标识性”，就像数据的主键一样，能够唯一标识一个版本。没有“可标识性”，就称不上是一个版本。一个版本只要发布了，就存在需要定位问题、回退的可能。如果没有打标签，当需要定位问题，或者日后需要回退的时候，就做不到了
正确的做法，是只要发了版本，就一定要在代码库上打上标签。可以是用版本号打标签，比如b010，spc001；也可以用时间打标签，比如tag_20120719
打了标签之后，在任何时候，无论是要搭建现场的镜像环境，或者回滚，或者比较两个版本的差异制作升级包，都可以做到了