解决了挂靠问题后，接下来是考虑成员录入的信息内容了，除了基础的业务线节点、姓名外，由于研发还区分了前端、后端，所以还需要额外增加成员归属端、成员角色信息。此外由于我司的办公软件采用了钉钉，某些需要钉钉推送 (特别是 @ 提醒) 时，需要有用户的手机号。最后结合公司的实际情况，每个人有独立且唯一的邮箱地址作为唯一凭证，也作为主要信息摘录下来。
以下为设计结果：
(补充说明：此处的设计经过精简，实则因为缺陷信息以及代码信息的获取过程中踩了坑，从而放弃了一些字段设计，后续文章中将会提到)
大家好，我是困学，目前在杭州某互联网公司从事测试开发工作，这些年从业务测试逐渐转型至测试开发，从代码小白逐渐成长，到现在具备自行设计并落地系统的能力，一路而来也有 5 年的时间。
5 年时间内结合公司内部的实际情况与质量管理诉求，实现了一套质量保障系统，以期用数据推动管理，以数据反馈提升效果，总算有所裨益。所以在这个系列的文章中，我将从账户体系设计、项目管理、缺陷管理、CI 管理、统计可视化等方面讲讲这套系统的实现思路，抛砖引玉，与各位共同进步，谢谢。
先从账户体系设计聊起吧，互联网公司虽组织架构各异，大体上以事业群、事业部、业务线为树状发散路径进行业务发展，常见角色包括产品经理、设计师、前端研发、后端研发、QA、运营等角色依层级挂靠在这些树状节点上，那么自己设计系统时是否要参考公司的组织架构呢？我的建议是不用，一来公司的组织架构随着业务发展时常会有所改动；二来公司的组织架构往往层级较多，维护的成本较高；三来我们更需要聚焦在实际项目推进单元 (即业务线)。综上所述，我最后采用的方案是将各类角色挂靠在业务线的组织节点上。
解决了挂靠问题后，接下来是考虑成员录入的信息内容了，除了基础的业务线节点、姓名外，由于研发还区分了前端、后端，所以还需要额外增加成员归属端、成员角色信息。此外由于我司的办公软件采用了钉钉，某些需要钉钉推送 (特别是 @ 提醒) 时，需要有用户的手机号。最后结合公司的实际情况，每个人有独立且唯一的邮箱地址作为唯一凭证，也作为主要信息摘录下来。
以下为设计结果：
(补充说明：此处的设计经过精简，实则因为缺陷信息以及代码信息的获取过程中踩了坑，从而放弃了一些字段设计，后续文章中将会提到)
项目迭代是日常最重要的工作，项目迭代的同时能够产生很多有价值的数据，比如参与的人员，项目缺陷信息 (包括基础信息、缺陷原因、缺陷等级、缺陷处理周期，项目参与人员被指派的缺陷数分布等)、项目代码信息 (增加多少行代码、删除多少行代码、变更代码的总行数、项目参与成员提交代码量的分布等)。随着项目数量的增加，价值数据会逐渐累积，为后续提升项目质量提供指导数据。
以下为设计结果：
缺陷管理部分按业务阶段可分为项目内测缺陷、线上缺陷。而不同公司依据实际情况，管理缺陷时使用的系统有可能是自建的，有可能是使用已经成熟的缺陷管理系统如 jira、禅道等。所以获取缺陷数据的时候要依据本公司的实际情况进行字段设计，而我所在的公司使用的是 jira 管理平台，那么通过翻阅 jira 系统能提供的查询 api 可知，jira 系统支持通过 jquery 语句返回缺陷信息：
那么在我司的系统设计内就需要录入这个字段信息：
其次我们需要知道，在类似 jira 的缺陷管理系统中，项目内测缺陷、线上缺陷或者其他类型定义的缺陷，对于 jira 来说只是 jquery 语句不同，那么在设计缺陷获取的代码逻辑时，应当全盘考虑，避免为业务内测缺陷设计一套，线上缺陷设计一套。
以下为设计结果：
测试行业发展到现在，绝大多数互联网公司对于测试的要求已经不再停留在业务测试上，更多地要求自动化能力，代码能力，测试人员需要具备将业务话语通过自动化脚本进行表达，同时自动化也是释放测试人力，保障线上主流程业务平稳运行的重要保障，因此对于自动化的质量数据反馈也是系统的重中之重。
而目前大多数公司会使用一些比较成熟的自动化框架，或开源，或二次开发，或自研，那么如何将这套自动化框架与质量保障平台对接？得出自动化脚本的质量数据呢？在后面的文章中，我将分享以 RF 为基础的二次开发自动化框架对接质量保障系统的过程。
以下为设计结果：
通过以上价值数据的逐步积累，为数据阅读体验，同时也为更直观地数据对比，需要将一些价值数据进行图表的可视化呈现，以下为部分内容的设计结果：
上述内容均为系统内较大板块的功能，除以上功能外，还有一些配套的小工具，如测试资源的维护及 outgoing 获取，缺陷跟进提醒，缺陷指派提醒，本周缺陷汇总，项目报告等等，有机会的话，穿插在各个大板块内进行分享。
本系列的文章除了介绍目前实现功能外，也会分享在实现过程中出现的各种情况以及我个人的心路历程，也希望大家批评指正，互相启发。
