每日构建和冒烟测试
1,736 Views『作者：RickyZhu 转载务必注明出处和作者』
Tag:testing
这个题目来源于上周六在广州软件测试交流会的一个主题，pent老弟介绍了他的一个简单但是非常有效的架构。说这个架构简单是因为结果非常简单，除了任务定制，调度之外，没有其他多余的功能，说有效或者强大是因为他实现了一个强大的自动化测试回归机制，系统虽小，该有的功能都有的。这个架构分四个部分：
每日构建（daily build）-》部署（deploy）-》冒烟测试（smoke test）-》结果报告
四个部分是是一个完整的整体，对于有些项目来说，其他中的第二个步骤部署可能不一定是必须的。
先说每日构建，这对于一个产品的研发特别是协同开发的产品来说，是特别重要的一个缓解，而且在很多公司已经形成一个良好的机制，每天下班时间，系统自动根据配置管理进行每日构建，大大节省了研发的时间。
部署这个部分我不是很熟悉，就不介绍了。
冒烟测试，其实我更喜欢叫他可接受性测试，就是新的label出来之后，首先有一批最高级别优先级的测试用例需要进行回归，以便验证老的功能依然正常工作，新的修改或者新功能的增加并不会影响老的feature。这个过程如果失败，那么label就直接打回给开发部分，进行重新修改和编译。一般来说，在实际项目中，这个时间或者说这个测试占用的资源越少越好，而且这部分测试自动化的收益也最大，所以自动化的迫切程度也最强。这里实现了自动化，完全减少了人为的投入，大大提高的资源的使用率和测试的效率。
结果发送就没有什么好说的了，不过这也是研发经理或者老板们最关心的话题，每日构建的成功率有多高，每次都是因为什么原因导致日构建失败，人为的原因还是其他的原因，有的时候这都可以作为考核开发人员绩效的一种参考和依据。
测试部门的经理也会在每天上班的时候收到一封冒烟测试顺利通过的邮件，这样的话，一天的测试工作就好进行有效的安排。
记得之前一家公司的一位研发总监数次提到要把日构建做起来，好像直到我走的时候这都还是一个良好的愿望，不能不说是一个遗憾。
感谢pent老弟的精彩分享。
效率真高, 期待下次的交流! ^_^