主管一席话引发的思考

昨天主管召集开会，讲了一些事情，摘录其中我认为有价值的，在此记录一下：

1、BUG修改之后，在转测试回归之前，开发内部要自行验证。这个是传统了，不过主管建议不要只依赖现有的DTS系统（公司的一个BUG管理系统），因为其内置的流程，只支持一个人审核问题，这样往往不够准确，有可能回归不通过。所以主管建议自行用EXCEL进行跟踪，关键是进行两轮审核，这样可以降低回归不通过的概率。

这里有2点值得总结，首先是2轮审核的流程，其次是不依赖现有的BUG管理系统。这个是有道理的，如果别的公司没有BUG管理系统，BUG是否不跟踪了呢？所以任何系统只是工具，起到辅助的作用，关键还是对BUG进行跟踪管理的意识

2、BUG修改之后，在DTS中填问题单处理过程，要注意规范。

这点我有些不是很认可，因为我还没有认识到规范填写问题单的价值。不过从另外一个角度想，对于已经比较成熟的团队，可能可以不依赖这种管理手段。但是鉴于目前我们开发团队还比较年轻，这些管理手段是必要的。姑且不论规范填写问题单，给BUG管理本身可以带来多大价值，至少通过要求员工规范填写问题单，可以培养员工的执行力，这对促进团队的成熟是很有帮助的。

团队越成熟，配合越默契，管理成本就越小，所需的管理手段就越少。反之，当团队还不成熟，员工普遍能力较弱的时候，这些管理手段也就是必要的

3、关于转测试

主管提到了几个文档，包括“版本说明书”、“安装/升级指导书”、“测试建议”、“冒烟测试结果”、“遗留问题说明”

这些文档，涉及到转测试流程的管理，以后有空单独写一篇帖子来说明

4、版本发布规范

主管提到一点，未经测试的版本，不允许发出。这点很关键，值得单独记下来。

未经测试的版本不能发布，这个原则是很简单的，但是可以引申

4.1、版本A已经转测试了，测试过程中发现了一个问题，这个时候能不能用xxx.class替换掉呢？

肯定不行，所谓的版本，应该是一个完整的包。如果直接替换文件，那么已经不能保证包的完整性，这个替换后的版本，就等于是一个新的未经测试的版本。在替换之前的测试，严格来说等于是无效的。要发出去，就要重新测一遍。

正确的做法，是把这个问题作为一个遗留问题，评估其影响，写在遗留问题列表中。版本还是正常发出去，这个问题可以在之后修改，合入下一个版本进行测试。如果问题很严重，是版本的严重缺陷，不能外发，那么可以增加一轮测试，回归之后再发布

4.2、版本A转测试，测试结束之后，测试可以找开发要一个新的包，发布出去吗？

不可以，因为这个新的包，不能保证和测试的版本完全一致，那么这个新的包，也就是一个未经测试的版本

正确的做法，应该是把测试的版本发出去。即：转测试时是什么版本，测试结束之后就发什么版本

4.3、现场发现了几个问题，开发提供的补丁只有几个文件而已，可以不打标签，直接发出去吗？

不可以，所谓的版本，除了“完整性”之外，还需要一个“可标识性”，就像数据的主键一样，能够唯一标识一个版本。没有“可标识性”，就称不上是一个版本。一个版本只要发布了，就存在需要定位问题、回退的可能。如果没有打标签，当需要定位问题，或者日后需要回退的时候，就做不到了

正确的做法，是只要发了版本，就一定要在代码库上打上标签。可以是用版本号打标签，比如b010，spc001；也可以用时间打标签，比如tag_20120719

打了标签之后，在任何时候，无论是要搭建现场的镜像环境，或者回滚，或者比较两个版本的差异制作升级包，都可以做到了

   1.1 重要的是让开发人员吃透测试用例.没有测试用例的BUG让开发人员补齐
   1.2 excl 与buglist 是一码事. 不如写在黑板上 给程序员压力.....
2.写回复单这个一定要写.eclipse有个工具强制svn提交写回复,选择buglist号
3
4.学名叫回归测试

4.1 测试自动化布署测试使用最新版本测试1周左右.随时提随时改动.

4.2 ZAB 是个很严肃的事 在ZAB后是不可以进行改动并上线的
没有回归测试的代码上线是要罚款的

4.3 上线失败就回滚版本.....tester回去罚款.
compare比对上线这种事只有在作坊作过.

抛哥何故这么激动

这个检查不是静态检查，而是开发内部多回归一次，是可以降低转测试之后回归不通过的概率的。

因为团队比较年轻点，说难听的就是良莠不齐，所以管理成本是比较高一点。如果已经是很成熟的团队，再搞这套确实有点多余

excel和黑板确实差不多，都是记录的工具而已。。不过一来黑板上的东西会被擦掉。。二来一百多个BUG，黑板也写不下

改了一下.

写个数喽

未分配个数	24个	已分配个数	58
block	无	ZAB	2012-8-1
	分配个数	已完成个数	已关闭个数
张三	10	9	7
李四	8	15	9
总计	18	24	16