最近个人几篇文章介绍了改测试等待的文章. 关联文章的地址
周末参加了在杭州举办的延续交付话题沙龙的讨论，将这次活动中的一些出色问答和教训警语记录下来供大家参考：
- ”延续交付如何让老板看到代价？“，这是事先讨论的比拟剧烈的话题，大家形成的基本结论是可以通过权衡周期时间来看延续交付前后的变化，如果应用延续交付前的周期时间是1周，运用了延续交付后周期时间变为3天或者更少了那么就为公司提高了竞争力，就比竞争对手更快的退出新产品、功能了。
-
“延续交付是公司软件研发综合能力的体现“，它体现了从编码->测试->上线全流程的整体协调和相关工程实践的应用能力。特别是DevOps两部门的融合，延续交付的自动化管道犹如一个个自动化的生产线，只不过最后的输出就是上线的软件。
-
"让写代码的人专心写代码"，让开发人员分心的事件或者说须要等待的事件不少，例如：等待测试呆板/资源、等待测试结果的反馈、等待品质数据反馈。而延续交付可以尽可能的下降开发人员上述的一些等待时间，从而提高生产率。
-
“通过可视化来影响团队”，有效一个表现器用来表现Jenkins build pipeline，也有效一个闪烁的红灯来表示构建失败的情况，通过这些可视化的手腕来使团队遵循’修复构建失败是第一优先级的事件‘的约定。
-
“自动化测试的切入点须要开发测试同事一起来决议“，开发和测试同事可以坐在一块吧系统的架构、模块画出来，看看哪些是须要做UT、哪些须要做IT（接口测试/集成测试）等，然后从一个最小部分开始实施，逐渐的把自动化测试加入到延续集成中去。
-
延续交付不是一个最终状态，而是‘在路上’的一个进程，它没有终点，并非意味着将发布周期从1周缩短为2天就是延续交付了，更重要的是“将发布的选择权交给业务部门，而不是IT部门”，所以说延续交付一个一直优化提升的进程，它没有一个业界的‘终点’定义。
正如《延续交付》一书书中所说“如果在软件开发中的某个任务令你非常痛苦，那么处理痛苦的方法只有更频仍的去做，而不是躲避”，只要我们从思想上可以接受倏地失败、倏地修改、倏地发布的节奏，那么延续交付的理想国就为期不远了。
文章结束给大家分享下程序员的一些笑话语录：
刹车失灵
有一个物理学家，工程师和一个程序员驾驶着一辆汽车行驶在阿尔卑斯山脉 上，在下山的时候，忽然，汽车的刹车失灵了，汽车无法控制地向下冲去， 眼看前面就是一个悬崖峭壁，但是很幸运的是在这个悬崖的前面有一些小树 让他们的汽车停了下来， 而没有掉下山去。 三个惊魂未定地从车里爬了出来。
物理学家说， “我觉得我们应该建立一个模型来模拟在下山过程中刹车片在高 温情况下失灵的情形”。
工程师说， “我在车的后备厢来有个扳手， 要不我们把车拆开看看到底是什么 原因”。
程序员说，“为什么我们不找个相同的车再来一次以重现这个问题呢？”
---------------------------------
原创文章 By
测试和等待
---------------------------------