最近公司刚完成了一个比较大的项目-单品页模块化，即使用现在比较流行的Twitter Bootstrap进行前端开发。说其大是因为工作量大，开发前期投入约80人日，包括前端开发及PHP开发，且不包括修复bug的时间，测试投入约48人日，同时也是非常重要的项目，直接关系到转化率，稍有差池就会导致转化率的下降。而我有幸成为该项目的测试负责人，此文即介绍我自己是如何带这个项目的。

　　1. 人员分工合理，老人带新人

　　其实这次项目中，人员分配是3个老人（工作也不到2年），2个新人（工作不到1年），2个实习生，加上我自己共8个人负责功能相关测试。通过把功能及测试内容进行拆解，并对子功能评估工作量，测试难度及影响范围，与参与的人中最熟悉的人一起评估大概工作量，结合项目计划，投入参与的人员，制定出最终的测试工作量评估，当然，在评估的时间上加上buffer时间将风险得以降低。秉承以下原则进行分配工作：

　　1）最核心的内容让最熟悉的人来做；

　　2）新人负责边缘一点的功能，边做边学；

　　3）在其中挑出一个能承担较多的人，以减少“巴士因素”；

　　4）其中1个或2个人工作内容相对少点，方便灵活调配去协助其他人；

　　5）让细心的人做更多页面测试，让逻辑思维强的人做更多业务逻辑性测试，充分发挥各自优点。

　　2. 做好计划，一切心中有数

　　一份好的计划具有指导意义，可以回答何时能发布的问题。所以为了制定一份靠谱的计划，需要充分理解项目内容，项目人员情况，其余版本代码合并时间及可能的风险，需要进行哪些内容的测试，何时开展性能测试，需要做怎么样的兼容性覆盖，哪些功能需要做安全性测试等等。其实我觉得可能并不一定要撰写一份完整的长篇计划文档，只要在一两页能列出以上内容，说明了测试计划最关键部分，其余的都是形式。

　　3. 严格控制其余需求加入及本需求变更

　　影响项目计划的三大杀手锏：开发未按时提交代码，开发质量差及需求变更。需求变更可能会导致对之前的代码架构重设计，测试人员重新测试，严重影响项目计划，在进行该项目时，就与项目管理及PM达成一致，为了保证按时上线，控制其余需求加入，并不再对本次需求进行优化，保证该项目的优先级，预计的项目人员及项目资源。

　　4. 明确测试用例，做好评审

　　任何一个项目，一份考虑较周全的用例可以大大降低项目风险，增强测试人员乃至整个项目组的信心。这个项目也毫不例外，因为没有新的业务逻辑及功能，所以前期我们只需整理之前的用例，并再次与开发人员及PM评审，并列出冒烟测试用例，而它将作为冒烟测试运行之用例，也用于开发人员自测使用，毕竟是经过评审过的，所以大家都认可。

　　5. 保持测试与开发环境独立

　　开发环境与测试环境的独立其实并不是从这个项目开始的，而是一直以来都是这么做的。毕竟每一轮次代码及环境的稳定性会影响到所有测试人员的进度，谁都不想让开发人员在测试环境任意调试，修改配置，或直接进行开发，如果遇上非要在测试环境来复现某个问题时，也要等到环境没人用时进行。这么做也是为了让我们每一轮次的测试结果都是可信的，而不会因为环境的变化，让刚才测试通过的用例又执行失败，让刚刚报的一个bug突然变成了NOT A BUG。

　　6. 每轮次冒烟测试，督促提高开发质量

　　每一轮次的系统测试，都要进行冒烟测试，同时越到项目后期，越要提高冒烟标准。这么做的意义也是为了督促开发人员多自测，让团队一起为产品质量及发布齐心协力。所以，在一开始冒烟测试时，可能就把影响流程性的会block其他很多case（比如10条及以上）的case作为冒烟测试用例，因为第一轮次的测试都是覆盖性的，而往后，可能就是多回归信心不太足的模块，回归bug等，那么，在后期的冒烟测试时，对于多次反馈仍未修复的较严重的bug和bug重灾区的核心功能及流程也有必要作为冒烟测试范围。每一轮次的测试结果都在邮件中抄送给各个团队负责人及CTO，开发团队每个Q进行的绩效考核也将考虑冒烟的情况，督促提高开发质量。而且若因开发质量不够好冒烟测试不通过而导致的项目延期，则不再属于测试团队的责任。