密级 中级 (供内部测试完毕后使用)
Servlet图书管理系统
测试报告
报告编号: ServletBMS-TR-1
（Servlet Book Management System-Testing Report）
部门经理______项目经理______
开发经理______测试经理______
研发公司: 第六科技有限公司 用户单位: 广东用户高教社
| 版本 | 作者 | 时间 | 变更摘要 |
| 1 | 李测试 | 2022年6月3日星期五 | 新建 |
目录
一 引言
二 测试概要
三 测试结果及缺陷分析
四 测试结论与建议
可能角色可参考相应章节:
项目管理者:测试执行中成本、资源和时间.
高层经理:简单的图表与其他项目进行同向比较.
开发人员:缺陷结果以及分析,产品开发质量的信息.
二 测试概要
三 测试结果及缺陷分析
四 测试结论与建议
一 引言
1.1编写目的
本测试报告为Servlet图书管理系统项目的测试报告，目的在于总结测试阶段的测试以及分析测试结果，描述系统是否符合需求说明书(ServletBMS -RD-2.0)。预期参考人员包括测试人员、开发人员、项目管理者、其他质量管理人员和需要阅读本报告的高层经理。
1.2项目背景
随着社会经济的迅速发展和科学技术的全面进步以及计算机事业的飞速发展，以计算机科学与通信技术为基础的信息管理系统IE处于蓬勃发展的时期。随着经济文化水平的显著提高，人们对生活质量及工作环境的要求也越来越高，但伴随着人的劳动强度的增大，以及社交活动的广泛开展，如何来提高人民纸质书本阅读量，是一个很现实的问题。无疑，科技的蓬勃发展使更多人依赖电子书，逐渐失去了对阅读纸质书本重要性的理解。如今书籍的发展，也继承了信息化的发展道路，网络的兴起，给了人们各种各样不同的选择。与此同时，为了管理好一个书店的正常营运，管理问题也就提上了日程。随着图书借阅问题的白热化，管理难度也越来越大，如何优化书店的日常管理也就成为了一个大众化的课题。
在计算机飞速发展的今天，将计算机这一信息处理利器应用于书店的日常管理已是势必所然，面且这也将为商店管理带来前所未有的改变，它可以带来意想不到的效益，同时也会为书店的飞速发展提供无限潜力。采用计算机管理信息系统已书店管理科学化和现代化的重要标志。要想在激烈的市场竞争中立于不败之地，没有现代化的管理是万万不行的。
通过对书店管理日常工作的详细调查,搜集了大量的资料,从系统结构的组织，功能的实现，技术的要求以及可行性等多方面进行考虑，我认为本课题是一个适应现今书店信息管理需求的计算机信息管理系统，具有一定的实际开发价值和使用价值。
1.3系统简介
本设计以图书管理业务为对象,系统实现用的前台开发工具是eclipse，后台数据库为MySQL。设计过程中的重点和难点是对整个系统的需求分析和数据库详细设计。
该系统对数据进行保存、修改、删除等管理。为用户提供了一个友好、简单快捷的运行操作平台。该系统对数据进行保存、修改、删除等管理，为用户提供了一个友好、简单快捷的运行操作平台。本系统的各界面设计友好、流程正确、功能也较为完善，旨在为用户提供方便快捷的服务，使人们走近书籍，走进书籍，热爱读书。
本次设计意在为图书管理行业提供一个简便、易操作、可靠的借还管理系统，实现图书借阅、书店人员的更新及管理。
1.4术语和缩写词
数据库:通常指代 MySQL数据库;
系统: 通常指代Servlet图书管理系统,即ServletBMS（Servlet Book Management System）.
1.5参考资料
莞理第七测试科技有限公司《公司规范》,《测试手册》
图书管理系统需求说明书
图书管理系统-完整设计报告书
软件安装使用说明文档
2.0版 Servlet图书管理系统测试计划
2.0版 Servlet图书管理系统测试用例表
Servlet图书管理系统测试用例执行表
二 测试概要
图书管理系统需求说明书规定的系统功能进行功能测试。（其他测试经理和质量人员关注部分）
2.1测试用例设计
本小节简要介绍测试用例的设计方法。
1.等价类划分：
目标：用最少的测试数据，比较高的效率，以达到最好的测试质量
只要有输入框输入数据的地方，就可以用等价类划分这一方法来测试，从大量数据中挑选少量代表数据进行测试
等价类划分为有效等价类和无效等价类
有效等价类：有意义的、合理的输入数据集合，程序可以接收到有效等价类的数据并正常执行
无效等价类：无意义的、不合理的输入数据集合，程序接收到无效等价类的数据，弹出错误提示或者不允许用户输入的数据
2.边界值
只要有输入框输入数据的地方，就可以用边界值这一方法来测试，一般与等价类划分共同使用，找到有效数值和无效数值之间的分界点及其两边的点进行测试
根据需求，取出边界值
小于最低有效值的整数
等于最低有效值的整数
大于最低有效值的整数
等于最高有效值的整数
大于最高有效值的整数
注意：
（1）对于不同控件的有效等价类和有效的边界值，可以尽可能的在一条用例中进行测试
（2）在使用边界值测试方法取值时，并非只是取有效边界值的数值，而是应包含有效边界值和无效边界值
2.2测试环境与配置
 |
数据库服务器配置
硬盘：可用空间大小大于200GB
应用软件：Python 3.8.8，Anaconda Navigator (Anaconda3)，Python库selenium 3.141.0；Google Chrome 版本 99.0.4844.84（正式版本） （64 位），Chrome驱动 99.0.4844.51/，2022-05-29T08:00:00Z
产品安装测试所选择的客户端/服务器组合：
客户端操作系统—Windows 95；服务器端操作系统—Sum Solaris 2.6；
客户端操作系统—Windows 2010；服务器端操作系统—Linux 6.5
2.3测试方法(和工具)
测试中采用的方法主要是黑盒测试。
工具:
Python 3.8.8，Python库selenium 3.141.0；
Anaconda Navigator (Anaconda3)，
Google Chrome 版本 99.0.4844.84（正式版本） （64 位），
Chrome驱动 99.0.4844.51/，2022-05-29T08:00:00Z
三 测试结果及缺陷分析
3.1测试执行情况与记录
描述测试资源消耗情况，记录实际数据。（测试经理、项目经理关注部分）
3.1.1测试组织
表1 测试人员投入
| 姓名 | 职位 | 职责 | 可工作时间 |
| 测试团队负责人 | 测试协调、报告、初步功能测试 | 100% | |
| 测试员 | 特征测试、回归测试、安装产品和准备测试环境并服从测试调配 | 100% | |
| 测试员 | GUI测试、产品安装测试并服从测试调配。 | 100% |
3.1.2测试时间与成本
（测试经理、项目经理关注部分）
列出测试的跨度工作量和成本，最好区分测试文档和活动的时间。数据可供过程度量使用。
表6列出了Servlet图书管理系统的系统测试时间进度计划。表中列出的冒烟测试时为了尽早看一下软件的情况，它使我们能发现主要的阻碍性缺陷，以及存在于测试配置和测试用例中的缺陷。冒烟测试将包含安全测试和特征测试的一个子集。
表6 Servlet图书管理系统测试的时间进度计划
| 任务 | 开始时间 | 结束时间 | 合计/工作日 |
| 配置并调试两种测试环境 | 4/20 | 4/25 | 6 |
| 对预备构建执行冒烟测试 | 4/25 | 4/27 | 3 |
| 第一次测试循环 | 4/28 | 5/8 | 12 |
| 第二次测试循环 | 5/8 | 5/18 | 10 |
| 第三次测试循环 | 5/18 | 5/28 | 10 |
| 复查产品是否准备好 | 5/28 | 6/10 | 13 |
| 总计 | 54 |
我们假定由开发团队执行的所有单元测试和集成测试都会在第一种测试环境开始之前完成，在单元测试和集成测试中发现的所有灾难性缺陷都会在系统测试开始之前得到修正。
预计Servlet图书管理系统的每个测试循环所需的时间见表4。请注意，每个循环测试包括针对一个被测构建运行一组完整的测试。如果测试Servlet图书管理系统需要三个测试循环，则总测试工作将需要表中预估工作量的三倍。
表4预计每个测试循环所需的工作量
| 任务 | 时间/小时 |
| 产品安装测试 | 35 |
| 运行正常功能测试并报告缺陷 | 30 |
| 验证对缺陷的修正 | 25 |
| GUI测试 | 15 |
| 报告测试状态 | 15 |
| 进行缺陷复查 | 20 |
| 总计 | 140 |
| 测试类型 | 人员成本 | 工具设备 | 其他费用 |
| 配置并调试两种测试环境 | 2*300*6 | 4*200*10 | 2*100*10 |
| 对预备构建执行冒烟测试 | 2*300*3 | 4*100*3 | 2*100*3 |
| 第一次测试循环 | 3*300*12 | 4*100*12 | 2*100*12 |
| 第二次测试循环 | 3*300*10 | 4*100*10 | 2*100*10 |
| 第三次测试循环 | 2*300*10 | 4*100*10 | 2*100*10 |
| 复查产品是否准备好 | 3*300*13 | 4*100*10 | 2*100*10 |
| 总计/RMB | 42,900 | 26,000 | 11,000 |
在数据汇总时可以统计个人的平均投入时间和总体时间、整体投入平均时间和总体时间，还可以算出每一个功能点所花费的时/人。
| 用时 人员 | 编写用例 | 执行测试 | 总计 |
| 30 | 200 | 230 | |
| 60 | 300 | 360 | |
| 40 | 280 | 320 | |
| 合计 | 130 | 780 | 910 |
这部分用于过程度量的数据包括文档生产率和测试执行率。
| 文档生产率 人员 | 用例/编写时间 | 用例/执行时间 | 平均 |
| 22/30*100%=73.3% | 5/200*100%=2.5% | 37.9% | |
| 34/60*100%=56.7% | 40/300*100%=13.3% | 35% | |
| 18/40*100%=45% | 29/280*100%=10.4% | 27.7% | |
| 合计 | 74/130*100%=56.9% | 74/780*100%=9.49% | 33.2% |
3.1.3测试版本
测试版本:Servlet图书管理系统第一版本,
即ServletBMS（Servlet Book Management System）
测试次数回归测试3次。因为这是产品的第一个版本，所以不需要验证以前版本中修正过的缺陷是否又重新出现。这个版本关注的是系统测试阶段修正的缺陷不会破坏以前能工作的功能。
我们将使用以下方法来对产品的第一个版本进行回归测试。
发现缺陷时，它们会被修正。对测试团队收到的每个软件构件，都会执行测试以验证那些修正过的缺陷没再重现。换言之，每个缺陷修正都会在声称修正了它的版本中进行验证。
在产品已稳定并通过测试用例的证明之后，会进行一次最后的回归测试，然后再是产品是否准备好的复查。对于这个版本来说，通过回归测试意味着通过所有的测试用例。
3.2覆盖分析
3.2.1需求覆盖
需求覆盖率是指经过测试的需求/功能和需求规格说明书中所有需求/功能的比值，通常情况下要达到100％的目标。
| 测试类型 | 是否通过 | 备注 | |
| 3.1.1 用户界面 | 单元功能测试 | P | |
| 3.1.2 导航 | 单元功能测试 | Y | |
| 3.1.3 用户认证—读者 | 单元功能测试 | P | |
| 3.1.4 用户认证—管理员 | 单元功能测试 | P | |
| 3.1.5 注册 | 单元功能测试 | P | |
| 3.1.6 图书管理 | 单元功能测试 | Y | |
| 3.1.7 读者管理 | 单元功能测试 | Y | |
| 3.1.8 图书分类信息 | 单元功能测试 | Y | |
| 3.1.9 图书借阅信息 | 单元功能测试 | P | |
| 3.1.10 图书归还信息 | 单元功能测试 | Y | |
| 3.1.11 管理员管理 | 单元功能测试 | P | |
| 3.1.12 热门推荐 | 单元功能测试 | Y | |
| 3.1.13 最佳读者 | 单元功能测试 | Y | |
| 3.1.14 读者反馈 | 单元功能测试 | Y | |
| 3.1.15 图书查询 | 单元功能测试 | Y | |
| 3.1.16 借阅信息 | 单元功能测试 | Y | |
| 3.1.17 借阅历史 | 单元功能测试 | Y | |
| 3.1.18 问题反馈 | 单元功能测试 | P | |
| 3.1.19 个人资料 | 单元功能测试 | Y | |
| 3.1.20 修改密码 | 单元功能测试 | Y |
根据测试结果 ，P表示部分通过，N/A表示不可测试或者用例不适用。
需求覆盖率: Y项13/需求总数20 ×100％=65%
3.2.2测试覆盖
| 需求/功能（或编号） | 用例个数 | 执行总数 | 未执行 |
| 3.1.1 用户界面 | 3 | 3 | 0 |
| 3.1.2 导航 | 2 | 2 | 0 |
| 3.1.3 用户认证—读者 | 12 | 12 | 0 |
| 3.1.4 用户认证—管理员 | 11 | 11 | 0 |
| 3.1.5 注册 | 4 | 4 | 0 |
| 3.1.6 图书管理 | 3 | 3 | 0 |
| 3.1.7 读者管理 | 13 | 13 | 0 |
| 3.1.8 图书分类信息 | 3 | 3 | 0 |
| 3.1.9 图书借阅信息 | 1 | 1 | 0 |
| 3.1.10 图书归还信息 | 1 | 1 | 0 |
| 3.1.11 管理员管理 | 13 | 13 | 0 |
| 3.1.12 热门推荐 | 1 | 1 | 0 |
| 3.1.13 最佳读者 | 1 | 1 | 0 |
| 3.1.14 读者反馈 | 3 | 3 | 0 |
| 3.1.15 图书查询 | 3 | 3 | 0 |
| 3.1.16 借阅信息 | 2 | 2 | 0 |
| 3.1.17 借阅历史 | 1 | 1 | 0 |
| 3.1.18 问题反馈 | 6 | 6 | 0 |
| 3.1.19 个人资料 | 1 | 1 | 0 |
| 3.1.20 修改密码 | 2 | 2 | 0 |
测试覆盖率计算: 执行数74/用例总数74 ×100％=100％
3.3缺陷的统计与分析
缺陷统计主要涉及到被测系统的质量，因此，这部分成为开发人员、质量人员重点关注的部分。
3.3.1缺陷汇总
| 被测系统 | 系统测试 | 回归测试 | 总计 |
| 1 | 3 | 3 | 7 |
| 合计 | 3 | 3 | 6 |
按缺陷类型
| 用户界面 | 一致性 | 功能 | 算法 | 接口 | 文档 | 其他 |
| 5 | 0 | 1 | 0 | 0 | 0 | 0 |
按功能分布(“1”代表有缺陷)
| 功能 | 缺陷 |
| 3.1.1 用户界面 | 1 |
| 3.1.2 导航 | |
| 3.1.3 用户认证—读者 | 1 |
| 3.1.4 用户认证—管理员 | 1 |
| 3.1.5 注册 | 1 |
| 3.1.6 图书管理 | |
| 3.1.7 读者管理 | |
| 3.1.8 图书分类信息 | |
| 3.1.9 图书借阅信息 | 1 |
| 3.1.10 图书归还信息 | |
| 3.1.11 管理员管理 | 1 |
| 3.1.12 热门推荐 | |
| 3.1.13 最佳读者 | |
| 3.1.14 读者反馈 | |
| 3.1.15 图书查询 | |
| 3.1.16 借阅信息 | |
| 3.1.17 借阅历史 | |
| 3.1.18 问题反馈 | 1 |
| 3.1.19 个人资料 | |
| 3.1.20 修改密码 |
按严重程度
| 严重 | 一般 | 微小 |
| 0 | 5 | 0 |
缺陷的雷达图和柱状图
3.3.2缺陷分析
(开发人员可以在此分析基础上得出那部分功能/需求缺陷最多)
本部分对上述缺陷和其他收集数据进行综合分析
缺陷综合分析
缺陷发现效率 ＝ 缺陷总数7/执行测试用时780 =0.897%
用例质量 ＝ 缺陷总数7/测试用例总数74 ×100％＝9.46%
缺陷密度 ＝ 缺陷总数7/功能点总数20 ＝35%
重要缺陷摘要
| 缺陷编号 | 简要描述 | 分析结果 | 备注 |
| 1 | 读者端借阅记录，没有续期而是只有还书一种按钮 | 不满足需求文档,可能导致用户不能对超出借阅图书的还书日期的图书进行续订操作,可能是前端在与后端通信后,没有对借阅记录中的还书日期与当前时间进行比较,选择是还书还是续期的功能按钮显示在前端,或者本系统无法取得正确的当前时间。 |
3.3.3未解决问题
未解决问题
功能/测试类型：单元功能测试
缺陷具体描述/测试结果：用户注册和管理员提交图书类别等提交表单信息时,大多数功能模块没有对客户提交的字段进行相应的判断包括字段格式、总长度，没有向客户进行相应的错误类型提示如”反馈信息标题过长”等，而是提示其他通用错误类型如：“这是必填字段” 或者停留、直接跳转到没有提示的页面。
评价： 用户体验和交互一般，但是功能上满足基本需求说明书。
四 测试结论与建议
此部分为项目经理、部门经理以及高层经理关注。
4.1测试结论
(1)本次测试执行充分,以下特性较高:安全性、可靠性、可维护性,在功能上基本满足需求说明书(ServletBMS -RD-2.0) 。
(2)对测试风险的控制措施和成效.
根据“人机料法环”分析方法，本测试团队全面分析出项目风险主要来源
控制措施:1根据风险发生的概率和带来的影响确定风险的优先级，然后采取措施避免那些可以避免的风险2，风险转移 3 有些风险不可避免就设法降低风险 4 为了避免转移或降低风险事先要做好风险管理计划 5 对风险的处理要制定一些应急的有效的处理方案 6 在做计划时估算资源预算时间等要留有余地不要用到100% 7 制定文档标准同意建立一种机制保证文档及时产生。
风险控制成效:测试过程风险控制人王国华发现测试员黄元镇不熟悉系统业务的风险,采取了协调开发组本领域系统业务专员D同学对测试员黄元镇进行业务逻辑辅助和培训,有效提高和稳定了测试工作质量。
测试目标已经完成,本版本系统通过了测试,可以进入下一阶段项目目标。
4.2建议
本系统比较大的功能性缺陷是读者端借阅记录，没有续期而是只有还书一种按钮，不满足需求文档,可能导致用户不能对超出借阅图书的还书日期的图书进行续订操作。较大的不足是用户注册和管理员提交图书类别等提交表单信息时,大多数功能模块没有对客户提交的字段进行相应的判断包括字段格式、总长度，没有向客户进行相应的错误类型提示，而是提示其他通用错误类型如：“这是必填字段” 或者停留、直接跳转到没有提示的页面。用户体验和交互一般，但是功能上满足基本需求说明书。
此版本的系统亟待我们测试小组配合开发小组进行补充开发、完善和发布新版本系统，进一步提高用户体验和完全满足需求说明书。
本测试小组对缺陷修改的建议:建议开发组人员,开发时遵照需求说明书进行开发,提高公司协作交付效率。
对过程改进方面的建议:建议测试小组进行用例设计时,充分在整体上考虑测试用例,在不过度提高单个用例的测试成本时对可以合并测试的用例进行合并,减少冗余和重叠测试。自动化测试后，要手动复现缺陷，即采用自动便捷的自动化测试和灵活的手动测试相结合的方式。
1730
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
