Database design and interface design analysis of a defect management system

In terms of WinForm, based on the different business, we can use the efficiency of the tool, quickly do a lot of different business systems, a defect management system, want to put the unit Test business specifications, statistics and analysis of each version of the defect information, this chapter to collate these database design and interface design related content, To do an introduction, I hope to give you a comparative reference to learn about the case.

1. Business analysis of defect management system

In many defect management systems, we often need to manage the defect information records, as well as the opening and closing process of the defect records, so as to achieve the tester-"developer-" testers of the entire closed-loop process.

In general, the defect management system can be deployed in the local area network, or the public network within the convenience of the use of various project team members, so you can use a BS architecture, or CS architecture to achieve distributed applications, generally, the use of CS, in the data processing will be friendly, so combined with demand, I used the hybrid framework I used, the data using WCF services to achieve the sharing of data.

Defect information, usually belong to a specific project, a version, specific information under a module, so these classifications must be maintained independently, in order to facilitate the subsequent statistics and analysis, general defect information also need to submit error picture attachment information, convenient and intuitive understanding and developers troubleshooting.

Defect project information, in order to classify, we can also be divided into a domain for management, that is, the concept of grouping, such as by different types of projects, divided into different project domains, such as product projects, customer projects, research projects and other categories can be.

All of these are important attribute information in the flaw, so we need a good design in the defect management system to make our system conform to our business process.

In general, the version and module are for different projects, defect status, defect type, priority, urgency, these are common dictionary items, and will not change because of the project.

In addition, the defect processing is generally a closed-loop process, initially usually initiated by the tester (status is not resolved), submitted to the developer, the developer based on the defect record, set a reasonable state, if it is normal need to deal with the defect, generally need to fix the error, and set the status is resolved, Then the tester to the defect regression test, if the defect has been resolved, set the defect status is closed, or reopen the defect as unresolved state, in turn, the final consensus, is not resolved or deferred resolution. These modifications also need to be documented in the defect system, which has been tracked for a historical period.

2. Database design of defect management system

In order to store the above defect information, we need to design some tables for the storage of data, in addition to some common information storage, such as dictionary information, attachment information, the use of general module storage, for information about the defect, we also need to design the following table object to store information.

There is a certain relationship between the above tables, which are identified in the Red section.

3. Interface design of defect system

interface design or the use of common toolbar layout, according to the information relationship of the defect, when we look at the information, let the user first in the specific domain under the selection of specific items, and then display the defect information under the project.

After selecting the project information, we generally need to display its defect list according to the project, and provide important information to show the defect information.

Double-click to expand the specific defect information, including attachment submission and view management, defect modification history and other information.

For some dictionary attributes in the defect, we can maintain it through a unified dictionary module, as shown below, which can be used to manage the defect status, defect type, priority, severity, etc. independently.

In general, we still need to obtain a certain statistical analysis report according to the defect record, in order to make an assessment of whether the version can be released normally, or to understand the need of the classification, trend and other information of the defect.

For example, we can in the defect classification statistics, the defect status, defect type, severity, priority and so on according to the version of the information of a statistical classification, can also be based on the trend of the defect statistics and so on.

Database design and interface design analysis of a defect management system