在Winform方面，基于业务的不同，我们可以利用工具的效率，快速做很多不同的业务系统，前期做了一个缺陷管理系统，想把单位的测试业务规范下，也好统计和分析每个版本的缺陷信息，本篇整理这些数据库设计和界面设计的相关内容，做一个介绍，希望给大家一个对比参照的案例进行学习了解。
1、缺陷管理系统的业务分析
在很多缺陷管理系统里面，我们往往需要管理的就是缺陷信息的记录，以及缺陷记录的开闭过程，从而实现了测试人员-》开发人员-》测试人员的整个闭环过程。
一般情况下，缺陷管理系统可以部署在局域网内，或者公网内方便各个项目组成员的使用，因此可以采用BS的架构，也可以CS架构实现分布式的应用，通常情况下，采用CS的方式，在数据处理方面会友好一些，因此结合需求，我这里采用了我常用的混合型框架，数据采用WCF服务获取，实现数据的共享。
缺陷信息，一般是属于具体某个项目，某个版本，某个模块下的具体信息，因此这些分类必须独立进行维护，才能方便进行后面的统计和分析，一般缺陷信息还需要提交出错的图片附件信息，方便直观的了解和开发人员排错。
缺陷项目的信息，为了分类，我们还可以分为一个域进行管理，也就是分组的概念，如按不同类型的项目，分为不同的项目域，如产品项目、客户项目、研究性项目等分类都可以。
以上这些都是缺陷里面很重要的属性信息，因此我们需要在缺陷管理系统里面很好的设计才能使得我们的系统符合我们的业务流程。
一般情况下，版本和模块是对应不同项目的，缺陷状态、缺陷类型、优先级、紧急程度，这些是通用的字典项目，不会因为项目而变化。
另外，缺陷处理一般是一个闭环流程，最初一般由测试人员发起（状态为未解决），提交给开发人员，开发人员根据缺陷记录，设置合理的状态，如果是正常需要处理的缺陷，一般需要修正错误，并设置状态为已解决，然后测试人员对缺陷进行回归测试，如果缺陷已经解决，则设置缺陷状态为已关闭，否则重新打开缺陷为未解决状态，依次循环，最后大家达到共识，是不解决或者推迟解决等。这些修改的过程也需要在缺陷系统里面进行记录，已进行跟踪历史。
2、缺陷管理系统的数据库设计
为了存储上面的缺陷信息，我们需要设计一些表进行数据的存储，除了一些通用性的信息存储，如字典信息、附件信息，采用通用模块存储外，对于缺陷的相关信息，我们还需要设计如下的表对象来存储信息。
上面的表之间有一定的关系，在红色部分进行了标识。
3、缺陷系统的界面设计
界面设计还是采用常见的工具栏的方式进行布局，根据缺陷的信息关系，我们查看信息 的时候，让用户先在具体的域下面选择具体的项目，然后展示该项目下的缺陷信息。
选择项目信息后，我们一般需要根据项目显示它的缺陷列表，缺陷信息提供重要的信息展示。
双击可以展开具体的缺陷信息，其中包括附件提交和查看管理，缺陷的修改历史等信息。
对于缺陷里面的一些字典属性，我们可以通过统一的字典模块进行维护，如下所示，可以对缺陷状态、缺陷类型、优先级、严重程度等信息进行独立的维护管理。
一般情况下，我们最终还是需要根据缺陷的记录，获得一定的统计分析报表，以便对该版本是否能够正常发布进行一个评估工作，或者是了解缺陷的分类、趋势等信息的需要。
例如，我们可以在缺陷分类统计里面，把缺陷状态、缺陷类型、严重程度、优先级等根据版本信息进行一个分类统计，也可以根据缺陷的趋势进行统计等等。
在Winform方面，基于业务的不同，我们可以利用工具的效率，快速做很多不同的业务系统，前期做了一个缺陷管理系统，想把单位的测试业务规范下，也好统计和分析每个版本的缺陷信息，本篇整理这些数据库设计和界面设计的相关内容，做一个介绍，希望给大家一个对比参照的案例进行学习了解。
1、缺陷管理系统的业务分析
在很多缺陷管理系统里面，我们往往需要管理的就是缺陷信息的记录，以及缺陷记录的开闭过程，从而实现了测试人员-》开发人员-》测试人员的整个闭环过程。
一般情况下，缺陷管理系统可以部署在局域网内，或者公网内方便各个项目组成员的使用，因此可以采用BS的架构，也可以CS架构实现分布式的应用，通常情况下，采用CS的方式，在数据处理方面会友好一些，因此结合需求，我这里采用了我常用的混合型框架，数据采用WCF服务获取，实现数据的共享。
缺陷信息，一般是属于具体某个项目，某个版本，某个模块下的具体信息，因此这些分类必须独立进行维护，才能方便进行后面的统计和分析，一般缺陷信息还需要提交出错的图片附件信息，方便直观的了解和开发人员排错。
缺陷项目的信息，为了分类，我们还可以分为一个域进行管理，也就是分组的概念，如按不同类型的项目，分为不同的项目域，如产品项目、客户项目、研究性项目等分类都可以。
以上这些都是缺陷里面很重要的属性信息，因此我们需要在缺陷管理系统里面很好的设计才能使得我们的系统符合我们的业务流程。
一般情况下，版本和模块是对应不同项目的，缺陷状态、缺陷类型、优先级、紧急程度，这些是通用的字典项目，不会因为项目而变化。
另外，缺陷处理一般是一个闭环流程，最初一般由测试人员发起（状态为未解决），提交给开发人员，开发人员根据缺陷记录，设置合理的状态，如果是正常需要处理的缺陷，一般需要修正错误，并设置状态为已解决，然后测试人员对缺陷进行回归测试，如果缺陷已经解决，则设置缺陷状态为已关闭，否则重新打开缺陷为未解决状态，依次循环，最后大家达到共识，是不解决或者推迟解决等。这些修改的过程也需要在缺陷系统里面进行记录，已进行跟踪历史。
2、缺陷管理系统的数据库设计
为了存储上面的缺陷信息，我们需要设计一些表进行数据的存储，除了一些通用性的信息存储，如字典信息、附件信息，采用通用模块存储外，对于缺陷的相关信息，我们还需要设计如下的表对象来存储信息。
上面的表之间有一定的关系，在红色部分进行了标识。
3、缺陷系统的界面设计
界面设计还是采用常见的工具栏的方式进行布局，根据缺陷的信息关系，我们查看信息 的时候，让用户先在具体的域下面选择具体的项目，然后展示该项目下的缺陷信息。
选择项目信息后，我们一般需要根据项目显示它的缺陷列表，缺陷信息提供重要的信息展示。
双击可以展开具体的缺陷信息，其中包括附件提交和查看管理，缺陷的修改历史等信息。
对于缺陷里面的一些字典属性，我们可以通过统一的字典模块进行维护，如下所示，可以对缺陷状态、缺陷类型、优先级、严重程度等信息进行独立的维护管理。
一般情况下，我们最终还是需要根据缺陷的记录，获得一定的统计分析报表，以便对该版本是否能够正常发布进行一个评估工作，或者是了解缺陷的分类、趋势等信息的需要。
例如，我们可以在缺陷分类统计里面，把缺陷状态、缺陷类型、严重程度、优先级等根据版本信息进行一个分类统计，也可以根据缺陷的趋势进行统计等等。
本文转自博客园伍华聪的博客，原文链接：一个缺陷管理系统数据库设计和界面设计分析，如需转载请自行联系原博主。
