周六参加的一个 devops 沙龙，看的不仅是测试，更是整个团队。听完后感觉还是有不少收获的，在此记录一下，也是作为自己的成长记录。
官网：http://DevOpsDays.org
中国：http://ChinaDevOpsDays.org
讲师：汇丰基金服务软件负责人 刘华 著有：《猎豹行动：硝烟中的敏捷转型之旅》
银行项目特点：非 MVP ，偏向大而全
时间、预算、范围、外部依赖
传统内部开发团队：先做几个迭代，测速再估算
银行难点：外部依赖多，非内部团队
工具：MS Project（工作分解结构）
敏捷交付模式：
通过限制在制品，确保聚焦最高优先级的交付
优先级排序：IT 上线标准>合规要求>公司内控要求>业务定制化需求
敏捷原则：
去中心化、协作、透明...
敏捷教练需要在战壕里
业务人员如果给不出具体验收条件，需求就是不完整的，进入不了开发阶段。
验收条件目标：可测试、任何人均可操作。
举例：开四停四、新个税办法说明。核心点：举个具体的例子
问：瀑布流团队，如何快速反馈
答：各个节点切换（如提测、发布前）时，均需要和需求方进行反馈沟通，确认理解一致
埃森哲卓越测试中心负责人 17 年从业经验 陈晓鹏
赌场项目 博彩管理系统
挑战：
组织架构图：
5 个 scrum team，每个 team 2 个 BA，5 个开发，1 个功能测试。2 个测试开发（5 个 team 共用）
系统架构图：
given when then
价值：
减少浪费——业务导向
变更安全——自动化验收减少变更风险
发布更快——自动化验收提高效率
需求明确——避免理解不一
对测试带来的困难：
技术风险——对新技术经验不足
进度风险——测试时间少
质量风险——涉及会员账户，对质量要求高
管理风险——Scrum+BDD，测试人员玩法和瀑布流差异大，需要探索
解决思路：
解决方案：
cucumber 粘合，产生代码框架，节省转换工作
selenium 执行 web UI
cucumber 基础上加关键语句，做 api
架构：
测试流程：
持续集成流程：
各节点图
整体流程图
一个 sprint 中的自动化测试流程
问：feature 由业务写，可能吗？
答：BA 和客户沟通后编写，开发、测试、BA 一起 review 确认
问：测试数据怎么管理
答：放到配置管理中，脚本自行创造需要的测试数据和测试后进行消除
问：对于复杂度较高，链条较长的系统，测试稳定性会受到非常多的影响，数据如何管理？
答：建议听后续微服务的分享，做好服务解耦 ：（
问：自动化发现不了 bug ，意义何在？
答：杀虫剂理论（第一次杀得了，后续会免疫），自动化需要不断更新维护
问：自动化测试开发做更强，测试人员价值何在？
答：1. 测试人员也会自动化。2. 关注集成层面、整个系统层面的测试，以更全面的角度查看系统质量
PPmoney 容赜
救赎：曾经拥有，失去后找回来
13-14 年：重复的业务封装在几个服务，SOA 架构，演进较慢
15-16 年：提出口号：打造世界一流的微服务框架，自研 dolphin
16-17 年：反思，spring cloud 全家桶，100+ 服务
17-18 年：救赎，微服务 + 容器化部署
热闹驱动三连击：
框架转型态度
框架选型态度
工程效率的严重挑战
开发：架构复杂、服务拆分粒度
测试：复杂接口测试、代码质量、Bug 追踪分析
运维：交付频率、监控复杂
困惑
微服务在 12-15 年均未纳入采用阶段。在使用微服务前，需要在持续交付和基础设施自动化实践方面具备最低程度的成熟度。
持续交付和基础设施自动化、演进式设计等，需要补足。
如何救赎
流程文化——建立规范
代码评审委员会
组织变革
工具引入
完善微服务基础设施（ppmon 全家桶）
案例：监控系统的挑战
度量（立体化监控）、日志（elk）、跟踪（pinpoint）
改造 logback 插件——注入调用链主键（transanctionId）串联各系统信息——统一日志规范让其在全团队落地——发起错误日志零容忍活动——发起仪表盘设计大赛
容器化的持续交付流水线——jirachi 研发云平台，构建产物为 jar 及 docker 镜像
第一个：测试环境部署频繁，业务测试相互干扰，环境间相互调用关系复杂
使用 jirachi ，各环境独立隔离，各服务自主部署
第二个：新入职员工培养
组织技术比赛>优胜作品成果>DevOps 团队参与技术框架升级>输出入职培训流程，实践 PPmon 框架
总结
规划
问：怎么拆耦合度比较合适？
答：没有统一标准，需要根据实际情况不断调整
问：这么多改进，如何如此快速地推进
答：文化先行，让大家兴奋起来。放权，协助协调资源，交给具体的负责人推行。软硬兼施，软靠活动，硬靠考试、规范。
测试一下专栏编辑
