前言

大家好,我是困学,目前在杭州某互联网公司从事测试开发工作,这些年从业务测试逐渐转型至测试开发,从代码小白逐渐成长,到现在具备自行设计并落地系统的能力,一路而来也有 5 年的时间。
5 年时间内结合公司内部的实际情况与质量管理诉求,实现了一套质量保障系统,以期用数据推动管理,以数据反馈提升效果,总算有所裨益。所以在这个系列的文章中,我将从账户体系设计、项目管理、缺陷管理、CI 管理、统计可视化等方面讲讲这套系统的实现思路,抛砖引玉,与各位共同进步,谢谢。

账户体系

先从账户体系设计聊起吧,互联网公司虽组织架构各异,大体上以事业群、事业部、业务线为树状发散路径进行业务发展,常见角色包括产品经理、设计师、前端研发、后端研发、QA、运营等角色依层级挂靠在这些树状节点上,那么自己设计系统时是否要参考公司的组织架构呢?我的建议是不用,一来公司的组织架构随着业务发展时常会有所改动;二来公司的组织架构往往层级较多,维护的成本较高;三来我们更需要聚焦在实际项目推进单元 (即业务线)。综上所述,我最后采用的方案是将各类角色挂靠在业务线的组织节点上。
解决了挂靠问题后,接下来是考虑成员录入的信息内容了,除了基础的业务线节点、姓名外,由于研发还区分了前端、后端,所以还需要额外增加成员归属端、成员角色信息。此外由于我司的办公软件采用了钉钉,某些需要钉钉推送 (特别是 @ 提醒) 时,需要有用户的手机号。最后结合公司的实际情况,每个人有独立且唯一的邮箱地址作为唯一凭证,也作为主要信息摘录下来。
以下为设计结果:

(补充说明:此处的设计经过精简,实则因为缺陷信息以及代码信息的获取过程中踩了坑,从而放弃了一些字段设计,后续文章中将会提到)

项目管理

项目迭代是日常最重要的工作,项目迭代的同时能够产生很多有价值的数据,比如参与的人员,项目缺陷信息 (包括基础信息、缺陷原因、缺陷等级、缺陷处理周期,项目参与人员被指派的缺陷数分布等)、项目代码信息 (增加多少行代码、删除多少行代码、变更代码的总行数、项目参与成员提交代码量的分布等)。随着项目数量的增加,价值数据会逐渐累积,为后续提升项目质量提供指导数据。
以下为设计结果:


缺陷管理

缺陷管理部分按业务阶段可分为项目内测缺陷、线上缺陷。而不同公司依据实际情况,管理缺陷时使用的系统有可能是自建的,有可能是使用已经成熟的缺陷管理系统如 jira、禅道等。所以获取缺陷数据的时候要依据本公司的实际情况进行字段设计,而我所在的公司使用的是 jira 管理平台,那么通过翻阅 jira 系统能提供的查询 api 可知,jira 系统支持通过 jquery 语句返回缺陷信息:

那么在我司的系统设计内就需要录入这个字段信息:

其次我们需要知道,在类似 jira 的缺陷管理系统中,项目内测缺陷、线上缺陷或者其他类型定义的缺陷,对于 jira 来说只是 jquery 语句不同,那么在设计缺陷获取的代码逻辑时,应当全盘考虑,避免为业务内测缺陷设计一套,线上缺陷设计一套。
以下为设计结果:


CI 管理

测试行业发展到现在,绝大多数互联网公司对于测试的要求已经不再停留在业务测试上,更多地要求自动化能力,代码能力,测试人员需要具备将业务话语通过自动化脚本进行表达,同时自动化也是释放测试人力,保障线上主流程业务平稳运行的重要保障,因此对于自动化的质量数据反馈也是系统的重中之重。
而目前大多数公司会使用一些比较成熟的自动化框架,或开源,或二次开发,或自研,那么如何将这套自动化框架与质量保障平台对接?得出自动化脚本的质量数据呢?在后面的文章中,我将分享以 RF 为基础的二次开发自动化框架对接质量保障系统的过程。
以下为设计结果:



统计可视化

通过以上价值数据的逐步积累,为数据阅读体验,同时也为更直观地数据对比,需要将一些价值数据进行图表的可视化呈现,以下为部分内容的设计结果:



其他工具

上述内容均为系统内较大板块的功能,除以上功能外,还有一些配套的小工具,如测试资源的维护及 outgoing 获取,缺陷跟进提醒,缺陷指派提醒,本周缺陷汇总,项目报告等等,有机会的话,穿插在各个大板块内进行分享。

结尾

本系列的文章除了介绍目前实现功能外,也会分享在实现过程中出现的各种情况以及我个人的心路历程,也希望大家批评指正,互相启发。


↙↙↙阅读原文可查看相关链接,并与作者交流