追悼会（一）

   本次测试基本上是按照测试V模型来执行的。
  前期介入项目比较早，对需求吃的比较透彻。特别是前期功能测试的方案和计划做的比较好，缺点有3点：

  一是没有做测试设计，也就是说没有完善测试用例和充分熟悉新模块的所涉及的内容而针对这些做一些测试设计；

二是前期人员变动导致测试有一些吃紧（建议测试人员要稳定）；

三是研发新模块移交测试改变和推迟。（有些模块是已经做好了，但是没有人移交过来，导致测试放在接近版本发布后期执行，由于时间紧，有些走过场的形式；本来没有计划做测试，后期又改变所要做测试，人员方面有些措手不及。）
后期性能测试，对于工单部分做的比较完整。设计测试方案花费了很多时间，所幸结果比较好。值得学习的经验是：充分研究熟悉模块之间的关系之后，可以考虑给出测试需求与研发人员合作测试程序。
    最后接近发布版本后期是本次测试的一大败笔。后期大家的测试疲劳，包括测试与研发人员。安装程序一天做多个，已经修改的问题在安装程序中再次出现。再就是前期遗留的新模块推迟到这里测试，以及本来决定到客户那里测试的模块移交测试组，测试人员对新模块不熟悉，产生措手不及以及一切突然不能掌握的无头绪的心态，再加上没有验收测试的安装程序频繁出错，后期的测试总结开始统计，由于没有完成的测试，导致测试总结的也是很棘手，然后产生抱怨。（汗，测试人的心态也是很重要，当一个测试人员心态错误的时候，我认为测试也开始失败：不要太注重验收日期，这里说的意思是在计划改变的时候验收的日期改变是正常的，死抠以前的验收日期，打乱计划，于整个测试来说是不好的。）总归来说，后期出版本时期测试失误在于没有计划，这里建议增加接受测试，并且需要有一定测试计划，一步一步的来，对于bug的修改，特别是后期，对于研发人员后期最后能保证bug修改的及时性，准确提交tag，不要一个安装版本解决一个问题。
     测试总结的时候出现一个问题就是对bug的等级没有要求，导致统计数据有些不方便。