devops 下测试组织管理面临的挑战及应对

    导读

    先从引发的5个问题讲起，再简单回顾一下devops 简介和兴起背景 ,再从itest 测试管理团队的视角提出应对办法

   DevOps后，测试面临的挑战

       敏捷开发必然是迭代开发管理模式，以实现持续集成和持续交付，而不是瀑布模式下阶段性介入。

       问题1：持续集成首先引入的问题是集成环境的管理的问题，大公司有专门的运部门还相对好一些，小公司环境会直接摔给测试人员自己整，测试人员如果环境一直依赖开发人员，那测试人员在公司的地位当然也可想而知了。

      问题2： 持续交付下，不可能做到每个迭代手动回归的所有case

      问题3：每个迭代侧重点不一样，测试策略必然不一样

      问题4：上级管理者，需要快速知道整体测试进展，以便更好的进行风险把控

　   问题5：敏捷测试中，在每日站立会中，要拿测试数据说话，咋便利收集测试数据，简单扔两个统计图是远远不够的，需要体现出进度和工作量的数据，以及相关过程监控趋势分析数据，数据从哪来呢?

       在探讨应对之道前，先简单回顾一下 devOps

DevOps 简介：

      DevOps 是一个完整的面向IT运维的工作流，以 IT 自动化以及持续集成（CI）、持续部署（CD）为基础，来优化程式开发、测试、系统运维等所有环节，DevOps的引入能对产品交付、测试、功能开发和维护起到意义深远的影响。

DevOps 兴起的必然趋势：

　　配套技术录下已发展成熟：微服务架构理念、容器技术使得DevOps的实施变得更加容易，计算能力提升和云环境的发展使得快速开发的产品可以立刻获得更广泛的使用。

      来自市场的外部需求：这世界变化太快，产品需要快速适应这些变化，并需要快速把产品交互到用用手中，团队可以更快地得到用户的反馈，从而进行更快地响应。而且，DevOps小步快跑的形式带来的变化是比较小的，出现问题的偏差每次都不会太大，修复起来也会相对容易一些。

 实现DevOps

      硬性要求:相关支撑工具，如cd/ci 工具，自动化运维工具等

      软性需求：团队文化 ，即敏捷开发文化；团队技术水平

      如何实现devops 不是本文要阐述的问题。

既然devOps 是必然趋势，那开篇的问题也应意味着迟早要碰到，下面我们来看看应对之道：

 问题1，测试环境管理应对之道：

      采用虚拟化技术，主要是容器技术，第一可实现快速部署，第二在有限硬件资源下，可合理调配资源降底环境成本，当然大厂有大厂的玩法，小厂有小三的玩法，但都可以用，只是大厂在使用上需结合业务系统自身的特点做一定的整合或改造，比如微服务的路由，微服务网关，业务组件多，可能还需要用类似Kubernetes相关技术以及Namespace实现隔离;小厂是单体应用，或是数量不多的少量微服务，或是微应用，用原生的docker 就可以解决，测试人员编写docker file 也不是难事。

 

  Itest(流程驱动开源测试管理软件新秀官网)  即将发布的3.1.2 版本中，将实现环境管理功能，简单来说，就是可以管理测试环境的docker 镜像，或docker file 文件，实现一键部署测试环境，当然我们这是小厂的玩法 ,大厂这里略过，估计会有一套相关环境管理的支持系统做辅助。

 环境功能已开发完成，未测试，业余时间做，等不忙了进行测试，即将发布的3.1.2 版本会含此功能 

 预发环境可理解为UAT 环境，就是线下和生产环境的软件环境一模一样的环境，当然硬件配置上会有差别

 问题2，每个迭代不可能手动执行所有case ，应对之道：

    自动化测试，首先自动化回归测试所有case 对应的接口，然后手动重点测试当前迭代完成的功能，再根据具体研发实现的改动，圈定一些测试包，手动执行测试包内的有例，说到这里，肯定有同学会反问，这要做风险很大，确实是有风险，这要求开发团队在实现时，要么组件化，要么微服务化，这样新的迭代对原有功能实现的影响最小，话有说回来，既然要玩devOps ，必须这么搞测试呀，如两周一个迭代，每个迭代手动跑完所有CASE是不实现的，就算有这风险， 也能倒逼研发在设计时多考虑组件化，微服务化，降低偶和（中型及大厂都有这自己的企业中台实现这些比较容易），才能快速迭代，快速响应变化，否则这是假敏捷，只是把瀑布模型拆分为几个提交可测试特件的里程碑（虽然这也是一小点进步）。当然上述这是其中两种主要方法，现实中还需要根据实际情况作出相应调整。

 

Itest(流程驱动开源测试管理软件新秀官网)  测试包管理功能如下图所示，3.2.1 版中奖现接口测试功能，在EXCEL中一行测试一个接口，设置上接品URL，参数，请求方式， 预期返回数据 ，如需要，还有用于认证的toekn 参数，然导入到itest 中，itest 来执行这些接口测试，并把测试结果管理起来，也可在ITEST中设置每个接口执行测试的次数，以及执行的时间，或是按预定的时间，itest 定时去执行这个接口测试。

 

每个一测试包，代表了某个测试策略的一组测试用例，且可查看执行结果

    另外测试小组能力水平也不一样，且具体到某个迭代开发团队，测试团队，可能都有差别，比如团队是分布式的 可参见本一另一个贴子 分布式团队中沟通引发的问题, itest 解决之道  

     不同的团队规模，不同的迭代内容，不同的测试策略，测试流程也可能不一样，在itest 中  流程推动缺陷流转，不同的流程对应不同的状态演化，反应不同管控目的，并可实时调整

 

 

 问题3， 每个迭代侧重点不一样，测试策略必然不一样，应对之道：

     itest  (流程驱动开源测试管理软件新秀官网) 根据当前或即将进行的迭代的产品或是项目目标，定测试任务，以便进行整体上的把控，然后挑选出当前迭代要解决的BUG和需求（itest 后期会增加需求管理功能），以及要执行的测试用例包，组成一个完整的测试迭代；然后测试和开发人员，直接在这个迭代下处理 BUG，执行用例，填写测试进度任务进度，填写需求实现状态（进度）。且可以便捷的查看特定测试迭代的报告；对于单一某个测试包也可查看其测试结果。

 测试迭代报告

问题4：上级管理者，需要快速知道整体测试进展，以便更好的进行风险把控

     上级管理者， 首要关注的是整体的测试进度，在itest 中，在一个测试迭代内可建多个测试任务，每个任务针对特定测试目的，然后以敏捷管理的看板形式展现出来，一目了然，没有再实现甘特图，我们认为，电子看板就足够了，当进度和上级管理者预期有出入时，他可提交干预，加入更多资源，或是其他风险规避措施。测试执行中，具体的 BUG数据，用例执行数据不是不重要,他是更“微观”数据，在管理上首先需要宏观方面管理数据，把测试工作纳入到任务管理中，就是为了宏观管理目的，宏观和“微观”本质上就是先整体后具体。

 

  问题5：敏捷测试中，在每日站立会中，要拿测试数据说话，咋便利收集测试数据，简单扔两个统计图是远远不够的，需要体现出进度和工作量的数据，以及相关过程监控趋势分析数据，数据从哪来呢?

    itest (流程驱动开源测试管理软件新秀官网) 的应对之道：站立会，每个人说话的时间不长，就更要求有整理好的数据说话，体现测试的专业性，在ITEST中，提供两个数据渠道，第一通过总览，帮助会前，作每日工作复盘；第二通过测试度量，以27个主题，从多维度(时间、人员、工作量、团队、缺陷和用例)、多指标过程监控，和结果汇总两方面来量化测试工作，然后再对这些量化数据进行归纳和总结。下面仅用几个图例来示例，后续会有相关解读itest 测试度量的贴子发出。比如BUG 龄期，itest 中有绝对龄期和相对龄期，一个指从BUG被发现，到被closed的 龄期,相对龄期指BUG停留在某个状态下的龄期,测试用例的执行，不仅看用例数，更看执行成本 ，从提交|打开|待处理|关闭|处理bug次数 趋势中分析，整个研发团队(含测试)工作瓶颈点在哪等等。

    itest ,一款汇聚10年经验，流程驱动测试的开源的测试管理软件，是我们测试人自己开发测试管理软件，体现我们对测试的情怀，是最懂测试人的开源测试管理软件新秀  ；Itest 开源团队成员由来自对软件测试有情怀，热衷于开源，又热心传播分享我们测试理念的一群人组成。也可在线体验，也有一键安装包， https://itest.work/rsf/site/itest/product/index.html 

 

本文借鉴了下面PPT的管理理念，itest 是PPT中阐述内容加devops 思想的落地实现产品

项目管理在测试管理中的应用 

 

 附itest  v3.1.1 上敏捷测试功能模型，后续随着新版本发布，会加入新插性，如接口，环境，需求，