Agile

背景当初所在公司用上了滴滴出品的 agileTC ，整体上十分好用。但有个性能大家都在召唤：反对测试工作中批改用例集内容，并同步批改到残缺用例集中。所以有了这篇文章。 先阐明下具体应用的场景，让大家更了解为什么要做这个性能，目标是什么： 首先，测试集、测试工作这块是自身 agileTC 的已有设计，测试集用于存储测试用例，测试工作用于执行用例。测试工作能够在用例集中筛选/全选用例，进行每个用例的测试后果注销。但测试用例不能批改用例，要批改用例必须到用例集编辑界面（此界面无筛选性能） 在我司的理论我的项目应用中，常见用法是： 1、项目前期次要是多数 1-2 人参加，他们依据需要及技术计划，实现初版的残缺用例，并在外面标记开发自测用例。用例评审用的也是这一版。2、提测前开发自测时，测试会创立对应的开发自测用例并给开发参照执行、注销后果。3、提测后，用例会分给多人执行（人数可能不止后期的 1-2 人），会通过自定义标签模式记录这批用例是谁负责。此时会通过测试工作的筛选条件来筛选到只剩下此人负责的用例，独自进行执行和注销。 理论执行中，可能会因为需要变更、局部需要细节须要补充等起因，在 2、3 步常常须要更新用例集。尽管也能够到测试集进行更新，但测试汇合计会有过千个用例，而测试工作则只有数百个，因而在测试工作中就进行更新，相对而言会更为不便。 因为总用例集须要用于进行一些数据统计和二轮测试用，所以此时也须要更新。基于此，所以做这个增量保留的性能。 这块性能之前本人其实也有大抵想过，但始终没有想得特地透彻，这次做的过程中也是一开始想着间接用现成的 json-patch 间接就能够满足，但本人随机测试一下就呈现用例被笼罩且没有任何抵触提醒的问题，所以前期罗唆彻底梳理了一遍整体设计思路，再从新写代码、加单测。 这块可能其余有做基于百度脑图的 xmind 用例治理平台相干的同学也有遇到，所以在此分享一下，也冀望大家有更好的思路，能够上面评论交换下。 全文较长，倡议能够先看目录理解大略，再具体看内容设计方案思考现有技术计划是这样的： 1、当初用例集和测试工作，波及 2 个表，test_case 和 exec_record。 2、test_case 表存储每个残缺的用例集 json 内容，包含节点、标签、优先级。这个残缺的 json 能够间接被脑图组件残缺加载和展现。 3、exec_record 表存储每个测试工作的信息，包含筛选条件、各节点的执行后果。其中各节点执行后果存储形式是节点 id+ 测试后果，示例： {"bv8nxhi3c800":"9","c8tws927cpc0":"9","c8tws7dgbm80":"9"}4、在前端界面展现的测试工作内容，理论是通过 用例集表 json 依据筛选条件筛选节点->筛选后节点 json 和测试工作的测试后果进行合并 两个步骤得出。这个合并和筛选是实时的，每次刷新加载测试工作的脑图编辑界面，都会做一遍。 5、对于用例集的多人合作，滴滴自身也自带多人同时编辑用例的性能（集成在前端编辑器中，通过 websocket 实时存储 diff 和更新），但因为之前应用时发现会呈现用例失落、用例反复之类的问题，起因猜想和一些网络不稳固导致同步可能不够实时无关。因为前端编辑器没有开源，无奈真正寻找到本源及修复，加上一些对脑图编辑器二次调整的须要，所以改用了另一个基于 kityminder + vue 改的脑图组件，也因而无奈应用这个自带的多人同时编辑用例性能（这个性能要求编辑器实时上报用户的每一次操作改变，这个性能只有 agileTC 的脑图编辑器组件才具备）。 以前用过的另一个用例治理平台，模型会简略很多： 1、不辨别用例和工作，用例自身就带有注销测试后果性能，数据库只须要存用例内容。 2、保留时，会主动依据服务端内容计算出本次保留和关上界面时版本的 diff ，而后把这个 diff 和最新用例内容进行主动合并存储。若合并发现抵触，则反馈抵触内容，让用户在前端界面手动解决抵触后存储。 在理论实际中，会呈现合并抵触的状况极少，绝大部分状况都是能够间接主动合并存储的。所以大家的理论用法，也根本都是主测先创立一个简略的 xmind 并分好每个人负责的一级节点，而后各负责人员再去往这个一级上面扩大具体的用例内容。 基于下面的这些历史教训和计划，整体设计方案有两个大方向： 方向一：最小改变准则。用例集每次保留都是增量保留（包含工作中编辑、用例集中编辑），由服务端主动通过 base 版本和保留版本得出 diff ，再利用到最新的用例集中。 ...