基于软件测试的缺陷管理系统的设计与实现.doc

广州大学华软件学院 软件工程系 冯名诗 毕业论文——基于软件测试的缺陷管理系统设计与实现
广州大学华软软件学院
毕业论文（设计）

课题名称 基于软件测试的缺陷管理系统的设计与实现
——基本业务管理与信息统计分析模块
学 院 华软软件学院
系 别 软件工程系
专业班级 软件开发2班
学生姓名 冯名诗
学 号 0740112244
指导教师 林平荣
日 期 2011年4月10日
摘要： 软件测试近些年来在国内的发展非常快速，它可作为企业软件项目开发中的软件质量和项目管理的监控技术，逐渐成为企业软件开发的成败直接挂钩的项目过程。
FGWBMS软件缺陷管理系统开发目的旨在建立一个以微软的ASP.net MVC2与MSSQL Server 2005为基础，符合CMMI对于软件缺陷管理功能，而且轻量、精致的软件缺陷管理系统(BMS)。
软件缺陷管理为本系统的主要应用目标，同时能够满足不同用户群（如项目经理、测试人员、开发人员）的流程控制，提供足够灵活的接口是实现上述需求的关键。
本论文主要介绍了基于B/S模式软件缺陷管理系统的MVC2三层模式与ADO.NET Entity Framework(EF)混合开发架构的基本业务与信息统计分析模块的设计与实现，侧重点放在了讨论这个程序的需求分析、设计、实现及所用到的项目管理知识。对维护人员提交的缺陷报告认真鉴定、筛选、分类,进入不同的处理流程,以获得真正的缺陷跟踪数据。

关键词： MVC2,软件缺陷,BMS
Abstract: Software testing develops very fast in recent years domestically. It can be used as the monitoring technology of software quality and project management in the development of enterprise software project, and gradually becomes the project process tied to the success or failure of enterprise software development.
The development aim of FGWBMS is to establish a lightweighted and delicated BMS based on Microsoft's MVC2 and MSSQL Server 2005 to which accords with the function request of CMMI.
The main application target of the system is to manage the software defect as well as satisfy different user groups’ (such as the project manager, testers, developers) process control above which is achieved mainly by providing the interface flexible enough.
This paper mainly introduced MVC2 three-layer model based on the BMS of B/S and the design and implementation of the mixed development framework ’s basic business information as well as statistical analysis which belongs to ADO.NET Entity Framework (EF). The paper emphasises not only on discussing the needs as well as the design of the program but implementing the knowledge of project management. To get the real defect tracking data, we must seriously identificate, screen, classificate the defect reports which is submitted by maintenance personnel and actualize different treatment process.

Keywords: MVC2；Software Defect；BMS
目录
前 言 1
第1章 系统分析 3
1.1 系统设计目的 3
1.2 功能简介 3
1.3 系统需求 3
1.3.1 功能需求 4
1.3.2 性能需求 9
1.4 用例分析 10
1.4.1 主程序用例 10
1.4.2 项目管理用例 11
1.4.3 模块管理用例 12
1.4.4 版本管理用例 13
1.4.5 缺陷管理用例 14
1.5 运行环境 15
1.5.1 硬件环境 15
1.5.2 软件环境 15
第2章 数据库设计 16
2.1 数据库设计分析 16
2.2 数据库字典 16
2.2.1 T_Project 16
2.2.2 T_P_Version 17
2.2.3 T_P_Module 17
2.2.4 T_Defect 18
2.2.5 T_D_Properties 18
2.2.6 T_D_Log 19
2.3 E-R图 20
第3章 功能模块设计 21
3.1 MVC模式分析 21
3.2 ADO.NET Entity Framework分析 22
3.3 开发设计模型 23
3.3.1 系统整体模式架构 24
3.4 权限模块 25
3.5 模块结构 27
3.5.1 母板模块(Shared/ Site.Master) 27
3.5.2 业务模块(View目录下) 27
3.5.3 控制模块(controllers目录下) 30
3.6 核心模块设计 32
第4章 部分功能实现 35
4.1 ASP.NET MVC2模式 35
4.1.1 MVC2的强类型 35
4.1.2 MVC2的代码组织 36
第5章 系统测试 39
5.1 测试说明 39
5.1.1 测试平台环境如下： 41
5.1.2 主要测试业务： 41
5.1.3 功能测试： 41
5.2 性能测试 44
5.2.1 测试对象 44
5.2.2 测试工具 44
5.2.3 测试目的 45
5.2.4 术语及缩写词 45
5.2.5 计算公式 46
5.2.6 测试模型 47
5.2.7 测试过程简述 47
5.2.8 测试结果 48
设计总结 49
致谢 51
参考文献 52

55

前 言

随着软件产业的发展，软件的质量已经越来越成为软件产品成功的关键性因素，质量保证的一个重要方法就是通过测试活动来尽早的发现问题。软件测试的出现保证了软件在生产过程中的质量控制，在测试过程中所发现的质量问题就被称为“软件缺陷”。
软件中的缺陷(Defect或BUG)是软件开发过程中的“副产品”。通常，缺陷会导致软件产品在某种程度上不能满足用户的需要。每一个软件开发团队都必须知道如何妥善处理软件中的缺陷，这关系到软件生存、发展的质量根本。
在软件开发流程的每个阶段都必须引入软件测试技术，及早测试，杜绝错误的蔓延。然而，测试工作的天性决定了测试人员可能是开发人员总想回避的角色。在测试实践的早期，当测试人员查出某个缺陷，报告给开发人员时，多数情况下开发人员会象征性表示一下感谢，然后把测试报告撂在一边，继续忙手头的工作。事后到底有没有修改，谁也不知道。如果测试人员频繁给同一开发人员报错或不停地追问缺陷的修改情况，开发人员或许会逐渐丧失好脾气，出于维护技术权威或其他目的，他会狡辩：这不是错误，这是软件的一个特殊功能。或者说：这不是什么大问题，现在开发进度紧，而且纠正起来也挺麻烦的，等有时间再说吧。于是，不了了之，问题依旧存在。
为了规避这种情况的发生，软件企业必须引入软件缺陷跟踪管理机制。测试人员不再需要直接与开发人员接触，甚至不需要知道开发者是谁，查出错误以后，直接报到缺陷跟踪管理系统就可以了（有些测试团队是有写入权限控制的），开发人员做不做修改以及什么时间之前必须完成修改是项目管理部门的事情（当然测试团队也可以提相关建议）。引入缺陷跟踪管理机制一方面划清了各个角色的职责，避免了不必要争执，另一方面也有助于项目管理部门及时了解软件产品在生产过程中所处的质量状况，从而更好地控制产品的质量。
BMS是Bugs Manager System的缩写，中文意思是＂缺陷管理系统＂，软件缺陷管理是在软件生命周期中为确保缺陷被跟踪和管理所进行的活动。狭义地讲，BUG是写程序过程中造成的错误。广义地讲，BUG是影响客户正常使用的任何问题。就是说，BUG不仅仅是编程中出现的问题，还包括客户需求和功能规范等方面。
那么缺陷管理有什么优点？
1. 便于查找和跟踪。对于大型本地化软件的测试，报告的错误总数可能成百上千个，如果在没有错误跟踪系统的情况下，要求查找某个错误，简直是搜索者的恶梦，其难度和效率可想而知。这样就会导致某个缺陷被遗忘，质量得不到保证。
2. 便于跟踪和监控错误的处理过程和方法。可以方便地检查处理方法是否正确，可以确定处理者的姓名和处理时间，作为工作质量的统计和考核的参考。
3. 便于集中管理，提高效率。本地化服务商和软件供应商共享同一个错误跟踪系统数据库，各自负责处理己方需要处理的软件错误。对于需要对方提供更多信息的错误，可以通过改变错误的当前信息（状态、处理者、处理建议等），使对方尽快处理。
4. 安全性高。通过权限设置，不同权限的用户能执行不同的操作，保证只有适当的人员才能执行正确的处理。例如，测试工程师只能报告和验证错误，修复工程师能够修复错误。
5. 保证处理顺序的正确性，根据当前错误的状态，决定当前错误的处理方法。例如，如果是新报告的确认的错误，那么需要修复。如果是已经修复的错误，需要测试者验证是否完全修复。
6. 便于项目结束后的存档。错误跟踪系统具有方便存储的特点，可以随时或在项目结束后存储，以备将来参考。

在国外，缺陷跟踪对于保证软件质量的重要作用目前已经被大多数软件组织所接受。在Sourceforge.org上，几乎每一个比较受欢迎的开源项目，都有十分完备的Bug追踪记录。
目前比较著名的商业缺陷跟踪软件有Compuware公司的TrackRecord。开源软件有Mozilla的Bugzilla。

第1章 系统分析

软件中的缺陷(Defect或BUG)是软件开发过程中的“副产品”。通常，缺陷会导致软件产品在某种程度上不能满足用户的需要。每一个软件开发团队都必须知道如何妥善处理软件中的缺陷，这关系到软件生存、发展的质量根本。
软件缺陷管理系统，管理的信息对象即是软件缺陷，在知道软件缺陷的定义之后就可以进行管理。软件缺陷管理是在软件生命周期中为确保缺陷被跟踪和管理所进行的活动。狭义地讲，BUG是写程序过程中造成的错误。广义地讲，BUG是影响客户正常使用的任何问题。就是说，BUG不仅仅是编程中出现的问题，还包括客户需求和功能规范等方面。

1.1 系统设计目的

本软件缺陷管理系统设计目的旨在建立一个以ASP.NET MVC2与MSSQL 2005为基础，功能简单、结构灵活而且轻量、精致的管理系统。软件缺陷管理为本系统的主要应用目标，同时能够满足不同用户群（如项目经理、测试人员、开发人员）的管理，实现上述需求的关键。
1.2 功能简介

项目管理功能：缺陷所对应的项目，模块，版本等的管理
缺陷管理功能：本系统的主要内容。
信息统计分析功能：对不同属性软件缺陷统计，并分析结论。
1.3 系统需求

在本文中主要是从简单的两个方面进行阐述系统的需求，也是任何信息系统所关心的最基本的需求：功能需求，与性能需求。
1
1.1
1.2
1.3.1 功能需求

功能需求是本系统体现其作用的重点，也是用户所要求的功能，作为一个软件缺陷管理系统，其重中之重就是缺陷的管理。
同时作为一个软件缺陷，同样有其归属，软件缺陷只会出现在一个软件项目中，这是一个大的方向。从细分的时候，一个项目有多个版本，一个版本中有多个模块，而软件缺陷可以在这其中任一个对象当中。如整个项目和客户所需的软件不符合，这是一个软件缺陷；某个版本的性能达不到客户要求，这是一个软件缺陷；某个版本中的某个模块无法正常使用或得出的结果与客户要求的不符合，这一样是一个软件缺陷。所以软件缺陷和项目是不可分离的，要对软件缺陷进行管理，就必须对其项目进行简单的管理。同时信息管理还有一个重要功能模块，即是统计功能，让项目经理能够发现某种缺陷的发生频率与防止其再次发生。
任何的信息管理系统，都离不开其管理者，即使用者。软件缺陷管理系统发展至今，可以说在项目中涉及的人员都可以使用软件缺陷管理系统，如在软件工程中，项目的前期，如需求师；项目的管理人，项目经理；测试小组中，测试工程师；项目中的开发人员。还有就是一个大项目中，多个组织和公司同时进行开发时，会多出很多参与到项目中的人员。本系统是一个轻量级的软件缺陷管理系统，所以本文只针对三个角色进行描述。

1.3.1.1 项目管理需求：

a) 项目管理：新增项目、修改项目、删除项目、项目列表。
b) 模块管理：新增模块、修改模块、删除模块、模块列表。
c) 版本管理：新增版本、修改版本、删除版本、版本列表。
1.3.1.2 缺陷管理需求：

软件缺陷有一系列的属性组成，这些属性指示了需要系统跟踪和管理的是什么。
软件缺陷属性包括：缺陷标识、缺陷类型、缺陷严重程度、缺陷产生可能性、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷原因。

缺陷标识：是标记某个缺陷的唯一的表示，可以使用数字序号表示。
缺陷类型：是根据缺陷的自然属性划分缺陷种类

缺陷类型
描述
功能
影响了各种系统功能、逻辑的缺陷
用户界面
影响了用户界面、人机交互特性
文档
影响发布和维护
软件包
由于软件配置库、变更管理或版本控制引起的错误
性能
不满足系统可测量的属性值，如执行时间，事务处理速率。
系统/模块接口
与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表等不匹配、冲突。
表格 11 缺陷类型列表

缺陷严重程度：是指因缺陷引起的故障对软件产品的影响程度，所谓“严重性”我指的是在测试条件下，一个错误在系统中的绝对影响。

缺陷严重等级
描述
致命
系统任何一个主要功能完全丧失、用户数据受到破坏
严重
系统的主要功能部分丧失、数据不能保存
一般
系统次要功能没有完全实现，不影响用户的正常使用
较小
使操作者不方便或遇到麻烦，它不影响功能的操作和执行
表格 12 缺陷严重程度

缺陷产生的可能性：指缺陷在产品中发生的可能性，通常可以用频率来表示。

缺陷产生可能性
描述
总是
总是产生这个软件缺陷，其产生的频率是100%
通常
按照测试用例，通常情况下会产生这个软件缺陷，其产生的频率大概是80-90%
有时
按照测试用例，有的时候产生这个软件缺陷，其产生的频率大概是30-50%
很少
按照测试用例，很少产生这个软件缺陷，其产生的频率大概是1-5%
表格 13 缺陷长生的可能性列表

缺陷优先级：指缺陷必须被修复的紧急程度。“优先级”的衡量抓住了在严重性中没有考虑的重要程度因素。

缺陷优先级
描述
立即解决(P1级)
缺陷导致系统几乎不能使用或测试不能继续，需立即修复
高优先级(P2级）
缺陷严重，影响测试，需要优先考虑
正常排队(P3级）
缺陷需要正常排队等待修复
低优先级(P4 级)
缺陷可以在开发人员有时间的时候被纠正
表格 14 缺陷优先级列表

一般来讲，缺陷严重等级和缺陷优先级相关性很强，但是，具有低优先级和高严重性的错误是可能的，反之亦然。例如，产品徽标是重要的，一旦它丢失了，这种缺陷是用户界面的产品缺陷，但是它阻碍产品的形象。那么它是优先级很高的软件缺陷。

缺陷状态：指缺陷通过一个跟踪修复过程的进展情况，也就是在软件生命周期中的状态基本定义。

缺陷状态
描述
打开
问题还没有解决，存在源代码中，确认“提交的缺陷”，等待处理，如新报的缺陷。
修复
已被开发人员检查、修复过的缺陷，通过单元测试，认为已解决但还没有被测试人员验证
关闭
测试人员验证后，确认缺陷不存在之后的状态。
重新打开
测试人员验证后，还依然存在的缺陷，等待开发人员进一步修复
不能重现
开发不能复现这个软件缺陷，需要测试人员检查缺陷复现的步骤。
需要更多信息
开发能复现这个软件缺陷，但开发人员需要一些信息，例如：缺陷的日志文件，图片等。
表格 15 缺陷状态列表

缺陷来源：指缺陷所在的地方，如文档、代码等。

缺陷来源
描述
需求说明书
需求说明书的错误、或不清楚引起的问题
设计文档
设计文档描述不准确、和需求说明书不一致的问题
系统集成接口
系统各模块参数不匹配、开发组之间缺乏协调引起的缺陷
数据流(库)
由于数据字典、数据库中的错误引起的缺陷
程序代码
纯粹在编码中的问题所引起的缺陷
表格 16 缺陷来源列表

缺陷根源：指造成上述错误的根本因素，以寻求软件开发流程的改进、管理水平的提高。

缺陷根源
描述
测试策略
错误的测试范围，误解了测试目标，超越测试能力等
过程，工具和方法
无效的需求收集过程，过时的风险管理过程，不适用的项目管理方法，没有估算规程，无效的变更控制过程等。
团队/人
项目团队职责交叉，缺乏培训。没有经验的项目团队，缺乏士气和动机不纯等。
缺乏组织和通讯
缺乏用户参与，职责不明确，管理失败等。
硬件
硬件配置不对、缺乏，或处理器缺陷导致算术精度丢失，内存溢出等
软件
软件设置不对、缺乏，或操作系统错误导致无法释放资源，工具软件的错误，编译器的错误，2000 千年虫问题等。
工作环境
组织机构调整，预算改变，工作环境恶劣，如噪音过大。
表格 17 缺陷根源列表

软件缺陷的属性只是作为一个软件缺陷的组成部分，参与人员需要管理缺陷不只一个，不同的角色参与的管理也是不同的，所以下面是大概所需要的功能。
a) 缺陷管理：新增缺陷、修改缺陷、缺陷列表、缺陷日志。

业务的处理是本文的重点，也是本系统的重点之一。
整个业务的一般流程都是根据软件缺陷的状态进行跟踪管理的，不同状态由不同的角色进行处理，这就向工作流(BPM)一样。缺陷信息提交后，会进行分配，进入待修正状态。通常情况下，被分配的开发人员会负责对它进行修复。然后由测试人员进行验证，验证通过后就会被关闭。如果没有通过验证，就会交给开发人员进行修复。但开发人员基于某种原因或理由，也可能会拒绝修改，这时会交给评审委员会进行评审，如果通过评审，则这个缺陷会被关闭，否则开发人员还是要继续进行修复。
这个过程涉及到的人员角色有：
测试人员：进行测试的人员，缺陷的发起者；
项目经理：对整个项目负责，对产品质量负责的人员；
开发人员：执行开发任务的人员，完成实际的设计及编码工作；

1.3.1.3 信息统计分析需求：

a) 信息统计：不同属性类型的缺陷统计、不同模块中缺陷统计、不 同版本中缺陷统计。
b) 统计分析：根据相应公式计算统计信息，得出结论。
1.3.2 性能需求

忽略网络环境因素、主题模板及功能插件运作的因素，以本地测试为准。

1.3.2.1 响应时间与内存使用量：

数据库安装响应：时间2秒内，内存使用量最高上限8,000,000 bytes。
前台浏览响应时间：时间0.8秒，内存使用量最高上限9,000,000 bytes。
后台操作响应时间：时间0.9秒，内存使用量最高上限9,000,000 bytes。

1.4 用例分析

1.4.1 主程序用例

项目管理
模块管理
版本管理
缺陷管理
主程序用例图
项目经理
图 11 主程序一级用例图
测试人员
开发人员
<<include>>
<<include>>
信息统计与分析

项目经理进行登陆认证后，在进行项目管理，模块管理，版本管理，缺陷管理等方面的操作。
测试人员，开发人员进行登陆认证后，可以进行缺陷管理。

1.4.2 项目管理用例

项目经理
创建项目
统计项目数目
删除项目
编辑项目内容
项目管理
<<include>>
<<include>>
<<include>>
图 12 项目管理用例图
修改项目描述
修改项目标题
<<include>>

a) 系统从项目管理中，提取编辑项目内容，创建项目，删除项目等功能，让项目经理进行对其选择操作。
b) 编辑项目内容，包括修改项目标题，修改项目描述。
c) 一旦项目经理完成编辑项目内容，创建项目，删除项目等方面的操作后，系统就自动对项目进行统计数目。

1.4.3 模块管理用例

项目经理
创建模块
统计模块数目
删除模块
编辑模块内容
模块管理
<<include>>
<<include>>
<<include>>
图 13 模块管理用例图
修改模块描述
修改模块标题
<<include>>

a) 一旦创建项目后，系统从模块管理中，提取编辑模块内容，创建模块，删除模块等功能，让项目经理进行对其选择操作。
b) 编辑模块内容，包括修改模块标题，修改模块描述。
c) 一旦项目经理完成编辑模块内容，创建模块，删除模块等方面的操作后，系统就自动对模块进行统计数目。
1.4.4 版本管理用例

项目经理
创建版本
统计版本数目
删除版本
编辑版本内容
版本管理
<<include>>
<<include>>
<<include>>
图 14 版本管理用例图
修改版本描述
修改版本标题
<<include>>

a) 一旦创建项目后，系统从版本管理中，提取编辑版本内容，创建版本，删除版本等功能，让项目经理进行对其选择操作。
b) 编辑版本内容，包括修改版本标题，修改版本描述。
c) 一旦项目经理完成编辑版本内容，创建版本，删除版本等方面的操作后，系统就自动对版本进行统计数目。

1.4.5 缺陷管理用例
项目经理
缺陷管理
编辑缺陷
添加缺陷
<<include>>
图 15 分类管理用例图
修改缺陷状态
记录缺陷日志
开发人员
测试人员
<<include>>
<<include>>

a) 项目经理，在缺陷管理中，可以进行添加缺陷，编辑缺陷，等方面的操作。
b) 测试人员，可以发起缺陷，即添加缺陷。
c) 测试人员对缺陷进行验证，开发人员提交修复后，即修改缺陷状态操作
d) 无论任何人在缺陷管理中对缺陷状态进行修改，都会记录其历史日志。

1.5 运行环境

1.5.1 硬件环境

a) 服务器端:
服务器端的最低配置是由建立站点所需的软件来决定的，在最低配置的情况下，服务器的性能往往不尽人意，现在硬件性能已经相当出色，而且价格也很便宜，因此通常应给服务器端配置高性能硬件。
本网络系统服务器端的配置如下：
处理器：Inter Pentium（Celeron） 4 2.4GHz 或更高。
内存：512MB
硬盘空间：60G
显卡：SVGA显示适配器

1.5.2 软件环境

a) 服务器端:
操作系统：Windows NT/2000/2003//2008/XP professional
网站服务器：IIS6 + .NET 4.0
数据库管理系统：MSSQL Sever 2005

b) 用户端:
操作系统：Windows NT/2000/2003/XP professional或Linux 2.6.4 .etc

第2章 数据库设计

2.1 数据库设计分析

各数据表描述
数据表
描述
相关区域
T_Project
项目信息
Admin > Comments
T_P_Version
版本信息
Admin > Settings
T_P_Module
模块信息
Admin > Posts
T_Defect
缺陷信息
Admin > Catetories
T_D_Properties
缺陷属性信息
Admin > Users
T_D_Log
缺陷日志信息
Admin > Users
表21 数据表描述
2.2 数据库字典

1
2
2.2.1 T_Project

字段名
类型
默认值
扩展
描述
P_ID
varchar(50)

id
P_Title
varchar(50)

项目名称
P_Description
varchar(500)

标识描述
表 22 T_Project表

键名
类型
字段名
PK_T_Project
PRIMARY
P_ID
表 23 T_Project索引

2.2.2 T_P_Version

字段名
类型
默认值
扩展
描述
P_V_ID
nvarchar(50)

id
P_ID
nvarchar(50)

FK->T_Project.P_ID
项目id
P_V_Title
nvarchar(50)

版本名称
P_V_Description
nvarchar(500)

版本描述
表 24 T_P_Version表

键名
类型
字段名
PK_T_P_Version
PRIMARY
P_V_ID
表 25 T_P_Version索引

2.2.3 T_P_Module

字段名
类型
默认值
扩展
描述
P_M_ID
nvarchar(50)

id
P_ID
nvarchar(50)

FK->T_Project.P_ID
项目id
P_M_Title
nvarchar(50)

模块名称
P_M_Description
nvarchar(500)

模块描述
表 26 T_P_Module表

键名
类型
字段名
PK_T_P_Module
PRIMARY
P_M_ID
表 27 T_P_Module索引

2.2.4 T_Defect
字段名
类型
默认值
扩展
描述
D_ID
nvarchar(50)

id
D_Title
nvarchar(50)

缺陷名称
D_Properties_ID
nvarchar(50)

FK->T_D_Properties.D_P_ID
缺陷属性id
D_Description
nvarchar(500)

缺陷描述
D_OpenDate
datetime

打开时间
D_UpdateDate
datetime

更新时间
P_ID
nvarchar(50)

FK->T_Project.P_ID
项目id
P_V_ID
nvarchar(50)

FK->T_P_Version.P_V_ID
版本id
P_M_ID
nvarchar(50)

FK->T_P_Module.P_M_ID
模块id
D_HandlerUser
nvarchar(50)

FK->T_Users.U_ID
处理人id
D_Designee
nvarchar(50)

FK->T_Users.U_ID
指派人id
D_Sponsor
nvarchar(50)

FK->T_Users.U_ID
发起者id
表 28 T_Defect表

键名
类型
字段名
PK_T_Defect
PRIMARY
D_ID
表 29 T_Defect索引

2.2.5 T_D_Properties

字段名
类型
默认值
扩展
描述
D_P_ID
nvarchar(50)

id
D_P_Type
nvarchar(50)

缺陷类型
D_P_Severity
nvarchar(50)

缺陷严重程度
D_P_Priority
nvarchar(50)

缺陷优先等级
D_P_Status
nvarchar(50)

缺陷状态
D_P_Origin
nvarchar(50)

缺陷根源
表格 210 T_D_Properties表

键名
类型
字段名
PK_T_D_Properties
PRIMARY
D_P_ID
表 211 T_D_Properties索引

2.2.6 T_D_Log

字段名
类型
默认值
扩展
描述
L_ID
nvarchar(50)

id
L_Date
datetime

日志时间
L_User
nvarchar(50)

用户
L_D_ID
nvarchar(50)

缺陷id
L_Description
nvarchar(500)

日志描述
L_Status
nvarchar(50)

缺陷状态
表格 212 T_D_Log表

键名
类型
字段名
PK_T_D_Log
PRIMARY
L_ID
表 213 T_D_Log索引

2.3 E-R图

T_Defect
s
T_Project
拥有
T_P_Module

拥有
n
1
1
1
P_ID
D_ID
P_M_ID

图 21主程序E-R图

T_P_Version

拥有
n
n
P_V_ID
关联
关联
1
1
1
1

T_Defect

T_D_Properties

1
D_ID
拥有
1
D_P_ID
图 22 缺陷管理E-R图
拥有
T_D_Log
L_ID
1
n

第3章 功能模块设计

3.1 MVC模式分析

使用像ASP，PHP，或者CFML这样的基于过程化开发的语言来开发一般的Web应用程序，它们的输入、处理和输出都不能很好的进行分离，因而很难体现出业务模型和业务重用性，以至于代码难以结构混乱和难以维护。MVC从根本上强制性的将它们分开。
MVC是一种将应用程序的逻辑层和表现层进行分离的方法。ASP.NET MVC2是基于模型-视图-控制器这一设计模式的。本系统采用ASP.NET MVC2框架下的MVC开发模式。
· 模型(Model)代表你的数据结构。通常来说，你的模型类将包含取出、插入、更新你的数据库资料这些功能。
· 视图(View)是展示给用户的信息。一个视图通常是一个网页。
· 控制器(Controller)是模型、视图以及其它任何处理 HTTP 请求所必须的资源之间的中介，并生成网页。

MVC三层模式的好处显而易见，首当其冲就是模型重性能很好地发挥，因为模型是自包含的，并且与控制器和视图相分离，所以很容易改变你的应用程序的数据层和业务规则。由于运用MVC的应用程序的三个部件是相互对立，改变其中一个不会影响其它两个，所以依据这种设计思想你能构造良好的松偶合的构件。

图 3-1 MVC模式

3.2 ADO.NET Entity Framework分析

图 3-2 ADO.NET EF结构

ADO.NET Entity Framework是微软以ADO.NET为基础所发展出来的对象关系对应(O/R Mapping)解决方案。Entity Framework以Entity Data Model(EDM)为主,利用抽象化数据结构方式,将数据库对象转换成应用程序对象,库表字段转换为属性,并系转换为关联系统,把数据库的E/R模型转换成对象模型,使开发人员通过对概念应用程序模型编程来创建数据访问应用程序,以此降低面向数据的应用程序所需要的开发量,并减轻系统维护工作。
Entity Framework技术的应用中,可针对数据库中各个表按照1:1映射生成模型和映射信息,在代码中直接对表中数据进行增、删、改、查操作。但在实际应用中,这种简单的处理方式不利于进一步降低程序开发工作量,部分情况还违背了“程序开发以应用为中心的概念模型来工作”的理念,对象的概念不清晰。为此,对几种常用的数据库情景的建模方法进行列举：
a) 带有有效载荷的多对多关系建模 
b) 自引用关系建模 
c) 跨表实体建模 
d) 多实体建模 
e) 多表派生建模 
f) 表分割建模 

3.3 开发设计模型

基于ASP.NET MVC2 + ADO.NET EF模型的一点看法，能解决数据访问到逻辑分析考虑，为系统设计找到一个平衡点，它能把扩展功能从框架中剥离出来，降低了框架的复杂度，让框架更容易实现。扩展功能与框架以一种很松的方式耦合，两者在保持接口不变的情况下，可以独立变化和发布。公开插件接口，让第三方有机会扩展应用程序的功能，共同分享成果。
为更好地体现出系统的灵活性和可扩展性，本系统采用了MVC三层模式开发和ADO.NET EF的混合开发模式，实现数据连接层和业务层的分离，加上事件处理（Action）和过滤器（Filter）处理的机制，在数据库存取数据时，进行格式化数据。

2
3
3.1
3.2
3.3
3.3.1 系统整体模式架构

Controller
控制器
Model模型
(业务处理模型)
View
视图
客户
MVC
模型
图 33混合式开发模型图

3.4 权限模块

ASP.NET 所具有的表现层，业务逻辑层和数据访问层的三层架构，使页面代码与逻辑处理代码与访问数据库的代码相互分开并且相互透明。此系统的所有访问控制和权限控制基本上是通过软件界面来实现的，通过对界面的控制来控制主体对客体的访问。在系统中对界面的表现要求主要有两种:软件界面元素的可见性和可访问性；软件界面数据集合的可见性和可操作性。即将用户按总部和办事处分角色，总部可以看到全体办事处的信息，而办事处只能看到自己办事处的相关