今天在InfoQ看到一个google关于test的演讲, 非常精彩

　　讲座中包含了两个对我来说比较新的东西。

　　第一个是"开发测试"。 作者没有深入， 每次提到开发测试都是简单带过， 只说了这个是和单元测试独立的， 需要开发人员执行的测试。 传统方法中， 开发人员的压力更多来自于进度。 所以推动开发人员对代码质量的热情， 和最终集成后产品质量的热情是非常重要的一个环节。 开发测试是实现这个目的的一个很重要的工具， 但是难点在于如何定义和执行。 是让开发人员手动过一遍预先设计的任务， 让开发人员设计并且执行一套自动化？ 还是简单地分担部分测试人员的工作？ 我个人认为， 开发测试的文化重于流程和结果。 而文化不是简单堆砌一些流程， 表格， 文档就可以搞定的。 希望作者能够跟深入介绍下如何在开发团队中推动这样的文化。

　　第二个是diff sign off。 这个问题的背景在执行大的sign off流程中， 是需要把所有的回归测试 (我们也叫full test pass)都跑一次呢， 还是有什么简单些的办法。 作者这里提到了diff sign off。 就是说重要的回归测试固然要跑， 但是我们可以根据产品的变化， 特别是代码的变化， 来舍弃一些回归测试。 比如前一个milestone跑过了性能测试的回归， 在接下来的一个月中， 所有的修改都是针对localization比如汉化， 而且通过代码比较工具分析下来的确也是这样的话， 那测试人员就不需要跑所有的性能回归测试了。 在我们的测试过程中， 我们没有对应的专用名字， 但是在某些时候还是用了同样的方法进行分析。 我个人认为这是一种非常高效，值得推广的方法， 但实际情况是没有人明目张胆地提出来这样操作。 我觉得主要因为我们组织不够agile， 跳票习惯了， 所以多花点时间来个全回归终归安全一点。 次要原因是自动化覆盖的确比较全面，（当然不同team的质量有高低）， 所以好像也没有太大必要。 在google 10个开发里面只有1个测试， 比我们现在还极端， 所以diff sign off自然很有用武之地。

　　关于diff sign off， 我上个星期的类似的例子是， 我们把工具升级到vs2010了。 但是前面一个milestone发布的东西是vs2008的。 大家讨论要不要留一个vs2008的环境， 谨防要出hotfix。 我的意思是要出hotfix也用vs2010编译就是了阿。 但老板的意思是， 如果这样的话， 那发布hotfix光冒烟就不够， 一定要全回归， 因为编译器变了。 我在想， C#写的标准代码， 编译器导致问题的几率是非常低的。 我觉得编译器的安全程度反而大于冒烟的安全程度。 所以， diff sign off的推动， 很大程度上取决于既存的流程和经验。

　　另外， 讲座中也包含了一些我认为应该包含却没有包含的东西。

　　作者强调了测试角色的历史变化， 提到了新时期测试工作的目标。 但全篇所讨论的测试， 更多偏向于after the fact这个现实。 里面强调单元测试， 开发测试等需要开发人员注意的东西， 但这一切都是发生在编码之后。 我认为agile test， 以及整个软件测试应该关注如何把bug扼杀在编码之前。 BJ一般把这个叫做"fix the bug before the fact"。

　　这个要展开讲就很多了。 我个人实践下来最有效的方法有几个。