原计划本篇要写0代码接口测试，因最近询问Codes 迭代的人多，就先写多事项闭环迭代的创新实现。

1、简介

     Codes 重新定义 SaaS 模式 = 云端认证 + 程序及数据本地安装 + 不限功能 + 30 人免费 

     Codes  是一个 高效、简洁、轻量的一站式研发项目管理平台。包含需求管理，任务管理，测试管理，缺陷管理，自动化测试，cicd 等功能； Codes 帮助企业加速融合研发、测试、运维一体化进程。商业版不限功能，本地安装只限用户数，30 个用户免费 ; 社区版当前只开放了测试跟踪管理 (主要功能用例管理，缺陷管理)，后续接着分离其他功能代码出来。

官网 https://icodes.work/

gitee 代码仓库 https://gitee.com/xiaoming1q/icodes

       2、背景

      市面上老一点的项目管理工具迭代下只含任务，其他一些新的项目管理工具迭代下包含了需求、任务和缺陷。迭代下只包含任务显然很不合理；只有需求、任务和缺陷，也是有问题的。

      一个研发周期的闭环：从需求-->到研发任务-->到测试-->到上线。一个迭代就是一个研发周期，迭代下的需求除了可分解为开发任务外，也应可分解为测试用例才方便测试左移；很多项目管理工具，迭代下虽然有需求和任务，但是他们是隔离的，不能从需求中拆分出任务，这也不符合一般的敏捷开发过程。

        3 多事项闭环迭代功能说明

        3.1  敏捷场景拆解为迭代的业务过程

       Codes 产品团队基于以上众所周知的认知，不走寻常路，从实际出发采用多事项闭环迭代的实现方式。敏捷开发的场景如下图所示：

​

       Codes 中把上述敏捷场景拆解为迭代，迭代作为一个完整的研发周期闭环，包含了从需求、到任务、到用例、到测试、到缺陷、到自动化测试到上线，并自动生成迭代总结并存档。

     敏捷场景拆解为迭代的业务过程：1从需求池中分配需求到迭代下 2在迭代下把研发把需求拆分为任务 3在开发拆解任务的同时，测试同学可进行需求测试并针对需求编写测试用例 4待开发同学完成研发任务提交测试后，测试同学执行测试用例，且执行不通过就提交缺陷 5在工作的过程中提交工时日报，自动计算迭代进度   6 迭代总结及复盘 7上线发布。

      3.2 Codes多事项闭环迭代功能说明

       如下图所示，迭代下有需求、任务、缺陷，测试用列，功能业务场景，接口场景，交付物和发布，场景内用例，人员分工。需求可分拆解为任务和分解为测试用例；功能业务场景为场景用例，是一组有执行顺序的用例集合；交付物为迭代中产出的各种文档；发布指上线时执行的一系列有先后顺序的事项，也可当一个发布的check list 来看，省得因粗心引发问题；人员分工，显示迭代下各人员事项分工及进度；工时趋势显示预估工时、实际工时和已用工时趋势。

​

     Codes 的迭代也为不完全按标准流程的场景提供了灵活性。比如，如果需求很简单可以不拆解为任务，直接把需求当任务来处理；另外如果没有需求，直接建任务也是可以的，这时在迭代下任务的TAB页中可以把不关联需求的任务分配到迭代下。迭代下任务TAB中的任务有两个来源，拆解需求的任务，以及手动分配到迭代下不关联需求的任务。

      3.3 为方便从不同维度来查看相关工作项，需求、任务，缺陷和用例都支持分组显示。

需求分组，可按负责人、创建人、来源、优先级、流程、需求分类、状态来分组以及以看板视图来显示。缺省为标准视图，也就是不分组的列表显示。

任务分组，可按负责人、任务类型、紧急程度、需求、状态来分组以及以看板视图来显示。

​

缺陷分组，可按待处理人、提交人，状态、等级、需求来分组以及以看板视图来显示。

      迭代下的缺陷可以是当前迭代中新提交的缺陷，也可能是需要当前迭代解决的存量缺陷。

用例分组，可按执行人、状态、类别、优先级和需求来分组显示。标准视图是缺省视图，就是不分组的列表。

​

      3.4 以迭代方式组织测试的特点

      传统是以测试计划来执行测试，一个计划下分配要执行的用例，难以体现出测试执行人员的分工以及不同执行人员之间的执行进度。一个执行人一个计划，多人就要建多个计划，非常不方便，同一个计划下如不同的人执行不同的用例只能口头来安排。

     Codes 中，把用例分配到迭代下后，再分配执行人，也就是在同一迭代下，各自有各自要执行的用例，然后可以查看到总进度也能看各自的进度。

分配用例到迭代

在当前迭代需求下，编写的用例自动分配到当前迭代下，当然也可以分配其他的用例到当前迭代下。

​

分配执行人

     可勾选要分配的用例，也可以左边的树上勾选相关需求，也可把当前查询到的用例全部分配（不用一一勾选）

​

执行用例

可快速执行，比如回归测试时，不需要查看用例明细后再执行。

​

也可点用例状态，在用例明细中执行

​

查看执行情况，有总进度也有各人各自的进度

​

      3.5 交付物

    迭代中的一切产出物可以在这里维护，且会自动放到项目文档下，在项目文档和迭代交付物中都可方便的查看迭代中所产出的文档。

​

     3.6 人员分工

     这里可以看迭代下各人员的事项安排及进度

       3.7 迭代工时趋势 

       可以查看迭预代估、实际及已用工时的趋势，Codes 中还可查看阶段以及项目的工时的趋势。

​

      3.8 迭代报告及发布

      迭代报告可导出来，且迭代设置为完成时自动在项目文档中存一份迭代总结。除总览的TAB外，其他TAB都是明细数据。

​

发布

主要作为上线前check list事项 ,确保上线不会因遗漏出问题。

​

3.9 采用多事项且闭环的迭代的好处

      以迭代为中心来组织研发工作，围绕需求拉通上下游所有研发活动。方便复盘，过程管理更通透和全面。那会不会带来混乱呢？肯定不会，虽然所有事项都在一个迭代下，但不同职位的人员进入迭代的执行时间是不同的。

      因迭代中包含了的所有事项，那么迭代的进度和工时更完整的。用例我们用执行成本而不是用例个数来计算工时，另外在Codes 工时日报中除把迭代下，需求，任务，缺陷，用例工时都记录下来外，其他事项，如开会等也计算到工时中，没有预估工作量的待办事项也通过日报中剩余工时记录下来，也就是说Codes 计算进度的数据是全面的，所以计算的进度更准确。

上图迭代进度还可下钻到人

       原本就浑然一体的工作形成闭环，打破使用者的割裂感：不需要文档在叧一个功能模块中集中维护，做到研发和测试不分家，实现统一管理。也解决了测试在DevOps快速迭代中的木桶效应，促进了研发、测试、运维一体化融合进程。

       更具灵活性，可闭环选代，也可非闭环迭代即和传统做法一样只有部分事项参与迭代。

     最后打个总结：Codes多事项闭环迭代一点技术门槛都没有，我们这样实现就是为了方便完整管理一个研发周期，可以按版本来规划迭代，也可按交付的时间周期来规划迭代。创新不是为了玩新奇，是为了解决问题，下一次我们来聊聊另一个创新点，也是很酷的功能，欲知后事如何，且看下回分解。匠心打磨，持续创新是Codes的产品基因。