兖州网站建设推广,成立公司的好处和坏处,来年做哪些网站致富,快速做网站的软件前言 Codes 是国内首款重新定义 SaaS 模式的开源项目管理平台#xff0c;支持云端认证、本地部署、全部功能开放#xff0c;并且对30人以下团队免费。它通过整合迭代、看板、度量和自动化等功能#xff0c;简化测试协同工作#xff0c;使敏捷测试更易于实施。并提供低成本的…前言 Codes 是国内首款重新定义 SaaS 模式的开源项目管理平台支持云端认证、本地部署、全部功能开放并且对30人以下团队免费。它通过整合迭代、看板、度量和自动化等功能简化测试协同工作使敏捷测试更易于实施。并提供低成本的敏捷测试解决方案如同步在线离线测试用例、流程化管理缺陷、低代码接口自动化测试和 CI/CD以及基于迭代的测试管理和测试用时的成本计算等践行敏捷测试。 Codes 敏捷测试功能架构图 1、背景 敏捷开发越来越流行且敏捷研发取得了一定成效如下图所证 敏捷测试是敏捷开发的必然需求 持续交付可以降低发布风险提⾼可靠性使软件能够根据⽤户反馈、市场变化和企业战略变更不断进行调整敏捷测试是持续、快速、有效的测试过程作为软件交付流⽔线的重要一环敏捷测试是企业改进加快交付的关键途径。 遗憾的是测试成了敏捷开发中持续交付的最大短板。为什么测试环节会成为敏捷开发快速交付中的瓶颈主要有如下7个方面的原因
1、用例维护效率低手工测试占比大
2、测试产出难量化
3、测试左右移难
4、测试管理人员和测试执行人员难以高效协同
5、测试速度慢碎片化管理
6、用例重用难或重用方式不便捷
7、缺陷管理太简陋主要靠人来推动 VUCA时代市场要求企业快速响应变化企业需要集中内部资源不断试错快速迭代更加灵活的应对外部变化存量时代要求越来越高测试如何”敏捷”起来呢
2、敏捷测试关键在于什么 从适配敏捷开发的角度来看实施敏捷测试关键在于下面5要素 迭代作为测试的实施组织形式看板让各阶段研发活动公开透明将测试工作透明化自动化可以提高测试效率度量让测试成果可量化测试左右移使测试紧跟开发的节奏且尽早开展测试右移一可让测试独立维护测试环境二可确保生产环境任何风吹草动都可被测试感知。
另外从质量管理层次和质量分类上来看也能证明上述5要素的合理性。
质量管理层次 质量分类 3、敏捷测试与传统测试有什么不同 过程都和下图一样关键在于测试的组织管理形式不同。比如介入的时机采用的一些手段不同整个测试的组织过程是最大的不同。 4、Codes敏捷测试落地实施 Codes让迭代、看板、度量和自动化以井然有序融会贯通的方式融合到测试协同中同时又能轻松帮助测试测试左右移让敏捷测试与“润物细无声”的方式落地。 Codes以迭代来组织测试 Codes 敏捷测试协作图 1)、测试左右移相对来说要难一点Codes 有很好的解决方案 CI/CD 和接口自动化对没代码能力的同学来说是个难于跨越的坎左移只要有需求管理相关功能就可以需求阶段就介入测试并分解需求为例。接口自动化CI/CD 都是很能提升测试效率常用手段之后但是也面临一系列问题而难以实现。且看下面Codes 的化解之道。
接口测试常见技术问题如图所示 Codes 一一轻松化解接口测试如下图 拖拽生成断言和拖拽提取参数让接口测试傻瓜化创新式接口混沌测试瞬间完成接口健壮性测试(不用穷举只需配置好混沌规则Codes自去排列组合来执行)另外内置了50多个常用函数满足日常参数化的需要。 自动推导接口依赖拓补关系图让接口关系不再是黑匣子,便捷的接口调用链让接口测试也可以奢侈一把用上APM的高级功能。 拖拽式接口场景编排连胶水代码都省了 采用面向对向的属性命名方式再复杂的对像用XXX.XXX.XXX 的形式来表达其属性可读性好且非常方便在excel 数据驱动文件中进行配置否则复杂json对像用Excel 没法表达。关于接口测试Codes的完整解决方案详见我们团队成员在testerhome上发表的原创精华贴《测试架构师如何解读测试平台的各种争议》。 CI/CD对于大部分测试来说只能依赖运维同事等靠要很多时候不好配合 Codes 采用创新性零代码CI CD拖拽式轻松进行流水线编排屏蔽底层平台复杂性不会写脚本一样轻松进行流水线编排帮助测试人员零基础右移打通测试与运维的壁垒提升测试效率。 左移可以很好的解决常见的需求管理问题 测试提前介入对需求测试可提前规避一些问题围绕需求拉通所有研发活动完整闭环不怕被甩锅。脑图视图便于梳理需求间的业务逻辑关系。 迭代下从需求开始拉通到测试、到发布一切活动可追溯所有干系人信息对齐。 2)、用例管理Codes 也是用独特的创新来解决重用性不高可维护性不好问题
Codes 测试用例管理敏捷化方案 产品用例库和公共用例库并存。 关键在于产品用例库产品用例库和项目中的用例可以双向同步且同步时项目需求也一起同步了。如有变更会自动保存用例历史版本。 线上线下用例不止是导入也可同步提升用例的维护效率 导出用例到Excel后线下修改执行增加新用例后再同步导入到线上。这也是为什么Codes中没有在平台上评审功能因为评审不管是线上还是线下都是一个集体活动评审时直接在导出的用例上进行修改修改完成后再同步到线上在平台上评审就是单纯走下流程仅仅是流程合规没实际用处。 导入用例时如输入的模块类型优先级标签不存在会自动在系统上创建。 脑图用例保持脑图的简洁不用指定特殊的格式保持脑图的本真用法
叶子节点是用例其他作为模快。脑图也是以文件来维护只是转标准用例后两边双向同步。 标准用例也可显示为脑图视图 业务场景用例 把多个单一用例编排组合为业务场景也是Codes 复用用例的另一种方式且按业务场景来管理一目了然。除了单一的功能用例还有不同的业务场景特别是流程类功能测试有了场景不怕漏了还便于管理。 3)、以迭代为中心来组织和开展测试工作 迭代有三个测试相关的状态设置迭代为提交测试状态时将整个迭代的下的需求和待处理的缺陷提测会自动给测试人员发通知然后设置迭代为测试中表示在进行测试了设置迭代为测试完成也会给项目全员发通知和迭代报告。交付物放迭代下含测试在内的一切文档。详见《记Codes研发管理平台——多事项闭环迭代的创新实现》。 现实中在某一轮测试中一定是不同的人执行不同的用例然后测试经理能需要知道整体的测试进度和每个人的测试进度。而传统的测试计划有一个很大的弊端计划下只分配了用例没法指定执行人。可能执行人是通过口头约定口口相传不方便管理也可能不同人建不同的测试计划这增加了工作负担同时没法查看整体进度。 如下图所示第一步先分配用例第二步分配执行人第三步执行用例。另外还可在不同的视图间切换。 第4步 可以查看整体及个体执行进度 还可以在执行人、状态、类别、优先级、需求和脑图视图间切换。下图为脑视图。 如果是回归测试或是对测试用例很熟可以批量快速执行如下图所示左边的树上显示当前执行人所分配用例对应的需求及各需求下用例数和执行数如执行完会一个勾。当然也可导出后线下执行再同步到线上。 再回头来看看分配用例到迭代也就是要执行哪些用例 迭代下分解需求为用例时会自动把所分解的用例自动分配到当前迭代下其他用例需要手动来分配。如下图所示 上图中“分配”表示把勾选的用例分配到迭代下可跨页选“全部分配”表示把当前查询到的所有用例分配到迭代下最后一个按钮表示把左则需求树上所勾选的需求下的用例分配到当前迭代下。 另外测试用例如何计算执行工时,全网只有Codes 有解决办法。每个用例有执行成本也就是执行用时通过执行成本可以统计到执行用例用时情况用例个数的多少不代表执行用例工作量。
再回头来看看分配用例执行人也就是执行用例的人员分工 左边的树显示当前迭代下所有用例对应的需求且树上各节点上显示用例数和已分配执行人的用例数如已分完会显示一个勾。分配执行人时可手动一个一个勾选用例后再分配到执行人也可在左边树上直接勾需求后把需求下的用例分配给某个执行人 除了上面的快速执行外我们再来看看用例的常规执行
常规执行会一个一个弹窗显示用例明细左则显示当前执行人所分配用例对应的需求及各需求下用例数和执行数如执行完显示一个打勾。如下图所示 如果只用脑图用例直接把脑图文件分到一个或多个迭代下然后直接在脑图中执行用例只是在执行前先切换到在哪个迭代下执行即可从用例管理中心脑图维护中进入。可以导入Xmind 也可直接在web 编写脑图。 4、流程驱动的缺陷管理 缺陷也是纳入到迭代下进行处理 传统的缺陷管理有如图所示问题 Codes 采用创新的流程驱动能够“因地制宜” 告别一刀切可按需实时调整测试流程以反映不同管控目的不同流程对应不同的bug状态更能反映项目实况并根据流程推动bug状态的演化。 配置工作流太复杂。Codes采用化繁为简配置方式启用什么流程以及选择流程节点上的处理人员如下图所示一个完整的流程从1提交问题、2到测试交叉、3到分析问题、4到分配问题、5到修改问题、6到开发互验、7到分歧仲裁、8测试确认。这流程可以说是全网最全的一个缺陷流转流程图中标星的为必选流程其他为可选流程可实时修改。 相关人员处理缺陷时不用关心缺陷有多少种状态缺陷控制引擎会自动根据测试流程缺陷当前状态及处理人员在项目测试流程中所处的的流程节点自动算出来当前可转换为什么状态以及选了不同状态后谁作为下一处理人。在缺陷管理列表中点击某个缺陷的状态进入缺陷流转处理。下面用几个示例来说明。详见《记Codes研发管理平台——流程驱动缺陷管理的创新实现》。 上图中为在修改问题节点上的开发人员处理缺陷时可演化的状态示例如设置为费解/需提供更多信息或“非错“时就自动打回到测试人员如设置为”挂起/不计划修“改 或 ”挂起/下版本修改“时就流转到仲裁人处如设置为”已改“或”已改/同步到测试环境“就流转到测试确认环节由测试确认后再关闭。
测试提交缺陷示例 如测试提交后下一流程为修改问题则新提交的问题为“待改”状态如下一流程为分配流程就”分配“状态并转分配人来处理如下一流程为析分流程就是”分析“状态并转分析人来处理如下一流程为测试互验就是”待置“状态并转互验人来处理且如互验人认为“待置”的缺陷描述有问题可以设置为“修正/描述不当”或直接“撤销”了。 流转历史及用时
快上线前缺陷一般要求日决我们要能查看到各环节用时信息。Codes 会记录各节点上的用时信息如下图所示 关联缺陷和需求关联随时可查看需求详情缺陷还可和用例关联通过webhook 缺陷还可和gitlab自动关联commit。 5、统计分析及度量 除了质量大屏还有一系列统计如缺陷时效用测试总览等20多个统计。 测试总览 接口总览 全网独有提交|打开|待处理|修改|关闭缺6趋势图能反映出测试和研发团队谁慢。 一共有如下5个缺陷趋势分析 另外还有11个缺陷相关统计且都可按版本来统计可选某个版本或的所有版本有些还可按人分组及不按人分组。 缺陷时效分析对于要上线前缺陷日决及重要缺陷可以很好的管控起来不会因这些重要缺陷延期而带来风险。且下图中缺陷达标数还可下钻 显示明细。 测试工作量分析对对比各测试人员工作情况且每一项可展开查看明细如下图所示 测试人员简报如下图所示 日执行用例趋势及明细可按人分组及不分组不分组就是总趋势。 测试项目简报 项目活跃度明细 开发工作量分析 编写用例用例趋势可按人分组也可以不分组不分组显示总趋势 迭代报告总览 迭代报告用例明细 还有一系列其他统计 不再一一列出仅列出测试样相关的部分统计分析
6、生成式全局看板再也不需手动创建看板 以逆向的方式也就是通过定义查询条件的方式来生成看板。所有人共用一个全局看板定制各自的看板。详见《记Codes 研发管理平台——生成式全局看板的创新实现》。
另外除工具平台外还有两个问题需要自行解决
1)、持续团队构建团队拓扑结构协作模式技术路线打磨团队的沟通方式。 团队的架构影响了团队的沟通协作的模式体现在团队研发的产品上反映了团队的研发效能。团队基于其通信结构生成体系结构这是康威定律里面说的。团队拓扑是指在一个团队中成员之间的网络结构和关系。它描述了一个团队中成员之间的交互模式和沟通方式包括信息传递、协作和决策过程等。这里不再展开来讲可查阅《高效能团队模式》。
2、流程规范的建设根据情况建立流程规范。如下两图是已内置于Codes内的流程规范 因篇幅有限没法一一道来本文只是选几点进行走马风观花式的介绍不过依然可以看出来我们一如继往的创新。更多很爽的测试管理相关、缺陷管理相关的功能要到Codes 中去慢慢品味Codes敏捷测试就像一壶茶越喝越香且Codes不限功能本地安装30人免费足够一般公司用了快去试试吧临池羡鱼不如退而使用Code 。最后以Codes 整体功能架构结束本文方便大家了解Codes“全景”
