中国软件技术大会 Day 1

早起拍到朝阳，收下一双美丽的膝盖

今天有参加中国软件技术大会，据说票价1800，参与的都是珠海的同事，幸好我们部门两地办公，不能厚此薄彼，才挣到一个北京的名额。

早上有几个大讲座，坑爹的是之前给我们的手册里写的ibm之类都没来，直接从亚马逊AWS开始介绍了。不过大仙说第一天早上基本都是广告。

的确都是广告…

AWS是广告，不过对于一个已经驰名的产品来说，只要说一下自己现在多牛逼就行了…

real bull

GBASE是一家大数据处理的公司，讲了一些干货，不过我那时的思维都被某人勾走了，想的尽是一些纯粹性问题，思维被踢回来以后发现GBASE说完了。

AWS云技术和GBASE说完后，剩下的演讲全是一些我不了解的公司的广告，听着听着发现现在中小型银行在运用各个市面上的软件的时候是真活跃，几乎每个公司说起自己客户的时候都有民生，中信之类。

到底哪种模式比较合适呢？自己开发应用，还是寻找已经成熟的产品？

下一个是ThoughtWorks的演讲，小册子里看到好玩的东西，AngularJS被评估为不推荐使用哈哈。

想到这里，收到邮件说生产的ActiveMQ全挂了，我这一身冷汗冒的跟吃井格似的，找人查了查问题，然后就被大仙叫回去了。

惦记着想听下午的讲座，就没吃饭在生产查了一个多小时问题，最后清理所有mq并重启。收集了日志周一再看吧。

讲座基本挤不进去了

紧赶慢赶，还是错过了一个半的讲座，竖起耳朵听了个半截儿的：

轻量级产品设计

讲座主要是面向手机和电商设计。轻量级应用只关注核心功能，不设计复杂的ui界面。比如百度Google一开始只有一个输入框，就可以认为是一个轻量级的应用。对用户来说，轻量级应用不会为用户带来学习的恐惧感。

将一个复杂产品进行拆分，变成轻量级的模块时，产品深度只适宜做两层，因为每增加一个环节都会增加流失率。

云里雾里，此所谓半截儿。

听完出来是茶歇时间，我在大厅看到了我在所有会上都没见过的东西

棉花糖机，凭证免费领取一个

所以我拿了，真的很久没吃过了

和S说起这事，我胡诌因为棉花糖像云，所以放在这里。事实当然是我想多了，或者主办方就是这么萌。晚上结束出来后发现提问题还能换奖品，主办方真是煞费苦心。

一个很有意思的换衣服的应用摆在大厅

完整地听完的两个讲座一个是DevOps，一个是民生银行的智能测试平台。

DevOps

我是第一次听到这个概念，查了下百度：
DevOps（英文Development和Operations的组合）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作。

可以理解DevOps为一个连续的过程

简单点说，DevOps是一种协调开发和运维的思维方式。是开发、测试和运维的高度协同。目前的大环境来说，有云计算，有容器，技术进步促使了DevOps的成熟，Docker的崛起使开发和运维合并，演讲者表示DevOps的窗口期已经来临。但就国内来说，目前DevOps在市场上是在刚起步的阶段。DevOps的发展就目前来说，应该做的工作是开始小规模尝试，而不是在市面上鼓吹DevOps的优越性，因为就产品来说，由于环境不同，并不是所有的产品都适合DevOps的思想。

DevOps的应用原则有四：

1、根据业务来发布，即根据业务考虑是否适用。
2、强调人和文化，强调开发团队和运维团队的和谐。
3、通过敏捷和精益的时间快速交付IT服务，必须有敏捷开发的基础和精益的基础，才能保证DevOps的质量
4、使用工具，使用各种工具来保证DevOps的连贯性。

如何实施DevOps：

• 团队成员对DevOps的定义要达成一致（不同企业可能不同）
• 聚焦在业务应用
  业务驱动，不适用测试的项目来做，需要有驱动力。因为敏捷和精益都需要一定的推动力才能实施。
• 实施步骤要有连续性
• 对DevOps的目标和范围一致

一个DevOps的团队包含三个部分：Dev+Ops+QA/Testing。但是目前开发和测试之间的界限变得越来越模糊，团队逐渐向两个部分压缩。就对开发的要求来说，开发人员交付的应该是一个环境，而不是一段代码，因此容器特别适合DevOps。

分台阶循序渐进实施，找到瓶颈，而后解决瓶颈，才能实现DevOps：
环境搭建——>代码部署——>测试——>架构解耦——>开发——>产品管理

如何选择合适的工具

评估那些工具更合适——>确定需要集成哪些数据——>将这些工具以自动化的方式组织起来——>持续优化

开发工具：GIT
优势：分布式；对分支友好，利于协作；速度快；对CodeReview集成度好
需要注意的问题：

• 学习曲线比较陡峭；
• 权限力度粗；
• Git工作模式选择；
• 大量二进制文件时的处理；
• 设计到项目引用/模块重用时，Submodule的一些操作有些费解

持续集成CI/持续部署CD工具：Jenkins
Jenkins的功能包括：编译构建，代码检查，自动部署，自动测试。至
若无法测试彻底，至少也应做到冒烟测试。

需要注意：

• 整体开发环境
• 循序渐进：从基本流程入手、逐步增加自动化环境、扩大应用规模

部署工具：Docker
通过Docker实现DevOps的环境统一，主要优势有：

• 开发、测试、生产环境的统一
• 解决底层环境的异构
• 易于构建、部署
• 轻量级
• 高效

民生银行IT系统智能一体化测试经验分享

在云和民生银行的这个讲座之间犹豫了一下，还是选择了这个讲座。演讲者是一个搞了15年开发测试，有5本著作的牛人（张绍英）。目前在民生的总行信息科技部。这次分享的这个智能一体化测试平台听得我云里雾里，从理念开始介绍到成果，节约了多少成本，可就是没有说架构，没有说实现方式。这可能也和我测试背景不足有关。简单整理一下：

智能测试平台，生产和测试IT人员都可以用，功能性能测试可以一起完成，无测试执行时间。平台主要是针对银行后台系统做全生命周期的质量管理。通过智能一体化测试平台将测试阶段前移，在开发阶段同时进行测试。

从单元测试，功能测试，集成测试，系统测试这几个层面来说，其位于集成测试之前，基本处于功能测试的阶段。主要实现的是接口（socket，rest，webservice等接口）的功能测试和性能测试。针对不同产品，需要由测试人员编写接口的测试案例，而后自动完成测试。可以组合接口测试（即前一个接口的输出是下一个接口的输入）。由于测试使用线程并发完成，所以执行效率极高。

开发阶段：一周执行一次，每次获取50-60个问题，解决后进行下一轮测试。
测试阶段：后台与前台集成后，结合平台，进行渠道的测试。

由于架构没说清楚，也没有说细节，所以只能大概知道这个产品能做什么。怎么做的完全不明白。

讲座结束后的提问环节，坐在我旁边一个人提问：

“请问如果我们公司的开发代码很烂，而且由于赶进度没有接口文档，也没有设计测试场景。现在是产品出来后，测试团队才开始接触产品进行测试。这种情况下您对我们的测试有什么好建议吗？”

全场侧目

老师愣了5秒

“我想你这个是管理有问题吧？”