软件问题修复跟踪系统实战开发教程（上篇）

1 引言

在软件开发行业，有个专业的名称叫BUG，中文名叫软件缺陷。软件缺陷指软件的质量问题，一般劣质的软件问题频发，难以使用，体验也非常差。

软件的缺陷往往是内部质量控制有问题，要么质量控制形同虚设，要么就是没有经过严格的软件测试。现实中没有建立质量控制体系的企业生产软件的时候比较随意，往往是程序员自测就进行上线了。

为了提高软件质量，需要建立一套线上的问题修复跟踪系统，详实的记录每个问题的修复过程，以达到提高软件质量的目的。

本文利用低码工具，来开发一款软件问题修复跟踪系统。包括PC端及移动端，制作步骤简单，没有开发经验的同学也可以照着快速制作。

2 需求分析

一般在软件企业，是有具体分工的。项目经理负责和客户沟通需求并编写需求规格说明书。开发经理负责软件的设计，包括接口、数据库、功能拆分等工作。研发负责具体的编码实现，而测试主要负责检测问题并验证问题是否修复。

传统软件开发企业在内部研发完成后，由项目经理发起测试申请，测试部经理审核通过后就会分配测试人员进行测试。而我们测试的总体流程如下：

在流程经过每一个环节的时候，我们的问题应该有一个状态需要进行记录，状态有几种情况：

1. 待分配，当测试人员录入问题的时候状态修改为待分配
2. 待修改，当项目经理分配好具体的人员后，状态修改为待修改
3. 已修改，当研发人员将问题修改完毕后，状态修改为已修改
4. 已验证，当测试人员验证完问题后，状态修改为已验证

业务流程分析完毕后，我们就需要考虑表单上要填写哪些字段，一般需要的是标题、问题描述、附件、问题编号、优先级、状态、测试人员、发现日期、项目经理、开发人员、修改日期、分配日期

3 数据源设计

低码工具开发应用的时候先需要做好数据源的规划，因为我们是需要从表单上选择人员，而人员又分为三种，分别是测试人员、项目经理和开发人员。所以我们设计一个人员表，分别管理这三类人员

字段名称	字段标识	字段类型
姓名	name	文本
岗位	job	枚举值

这里的枚举值，一共有三个选项，1表示测试人员，2表示项目经理，3表示开发人员

除了人员表之外，我们还需要设计一张问题表，字段按照需求规划的字段进行设计

字段名称	字段标识	字段类型
标题	title	文本
问题描述	desc	文本
附件	fj	图片
问题编号	bugno	自动编号
优先级	youxianji	枚举值
状态	status	枚举值
测试人员	tester	关联关系
项目经理	leader	关联关系
开发人员	developer	关联关系
发现日期	finddate	日期
分配日期	fenpeidate	日期
修改日期	modifydate	日期

这里的优先级的枚举值为1高，2中，3低

状态的枚举值为1待分配，2待修改，3已修改，4已验证

4 数据源开发

登录控制台，在数据源部分，新建数据源，先创建岗位人员表

接着创建问题表

5 创建用户

在开发应用之前我们先需要把用户创建好，分别创建三个用户，测试人员、项目经理、开发人员

6 创建工作流

因为是要走工作流审核，所以先需要创建工作流，并且设置好每一个活动的办理人

7 创建应用

一切就绪之后我们就可以根据数据源来自动生成应用了，先输入应用的名称

接着勾选数据源


为了让用户在填写表单后自动发起工作流，需要在数据源那设置事件处理，我们新建时就触发工作流

配置好后我们点击发布，先按照提示生成菜单

发布后，平台帮我们自动完成了所有界面的配置及生成工作，我们只需要按需使用和录入数据即可

8 开发小程序

除了PC端，我们还可以搭配一套小程序，供业务人员查询数据使用。功能比较简单，我们使用数据列表组件创建一个列表页面，使用详情组件开发一个详情页即可。在以往的教程中都有详细的介绍，我们这里只展示一下最终的效果


如果不用官方组件，需要自己展示枚举值是可以参考官方的api，如展示状态时

app.utils.formatEnum($context.id1.data.status, 'wtzt', app)

这里就调用了格式化枚举值的api，还有就是新出了一种api可以格式化关联关系

$context.id1.data['@developer'].v1.record.name

可以通过api的形式来展示具体关联表的字段，还是比较方便的

9 总结

本篇我们利用低代码工具使用无代码的形式开发了一套软件问题修复系统，包含PC端及小程序端。有了低码工具的自动化功能，我们只需要关注业务本身，技术问题就交给平台去完成。未来，低码的能力会越来越强，可以开发的系统范围会越来越广，早早的入局低码，早早的享受红利。