软件测试系统-细设计(适合学生学习).docVIP

方案设计 设计背景： 为了开发项目的需要，便于项目开发中的协作，并能有效追踪Bug，设计和开发一套适合内部小规模使用的缺陷追踪系统------缺陷跟踪管理系统。 设计目标： 版本由于设计时间短，只实现对一个5~10的项目开发小组的管理。 技术上采用，应用开发组都比较熟悉的ASP.NET来做开发语言，数据库将有SQL SERVER，以便于管理和移植。 该版本要为以后的升级和扩展提供支持，所以管理页面是采用简洁实用的方案，数据库表设计将严格遵循关系模型。 相关概念： 项目(Project)：指有多人配合完成的开发和设计任务。 模块(Model)：为实现项目功能而细化的，可以为小组成员接受的，定量的开发任务。(一般以一人一天来定义模块的大小)。 系统用户角色有三类： 管理用户：主要是用户权限的管理，对系统拥有最高管理，他可以批准成立新的项目组，发起新的项目。原则上一个项目组在一次开发生命周期中，只能针对一个项目。 测试用户：被要求测试某个同一项目组其他成员的开发模块，主要是完成Bug的提交、复核。他可以按照约定的测试方法和要求，或按照需求设计要求，进行测试，如果没有问题，他必须记录测试过程和具体结果，或上传自己的该次测试文档。如果发现Bug，可以提交Bug情况说明，必要时候上传Bug情况截图，返回开发人员修改。对开发人员申请的Bug关闭请求进行复核后，关闭该Bug。 软件开发用户：负责具体模块开发，他必须在每天工作结束后，在系统中提交开发的模块，并对需要测试的模块，提交项目组其他人员测试，他可以提交测试备案，对测试人员返回的Bug报告，进行处理，完成后需要说明处理过程，向测试人员申请Bug关闭。 缺陷(Bug)：一切不符合项目开发需求和设计的错误。 缺陷（Bug）的状态分为： 未解决（New）：测试未解决的软件缺陷或新提交的软件缺陷（Bug）； 已修复(Fixed)：开发人员已完成修正，等待测试人员验证； 关闭(Closed)：测试人员查看Fixed状态的Bug，若问题被修改，标志Bug已被修复；? 缺陷（Bug）标题： 简单概述缺陷的标题。 详细再现缺陷（Bug）步骤 具体详细地描述Bug的再现过程，以及Bug详细信息。 缺陷提交人?缺陷提交人的名字。 缺陷提交时间 缺陷提交的时间。 缺陷所属项目/模块?缺陷所属的项目和模块。 缺陷建议解决人?缺陷指定的解决人，建议某个相关开发人员修改。 缺陷解决时间开发人员修改此缺陷后的时间。? 必要的附件 对于某些文字很难表达清楚的缺陷，使用图片等附件是必要的。 详细设计 流程图 登录 【功能说明】 登录 【建议界面】 图3 登陆界面 登陆界面，以进行各项管理工作。 菜单列表 图4 管理员登录菜单列表 图5 测试员登录菜单列表 后台列表 操作员管理 【功能说明】 管理员添加操作员 【建议界面】 图6 操作员列表 图7 添加操作员 进行操作员的增加，修改，删除操作。删除判断主外建关系。已经产生记录的操作员可以先停用，再删除。删除时，只修改一个状态，并不真正删除，各业务表将保存次操作员的所有历史数据。 .错误类型 图8 错误类型 图9 添加错误类型 【主要处理】 1.增加，修改，删除各错误类型。删除时判断主外建关系，已经引用的不能删除，只能修改中文名称。 .项目设置 【功能说明】 设置项目 【建议界面】 图10 项目管理 图11 项目管理—添加新项目 新增项目 修改项目 删除项目，当项目被引用时，不得删除。判断外建约束。 . 功能 . 模块设置 【功能说明】 设置项目下的模块 【建议界面】 图12 项目模块设置 图13 模块设置—添加新模块 添加，修改，删除项目下的一级模块，删除时判断主外建关系，已经被引用时不得删除。 功能点设置 【功能说明】 设置项目模块下的功能点 【建议界面】 图14 功能点设置 图15 功能点设置—添加新功能点 添加，修改，删除一级模块下的各功能点.已经提交的不能删除，不能做提交的反操作。 功能提交 【功能说明】 程序员提交功能点 【建议界面】 图16 功能提交 1. 程序员对项目各功能点进行提交操作，只有提交的功能点，才能填写测试单。 不能进行提交的反操作。 测试报告 【功能说明】 测试报告提交 【建议界面】 图17 测试报告 测试报告列表 【功能说明】 查询Bug情况。 【建议界面】 图18 测试报告列表 结果分析 【功能说明】 统计报表 【建议界面】 图 19 统计信息 如图18，通过统计数据察看所有测试人员提交Bug的情