问题背景

写本文的背景, 主要来源于项目开发过程中的一些问题, 属于是十分影响进度的那类.

联调期间发现一些与约定接口文档不同问题, 导致存在的重新联调.
1. 变更比例相对较大.
业务的开发/调试需要等待平台上游功能开发完.
1. 如OS组和集群组的平台功能完毕后, 依赖这俩部分提供的基础系统与数据库的业务组件方能开工.
2. 这部分过程中, 其他组其实无法投入这部分的开发. 但是联调又基本就是同一时间各个组之间开展的.
ceph与业务层SAN/NAS之间的联动测试. SAN/NAS依赖ceph的实施能力
新架构下, 尝试通过更高的功能需求, 对老代码进行重构. 所需耗时就不单纯是开发的时间了.

问题理解

1. 需求/设计变更

这点, 个人理解只能是期望个人设计能力以及评委的用心程度了.

确认功能与需求全覆盖
接口交互, 异常考虑周全
清楚代码的历史包袱, 准备/沟通好变更.

这里倒是有个需要注意的, 模块与设计应当是匹配的. 后续其实迭代模块, 这些设计也是应该保留下来的. 仅在项目流程中出现一次, 后续这个设计就不再维护迭代, 可能不太好.

2. 基于平台的业务功能的开发过程

一个新增业务功能, 需要平台提供新功能支持, 而后业务部门方可开始开发.

目前采用的方式是, 业务小组的该功能相关的负责人会参与平台部门提供的业务功能配置的填写. 需求方面, 参与度较少. 主要还是架构师与平台功能组澄清功能.

从这个角度, 业务小组在这个开发过程的参与, 一般出现在平台功能组输出了规格文档, 平台功能组需要各业务组开始使用, 调试. 然后联调阶段.

然后在联调阶段, 业务团队会发现平台团队的功能/环境存在的问题, 此时平台方面开始处理修复. 然后继续联调. 按照缺陷单和最终的输出上肯定是一样的. 但是是否可能通过分批上车, 让平台功能的稳定性也能通过完整的闭环流程予以通过呢?

这种情况下, 业务部门此时是否更适合作为需求方? 而不是单纯的平台部门的联调方?

从上面的描述来看, 其实一开始就参与也可以. 但是, 实际执行过程中, 业务小组实际上在一开始阶段没有怎么投入人力, 但是基于项目管理的统计时, 由于需求并不区分平台功能, 还是业务功能, 此类需求最终统计人力资源消耗时其实也是将业务团队在一开始纳入了考量的. 而实际, 这个功能是初期平台功能组投入, 后期各业务组投入. 所以这部分, 可能按照[^## 5. 多任务同时派发与分批次派发]拆解成分批次的需求, 可能更为恰当?

TODO: 是否平台功能与业务功能, 是需要拆分的? 需求方面也应该区分对待? 简单搜了下, 没搜到此类的区分. 在多团队组织中, 是否确实是有必要区分处理?

3. 组装开源组件时的集成测试

部署类代码

ceph产品的cluster->osd->pool->rbd|cephfs|rgw->iSCSi|nfs|samba的部署就是一个链式关系, 这部分角度上来说, 关键是开源组件之间的接口依赖关系的联调测试的问题.

根据ceph-ansible的情况来看Test Scenarios — ceph-ansible documentation, 是通过vagrant搭建虚拟机, 然后拉起不同规格虚拟机来测试集群部署.

vagrant根据测试功能所需配置拉起对应盘的虚拟机, 然后运行.

NOSDS           = settings['osd_vms']
...
(0..NOSDS - 1).each do |i|
    config.vm.define "#{LABEL_PREFIX}osd#{i}" do |osd|
      osd.vm.hostname = "#{LABEL_PREFIX}osd#{i}"
      if ASSIGN_STATIC_IP
        osd.vm.network :private_network,
          ip: "#{PUBLIC_SUBNET}.#{$last_ip_pub_digit+=1}"
        osd.vm.network :private_network,
          ip: "#{CLUSTER_SUBNET}.#{$last_ip_cluster_digit+=1}"
      end
      # Virtualbox
      osd.vm.provider :virtualbox do |vb|
        # Create our own controller for consistency and to remove VM dependency
        unless File.exist?("disk-#{i}-0.vdi")
          # Adding OSD Controller;
          # once the first disk is there assuming we don't need to do this
          vb.customize ['storagectl', :id,
                        '--name', 'OSD Controller',
                        '--add', 'scsi']
        end

        (0..2).each do |d|
          vb.customize ['createhd',
                        '--filename', "disk-#{i}-#{d}",
                        '--size', '11000'] unless File.exist?("disk-#{i}-#{d}.vdi")
          vb.customize ['storageattach', :id,
                        '--storagectl', 'OSD Controller',
                        '--port', 3 + d,
                        '--device', 0,
                        '--type', 'hdd',
                        '--medium', "disk-#{i}-#{d}.vdi"]
        end
        vb.customize ['modifyvm', :id, '--memory', "#{MEMORY}"]
      end

根据ceph-ansible和openEuler的做法来看, 部署类代码均藉由对虚拟机的控制的CICD来完成质量保障.

这些操作, 关键是属于资源的调度, 如果撇去虚拟机提供的资源, 实际上就无法测试到其对虚拟机内的硬盘等资源的实际分配了.

如果是分配逻辑贴近业务, 则可以比如mock不同的配置进行单元测试, 输出的也是一种配置形态. 但是如果分配逻辑关键就是对虚拟机操作系统提供的基础API的兼容性确认, 则就只能是藉由CICD完成质量闭环了.

IO路径的核心逻辑代码

SAN/NAS对ceph存在依赖关系, 而ceph如果做大规模升级, 经常会出现不兼容的问题, 此时SAN/NAS基本上就很难在ceph适配开发的同时, 同时使用新版本进行开发.

开发阶段, 手动搭建ceph环境即可. 联调/集成阶段, 理论上下层接口如ceph自身的单元测试完成了一定程度的保障, 剩下产品层面的完整功能集成这种确实只能依赖CICD.

管理的web前后端代码

后端

当前我们的web后端, 是直接依赖底层的具体响应, 属于协议转换层. 而不是存在自身数据库设计的一个完整的管理平台后端, 因此个人来看确实无法脱离底层接口与操作系统, 自身进行这个web后端的业务逻辑的单元测试. 此时的话, 确实只能在底层开发完毕后, 通过CICD来闭环自身的质量.

如果是一个独立的后端, 底层只是作为一层数据来源, 以及具体实现层. 底层异常时, 其实不影响页面的数据展示与交互. 只是下发的请求会超时/失败. 但是不影响查询和展示. 这种层面的模块可能才能完成自身的单元测试吧.

前端

前端模块主要就是依赖后端提供的协议设计了, 本身就具有mock能力. 协议设计变了, mock也要跟着变.

可能存在一方面因素就是, 由于目前CICD不完善, 后端在开发过程中极度依赖底层的接口, 底层接口的设计变更导致链路的变更. 从而工作量加大. 本身如果做好了解耦, 可能前端,后端,底层三层之间不至于耦合这么紧密.

4. 藉由新版本需求, 同时进行功能开发

按照我现在的理解, 一般情况下感觉因为有版本的功能需求, 比如支持集群规模, 性能等存在了更高的要求, 所以此时可以抛弃一大波历史包袱, 从而进行代码重构.

但是客观上, 实际进行的过程中也确实遇到了很严重的问题.

代码的重构开发, 实际上需要的时间要比预估的多不少.

重构是在项目整个过程当中的一种习惯，并非是其中的一个阶段。

不要定下一两周时间，说这个工作是重构。应该在整个项目过程当中，随时开始，随时停止。每一次重构都是很细微。 [^在感觉项目代码的构架不行的时候,你们会怎么办? - 知乎](https://www.zhihu.com/question/47283785)

按照上文的表达, 其实一些工作, 可能不能在新项目上进行. 而应该提前或者在日常过程中, 就开展了. 新项目只做一个局部适配或者切换版本的工作, 这样可以相当程度上降低需要的时间代价.

5. 多任务同时派发与分批次派发

其实还是任务并行的问题, 如果是单纯的开发需求, 那实际上开发时已有初稿设计, 如果大家都提前定义后, 那确实后面开发的时间就无所谓, 互相之间没有依赖.

但是对于一些新定义的平台需求, 他基础平台开发完->自测通过->联调通过, 这个过程中其实是存在需要拉其他业务团队来设计, 沟通, 联调的. 而此时, 这就对其他团队的时间做出了限制, 这个阶段的时间由于要配合平台需求的落地, 就只得拆解部分时间. 这方面是否对于业务团队, 是否有必要那么快开始? 这个其实我现在来看, 还是个疑问.

考虑的可能的解决方式

分批次需求, 拆分轮次. 如平台功能, 提前进入. 如B1/B2轮次等, 其他相关依赖第一波平台功能开启.
1. 需求的数量级太大, 局部拆解. 如需要长时间预研的, 则纳入预研项目跟进进展. 在新项目的第一轮需求中不纳入考量.
2. 不能直接让多个资源组同时处理大批量需求, 这样就完全取决于资源组的人力协调. 这个协调成本每个阶段核对都会存在忽视风险.
  1. 比如OS组的包管理机制, 提供基础环境这种, 更适合提前开始. 至少先提供出基础框架/可供开发的基于老版本的兼容性方案. 如3-4月份优先复用老成果物提供基础方案也行.
3. 并行任务最好一个人同一时间不要超过3个? 工作流, 要拆解的更加细. 否则上下文切换带来的切换时间/环境准备时间等可能也会占用一部分?
  1. 项目中明确分批次验收, 甚至分子项目验收. 每个轮次出的成果物, 后续的人需要审核审批, 审批的人的时间管理由项目经理控制.
  2. 因为每个组阻塞一阵子, 上下游链路太长. 就仿佛ceph的链路一样, 对于不知晓常见问题的人, 就只能一层层推进. 而不是一步到位.

TODO

TODO: 这款其实是可以参考下开源社区如何处理这部分的? ceph的话, 这部分其实是通过qa集成测试完成的?

TODO: 持续集成/基线开发, 这部分应该跟测试所需的代码之间的解耦无关吧?

TODO:ceph-ansible的测试是怎么跑? 是否要做隔离?

企业集成[^【网站架构】中大型网站如何防止项目延期？敏捷开发在实际项目如何应用？\_停止重构的博客\-CSDN博客]

这里说的集成, 跟集成测试应该关联并不大. 跟ERP系统也有些关联.

指的是企业内的组件功能之间的集成好像.

类似大中台的那种理解? 由中心代理服务来管理各组件之间的通信.

更进一步就是

基于消息的企业服务总线, 将组件之间关联通过一条总线完成管理

当然这种管理机制, 如果总线不出问题的情况下, 延时可接受的情况下问题不大. 猪油最新的那种RDMA等技术, 对延时有要求时, 则物理总线会进行处理.

ESB 的定位，是一项采用开放标准的服务。这样就不需要为每个应用编写唯一的接口了。只需对应用进行最小幅度的更改，就能部署集成服务。 ESB 依靠符合行业标准的开放协议和接口，简化新的部署。

[^【网站架构】中大型网站如何防止项目延期？敏捷开发在实际项目如何应用？\_停止重构的博客\-CSDN博客](https://blog.csdn.net/Daniel_Leung/article/details/122347803)

OpenEuler

日常构建测试范围

QA: QA repo provides rules about how QA team runs and how contributors to this project, also includes test cases and framework

alpha版本

安装部署
- 我们比较关心的项
软件包安装/卸载
组件测试(内核/虚拟化/容器/编译器等)
系统集成类
系统服务类(登录/防火墙/分区/服务状态检查/日志/kdump)

beta版本

冒烟测试内容
新需求/特性功能验证
性能测试
升级
社区众测

TODO:beta由qa团队组织, 是否会保存类似系统测试用例设计呢? 这种是否有资料可以借鉴?

release

β版本测试内容
压力稳定性测试
安全测试
兼容性测试
文档测试

软件包测试标准

基本总结可以理解为, 是基于mugen: Test framework and test suites框架, 对软件包提供的CLI接口进行测试验证, 并完成安装卸载的. 有无痕要求.

TODO:潜在的问题, 如何解决那种依赖较多的包? 如ceph? 暂未找到

开源实习经验分享：openEuler软件包加固测试

联调集成质量小思

2022-10-30
专业

联调集成质量小思

问题背景

问题理解

1. 需求/设计变更

2. 基于平台的业务功能的开发过程

3. 组装开源组件时的集成测试

部署类代码

IO路径的核心逻辑代码

管理的web前后端代码

后端

前端

4. 藉由新版本需求, 同时进行功能开发

5. 多任务同时派发与分批次派发

TODO

企业集成[^【网站架构】中大型网站如何防止项目延期？敏捷开发在实际项目如何应用？\_停止重构的博客\-CSDN博客]

OpenEuler

日常构建测试范围

alpha版本

beta版本

release

软件包测试标准

TODO:潜在的问题, 如何解决那种依赖较多的包? 如ceph? 暂未找到

测试代码

openEuler/integration-test - 码云 - 开源中国系统基础包/命令的集成测试

联调集成质量小思

问题背景

问题理解

1. 需求/设计变更

2. 基于平台的业务功能的开发过程

3. 组装开源组件时的集成测试

部署类代码

IO路径的核心逻辑代码

管理的web前后端代码

后端

前端

4. 藉由新版本需求, 同时进行功能开发

5. 多任务同时派发 与 分批次派发

TODO

企业集成[^【网站架构】中大型网站如何防止项目延期？敏捷开发在实际项目如何应用？\_停止重构的博客\-CSDN博客]

OpenEuler

日常构建测试范围

alpha版本

beta版本

release

软件包 测试标准

TODO:潜在的问题, 如何解决那种依赖较多的包? 如ceph? 暂未找到

测试代码

openEuler/integration-test - 码云 - 开源中国 系统基础包/命令的集成测试

5. 多任务同时派发与分批次派发

软件包测试标准

openEuler/integration-test - 码云 - 开源中国系统基础包/命令的集成测试