场景1：同样一个开发，一个日常是自测上线，一个日常是有测试人员测试上线。二个日常发布后，开发的心情完全不一样。没有测试的日常发布上线后，他心里有一丝担心。发布后，自己马上查看日志，进行线上验证。有测试的日常，开发心里很平静。 这样一种现象，大家认为是好现象还是坏现象呢？可以有二种情况：

　　一、开发同学对测试同学的专业很信任，对经过测试同学测试的日常质量很放心。这种现象是好的，说明开发同学信任测试同学。

　　二、开发同学心里很平静并不是他对产品质量放心，而是因为有测试同学在后面做保障，有测试同学承担责任。这应该是我们最不想看到的结果，但我想这种情况是存在的，说不定还不少。这里并不是说开发同学的思想不好，而是我认为一直以来测试人员把自己的角色定位些偏了。大家都说测试人员是保证产品质量的角色，但是产品质量并不是由测试人员这一种角色来承担的，可我们现在的感觉确实是如此。出了问题就说你测试人员怎么做的。于是测试人员累死累活地在测试执行时间不辞亲苦地毫无怨言地找BUG。不错测试人员是保证产品质量的，但保证产品质量的方法并不是自己无怨无悔地找出多少BUG。一个好的测试人员，并不是他对业务有多熟悉，测试技术有多么地好，他应该是要自己的质量意识传达给团队成员，让团队成员分担产品质量的责任。不要把所有的责任都承担在自己的肩上，自己并没有想像的这么强。套句俗语：人不会累死，但会冤死。基于此我想提两个问题：

　　问题1：开发自测的标准。开发自测的标准不应该是测试人员不能做，从而由开发人员来做。而应该是根据需求的复杂程度来决定，比如说只是一个简单校验规则的改变的需求我不认为开发自测与测试人员测试会有什么不同。这样的需求就应该由开发自测，从而提高他们的质量意识。而对于有些比较复杂，但是技术要求比较高的需求，这些就应该要测试人员来测，如果不能测这就是测试人员需要提高的地方，或者至少由测试人员配合开发来测试。

　　问题2：项目何时结束？现在给我的感觉是对于PD，需求评审通过了，项目就结束了；对于开发，昌烟测试通过了，项目就结束了；对于测试，项目发面上线后，项目还没有结束。不知道这样的一种角色分工是否合理？PD在需求评审通过后除了确认需求，评估LATER BUG就无事何做了吗？开发在昌烟测试通过后，除了等待修复BUG就无事何做了吗？

　　场景2：看到过N多同学的旺旺签名为：项目执行中，忙。

　　经常听到测试人员说的一句话：最近很忙，项目测试中。忙什么呢？忙着测试执行，忙着提bug，忙着验证bug。基本上在项目测试执行过程中这些工作会占用测试人员90%以上的工作。有时候在想为什么会这样？

　　问题1：为什么会在项目最关键的时候让自己变得如此繁忙。就像一个准备上场比赛的运动员还在匆忙地寻找自己的武器及装备。是计划安排的问题吗？是前期准备的问题吗？还是测试着重点的问题。测试的价值不是在测试执行上，而是在测试的前期准备上，比如说需求的分析（而通常我们做的只是需求理解），设计的分析（很多同学不愿意去参加开发同学组织的设计评审，对于设计认为只要知道表结构及具体字段的含义即可。我们做的是黑盒测试，但是在测试人员心里被测对象绝对不应该是黑盒。），用例的设计。测试执行只是其中一个环节，而且绝不是最重要的一个环节。

　　问题2：测试执行的效率

　　有时候项目结束看看我们的数据，我们的BUG，看看我们的测试用例实验室用例可能会吓一跳。这么多的BUG，这么多的用例状态。即使不考虑需求本身光是录入这些BUG及更改用例的状态所费时间应该也是不少吧。这里面有些BUG我们是不是可以不提，比如一些低级的BUG是不是可以让开发在一定时间内修复即可。而用例的状态有没有必要细化到步骤里。所有的数据都是用来分析找出问题并提高效率的，有些数据我们是不是可以不要。说到测试执行的效率，很想说下测试的效率。测试技术的提升能不能提升效率，答案是肯定的。大家都知道越到后期发现的BUG，修复成本越大。所以从逻辑推理来讲，要想最大限度地提升测试效率，最有效的方法可能不是最大限度地提升测试执行的效率，而是最大限度地把BUG扼杀在萌芽状态。换句话说，测试执行的效率高并不代表测试的效率高。有时候觉得测试应该有点像班主任，事必躬亲绝对是不可取的。任人为用才是最好的方法。教师经常对学生说的一句话就是：“我们要做到老师在与不在一个样”。测试的境界是不是应该也是这样：“测试在与不在一个样”。当然这个一样是好的一样。

　　写了这么多，再回头看看，其实自己说的都是一些老生常谈的问题。比如说我们一直在讲的测试要走到上游去，可是有时候很想问问自己：我真的走到上游去了吗？我没有，但我希望有人有。