又一次的测试教训总结

    紧紧张张的有忙乎了一阵子，还没有来得及休息喘口气，就听测试组长说：上线的系统又出现了好多问题，局方又找出好多地方与集团规范不一致，对咱们完成系统又很不满意。。。。

    当时我听了，出了一身冷汗啊，是不是我测试的地方又出问题啦。。。

    赶快找组长要来局方提出的意见文档，打开一看，果不其然又有我的2个bug，仔细阅读一看，竟然是两个图片的链接没有加，哎，怎么再仔细也有落网之鱼啊。。。。。。。。。

    开发部经理一顿批：为什么这种小问题还有出呢，怎么这么粗心大意。。。。。。。之类

    经理一顿批：做事怎么这么不上心呢，如果想混日子，估计也待不了多长时间了。。。。很是难听

    我的天啊，这么忙乎一阵子，很是仔细、上心的工作，结果还是没有改变多少，难道我真的不适合做测试吗？可是我很喜欢测试。。。。。很伤心！

   痛定思定。。与其这么伤心不如好好总结一下，以防下次同样事故的出现！

  （1）工作方式有问题

      测试时，没有严格按照测试用例执行，写完测试用例，感觉测试用例都在自己的脑袋里面了，不用对照啦，测试下来，感觉和提前设计的测试用例基本一致

     这样的想法，现在想想挺可怕啊，做测试的最怕这种自以为是的了，以后切忌这种想法，一定要严格按照测试用例执行，中间测试时，如果遇到没有写到的问题，记得一定要及时加到测试用例里面，防止以后上线测试前验证测试时漏测试。

  （2）测试需求分析不到位，测试重点没有找对

      这个项目是一个网站的页面改版，现在看来应该是侧重页面细节的测试，而不是功能操作的测试啦。但是当时却正好相反，忽略了页面上的东东啦，而且对集团规范分析不够全面，不深，没有把这些细节问题挖掘出来

  （3）需求变更或bug修改后验证，没有主动和开发人员沟通了解可能受影响的功能有哪些，可能测试不全面

      我们这个项目需求变更很频繁，有些功能变更自己认为是正确就没有再和开发人员确认，这个是不应该的，以后像这种情况，最好还能找他们确认一下，到底自己理解的正不正确，毕竟他们是做开发的，过程肯定要比测试人员要清楚。bug修改后最好也能确认一下，这个bug修改后受影响的功能有哪些？验证时，侧中点有哪些？确认一下总比不确认好

  （4）自我情绪没有调节好，受项目组内的情绪影响太重

      这个项目在开发时，项目组内的气氛都是“怨声载道”的，开发人员忙无头绪的，自己也跟他们一样，不知道自己整天都在做什么，没有把自己的调节好。

     这种情况应该使自己从中跳出来，明确自己的职责，尽量不受其他人情绪的影响。

    这样一总结，自己还是有很多的缺陷啊，需要加强的地方太多啦，多总结，希望能成为以后工作当中的经验，“测试需求”很关键，一定要做好！！！

     给自己加油，a za，a za，fighting！