ImageVerifierCode 换一换
格式:DOCX , 页数:24 ,大小:91.52KB ,
资源ID:8412759      下载积分:3 金币
快捷下载
登录下载
邮箱/手机:
温馨提示:
快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。 如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝    微信支付   
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【https://www.bdocx.com/down/8412759.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录   QQ登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(超市收银系统测试计划.docx)为本站会员(b****6)主动上传,冰豆网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知冰豆网(发送邮件至service@bdocx.com或直接QQ联系客服),我们立即给予删除!

超市收银系统测试计划.docx

1、超市收银系统测试计划 超市收银系统测试计划 : 润 学号: 12740125 班级: 软件工程(1)班 指导老师: 路飞 1.引言1.1编写目的本测试计划主要用于控制整个超市收银系统项目测试,本文档主要实现以下目标:(1)通过此测试计划能够控制整个测试项目合理、全面、准确、协调地完成。(2)为软件测试提供依据:(3)项目管理人员根据此计划,可以对项目进行宏观调控。(4)测试人员根据此计划,能够明确自己的权利、职责,准确地定位自己在项目的任务。(5)相关部门,可以根据此计划,对相关资源进行准备。1.2背景本测试计划实现超市收银系统的测试。(1)项目任务的提出者为:各个超市; (2)系统的开发者为

2、:润; (3)系统的使用者为:各个超市;此测试项目的进行,将在需求确认后开始执行,基准是准确、全面的需求文档。测试重点是对开发实现的功能和性能进行测试。1.3定义无1.4测试目标该测试项目将通过设计和执行接受测试、界面测试、功能测试和性能测试,对软件实现的功能,以及软件的性能、兼容性、安全性、实用性、可靠性、扩展性各个方面进行全面系统的测试。基于本系统的业务复杂性和开发周期短的特性,系统测试的重点将放在功能测试和性能测试上。通过测试提高软件的质量,为用户提供最好的服务,并合理地避免软件的风险和减少软件的成本。2.计划2.1测试过程在项目开发确定好之后就开始进行测试计划的设计,伴随项目的结束而结

3、束,整个过程是一个连贯的互相协调进行的。具体流程如图2.1所示:图2.1 系统测试过程2.2进度安排及里程碑给出进行各项测试的日期和工作容(如熟悉环境、培训、准备输入数据、实施测试等),具体安排如下表2.1所示。表2.1 进度安排表里程碑任务工作开始日期结束日期制定测试计划润第一周周一周二设计测试严念慈周二周五实施测试润第二周周一周三对测试进行评估润、严念慈周三周五2.3角色任何项目的实施首先要考虑的是人的因素,对人的识别与确认,软件测试尤其不能例外。在软件测试常会把所有涉及人员进行分类以确立角色,并按角色进行职责划分。具体划分如下表2.2所示:表2.2 角色职责划分情况测试人员安排负责人:润

4、其他负责人职责联系信息职责:负责制定测试计划、编写和验收用例,完成项目实测,编写测试报告。测 试 组 成 员姓 名职 责联系信息严念慈负责功能测试用例的编写和实施润负责性能和其他非功能测试用例的编写和实施2.4 系统测试项目所需的系统资源如表2.3所示:表2.3 系统资源信息系统资源资源名称、类型数据库服务器MySql网络或子网服务器名称数据库名称chaoshi客户端测试PCWindows特殊配置需求测试存储库Bugs 硬件环境Intel Core(TM) CPU 2.0GHz;存4GB2.5可交付工件测试计划:一份测试用例:一份测试缺陷记录:一份测试报告:一份2.5.1测试模型超市收银系统1

5、.02.5.2测试记录采用测试用例的形式提交测试过程,详见测试用例文档。2.5.3缺陷报告采用缺陷记录的形式,详见测试缺陷记录文档。2.6测试资料测试文档:测试相关模块。需求文档:项目需求文档2.7项目风险分析从质量风险维度来看,软件测试可以被定义为“对软件系统中潜在的各种风险进行评估的活动”。软件测试自身的风险性是公认的,测试的覆盖度不能做到100%。测试的这种风险定义一方面源于这层含义,另外软件测试的标准有时不清楚,所以常常强调软件测试人员应该站在客户的角度去进行测试,除了发现程序中的错误,还要发现需求定义的错误、设计上的缺陷,可以针对产品的spec去报Bug。具体的风险分析如下表2.4所

6、示:表2.4 项目风险分析风险类型风险综述在确保质量的前提下人力资源与项目周期比列失调,因此人员不到位将存在项目风险。增加人员在不同环境下运行存在风险使用统一的环境资源进行测试进度存在风险实际进度按照开发进度进行,当实际开发进度变更时将按照实际发进度及时调整测试进度客户需求发生变更常与客户进行沟通,达成一致协议人员变动风险通过培训等措施使变更后的人员了解统的业务流程,对系统深入了解,以求在最大限度保证测试质量数据库测试中存在的风险因测试周期的限制,因此根据实际情况选择的测试策略存在的风险情况反应给客户,与客户商议达成一致版本部署风险版本在部署的时候,可能会由于数据库的导入错误等原因导致系统出错

7、。因此在实际给客户部署时同样存在此种风险。3 测试设计说明3.1概述3.1.1测试方法和测试用例选取的原则系统:根据系统需求说明书对系统进行单元测试、集成测试、系统测试、验收测试、性能测试,并结合可能的用户测试。全面:要求测试用例能够覆盖每一个测试点的要点。合理:从可行性角度考虑,测试不可能全面覆盖,所以设置好等价类划分,测试的用例的选择避免重复测试、选择最好的测试方法将测试点合理覆盖。3.1.2测试的控制方式测试用例的实现必须遵守测试计划的安排,实际测试必须以测试用例为基准。实际测试中测试用例的状态记载: (1)failed:如果某一步测试用例失败,不影响以后测试用例处理 (2)block:

8、如果某一步测试用例失败,并影响以后测试用例处理 (3)good:测试成功实际测试与外部交互使用缺陷记录清单进行交流。测试人员必须详细、准确填写缺陷记录容,开发修改人员要详细、准确地填写修改情况,通过缺陷记录清单的状态进行测试和修改交互。(1)open:当开始一个问题报告单时,为open 开发返回后,错误仍存在为 re-open(2)fixed / return 开发人员对错误进行了修改,为fixed 开发人员对错误没有进行修改,返回测试部为return(3)close/ cancel 测试人员确认错误已经修改,为close 测试人员确认错误的无效或可以接受(标记)为cancel测试版本的控制由

9、项目开发组随版本发布时提交版本提交单,测试组完成测试后提交版本测试报告,版本更新时由开发组填写更新记录。测试用例的命名原则: 测试点-编号 例如:CHS-01 缺陷记录清单命名原则 缺陷记录清单+_测试人员名称+_日期 例如:缺陷记录清单_润_201506253.1.3数据选择策略数据的选择全面覆盖所有数据、并要求避免冗余数据的使用(采用边界值、特殊值、以及普通值)。3.1.4测试过程描述和操作步骤1.测试过程描述(1)书写测试计划(2)参考测试计划、需求、概要设计以及部分详细设计文档进行用例设计(3)参考测试计划和测试用例进行实际测试操作(4)测试总结和报告2.操作步骤(1)测试基本流程(简

10、易的IVT)(2)测试功能块(重点为容错测试)(3)统计信息的测试(IVT)3.2软件说明超市收银系统主要涵盖管理员、库存管理员、售货员三种角色登录,实现功能主要有:用户管理、商品管理、库存管理、商品销售,详见需求规格说明书。3.3测试容及策略本测试将通过用户界面测试、集成测试,系统测试、验收测试、性能测试、负载测试、强度测试、容量测试、安全性和访问控制测试、故障转移和恢复测试、配置测试、安装测试方面对系统进行测试。用户界面测试用于核实用户与软件之间的交互,测试用户界面的正确性和易用性。3.3.1用户界面及易用性测试目的: 确保用户界面通过测试对象的功能来为用户提供相应的访问或浏览功能;另外,

11、UI测试还可以确保UI中的对象按照预期的方式运行,并符合公司或行业的标准。容: 对系统的功能页面进行各种可操作性测试。重点: 容错检测,易用性。3.3.2集成测试目的: 检测系统是否达到需求,对业务流程及数据流的处理是否符合标准,检测系统对业务流处理是否存在逻辑不严谨及错误,检测需否存在不合理的标准和要求。容:利用有效的和无效的数据来执行各个用例,用例流或功能,以核实在使用有效数据时得到的预期结果,在使用无效数据时显示相应的错误消息或警告消息,个业务规则都得到了正确的应用。重点:测试的单元模块之间的接口和调用是否正确,集成后是否实现了某个功能。3.3.3系统测试目的:将软件整合为一体,看各个功

12、能是否全部实现。容:将整个软件系统看做一个整体进行测试,测试功能是否能满足需求,是否全部实现,后期主要包括看系统运行的性能是否满足需求,以及系统在不同的软硬件环境中的兼容性等。重点:系统在配置好的环境中是否可以正常运行。3.3.4压力测试目的:了解(被测应用程序)一般能够承受的压力,同时能够承受的用户访问量(容量),最多支持有多少用户同时访问某个功能。容:(1)因为事先我们不知道将有多少用户访问是临界点,所以在测试过程中需要多次改变用户数来确定,(2)计划的设置,每x时间后加载10用户(根据总用户数设置),完全加载后持续运行不超过5分钟(根据需要设置)。(3)当运行中的用户数100%达到集合点

13、时释放。重点:找到系统的临界值点3.3.5功能测试目的:功能测试就是对系统的各功能进行验证,根据功能测试用例,逐项测试,检查产品是否达到用户要求的功能。容:(1)页面检查:每一个是否都有对应的页面,并且页面之间切换正确。 (2) 相关性检查:删除/增加一项会不会对其他项产生影响,如果产生影响,这些影响是否都正确。 (3)检查按钮的功能是否正确:如update, cancel, delete, save等功能是否正确。 (4)字符串长度检查: 输入超出需求所说明的字符串长度的容, 看系统是否检查字符串长度,会不会出错. (5)字符类型检查: 在应该输入指定类型的容的地方输入其他类型的容(如在应该

14、输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错. (6)标点符号检查: 输入容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确. (7)中文字符处理: 在可以输入中文的系统输入中文,看会否出现乱码或出错. (8)检查带出信息的完整性: 在查看信息和update信息时,查看所填写的信息是不是全部带出.,带出信息和添加的是否一致 (9)信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入容的前后输入空格,系统是否作出正确处理. (10)检查删除功能:在一些可以一次删除多个信息的地方

15、,不选择任何信息,按”delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除,看是否正确处理.(11) 检查添加和修改是否一致: 检查添加和修改信息的要否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型. (12)检查修改重名:修改时把不能重名的项改为已存在的容,看会否处理,报错.同时,也要注意,会不会报和自己重名的错. (13)重复提交表单:一条已经成功提交的纪录,back后再提交,看看系统是否做了处理。(14)检查多次使用back键的情况: 在有back的地方,back,回到原来页面,再back,重复多次,看会否出错. (15)searc

16、h检查: 在有search功能的地方输入系统存在和不存在的容,看search结果是否正确.如果可以输入多个search条件,可以同时添加合理和不合理的条件,看系统处理是否正确. (16)输入信息位置: 注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方. (17)上传下载文件检查:上传下载文件的功能是否实现,上传文件是否能打开。对上传文件的格式有何规定,系统是否有解释信息,并检查系统是否能够做到。 (18)必填项检查:应该填写的项没有填写时系统是否都做了处理,对必填项是否有提示信息,如在必填项前加* (19) 快捷键检查:是否支持常用快捷键,如Ctrl+C Ctrl+V Bac

17、kspace等,对一些不允许输入信息的字段,如选人,选日期对快捷方式是否也做了限制。 (20)回车键检查: 在输入结束后直接按回车键,看系统处理如何,会否报错。重点:确保各项功能和用需求一致3.3.6性能测试目的:核实性能是否满足用户需求,将测试对象的性能行为当做条件的一种函数来进行评测和微调。容:负载测试、强度测试。(1)单个事务单个用户时候,在每个事务所语气时间围成功完成测试脚本,没有发生任何故障;多个事务多个用户时,可完成脚本没有发生故障的情况临界值。(2)使测试系统承担不同的工作量,得出系统持续正常运行的能力。(3)找出因资源不足或资源争用导致的错误。重点:确保性能指标满足用户需求。3

18、.3.7容量测试目的:所计划的测试全部执行,而且达到或超出指定的系统限制时没有出现任何软件故障。容:在客户机长时间执行相同的、最坏的业务时候系统维持的时间。重点:核实系统能否在连续或模拟了最多数量的客户机下正常运行。3.3.8安全性和访问控制测试目的:保证只有访问权限的用户才能访问系统,核实用户以不同身份登录有不同的访问权限。容:数据或业务功能访问的安全性,包括系统登录或远程访问。重点:确保治具备系统访问权限的用户才能访问应用程序,而且只能通过相应的网关来访问。3.3.9故障转移和恢复测试目的:检测系统可否在意外数据损失、数据完整性破坏、各种硬件、软件、网络故障中恢复数据。容:(1)客户机断电

19、、服务器断电看事务可否发生回滚。(2)网络服务器中断。重点:看数据库的恢复情况,以及系统在经历意外时间时候是否会发生崩溃现象。3.3.10配置测试目的:核实是否可以在所需的硬件和软件配置中正常运行。容:核实该系统在不同系统、不同软件和硬件配置中的运行情况。重点:软硬件配置不同时候对系统的影响。3.3.11安装测试目的:此1.0版本重点在于检查系统首次安装可否正常运行。容:启动或执行安装,使用预先确定的功能测试脚本子集来运行事务。重点:异常情况处理:如磁盘空间不足、缺少目录创建权限等;核实软件安装后可否正常运行。3.3.12验收测试目的:对整个系统,包括软硬件,试运行,看一下是否全部功能能够实现

20、。容:由软件测试工程师、用户等根据需求规格说明书对整个系统进行试运行,看是否能满足全部功能。重点:在可移植环境中、并发访问环境中系统是否可以正常运行。3.4测试用例围3.4.1 功能测试测试的重点将主要放在功能测试上,按照三种角色:管理员、库存管理员、售货员,每种角色包括如下模块:1.管理员管理员的具体功能模块和测试项如下表4.1所示:表4.1 管理员功能测试模块编号测试项登录1以管理员身份登录,登录成功则跳转电子商务管理主界面2用户账号被屏蔽,无法登录成功3输入非法标识符,提示输入错误字符4输入用户名错误,提示用户不存在5输入密码错误,提示密码错误用户管理1可设置每个用户的开启或屏蔽权限,进

21、行开启用户或删除用户2单击角色修改按钮,进入角色修改页面,点选角色,修改成功,跳转登录界面3对用户信息进行修改,输入已注册用户新信息,提交后跳转到登录界面4被管理员屏蔽或删除的用户,无法进行设置,提示重新激活账号商品管理1单击商品管理按钮,进入商品列表页面2可以添加商品信息,对添加商品信息进行简单输入信息验证,若输入非法标识符则指明错误;添加后跳转到商品列表界面3可以修改商品信息,对商品修改信息进行简单输入信息验证,若输入非法标识符则指明错误;添加后跳转到商品列表界面4可以删除商品信息,提示是否删除?确认删除后跳转到商品列表界面2若想修改,可以填写发件和收件地址、密码,提交后返回管理界面3键入

22、非法标识符,指明输入错误2.库存管理员库存管理员的功能模块和测试项如下表4.2所示:表4.2 库存管理员功能测试模块遍号测试项注册1用户单击登录入口的注册,输入相关注册信息,单击注册按钮,验证用户信息,核实无误则跳转登陆成功提示页面2用户单击登录入口的注册,若输入非法标识符,则需要弹出指明错误的警示框登录1以普通用户身份登录,登录成功则跳转电子商务管理主界面2用户账号被屏蔽,无法登录成功3输入非法标识符,提示输入错误字符4输入用户名错误,提示用户不存在5输入密码错误,提示密码错误商品入库1登录成功,单击浏览产品页,可以浏览产品2登录成功,单击查询商品浏览产品,可以查询特定商品3查询商品时如果合

23、法输入且没有该商品,需弹出无商品的提示框4查询商品时如果输入合法标识符,则弹出提示框指明错误3.销售管理员库存管理员的功能模块和测试项如下表4.3所示:表4.3 销售管理员功能测试模块遍号测试项注册1用户单击登录入口的注册,输入相关注册信息,单击注册按钮,验证用户信息,核实无误则跳转登陆成功提示页面2用户单击登录入口的注册,若输入非法标识符,则需要弹出指明错误的警示框登录1以普通用户身份登录,登录成功则跳转电子商务管理主界面2用户账号被屏蔽,无法登录成功3输入非法标识符,提示输入错误字符4输入用户名错误,提示用户不存在5输入密码错误,提示密码错误商品销售1登录成功,单击浏览产品页,可以浏览产品

24、2登录成功,单击查询商品浏览产品,可以查询特定商品3查询商品时如果合法输入且没有该商品,需弹出无商品的提示框4查询商品时如果输入合法标识符,则弹出提示框指明错误5商品成功搜索到后点击结账,自动弹出结账的相关信息3.5评价3.5.1围要求:1.功能测试涵盖测试全过程。2.界面测试涵盖测试全过程。3.逻辑测试测试路径的涵盖率为85%以上。3.5.2准则测试参数结果判定准则(1)完全通过:其对应测试用例通过率达到100(2)基本通过:其对应的测试用例通过率达到70及其以上,并且不存在非常严重和严重的缺陷(3)不通过:其对应的测试用例通过率未达到70%,或者存在非常严重和严重的缺陷测试入口出口准则1)

25、测试进入准则以下条件为进入测试的基本条件:(1)开发部/开发人员应提供软件说明书、详细需求或系统设计等必要文档;(2)被测样品,己通过无病毒检测;(3)被测样品,已通过单元测试(可选);(4)被测样品,已通过冒烟测试;(5)测试环境(场地、网络、硬件、软件等)已全部准备完备。2)测试暂停和再启动准则测试暂停标准:(1)测试环境发生变化(场地、网络、硬件、软件等),又处于不可使用状态;(2)被测样品有大量错误或严重错误,以至于继续测试没有任何意义(3)测试再启动标准:(4)错误得到修改后,需要重新启动测试(5)开发组提供错误修改后的安装程序以及再启动测试的相关说明(6)测试组安装修改后的程序。如

26、有必要,需要重新初始化测试数据,重新执行测试规程,恢复到发生错误前的状态。3)测试退出的准则测试结论达到完全通过、基本通过或不通过的标准时,测试可以退出4超市收银系统覆盖率测试4.1 逻辑覆盖测试逻辑覆盖测试主要是针对程序的部逻辑结构设计测试用例的技术,它通过运行测试用例达到逻辑覆盖的目的。包括以下3种类型的逻辑覆盖:(1)语句覆盖(2)判定覆盖(3)条件覆盖try if (myread.HasRows) if (myread.Read() /MessageBox.Show(登录成功); if (myreadUserID.ToString() = tbxUsr.Text & myreadUse

27、rPassword.ToString() = tbxPwr.Text & myreadUserRight.ToString() = 管理员) user = username; Form8 f3; f3 = new Form8(); f3.Show(); else if (myreadUserID.ToString() = tbxUsr.Text & myreadUserPassword.ToString() = tbxPwr.Text & myreadUserRight.ToString() = 员工) user = username; Form2 f2; f2 = new Form2();

28、f2.Show(); else MessageBox.Show(Please enter the correct user name and password!); catch (Exception ex) MessageBox.Show(string.Format(出错,出错原因0), ex.Message); finally connection.Close(); connection.Dispose(); mycmd.Dispose(); 程序流程图如下图4.1所示: 入口 myread.HasRows!=null N Y 语句块1 N myread.Read()容是 否匹配 Y 语句块

29、2 出口 图4.1 程序流程图4.2 语句覆盖语句覆盖就是设计若干个测试用例,运行被测试程序,使得每一条可执行的语句至少执行一次。根据概念,为了对上面的函数进行语句覆盖,只要设计一个测试用例就可以覆盖2个执行语句块中的语句。针对程序的判断语句,可在入口处设计测试用例。测试用例输入为:myread.HasRows!=null如果程序只运行上面的测试用例,虽然可以执行模块中的所有语句,但并不能检查判断逻辑是否有问题。例如在第一个判断中错误地把=写成!=,则上面的测试用例仍可以覆盖所有的执行语句。可以说语句覆盖率是最弱的逻辑覆盖准则。4.3 判定覆盖判定覆盖(也称为分支覆盖),设计若干个测试用例,运行所测程序,使程序中每个判断的取真分支和取假分支至少各执行一次。根据上面的定义,对于上面的程序,只要设计两个测试用例则可以满足条件覆盖的要求。测试用例的输入为:myread.HasRows!=null myread.Read()的容是

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1