智能厨房系统测试报告模板.docx
- 文档编号:25603751
- 上传时间:2023-06-10
- 格式:DOCX
- 页数:18
- 大小:50.44KB
智能厨房系统测试报告模板.docx
《智能厨房系统测试报告模板.docx》由会员分享,可在线阅读,更多相关《智能厨房系统测试报告模板.docx(18页珍藏版)》请在冰豆网上搜索。
智能厨房系统测试报告模板
智能家居系统测试报告
文档标识:
当前版本:
1.0
当前状态:
草稿
发布日期:
2013.06.03
发布
修改历史
日期
版本
作者
修改内容
评审号
变更控制号
组员:
李雄耀杨琪曾夏王浩然
组长:
王为峰
1.引言
1.1.编写目的、内容、读者
编写本测试报告主要有以下几个目的:
1.通过对测试结果的分析,得到对整体各个模块的质量评价;
2.分析测试的过程,产品,资源,信息;
3.评估测试测试执行和测试计划是否符合;
4.分析系统存在的缺陷,为修复和预防bug提供建议
测试包括以下具体内容:
1.用户测试:
主要测试系统的功能,操作性,性能,人机对话,系统界面,安全性等,主要参考对象为家庭用户。
比如,布置了本系统的家庭成员。
2.功能测试:
主要测试系统是否实现预计结果,此测试为软件的基本测试,主要参考对象为业主用户,开发人员,测试人员等。
3.压力测试:
压力测试用来评估在超越最大负载的情况下系统将如何运行。
主要参考对象为项目经理,开发经理,测试人员。
4.安全测试:
测试系统的可靠性,安全性,主要参考对象为业主用户,开发人员,测试人员。
本测试报告是智能厨房的测试报告,目的在于总结测试阶段的测试以及分析测试结果,描述系统是否符合需求。
预期参考人员包括用户、测试人员、、开发人员、项目管理者、其他质量管理人员和需要阅读本报告的高层经理。
1.2.项目背景
伴随着数字化和网络化的进程,智能化的浪潮席卷了世界的每一个角落,成为一种势
不可挡的历史化大趋势。
这一切的最终目的为人们提供一个以人为本的舒适、便捷、高效、
安全的生活环境。
如何建立一个高效率、低成本的智能家居系统已成为当今世界的一个热点
问题。
虽然目前智能家居系统有了一定的发展,并且市场上也开始出现相应的产品,但从总体的发展来看,不容乐观,现有的智能家居系统一般功能单一,提供的服务智能化不足,难以满足当今科技高速发展所引起的人们追求高品质生活的热情。
基于以上背景,本次项目提出的智能家居方案,旨在实现一个应用可扩展的智能家居系统。
并且在系统中充分融合现有的物联网方面的软硬件技术,最终完成一个处理流程合理、智能的家居系统。
1.3.用户群
1.主要读者:
项目管理人员,项目测试经理,业主相关人员;
2.其他读者:
项目其他相关人员
1.4.基本定义
一.严重bug:
出现以下缺陷,测试定义为严重bug:
1.系统无响应,处于死机状态,需要其他人工修复系统才可复原。
2.点击某个菜单后返回异常错误。
3.进行某个操作(增加、修改、删除等)后,返回异常错误。
4.当对必填字段进行校验时,未输入必输字段,返回异常错误。
5.系统定义不能重复的字段输入重复数据后,返回异常错误。
二.系统测试过程中有如下错误即为重要BUG:
1.系统兼容性差,与其他系统一起工作时不能正常运行或影响其他系统设备运行。
2. 密码明文显示。
3.程序在一些显示上不美观,不符合用户操作习惯或一些文字错误。
4.界面不规范。
5. 辅助说明描述不清楚
6.输入输出不规范。
7.可输入区域和只读区域无明显区分标志。
8.提示窗口文字未采用行业术语。
9.系统页面不必要的刷新、数据回发。
10.必要操作无任何操作提示或操作指引。
11.功能操作不连贯,按钮安放杂乱。
1.5.测试对象
结合本项目的特殊性,整个系统主要分文软件部分和硬件部分,而根据软件定义,软件包括程序、数据和文档,硬件也需要测试硬件的功能已经硬件的可靠性,所以测试并不仅仅是软件测试。
测试应贯穿于整个系统生命周期中。
在整个系统生命周期中,各阶段有不同的测试对象,形成了不同开发阶段的不同类型的测试。
需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档,包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序,都应成为“软件测试”的对象。
在软件编码结束后,对编写的每一个程序模块进行测试,称为“模块测试”或“单元测试”;在模块集成后,对集成在一起的模块组件,有时也可称为“部件”,进行测试,称为“集成测试”;在集成测试后,需要检测与证实软件是否满足软件需求说明书中规定的要求,这就称为“确认测试”。
将整个程序模块集成为软件系统,安装在运行环境下,对硬件、网络、操作系统及支撑平台构成的整体系统进行测试,称为“系统测试”。
为了把握各个环节的正确性,需要进行各种验证和确认工作。
验证是保证软件正确实现特定功能的一系列活动和过程,目的是保证软件生命周期中的每一个阶段的成果满足上一个阶段所设定的目标。
确认是保证软件满足用户需求的一系列的活动和过程,目的是在软件开发完成后保证软件与用户需求相符合。
验证与确认都属于软件测试,它包括对软件分析、设计以及程序的验证和确认。
在测试过程中,我们将充分考虑以上表述的相关对象,有针对性的加强一些内容的参考,保证做到一个全面、完整的测试。
1.6.测试阶段
阶段
内容
开始日期
结束日期
负责人
阶段一
模块测试
阶段二
功能测试
阶段三
安全测试
阶段四
压力测试
1.7.术语和缩写词
●在本文件中出现的“系统”一词,除非特别说明,均指“智能厨房系统”。
●MTBF:
平均无故障时间。
●MTTR:
平均维修时间。
●SMS(ShortMessageService):
短消息业务。
●结构化查询语言:
是关系数据库中使用的标准数据查询语言。
●系统:
子系统的集合。
●子系统:
模块的集合。
●模块:
功能的集合。
●功能:
处理任务的最小单元。
●系统参数:
控制系统的行为及流程的参数,内容存贮在系统数据库中,一般只由系统管理员维护。
●用户参数:
控制各工作站的界面、输入法等参数,内容存贮在各工作站软件安装目录下,用户可以修改。
●运行参数:
控制程序的启动以及与数据库的连接等,内容存贮在Windows系统的注册表中,第一次使用程序时系统会自动提示输入各种参数。
●角色:
一组具有相同权限的用户集合。
●权限:
执行某个功能,或操作某个模块、某个子系统的钥匙。
●用户:
操作系统的人。
1.8.参考资料
1.《中华人民共和国标准化法》
2.《信息技术软件包质量要求和测试》(GB/T17544-1998)
3.《信息技术软件产品评价质量特性及其使用指南》(GB/T16260-1996)
4.《软件工程产品评价》(GB/T18905-2002)
5.《软件产品管理办法》
6.《智能家居需求和设计说明书》
7.《智能家居祥细设计》
2.测试概要
测试开始日期
测试结束日期
测试天数
测试功能个数
执行测试用例数
BUG数
2.1.测试环境
2.1.1.软硬件配置
硬件环境应用服务器数据库服务器客户端
环境
应用服务器
数据库服务器
客户端
硬件配置
操作系统:
Windows7
处理器:
Corei3M380@2.53GHz
内存:
4GB
操作系统:
Windows7
处理器:
Corei3M380@2.53GHz
内存:
4GB
操作系统:
Windows7
处理器:
Corei3M380@2.53GHz
内存:
4GB
软件配置
新浪云平台
MYSQL5.6
Chrome,firefox
网络配置
10MLAN
10MLAN
10MLAN
2.1.2.网络拓扑图
图1测试网络拓扑图
服务器和数据库是架构在新浪云平台上,其中PC1和PC2是普通的上网终端,而智能家居是指部署了本系统的家庭用户。
2.2.测试计划
版本/时间计划开始实际开始计划完成实际完成加班增加资源:
版本/时间
计划开始时间
实际开始时间
计划结束时间
实际结束时间
加班
增加资源
B1
2013.6.25
2013.7.3
2013.6.30
2013.7.5
是
否
B2
2013.6.26
2013.7.4
2013.6.30
2013.7.6
否
否
计划任务祥细分解情况表:
任务
开始时间
结束时间
总计(天)
物品管理
2013-7-3
2013-7-3
0.5
web服务器
2013-7-3
2013-7-4
1
控制管理
2013-7-4
2013-7-5
0.5
流程管理
2013-7-5
2013-7-6
1
2.3.测试执行
此次测试严格按项目计划和测试计划执行,按时完成了测试计划规定的测试对象的测试。
针对测试计划规定的测试策略,在测试执行中都有体现,在测试执行过程中,依据测试计划和测试用例,对系统进行了完整的测试。
2.4.测试用例
2.4.1.功能性
◆系统实现的主要功能,包括食品管理,菜单管理,web服务,控制管理
◆系统实现的次要功能,包括菜单管理,界面响应,界面可靠性
◆需求规定的输入输出字段,以及需求规定的输入限制
◆
2.4.2.易用性
◆操作按钮提示信息正确性,一致性,可理解性。
◆限制条件提示信息正确性,一致性,可理解性。
◆必填项标识。
◆输入方式可理解性。
2.5.版本定义
给出测试版本,分为三个主要版本:
0字头为初稿,定好文档格式和测试方向和测试组织机构人员。
1.0版本完成全部功能测试,未经正式发布,未经审核;
2.0版整合所有测试人员的测试文档,完成所有测试,几经修改,经过测试经理,项目经理审核,达到正式发布的要求。
其中小数点后面的数字为修正了其中内容达到3个模块以上时相应增加0.1。
2.6.覆盖分析
2.6.1.需求覆盖
需求覆盖率是指经过测试的需求/功能和需求规格说明书中所有需求/功能的比值,通常情况下要达到100%的目标。
需求/功能
测试类型
是否通过
备注
物品管理
功能测试、业务测试
Y
web服务器
功能测试、业务测试
Y
控制管理
功能测试、业务测试
Y
流程管理
功能测试、业务测试
Y
表格中“是否通过”的四种状态:
[Y]:
全部通过
[P]:
部分通过
[N]:
不通过
[N/A]:
不可测试或者用例不适用
2.6.2.测试覆盖
需求/功能
用例个数
执行总数
未执行
物品管理
5
5
0
web服务器
5
5
0
控制管理
5
5
0
流程管理
5
4
1
3.测试用例
3.1.功能测试
测试编号
A001
模块名称
物品管理
建立日期
2013-7-3
建立人员
曾夏
修改日期
状态
[]草稿[]正在修改[√]正式发布
定义
物品管理模块能准确可靠的管理物品进出冰箱,并且提供物品管理人机交互界面。
用例
向冰箱上格加入带有“一斤猪肉”的信息RFID标签的物品
预期情况
1
本地能列出物品已进入冰箱上格
2
Web客户端可以在web服务器上查询新入库的物品
3
新进入的物品能参与菜单决策
4
实际结果
与预期结果一致
结论
功能测试通过。
测试编号
A002
模块名称
物品管理
建立日期
2013-7-3
建立人员
杨琪
修改日期
状态
[]草稿[]正在修改[√]正式发布
定义
物品管理模块能准确可靠的管理物品进出冰箱,并且提供物品管理人机交互界面。
用例
向冰箱上格拿出带有“一斤猪肉”的信息RFID标签的物品
预期情况
1
本地能列出物品已离开冰箱上格
2
Web客户端不会再显示着“一斤猪肉”的信息
3
“一斤猪肉”不会参与菜单生成
4
实际结果
与预期结果一样
结论
通过
测试编号
A003
模块名称
web服务器
建立日期
2013-7-3
建立人员
王为峰
修改日期
状态
[]草稿[]正在修改[√]正式发布
定义
Web服务器同时也包括了数据库,因此需要重点测试web服务器的数据管理,以及准确的页面显示
用例
上传“红烧猪肉”的菜谱,上传符合菜谱的物品,点击菜单
预期情况
1
能刷新出新上传的菜谱“红烧猪肉”
2
点击新菜谱名称,能显示新菜谱需要的物品列表
3
点击“演示菜谱”能演示菜谱的制作过程
4
实际结果
与预期结果一样
结论
通过
测试编号
A004
模块名称
Web服务器
建立日期
2013-7-4
建立人员
李雄耀
修改日期
状态
[]草稿[]正在修改[√]正式发布
定义
Web服务器同时也包括了数据库,因此需要重点测试web服务器的数据管理,以及准确的页面显示。
用例
删除“红烧猪肉”的菜谱,上传“红烧猪肉”菜谱的所有物品
预期情况
1
点击菜单不能刷新出“红烧猪肉”菜谱
2
3
4
实际结果
与预期结果一样
结论
通过
测试编号
A005
模块名称
控制管理
建立日期
2013-7-4
建立人员
王浩然
修改日期
状态
[]草稿[]正在修改[√]正式发布
定义
控制模块主要是要保证控制管理在接收正确指令串之后可以执行正确的命令。
用例
向控制模块发送转义的命令串
预期情况
1
单片机能够响应命令串
2
单片机能够按照顺序执行命令串
3
命令串执行完之后,单片机能够停止执行
4
实际结果
与预期结果一样
结论
通过
3.2.性能测试
1
测试对象介绍
2
测试范围与目的
3
测试环境与测试工具描述
4
测试驱动程序的设计
5
性能测试用例列表
性能A描述
用例目的
前提条件
输入数据
期望性能(平均值)
实际性能(平均值)
性能B描述
用例目的
前提条件
输入数据
期望性能(平均值)
实际性能(平均值)
3.3.压力测试
由于本系统规模比较小,压力测试嵌入在性能测试。
4.测试结果
4.1.Bug趋势图
4.2.Bug严重程度
测试发现的bug主要集中在控制模块和web服务器模块,属于一般性的缺陷,但是测试的时候,出现了几个个严重级别的bug,出现严重级别的bug主要表现在以下几个方面。
系统主要功能没有实现
1.重复添加输入命令串之后,出现命令中断执行的现象
2.多语言处理,未考虑非语种代码的情况
3.数据库设计未考虑系统管理员角色,导致用系统管理员进行操作的时候出现找不到页面错误
4.权限控制异常
严重级别bug按版本分布如下:
由严重bug版本分布图可以看出,严重级别的bug版本趋势和bug版本趋势基本是一致的,但是,在B7和B9版本中年,严重级别的bug明显增多,主要原因是B7和B9版本测试了权限控制按钮功能,权限问题出现的严重级别的bug比较多。
5.测试结论
4.1.功能性
Web服务器基本实现了需求分析的功能,就是菜谱演示只能定时演示动作。
控制模块也基本实现需求分析的功能,有一个小bug是命令串不能连续输入,否则将会打断先前的命令串,但是不会影响系统运行。
食品管理模块完美实现所有功能。
4.2.易用性
现有系统实现了如下易用性:
1.查询,添加,删除,修改操作相关提示信息的一致性,可理解性
2.输入限制的正确性
3.输入限制提示信息的正确性,可理解性,一致性
4.
现有系统存在如下易用性缺陷:
1.界面排版不美观
2.输入,输出字段的可理解性差
3.输入缺少解释性说明
4.中英文对应的正确性
5.中英文混排
6.菜谱文件需要utf-8编码方式
7.
4.3.可靠性
现有系统的可靠性控制不够严密,很多控制是通过页面控制实现的,如果页面控制失效,可以向数据库插入数据,引发错误。
现有系统的容错性不高,如果系统出现错误,返回错误类型为找不到页面错误,无法回复到出错前的状态。
4.4.兼容性
现有系统未进行其他兼容性测试
4.5.安全性
现有系统控制了以下安全性问题:
1.把某一个登录后的页面保存下来,不能单独对其进行操作不进行登录
2.直接输入某一页面的Url能否打开页面并进行操作不应该允许。
5.1.建议
在项目开始的时候应该制定码标准,数据库标准,需求变更标准,开发和测试人员都严格按标准进行,可以在后期减少因为开发,测试不一致而导致的问题,有时也可以降低沟通成本。
发布版本的时候,正确布置测试环境,减少因为测试环境,测试数据库数据的问题而出现的无效bug。
开发人员解决bug的时候,填写bug原因以及解决方式,方便bug的跟踪。
开发人员在开发版本上发现bug,可以通知测试人员,因为开发人员发现的bug很有可能在测试版本上出现,而测试人员和开发人员的思路不,有可能测试人员没有发现该bug,而且,这样可以保证发现的bug都能够被跟踪。
6.典型缺陷引入原因分析
测试过程中发现的缺陷主要有以下几个方面:
6.1.需求定义不明确
需求文档中,存在功能定义错误,输入输出字段描述错误,输入输出字段限制定义错误,输入输出限制定义缺失这几种类型的缺陷。
使得开发人员根据需求进行设计时,没有考虑相关功能的关联性,以及需求错误的地方,在测试过程中,需求相关的问题表现出来。
需求做改正,设计必须跟着做改动,浪费时间和影响开发人员的积性,降低开发人员对需求的信任,可能会导致开发人员不按需求进行设计而根据自己的经验来进行设计。
6.2.功能性错误
1、功能没有实现,导致无法进行需求规定的功能的测试。
主要是无法进入设施管理,会议室管理页面,安全项管理无法保存信息,地区,房型删除功能缺失。
2、功能实现错误,实现了需求未定义的功能,执行需求定义的功能时系统出现错误。
主要是角色拥有不属于自己的权限,联系人删除页面跳转错误等。
3、页面设计和需求不一致。
面设计没有根据需求进行,输入,输出字段文字错误,用户无法理解字段含义。
页面设计没有完成需求规定的输入限制验证,导致用户可以输入错误的或者无效的数据,这些数据有可能会引起功能性错误。
6.3.界面设计易用性缺陷
1、界面设计不友好,系统中很多页面的输入字段无明确的输入提示,用户无法理解何种输入是正确的,但是用户输入错误后,系统提示出错,增加用户负担。
2、提示信息错误,不模块相结果的提示信息不一致,用户操作后,相应的提示信息不明确,引起用户误解。
3、提示信息一致性,用户在不同界面执行相的操作,提示信息不全。
4、
6.4.开发人员疏忽引起的缺陷
因为开发人员的疏忽,导致系统需要验证的地方,调用了错误的验证,系统需要进行输入控制的地方没有进行相应的控制。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 智能 厨房 系统 测试报告 模板