客户实践 | Jira 在大型测试管理团队中的测试管理解决方案
作者简介：杨刚，烽火通信科技股份有限公司信息化中心测试电子信息平台项目经理，负责烽火通信测试端到端管理平台建设，在系统集成平台开发方面有多年丰富的管理和实施经验。
在本文中，杨刚将从研发测试核心需求和业务痛点出发，讲述烽火通信研发测试业务如何实现端到端拉通管理，以及如何以 Jira Software 为基础和核心，通过不断实践终使信息化在企业内部落地的历程。
背景概述
Jira Software 作为业界标杆的项目与事务跟踪工具，被广泛应用于全球各个行业；再结合 Atlassian 的全系列产品：Confluence、Bitbucket、Bamboo 和 Fisheye 等搭配使用，可以搭建一个贯穿研发各个环节的 DevOps 环境，来满足我们团队的日常管理需求。
在使用 Atlassian DevOps 产品平台的过程中，我们做为测试部门，还引入了 Jira 的测试管理插件：synapseRT – Test managementand QA in JIRA 进行测试管理。但是在我们实际使用该插件的过程中发现，synapseRT 可以做为 Jira 平台在测试管理环节的功能延伸，但受限于插件本身的缘故，实际测试过程的管理对于具有一定测试规模的公司来说，显得有些轻量级。
至关重要的测试环节无法在 Jira 上顺畅的运行，给负责平台建设的相关IT部门带来不小的挑战，但我们不惧怕挑战。经过业务部门与 Jira 开发团队夜以继日的努力。我们的测试任务管理解决方案也略有小成，因此今天把这个方案写出来共享给大家，希望能给迷茫中的你们带来一些帮助。
在日常项目进展的过程中，对于测试部门来说；我们的核心过程包括：
确定测试范围
测试计划
测试
测试报告
贯穿于整个环节的变更管理
在确定测试范围时的核心需求：
已完成和新项目之间有继承或者参考意义的，需要在二者之间快速复制已完成的项目测试范围，但目前不支持；
根据从原始需求到设计需求到测试用例的对应关系，在输入原始需求系统自动根据映射关系拉取相应的测试用例；
需要一个完整的树形结构，可以从多个维度快速提取并确认项目相关测试范围；
总之一句话，就是能快速、简单、准确的完成这些定制测试边界的事情；
在编制测试计划过程中的核心需求：
操作界面简单灵活，快速部署测试计划；
能直观看到测试进度及所有节点测试情况；
在测试过程中的核心需求：
测试任务领取入口清晰明了；
测试步骤完整、清晰
测试环境等其他要素在同一页面展示；
操作简单、便捷；
结果记录应支持富文本编辑查看；
在测试报告环节的核心需求
需求覆盖率；
测试结果；
Bug 解决进度；
测试覆盖率；
测试报告；
测试变更管理环节的核心需求
变更范围确认；
变更发起和评审；
变更任务安排和提醒；
在以上环节中，synapseRT 暂时无法满足我们的需求，尤其在最重要的变更管理环节，需求变更引起的后续一系列流程管理功能在当前平台上是缺失的。
要点解析：
引入基础数据项目概念
Jira数据集合一般以项目为单位，在总体制约情况下，我们以项目的形式创建基础数据库的概念，将其引入到测试过程管理的核心功能中。通过将一些经过验证的、准确的用户需求、研发需求、测试用例存储在基础库数据中，同时建立并记录不同个体之间的关联关系。这样，一套对象以及关系的基线就可以诞生。
引入对象小版本和基线版本概念
在基础库数据项目中，我们允许操作者在某个时间点对项目内所有数据的内容以及关系进行快照，并命名一个对应的基线版本，用户可以浏览某2个基线版本之间的差异，并进行单个或者整体回滚操作；
同时在大基线版本的前提下，我们应提供各个对象本身的小版本管理，以应对知识在积累过程中的版本信息和差异。
引入不同问题类型多级关联关系概念
Jira的原生关系，只支持一个级别的父子关系。显然在从需求到用例这样的场景内并不能达到我们的要求，因此我们对关系做了对应扩展，对于一对多、多对一、多对多的复杂关系处理，程序逻辑要游刃有余。
引入项目根据追溯关系自动拉取数据的概念
当基础库的基线数据被完善后，项目从外部或者内部输入最前端的用户需求，此时，对比项目与基础数据库的需求标识，（为每个对象数据编码，所有编号在系统具有唯一性）并根据基础数据库依赖关系，将关联数据依次在项目中部署；这样做不但节省了原来重复工作的资源浪费，而且缩短了项目时间，减少人为原因导致的数据错误。
引入需求变更任务流程
需求变更意味着后续的研发任务以及测试任务都要发生相应变动；我们设计出多维树形结构帮助团队更好的判断变更所带来的影响范围，通过审批的确认变更信息，会自动转化成相关的变更任务，并迅速传递给相关的研发和测试团队进行跟进处理。
将测试数据生成报告至 Confluence
测试数据一般包括参与者和参与团队的日报周报、测试方案、测试报告等内容，日报周报记录团队投入人力和测试进度，测试方案和测试报告则反馈测试计划排期和测试最终结果，我们将以上所有需要的数据在jira上收集，可在confluence建立对应报告的模板信息，通过手工或者自动激发在confluence创建报告页面。这样做的好处是系统根据提前定好的规则对数据进行加工并生成最终报告，不需要投入人工且减少人为原因产生的误差。
方案成果展示
按项目类型分类的顶级导航菜单：我们对 Jira 的顶级导航菜单做了定制化开发，使其更加符合业务团队的实际使用要求（参见下图）：
基础库数据管理界面：我们引入基础库的概念，用于存储历史项目中沉淀的资源信息以及其复杂的拉通关系，并通过树结构进行清晰的节点展示，按模块进行分类。这里我们克服了一个开发难点，就是在同一页面展现大数据量内容，保证数据完整性的同时，可以迅速加载出所有的节点信息；如下图：
基础数据库内同一页面浏览对象内容：通过左右将页面分割，用户可以在右侧界面迅速浏览到具体issue的具体信息，而不必打开新的页面去浏览，同一页面的好处就是能够看到具体详情的同时，可以参考具体issue的接结构信息；如下图：
基础数据库的树结构查询和筛选：在树结构显示中，我们引入查询和筛选功能，查询功能：快速模糊匹配关键字信息，在整颗完整树结构下，找到所有匹配的issue信息并逐个定位展示，筛选功能：去除不符合要求的树结构，只留下符合筛选条件的对象，并生成新的结构树进行展示，如下图：
基础数据库的对象跟踪关系查看：跟踪关系是我们要做的重点功能，通过点选要查询的对象，可以清晰的展示其上下游的跟踪关系，有了这些基础数据，可以提供给我们以前没有追溯到的信息。我们通过树结构前面的红蓝标记来区分当前对象是否具备一定的跟踪关系结构；如下图：
基础数据库数据导入功能：我们重新定义了 Jira 的基础导入功能，提升了导入效率。根据事先约定的模板，可导入带有富文本信息的 Excel 文件，并识别树形结构，从外部数据直接展示基础库/项目内的树形结构；
项目看板数据：在项目内我们定制了用于观察项目整体进展的项目看板，项目看板跟随单独项目并独立显示。在项目看版内，我们可以获取项目每个里程碑的进展情况，同时根据获取的项目数据，展示当前需求实现率、覆盖率、测试通过率、项目延期警告信息等关键信息。
项目内测试计划（synapseRT部分）：通过 synapseRT 这个测试插件，我们用到它现成的测试管理看板，可以直观生动的展示各种测试进度情况，测试小组再也不手忙脚乱。
在具体的测试计划界面，我们可以直观的看到项目内的各阶段测试的进展情况，以及其所产生的bug和bug的修复进展，测试数据一目了然。
项目内测试场景管理：在实际测试环节，我们往往要模拟各种测试场景来完善测试方案，在jira中我们引入测试场景概念，保证测试环节对各必要场景的复测覆盖达到100%；
快速建立项目内数据结构：项目创建后，我们引入原始需求的同时，系统自动根据已有的拉通关系完善后面的研发需求和测试用例，这大大节省了以往靠人工对比和梳理的技术数据建设时间，项目从一开始就开始敏捷化！
测试用例类型对象内容：在树状结构模式下浏览单个测试用例内容，既简单又清晰，测试人员时刻留意当前测试对象处于整体模块的那个环节上，减少重复和误差；
测试执行界面：通过 synapseRT 提供的测试执行界面，我们将用例准备环境和描述信息纳入执行界面，测试人员无需翻看用例的必要准备条件，在同一页面就可以查询到所有测试环节的全部信息，减少不必要的操作步骤。提高测试效率的同时又很美观！
变更管理部分界面：项目内的需求变更管理是一个重点，这会影响到整个项目的整体进度管理，如何管理好项目执行变更是保证项目进度的前提。我们显示完整的树结构，以不同颜色显示和选择变更内容以及变更设计范围，变更影响和预估一目了然，同时增加锁定和评审功能，保证变更可控。
在 Confluence 上自动输出报告：项目结项后，系统自动在 Confluence 按照预定模板生成我们所需的各种报告，并支持一键导出生成 Word 文档，这大大节省了以往靠人工统计数据的时间，也提高了数据的可靠性和准确率，为公司持续发展战略打下坚实良好基础。
总结和回顾
经过近2年时间的辛苦努力，通过各部门不断实践和改进，我们的测试管理平台日益完善，其在测试管理环节提升的效率以及节省的成本也被测试团队和领导给予肯定。
未来的路还很长，我们期待 Atlassian 的 DevOps 平台能够带给我们更多、更好更有价值的功能并顺利在公司内部各部门落地、生根、结果！
2020 我们一起继续努力！
