最近的项目工期紧，人手少。人手少是一直的情况，工期紧是因为老总们和客户们总是在变时间，为了讨好客户，加功能缩时间。 产品经理最近一直在犯错，就是在任何时候都会找你要版本部署给客户。我认为，找我要版本，可以，但是你要清楚你的风险。每个版本都是有问题的，不做缺陷评审贸然将冒烟测试通过的版本给客户，这个风险，谁承担？自己承担去。
这里就涉及到了一个问题，怎么样能提高冒烟的水平？也就是准确度。
这几天在忙一个老项目，要将项目重头到尾所有功能点覆盖一点，忘记需求和无用例的情况下，却开展了，取决与一个好办法，就是测试记录。
将测试的要点、测试步骤、测试结果和满足需求进行设计和填写，发现真的很管用。至少系统90%以上的功能点都能覆盖，先不说逻辑和业务是不是全，光光这1000多个功能点的覆盖就没有问题了。那回想一下，然后把这个表格扩充一下，加上业务逻辑和涉及页面，是不是能够形成每个项目的冒烟框架？
琢磨了琢磨，存在这样几个问题：
1.时间成本。新的项目开始，时间上是否能够承受。在只看原型的前提下，功能点是否可以就全面。
2.人员能力。谁来做？组员，还是组长，这是个问题。
3.意义。项目经理会问你，产品经理不过问，开发组长更不会问了，那这个意义，恐怕只有实验后你自己才能知道吧。
4.是否试用于每个项目。小项目肯定没有问题，那大项目呢？怎么做？组内通力合作，还是依靠个别力量。
想了那么多，恐怕还是关联上的问题。解决了管理和组织的问题，后面都好解决。
1.循序渐进，把冒烟用例使用迭代的方式进行。
2.测试组长领导由组员完成，组员测试测试的主体力量。
3.意义，就是最好不会让我们擦屁股吧。
4.这个需要时间和实践的验证。。呵呵
