项目已经到尾声，产品就要发布，可是心里依然没有底，分析一下原因，总结一下。

　　A> 项目回顾

　　1、项目是从原来的C/S版本转变成WEB版本；项目从头到尾都是按照USE CASE，编写程序和测试用例，总体执行应该说是有计划的；同时这个项目是按照产品的思想做的，也就是这个产品会给不同用户使用，所以配置很多，见到的产品（Build完成之后，默认配置的产品）或许只有实际功能的一半都不到

　　2、QA按照USE CASE以及SPRINT的安排，一个SPRINT差不多一个月一个月进行测试

　　3、Developer 按照USE CASE执行各个功能的实现，每个SPRINT不仅实现新功能，同时解决上一个功能的BUG

　　4、在新的一个SPRINT之后，QA只是验证上一轮的BUG是否已经解决，不进行全部的回归测试，而总体的BUG数量从感觉上不够的，简单的统计一下，没千行BUG数量可能只有个位数，这个只是老板曾今的统计，我也不懂这个代表的意义，只是以此和CMM的标准比较老板感觉上是不够的

　　5、项目持续了大概有2年左右，我是中间加入的；总体上有序的，但是由于业务复杂，QA和DEVELOPER的业务知识储备显然是不够的

　　B> 目前要做的事情--针对最后几个版本的测试

　　1、这个产品的全部的REGRESSION TEST

　　2、所有新的BUG，新功能的测试

　　3、新用户导入需要做的针对配置，用户定制部分的测试，目前至少有3个客户需要这个产品

　　C> 人力情况，以及工作的态度

　　1、总共有11个左右QA，这个产品主要分3个子系统，功能复杂；同时还有3个小产品

　　2、3个客户测试估计每周需要80个小时的工作量

　　3、QA基本上没有熟悉全部系统的人，都只是熟悉一个系统

　　4、需要在不耽误新客户导入的情况下进行完全的测试

　　5、组织架构是扁平的，基本都是老板看每个人，有小的Team Leader但是基本上Team Leader不会进行工作的分派，习惯的风格是如果有100个BUG要测，一个人从上往下作，一个人从下往上做，做完为止，基本没有详细的Review和对于个人测试过程中的追踪（这个指日常的Status Meeting，以及最后看绩效的时候不会考虑测试以及报告Bug的数量，还有就是个人对于系统的理解的考核）；老板主观上是相信每个人，但是实际过程中由于DEVELOPER对于BUG的逆反心理，以及确实由于需求不清楚的问题，QA只是不够，有误报BUG，或者FAIL BUG的（DEVELOPER会被REWORK的指标）最后造成不太愿意主动的报不太肯定的BUG，和测试没有提及的可能的功能（说的不太准确，但是态度上是这样的）

　　D> 老板的要求，以及员工的反应

　　1、每人在后面一周时间里面每天至少加班2个小时

　　2、对于每个系统都需要深入的测试，但是他说没有办法保证每个人都这么做，需要我们表现出态度

　　3、QA不太愿意加班，以及不太愿意完全担负最后产品的质量问题，理由是USE CASE的质量不高；我只要做完我需要做的事情就可以了，如果做完为什么还要加班？

　　------ 加班没有钱而且不能调休，这也是公司的风格，会把这些事情先说清楚，但是不太说直接责任的事情，但是万一出事，似乎会有严重后果，但是却不会在平时过程中把这种义务和责任的关系看的很重，最新想到的是我要多做多少事情，所以就会有QA和DEVELOPER沟通不好的问题------题外话

　　由于没有具体的要求，所以我觉得最后一周的工作不一定是有效的，而且老板提出要求之后，气氛有点不好，考虑到最后一段时间可能高强度的工作，但又起不到实际的效果的时候，老板可能会最后秋后算账的问题，我不知道这么做？我的担心是，由于只是储备的不足，实际测试的时候，很多配置不会测，最后加班也是磨时间，因为如果配置不测的话，功能至少减半，按照老板的说法是，他没有办法跟踪……

　　我的想法是：

　　1、列出每个人要做的事情，分优先级，同时估计需要的时间

　　2、每半天看进度（因为不是每个人愿意帮其他人测试的），动态调配人力分配

　　3、测试的内容的根据的按照USE CASE写的测试用例进行测试（要分优先级）----估算人力分配情况也应该按照这个方法进行

版权声明：原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。 本文出自littlebig的51Testing软件测试博客：http://www.51testing.com/?25525