查看完整版本: 日创建与冒烟测试的实践

日创建与冒烟测试的实践

日创建与冒烟测试，说是创新，实际上概念早有了。真正的用到了产品测试上，感觉效果还是蛮不错的。
      之前负责的XX产品测试由于工期比较紧张，于是果断采用日创建的方法，每日早上更新编译，上午一般回归前一天的问题，然后下午继续测试，把所负责的功能走一遍（几乎到处冒烟一次，呵呵），然后提交新发现的问题。然后开发人员更新程序，然后第二天重新发布、回归、冒烟。。。。。。彻底颠覆了之前测试中心集成测试的模式（之前是每完成一个功能，提交单元完成提交单，然后发布，逐个功能测试）。
      与之前的测试模式相比，有如下优势：
      1、每日连续遍历，保证了测试业务的连续性以及完整性；
      2、逐步求精的测试，测试程度比之前更加深入；
      3、更加关注业务场景以及流程，测试更贴近客户需求；
      4、工作效率极高，日创建-日测试；
      5、有利于弥补开发方面对于质量的不利影响；比如：工期紧张、开发人员缺乏自测；用这种办法对双方都是很大的督促；
      6、其他。。。。。。
      缺点：
      累，不是一般的累，每天的工作量可想而知，呵呵，真的是每天忙得屁股都冒烟了。如果继续这种模式测试，一定要合理的安排人员和工期。

比较适合自动化测试吧
呵呵

我也觉得
这样好累吧

我还以为是日（创建与冒烟测试）的实践

如果这样执行测试，应该算属于哪个部门阿？

冒烟!冒烟!

没有自动化测试的dailybuild不太现实。

这样的工作量是可想而知！！！  怎能一个累字了得 ！！！

太累

项目小尚可，如果项目大怎么办？天天3班倒？

这种测试没有自动化测试工具，只凭人工测试是很难想象的，不仅需要自动化测试工具，还需要有测试管理工具，呵呵！

这样才能体现自动化测试的重要性啊~~~呵呵！~~支持自动化测试！

这种回归，特别是有些项目涉及到一期二期的那种，建议用自动化测试实现回归！

这样做，不累死才怪