最近的困扰_记关于内部集成测试的考虑(2，是态度问题还是方法问题)

    这几天一直为内部集成测试的方法及制度在思考着，自己在关注一些方法，如每周自动构建，这个只要通过一个自动构建的工具就可以达到，目前这个工具已经在使用，只是使用人员的水平还够。余下的问题就是：

     第一，如何确认每周内部集成测试的问题测试范围呢？ 目前每周的任务的工作量是50个左右，有时还更多，还需要为每一个去分配B角的工作单？这感觉也太被动，对分配者的工作太依赖了。对分配者的工作量也增加了很多。如果只是自己测试自己的任务单，比较容易，但就有可能发了时间，却未必得到效果。如果交叉测试，是否通过指定人员的方式进行呢，这个是一个好方法。

 

    第二，如何能保证每周的测试时间呢，现在每天都要安排人员对工程出现的问题进行跟踪分析。占用很多的时间，对测试的质量很难保证。问题的跟踪往往有时要半天，还有是一天以上的都有。像上周，针对政策性的任务，把所有的开发人员都投入进去后，开发了一周的时间。基本没有做正常的任务，都在做变更。另外即使能专心测试，一天能测试几个单子呢？需要几天的测试呢，目前开发工作量都很大。宁可慢，也要保证质量，这个内部测试还是认真去做的，如何做，质量越差，每天在工程上暴露出来的问题就越多，每天在跟踪问题，查问题上时间就发得越多，典型的负螺旋效应。内部集成测试的事要宜早不宜迟。

 

   前一段时间，几个版本的发布前BUG密度都在1左右，相当于一个的任务，就有一个BUG，各种BUG都有，形形色色，当时还针对特别单元测试的方法进行培训及考试，但现在看来，还是不理想。上周发布的变更，还是有人没有做测试就提交代码了，脚本里很明显的字母错误，只要自己运行一下就知道了，可就没有做单元测试引起的。很无语，是没有单元测试的习惯吗？

 

   明天可以和开发组长再讨论一下。