devops 下测试组织管理面临的挑战及应对 分布式团队中沟通引起的问题, itest 解决之道

    导读

    先从引起的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 上敏捷测试功能模型，后续随着新版本发布，会加入新特性，如接口，环境，需求，