daily build & smoke test

小丫头

这几天部门隔壁CE组一直在说smoke test的事情，晚上正好空闲， 网上搜了一堆相关的文章看了看， 觉得还是很受启发的， 最最让我惊喜的是原来我们这块业务组已经一直在做这个了，只不过大家内部赋予的特定名字掩盖了smoke test这个专业而大众化的名称， 而且我们整个的过程全部都系统的实现了自动化。
在每天的设定时间点上， 系统从代码库中获取产品所用到的所有component的最新更新， compile, link, build， 不管成功或是失败，系统通过公司邮件系统自动发出类似于Notification的信息给相关人员（这个人员列表是预先订制好的），如果失败， 有专门的Build teram去追踪解决这个问题， 然后重复上面的过程，如果成功，则进入下面的automatic smoke test。 首先是系统自动graft build， 然后在符合配置的测试平台上通过一个依附VT而经过适用性改进的自动测试系统跑smoke test的脚本（这个脚本是预先订制好的， 在产品的不同阶段， 脚本的复杂程度会不同（由简单渐渐复杂），不过一个原则就是脚本覆盖产品的所有基本功能，测试的目的是Build能成功跑完所有的功能， 而不会去验证每个功能的实现正确与否），smoke test的测试结果也是有系统通过公司邮件系统发给相关人员，测试成功，则整个的daily build + smoke test结束， 如果在这里smoke test失败， 则该产品的测试人员要本地manual reproduce然后提交BUG， 同时回复邮件告知所有相关人。 在我们公司， daily build + smoke test到这边就算是一个轮回结束了，如果前面所说的过程都是OK的，那么这个过程应该可以算是完美的， 我作为测试人员觉得欠妥的地方在于如果smoke test失败，所提交的BUG和日常常规测试提交的BUG是走同一路径的（进入开发人员的待fix 队列）， 不管这个BUG修改时间会持续多久， 以后的每天的daily build + smoke test还是在继续，其实这样基本相当于做了无用功如果前面的那个BUG没有当天解决的话。 而且， 我个人感觉目前公司的开发人员也没有意识说这样的BUG是需要首先立刻解决的（尽管BUG写明是daiy build 后的smoke test结果），而作为测试人员，也没有完全意识到说smoke test的BUG应该是第一紧迫性的，而是从出现BUG的那个功能点的重要性上去设置BUG 的级别。如果说开发人员和测试人员在这个上面能达成共识，真正明白这个系统的初衷，并且有一个完善的流程可以用来引导督促所有项目人员，那么我们的这个daily build + smoke test的系统就真正完美了。
据说， 在微软是已经这样完美的实现了的，而且据说象windows NT或者excel 这样的大的产品，在项目后期阶段， 任何开发人员的change导致了daily build / smoke test失败，这个工程师是要立刻被call去fix Bug的， 不管是当时是下午三点还是上午三点，呵呵。

beiyue

小丫头，能不能说说你们smoke test怎么自动化起来的?

例如：用什么工具，怎么编写的脚本．

学习一下

Germin

是啊，我也想知道是如何实现的，哪位高手帮帮忙！

lvyunxiadou

同问，smoke test如何做滴？

拜谢