慕名已久的TiD大会于7月16在北京开幕，除我司外国内还有多家IT企业参会如腾讯，阿里，百度，IBM，华为，京东。大会内容非常多为了充分参加好这场会议，选课非常关键。今年TiD（Top innovation Depth）共分为AgileChina（敏捷）,Chinatest（测试）,SPIChina（过程改进），三个分会都是并行参加的，只能选择参加一部分，策略开会前也制定优先参加测试和过程改进类。这次F7也举办了两场，鉴于相司度比较高也去观摩了一下。
本次测试管理方面给人映像最深的还是京东和F7，自动化程度都很高。一个是传统的瀑布模型，一个是转型后的敏捷模型。一个需求要求可以不用100%验证，一个要求特性及波及特性均要回归。但他们的版本节奏共同点都要求快，在快节奏版本的情况下以前回归和升级测试的频度增加了，而这一切工作量的增加也只有对应自动化的支持。这两家公司均实现了很好单元测试，关键模块单元测试行覆盖率在80%，协议类模块达到100%，与之相比我们项目这块还有一定差距。讲师说明在单元测试推动都表示出很大的阻力，因为这块基本都是靠开发来完成。除重点模块有策略的重点保证外，其他的模块开发确实也没有时间去完成（单元测试与开发代码的工作量在1:1左右）与之想比我们今年开始sftp已完成所有的单元测试函数覆盖有了好的开头。接下来是接口类测试，基于webservice，rest，API等接两位讲师所在的项目基本是全覆，这点和我们项目类似，但我们项目接口测试这块个人觉得还有挖掘空间，某些接口可以依托开发封装进行测试。devops方面两位讲师所在项目自动化程度都非常高，基本不用手动搭建测试环境，QA不用被这种零碎的杂事束搏，可以干更多事情，而我们项目还有部分环境由于一些历史原因未实现自动部署。与其他两位讲师所在项目相比收获满满。个人觉得从测试环境下手，进一步优化测试硬件资源（哎，硬伤说多了都是泪）实现能自动绝不手工部署，让QA减少环境部署类时间开销。回归测试实现到一定程度比例自动化，后续高密度的版本回归测试如果靠手动测试时间成本，质量风险都会很高，特别是今年开始面临着高密度的补丁版本。
测试设计这块，在大会期间各种方法如数登场。大家讲从场景，测试方法等价类，边界值，因果图，兼容性，安全等角度去设计，但方法论都比较零星。这点看到了我们的优势，我们mfq测试设计这块无疑是走在前面的，大胆推测tid大会要到明后年才会有mfq的测试设计讲座。但同时也有新的测试方法值得大家学习，比如会上列举了一个函数有5个参数（囧，好复杂），每个参数10种类型取值，按照正常单元设计每种参数排列组合设计100000种组合即可,但根据最新研究95%以上的结果过只需要参数两两排列组合即可C10 9，在质量允许的范围内降低成本。
在质量改进方面，各家公司因地制宜把握有度。人默认都有守旧情怀，讲师提供的数据只有10-20%的人勇于接受新鲜事物并了解其真正的目的。在项目上问一个同学为什么要实现自动化，答曰项目这样要求的。我想这样改进的效果可能会打折，如果能让大家认识到后面推行自动化的真正原因，大家也会真正乐于接受。质量改进是一个循序渐进的过程，讲师举了一个例子特别有意思。话说一家公司要节约成本，取消每天发苹果的政策。如果强退取消每天发苹果的政策，想比大家都要造反。结果公司先取消一天不发苹果，每周发四个，第一周没有什么反应。在实时了一个月以后，改为一周发三个实时又一个月后改为一周两个，一直到最后取消苹果发送政策。改进还有其他很多有意思的内容，回来和一起分享。改进前期都有一定的时间成本，如何在质量与时间投入上找到一个平衡点还值得深思。
最后留一张个性签名图介绍这次收获满满的TiD之旅。
