近的项目工期紧，人手少。人手少是一直的情况，工期紧是因为老总们和客户们总是在变时间，为了讨好客户，加功能缩时间。

　　产品经理近一直在犯错，是在任何时候都会找你要版本部署给客户。

　　我认为，找我要版本，可以，但是你要清楚你的风险。每个版本都是有问题的，不做缺陷评审贸然将冒烟测试通过的版本给客户，这个风险，谁承担？自己承担去。

　　这里涉及到了一个问题，怎么样能提高冒烟的水平？也是准确度。

　　这几天在忙一个老项目，要将项目重头到尾所有功能点覆盖一点，忘记需求和无用例的情况下，却开展了，取决与一个好办法，是测试记录。

　　将测试的要点、测试步骤、测试结果和满足需求进行设计和填写，发现真的很管用。至少系统90%以上的功能点都能覆盖，先不说逻辑和业务是不是全，光光这1000多个功能点的覆盖没有问题了。那回想一下，然后把这个表格扩充一下，加上业务逻辑和涉及页面，是不是能够形成每个项目的冒烟框架？

　　琢磨了琢磨，存在这样几个问题：

　　1.时间成本。新的项目开始，时间上是否能够承受。在只看原型的前提下，功能点是否可以全面。

　　2.人员能力。谁来做？组员，还是组长，这是个问题。

　　3.意义。项目经理会问你，产品经理不过问，开发组长更不会问了，那这个意义，恐怕只有实验后你自己才能知道吧。

　　4.是否试用于每个项目。小项目肯定没有问题，那大项目呢？怎么做？组内通力合作，还是依靠个别力量。

　　想了那么多，恐怕还是关联上的问题。解决了管理和组织的问题，后面都好解决。

　　1.循序渐进，把冒烟用例使用迭代的方式进行。

　　2.测试组长领导由组员完成，组员测试测试的主体力量。

　　3.意义，是好不会让我们擦屁股吧。

　　4.这个需要时间和实践的验证。。呵呵