| 编辑推荐: |
| 本文来自于ibm,本文介绍了在部署环境和项目进展过程中遇到的挑战，,以及结合
DevOps 的项目开发测试流程的相关内容。 |
|
DevOps 技术简介
“DevOps”是“Development”和“Operations”的组合。表示通过吸引并协调软件交付生命周期中的所有参与者来完成其工作
( 参与者包括业务团队、架构师、开发人员和测试人员、还有 IT 运营和生产人员等 ) 他们都有一个共同的目标：持续创新，通过持续交付来支持持续创新，并通过持续反馈来改进创新。具体地说，就是在软件交付和部署的过程中沟通合作，更快速更可靠地发布质量更好的产品应用。
一个典型的 DevOps 由下面四个不断循环的步骤所组成：
规划与度量 (Steer)
开发和测试（Develop/Test）
发布和部署 (Deploy)
监控和优化 (Operate)
图 1. DevOps 流程图
图 2. 传统的开发流程 
DevOps 强调了系统的整体协作性能，而不是单个参与者或团队的性能和输出。
在传统的工作流中，通过识别需求（由业务团队进行）、构建需求（由开发和测试团队进行），然后将需求传递到
IT 操作进行部署并交付给用户。业务团队想要使解决方案可以盈利（控制成本）；开发和测试团队想要使解决方案可以处理尽可能多的新特性和缺陷（最大化改变）；IT
操作团队想要是的解决方案可以扩展、安全且不易被破坏（最大程度地减少更改）。这样的结果往往会导致最终的项目产品和客户预期产生偏差，而且工作周期也很长
在 DevOps 工作流中，业务团队常常提早接触客户，以便不断掌握和重塑需求。开发和测试团队与操作团队协同工作，并使用共同目标和流程来构建解决方案，这些解决方案很稳定，而且很容易供
IT 操作团队进行交付和维护。另外，将相同的部署工具用于所有开发和测试环境，有助于尽早检测出错误并进行修复。
引入 DevOps 之前项目开发遇到的问题
对客户的需求反馈不及时
客户的真实需求往往隐藏在具体需求之中，这需要产品经理、开发以及测试人员一起进行挖掘和及时反馈才能得到，但是原先传统的开发流程并不能及时获取用户的需求并及时进行反馈和修正。而且到了项目后期产品预发布之前经常会出现当前开发的功能与用户实际需求的偏差，后期的修复成本很高，往往会导致项目的延期。
开发和测试人员的沟通存在障碍
沟通问题还是由于传统开发流程所导致，只有开发人员正式提交版本之后测试人员才能进行测试，这样很多本应在重构、迭代初期就能发现的问题只能累积到测试版本提交的时候才能发现。
项目开发周期过长
一方面是由于传统的编码测试开发流程工作流模式所导致；另外一方面往往在项目后期产品预发布之前才发现当前开发的功能与用户实际需求会有一定程度的偏差，为了满足客户需求，又需要进行编码测试的流程，这样预期之外的流程也会导致项目的延期和开发周期变长。
测试范围不明确
当项目交付周期临近时，每一个新版本出来以后，测试范围到底应该覆盖原先的所有模块，还是将有限的时间和精力放在新功能和需求测试上面，这是每个测试人员感到疑惑的地方，往往会导致测试范围的不明确。
项目周期内测试覆盖率不高
在有限的项目周期内由于不能进行完整测试，会导致测试覆盖率不高
测试人员搭建环境和重复性手工测试的耗费时间过长
现在软件的安装和部署日趋复杂，导致了测试人员很多时候不得不将过多的时间耗费在环境的搭建上面，而且由于自动化测试的普及率不高，重复的手工测试也会耗费很多精力。
其他挑战和解决方式
除此之外，在部署环境和项目进展过程中还有其他挑战，其解决方式如下：
挑战一：网络环境横跨几道防火墙，测试服务器位于不同国家
如图所示，如果想访问客户端（Client）机器，原先的连接步骤是通过防火墙后登陆服务器（也称登陆节点
Login Node)，然后通过内部防火墙后才能访问到 Client 机器。
图 3. 网络拓扑图
解决方案：为了将复杂的网络环境简单化，方便开发调试和测试用例的执行，我们采用远程端口转发技术来构建
SSH 隧道。通过端口转发技术，我们将 GUI 和 CLI 后台的命令调用统一转发到到指定的登录节点机器上面，这样不仅避免了反复通过
BSO 登录到实际节点的繁琐步骤，也为后面的自动化测试提供了一个外部能访问的 http 站点。这样只需要通过直接访问
Server 就能达到控制和操作 Client 的目的 ( 极大的提高了开发、测试效率 )
图 4. 网络解决方案图
Figure-2. Remote port forwarding.
相关的转发代码如下：
ssh -Nf -g -L 8080:10.0.XX.X:8080 172.X.XXX.XXX
ssh -Nf -g -L 2111:10.0.XX.X:2111 172.X.XXX.XXX
注：转发到远端：ssh -L 本地端口 : 目标 IP: 目标端口 用户名 @ 目标 IP
转发到本地：ssh – R 本地端口 : 目标 IP: 目标端口 用户名 @ 目标 IP
-f ：后台认证用户 / 密码，通常和 -N 连用，不用登录到远程主机。
-N ：不执行脚本或命令，通常与 -f 连用。
-g ：在 -L/-R/-D 参数中，允许远程主机连接到建立的转发的端口，如果不加这个参数，只允许本地主机建立连接。
挑战二：开发新特性所依赖的硬件版本不稳定
尽管所有功能必须依托该硬件才能进行开发和测试，但是由于特殊条件导致硬件的固件版本并不稳定，给开发和测试带来了极大的困扰。由图可以看出，2
月到 3 月这一个月之间固件就升级了 4 次，而且并非每次都是稳定版本。
图 5. 固件版本更新列表
解决方案：敏捷开发和持续测试的思路就是不要等到固件版本完美了再开始。开发采用设置桩模块的方式先绕过该硬件
( 这里假定固件版本没有问题 )，进行后续的开发工作。测试先采用一个暂时稳定的内部版本进行测试，待产品每个周期
(Sprint) 结束之前再替换成正式稳定版。
挑战三：需要支持的操作系统很多，各种 arch 平台 (LE/BE/x64) 都需要测试
由于项目的需要，Redhat Enterprise/Centos/Ubuntu 的各种版本，以及 x86_64
LE BE 各种架构平台都需要支持，这给开发和测试带来了极大的挑战，如何在有限的时间内完成各种平台测试和开发。
图 6. 系统和平台列表 
解决方案：操作系统和架构平台太多，在限定时间内每个平台都完整测试显然不太可能，因此根据市场占有率的权重，经开发和测试讨论生成一个测试矩阵，使用该测试矩阵来在单位时间内覆盖客户
/ 市场所需的绝大部分平台和操作系统，测试矩阵覆盖范围之内的所有平台都需要完整测试以保证交付客户的产品质量；其余的平台则采用最小测试方案，来有效的减少测试工作量。与此同时，也在一定程度上提高了测试覆盖率。
结合 DevOps 的项目开发测试流程简介
为了解决了上述的一系列问题，我们依据 DevOps 将整个项目划分为：测试范围策略的制定、行为驱动开发、测试环境管理、自动化功能测试四大阶段，然后再细分为九个具体子步骤。
具体的内容以及相应阶段的负责人参见下表：
图 7. 开发步骤图
图 8. 完整开发流程图
结合 DevOps 的项目开发测试具体流程
S1[ 测试范围策略的制定 ] 制定测试范围
为了及时的对客户需求进行反馈，一旦客户的需求被产品经理所批准，产品经理需要和开发以及测试人员一起讨论明确需求，当需求明确以后开发和测试人员一起讨论并制定测试范围，下面这些问题在需求文档中都需要得到体现：
用户的真实需求是什么？是需要一个新功能还是希望解决一个已知的 bug
为了满足客户需求，是否有些潜在的风险和依赖关系需要被解决？ ( 通常这些潜在的风险会将项目周期放大
)
此次开发最主要的功能是哪些？
我们是否需要引入自动化测试来覆盖其他的范围？
注：
1. 这里假定产品经理角色来完成与客户的沟通和前期需求讨论工作，也可以依据项目的不同由其他人员来代替
2. 测试范围一旦讨论划分清楚，测试计划也可以同步生成并提供
S2[ 测试范围策略的制定 ] 及时矫正测试范围和资源分配
测试人员需要依据客户需求和开发人员在开发工作中的设计流程调整来及时矫正测试范围
开发人员随着开发的进度不断深入会发现客户需求的变更，而且有时由于资源的限制（通常是开发进度 deadline
的原因）导致计划的调整
一旦开发人员有计划的调整，测试范围和资源的分配也要相应进行调整
注：只有开发和测试的高度一致性才能保证项目的进度
S3[ 测试范围策略的制定 ] 自动化测试用例和脚本的优化
项目的进行过程中，测试人员需要不断的优化自动化测试用例和脚本
优化和规划测试用例能保证自动用例的覆盖范围最大化
下面一个例子就是 7x24 小时的规划样例
表 1. 自动化测试 7x24 小时的规划样例
注：这里假定测试服务器只有一台，测试人员的所有行为都需要在该测试环境里面进行
S4[ 行为驱动模式开发 ] 将用户新需求直接转换成用户故事 (User Story) 模式
行为驱动开发 (Behavior-Driven Development：BBD) 模式可以有效缩短开发周期。用户故事可以直接转换成开发、测试任务，从而缩短测试用例的设计和准备周期。
注：如果需求比较大，预计开发周期比较长，也可以用户故事地图模式来进行阶段性的需求分解分析
S5[ 行为驱动模式开发 ] 帮助文档采用在线编辑模式
帮助文档采用在线文档方式有利于团队里面所有的成员进行访问，各种角色的人对文档的理解和解读角度都不一致，有助于文档的完善
注：帮助文档在 beta 版本之前就可以发布
S6[ 测试环境管理 ] 测试服务器的管理
测试服务器的自动化构建解决了测试人员搭建环境耗费时间过长问题，而且环境集中分配和部署也有助于提高资源利用率。典型的测试服务器的搭建就是采用
Openstack 技术的 SelfServer 环境
如下图所示，将 Lab 里面所有的机器组成集群，当有编译、开发、测试需求的时候才会申请一台机器，并进行安装
如图所示登录 Openstack 集群管理系统：
图 9. 登录集群管理系统界面
创建包含所需要的产品集群
图 10. 创建产品集群
图 11. 配置集群相关参数
配置完成后开始创建
图 12. 集群创建中 
创建成功后如下
图 13. 集群创建成功
然后可以在 Overview 界面进行查看
图 14. 集群预览页面
测试服务器一旦生成完毕，也可以采用计划任务进行规范化：
9:00AM 启动服务器的编译脚本
9:30AM 版本编译完毕，启动脚本进行服务器相关配置脚本
11:00AM 配置脚本执行完毕，服务器可以随时交付测试组使用
图 15. 计划任务示例
S7[ 自动化功能测试 ] 覆盖范围包括产品原先的功能模块以及新功能和缺陷
自动化测试功能覆盖范围如下：
原先既有功能的自动化测试
根据客户反馈在原先产品版本上发现并修复的缺陷自动化测试
新功能已经生成用户故事的部分
覆盖测试范围的明确有利于开发和测试集中精力处理新功能和需求，将重复的功能测试交由自动化功能测试来完成。
注：这里假定在开发测试过程中已经给予测试团队一定的时间来撰写自动化测试脚本的时间，并且产品的 GUI
界面比较稳定没有太大的变动，并且 CLI 后台有比较丰富的接口函数便于集成调用
S8[ 自动化功能测试 ] 执行每日自动化测试脚本并生成报告
自动化测试的引入能够将测试人员从日复一日耗时过长的重复性手工测试解放出来。每日自动化测试的目的用以确保产品每日构建版本的稳定性，没有在修复缺陷的同时被引入新的问题。由于时间和资源问题，每日自动化测试的脚本运行时间一般控制在
3 小时以内，首先要保证的是产品的基础功能都能正常工作
下图是以 Selenium 为基础框架生成的自动化测试报告示例：
首先在模块中确定需要执行的测试用例集，然后执行用例
图 16. 浏览测试用例集 
图 17. 执行指定测试用例
用例执行完毕后会自动生成如下的测试报告
图 18. 生成测试报告 
如果配合框架接口，可以将各个模块、产品的报告集合在 Web Portal 进行集中展示和实时查看
图 19. 网页实时查看测试状态
注：由于本文重点在于流程的设计，所以 selenium 框架具体的实施细节并没有在此展示，如果有兴趣的读者可以留言一起进行探讨
S9[ 持续测试 ] 在每次的持续集成中持续测试
DevOps 需要持续集成测试，在每次重构 / 集成 / 迭代后都需要进行功能测试、单元测试来确保产品的稳定性。持续的集成测试能够确保问题的提早发现，降低后期修改的项目成本，也能一定程度上消除开发和测试人员的沟通障碍。
图 20. 持续测试流程图
注：持续测试只是持续计划、持续开发、持续部署、持续监控的一部分，DevOps 就是在各个角色之间进行快速的高效的协作策略来缩短周期提高效率
结束和展望
引入 DevOps 后测试新流程后带来的便利
对客户的反馈更及时
开发和测试人员的沟通更方便
开发和测试范围更清晰
需求变更更加快捷
缩短了开发周期
提高了有限项目周期内测试覆盖率
减少了测试人员搭建环境和重复性手工测试的时间周期
DevOps 作为敏捷开发 (Agile) 的一种项目具体实践过程，在项目的实施中，采用 Backlog
进行每个 Sprint 的管理，任务分解成用户故事取代原先的模块组件分离过程就是 Agile 的实施方式。每日的
Scrum 例会也可提高团队的协作性和进度控制管理。
另外这里的流程管理只是基于目前的项目所展开的，仍然有一些不足，比如：
测试环境的管理应该更加智能化和方便回收和复用
优化测试脚本来在有限的时间内提高测试模块覆盖率
开发和测试人员需要更加紧密的协作来保证用户故事的开发、测试更加便捷
随着项目的不断深入进行，测试服务器的管理脚本优化，自动化测试脚本的不断完善，我们相信一定会让 DevOps
的开发测试流程更加便捷和高效。 |
