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

《超市收银系统》测试计划

姓名： 张润
学号： 12740125
班级： 软件工程(1)班
指导老师： 路飞

目 录
1.引言 4
1.1编写目的 4
1.2背景 4
1.3定义 4
1.4测试目的 4
2.计划 5
2.1测试过程 5
2.2进度安排及里程碑 5
2.3角色 6
2.4 系统 7
2.5可交付工件 7
2.5.1测试模型 7
2.5.2测试记录 7
2.5.3缺陷报告 7
2.6测试资料 7
2.7项目风险分析 8
3 测试设计说明 9
3.1概述 9
3.1.1测试方法和测试用例选取的原则 9
3.1.2测试的控制方式 9
3.1.3数据选择策略 10
3.1.4测试过程描述和操作环节 10
3.2软件说明 10
3.3测试内容及策略 10
3.3.1用户界面及易用性测试 10
3.3.2集成测试 11
3.3.3系统测试 11
3.3.4压力测试 11
3.3.5功能测试 11
3.3.6性能测试 13
3.3.7容量测试 13
3.3.8安全性和访问控制测试 13
3.3.9故障转移和恢复测试 14
3.3.10配置测试 14
3.3.11安装测试 14
3.3.12验收测试 14
3.4测试用例范围 14
3.4.1 功能测试 14
3.5评价 17
3.5.1范围 17
3.5.2准则 17
4超市收银系统覆盖率测试 18
4.1 逻辑覆盖测试 18
4.2 语句覆盖 21
4.3 鉴定覆盖 21
4.4 条件覆盖 21
5超市收银系统黑盒测试 22
5.1边界值测试 22
5.2 等价类划分 22
5.3 因果图法 23

1.引言
1.1编写目的
本测试计划重要用于控制整个超市收银系统项目测试，本文档重要实现以下目的：
(1)通过此测试计划可以控制整个测试项目合理、全面、准确、协调地完毕。
(2)为软件测试提供依据：
(3)项目管理人员根据此计划，可以对项目进行宏观调控。
(4)测试人员根据此计划，可以明确自己的权利、职责，准确地定位自己在项目的任务。
(5)相关部门，可以根据此计划，对相关资源进行准备。
1.2背景
本测试计划实现超市收银系统的测试。
(1)项目任务的提出者为：各个超市；
(2)系统的开发者为：张润；
(3)系统的使用者为：各个超市；
此测试项目的进行，将在需求确认后开始执行，基准是准确、全面的需求文档。测试重点是对开发实现的功能和性能进行测试。
1.3定义
无
1.4测试目的
该测试项目将通过设计和执行接受测试、界面测试、功能测试和性能测试，对软件实现的功能，以及软件的性能、兼容性、安全性、实用性、可靠性、扩展性各个方面进行全面系统的测试。基于本系统的业务复杂性和开发周期短的特性，系统测试的重点将放在功能测试和性能测试上。通过测试提高软件的质量，为用户提供最佳的服务，并合理地避免软件的风险和减少软件的成本。

2.计划
2.1测试过程
在项目开发拟定好之后就开始进行测试计划的设计，随着项目的
结束而结束，整个过程是一个连贯的互相协调进行的。具体流程如图2.1所示：
图2.1 系统测试过程
2.2进度安排及里程碑
给出进行各项测试的日期和工作内容（如熟悉环境、培训、准备输入数据、实行测试等），具体安排如下表2.1所示。

表2.1 进度安排表
里程碑任务
工作
开始日期
结束日期
制定测试计划
张润
第一周周一
周二
设计测试
严念慈
周二
周五
实行测试
张润
第二周周一
周三
对测试进行评估
张润、严念慈
周三
周五
2.3角色
任何项目的实行一方面要考虑的是人的因素，对人的辨认与确认，软件测试特别不能例外。在软件测试中通常会把所有涉及人员进行分类以确立角色，并按角色进行职责划分。具体划分如下表2.2所示：
表2.2 角色职责划分情况

测
试
人
员
安
排

负责人：
张润
其他负责人
职责
联系信息
职责：负责制定测试计划、编写和验收用例，完毕项目实测，编写测试报告。

测 试 组 成 员
姓 名
职 责
联系信息
严念慈
负责功能测试用例的编写和实行

张润
负责性能和其他非功能测试用例的编写和实行

2.4 系统
测试项目所需的系统资源如表2.3所示：
表2.3 系统资源信息
系统资源
资源
名称、类型
数据库服务器
MySql
网络或子网

服务器名称

数据库名称
chaoshi
客户端测试PC
Windows
特殊配置需求

测试存储库
Bugs
硬件环境
Intel Core(TM) CPU 2.0GHz；内存4GB

2.5可交付工件
测试计划：一份
测试用例：一份
测试缺陷记录：一份
测试报告：一份
2.5.1测试模型
超市收银系统1.0
2.5.2测试记录
采用测试用例的形式提交测试过程，详见《测试用例》文档。
2.5.3缺陷报告
采用缺陷记录的形式，详见《测试缺陷记录》文档。
2.6测试资料
测试文档：测试相关模块。
需求文档：项目需求文档
2.7项目风险分析
从质量风险维度来看，软件测试可以被定义为“对软件系统中潜在的各种风险进行评估的活动”。软件测试自身的风险性是公认的，测试的覆盖度不能做到100%。测试的这种风险定义一方面源于这层含义，此外软件测试的标准有时不清楚，所以经常强调软件测试人员应当站在客户的角度去进行测试，除了发现程序中的错误，还要发现需求定义的错误、设计上的缺陷，可以针对产品的spec去报Bug。具体的风险分析如下表2.4所示：
表2.4 项目风险分析
风险类型
风险综述
在保证质量的前提下人力资源与项目周期比列失调，因此人员不到位将存在项目风险。
增长人员
在不同环境下运营存在风险
使用统一的环境资源进行测试
进度存在风险
实际进度按照开发进度进行，当实际开发进度变更时将按照实际发进度及时调整测试进度
客户需求发生变更
常与客户进行沟通，达成一致协议
人员变动风险
通过培训等措施使变更后的人员了解统的业务流程，对系统进一步了解，以求在最大限度内保证测试质量
数据库测试中存在的风险
因测试周期的限制，因此根据实际情况选择的测试策略存在的风险情况反映给客户，与客户商议达成一致
版本部署风险
版本在部署的时候，也许会由于数据库的导入错误等因素导致系统犯错。因此在实际给客户部署时同样存在此种风险。
3 测试设计说明
3.1概述
3.1.1测试方法和测试用例选取的原则
系统：根据《系统需求说明书》对系统进行单元测试、集成测试、系统测试、验收测试、性能测试，并结合也许的用户测试。
全面：规定测试用例可以覆盖每一个测试点的要点。
合理：从可行性角度考虑，测试不也许全面覆盖，所以设立好等价类划分，测试的用例的选择避免反复测试、选择最佳的测试方法将测试点合理覆盖。
3.1.2测试的控制方式
测试用例的实现必须遵守测试计划的安排，实际测试必须以测试用例为基准。实际测试中测试用例的状态记载：
(1)failed:假如某一步测试用例失败，不影响以后测试用例解决
(2)block:假如某一步测试用例失败，并影响以后测试用例解决
(3)good:测试成功
实际测试与外部交互使用缺陷记录清单进行交流。
测试人员必须具体、准确填写缺陷记录内容，开发修改人员要具体、准确地填写修改情况，通过缺陷记录清单的状态进行测试和修改交互。
(1)open:当开始一个问题报告单时，为open
开发返回后，错误仍存在为 re-open
(2)fixed / return
开发人员对错误进行了修改，为fixed
开发人员对错误没有进行修改,返回测试部为return
(3)close/ cancel
测试人员确认错误已经修改,为close
测试人员确认错误的无效或可以接受（标记）为cancel
测试版本的控制
由项目开发组随版本发布时提交版本提交单，测试组完毕测试后提交版本测试报告，版本更新时由开发组填写更新记录。
测试用例的命名原则：
[测试点]-编号
例如：CHS-01
缺陷记录清单命名原则
缺陷记录清单+_测试人员名称+_日期
例如：缺陷记录清单_张润_20230625
3.1.3数据选择策略
数据的选择全面覆盖所有数据、并规定避免冗余数据的使用（采用边界值、特殊值、以及普通值）。
3.1.4测试过程描述和操作环节
1.测试过程描述
(1)书写测试计划
(2)参考测试计划、需求、概要设计以及部分具体设计文档进行用例设计
(3)参考测试计划和测试用例进行实际测试操作
(4)测试总结和报告
2.操作环节
(1)测试基本流程（简易的IVT）
(2)测试功能块（重点为容错测试）
(3)记录信息的测试（IVT）
3.2软件说明
超市收银系统重要涵盖管理员、库存管理员、售货员三种角色登录，实现功能重要有：用户管理、商品管理、库存管理、商品销售，详见《需求规格说明书》。
3.3测试内容及策略
本测试将通过用户界面测试、集成测试，系统测试、验收测试、性能测试、负载测试、强度测试、容量测试、安全性和访问控制测试、故障转移和恢复测试、配置测试、安装测试方面对系统进行测试。
用户界面测试用于核算用户与软件之间的交互，测试用户界面的对的性和易用性。
3.3.1用户界面及易用性测试
目的： 保证用户界面通过测试对象的功能来为用户提供相应的访问或浏览功能；此外，UI测试还可以保证UI中的对象按照预期的方式运营，并符合公司或行业的标准。
内容： 对系统的功能页面进行各种可操作性测试。
重点： 容错检测，易用性。
3.3.2集成测试
目的： 检测系统是否达成需求，对业务流程及数据流的解决是否符合标准，检测系统对业务流解决是否存在逻辑不严谨及错误，检测需求是否存在不合理的标准和规定。
内容：运用有效的和无效的数据来执行各个用例，用例流或功能，以核算在使用有效数据时得到的预期结果，在使用无效数据时显示相应的错误消息或警告消息，个业务规则都得到了对的的应用。
重点：测试的单元模块之间的接口和调用是否对的，集成后是否实现了某个功能。
3.3.3系统测试
目的：将软件整合为一体，看各个功能是否所有实现。
内容：将整个软件系统看做一个整体进行测试，测试功能是否能满足需求，是否所有实现，后期重要涉及看系统运营的性能是否满足需求，以及系统在不同的软硬件环境中的兼容性等。
重点：系统在配置好的环境中是否可以正常运营。
3.3.4压力测试
目的：了解(被测应用程序)一般可以承受的压力，同时可以承受的用户访问量(容量)，最多支持有多少用户同时访问某个功能。
内容：
（1）由于事先我们不知道将有多少用户访问是临界点，所以在测试过程中需要多次改变用户数来拟定，
（2）计划的设立，每x时间后加载10用户(根据总用户数设立)，完全加载后连续运营不超过5分钟(根据需要设立)。
（3）当运营中的用户数100%达成集合点时释放。
重点：找到系统的临界值点
3.3.5功能测试
目的：功能测试就是对系统的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达成用户规定的功能。
内容：
（1）页面链接检查：每一个链接是否都有相应的页面，并且页面之间切换对的。
（2） 相关性检查：删除/增长一项会不会对其他项产生影响，假如产生影响，这些影响是否都对的。
（3）检查按钮的功能是否对的：如update, cancel, delete, save等功能是否对的。
（4）字符串长度检查: 输入超过需求所说明的字符串长度的内容, 看系统是否检查字符串长度,会不会犯错.
（5）字符类型检查: 在应当输入指定类型的内容的地方输入其他类型的内容(如在应当输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错.
（6）标点符号检查: 输入内容涉及各种标点符号,特别是空格,各种引号,回车键.看系统解决是否对的.
（7）中文字符解决: 在可以输入中文的系统输入中文,看会否出现乱码或犯错.
（8）检查带出信息的完整性: 在查看信息和update信息时,查看所填写的信息是不是所有带出.,带出信息和添加的是否一致
（9）信息反复: 在一些需要命名,且名字应当唯一的信息输入反复的名字或ID,看系统有没有解决,会否报错,重名涉及是否区分大小写,以及在输入内容的前后输入空格,系统是否作出对的解决.
（10）检查删除功能:在一些可以一次删除多个信息的地方,不选择任何信息,按”delete”,看系统如何解决,会否犯错;然后选择一个和多个信息,进行删除,看是否对的解决.
（11） 检查添加和修改是否一致: 检查添加和修改信息的规定是否一致,例如添加规定必填的项,修改也应当必填;添加规定为整型的项,修改也必须为整型.
（12）检查修改重名:修改时把不能重名的项改为已存在的内容,看会否解决,报错.同时,也要注意,会不会报和自己重名的错.
（13）反复提交表单：一条已经成功提交的纪录，back后再提交，看看系统是否做了解决。
（14）检查多次使用back键的情况: 在有back的地方,back,回到本来页面,再back,反复多次,看会否犯错.
（15）search检查: 在有search功能的地方输入系统存在和不存在的内容,看search结果是否对的.假如可以输入多个search条件,可以同时添加合理和不合理的条件,看系统解决是否对的.
（16）输入信息位置: 注旨在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方.
（17）上传下载文献检查：上传下载文献的功能是否实现，上传文献是否能打开。对上传文献的格式有何规定，系统是否有解释信息，并检查系统是否可以做到。
（18）必填项检查：应当填写的项没有填写时系统是否都做了解决，对必填项是否有提醒信息，如在必填项前加*
（19） 快捷键检查：是否支持常用快捷键，如Ctrl+C Ctrl+V Backspace等，对一些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了限制。
（20）回车键检查: 在输入结束后直接按回车键,看系统解决如何,会否报错。
重点：保证各项功能和用需求一致
3.3.6性能测试
目的：核算性能是否满足用户需求，将测试对象的性能行为当做条件的一种函数来进行评测和微调。
内容：负载测试、强度测试。
(1)单个事务单个用户时候，在每个事务所语气时间范围内成功完毕测试脚本，没有发生任何故障；多个事务多个用户时，可完毕脚本没有发生故障的情况临界值。
(2)使测试系统承担不同的工作量，得出系统连续正常运营的能力。
(3)找出因资源局限性或资源争用导致的错误。
重点：保证性能指标满足用户需求。
3.3.7容量测试
目的：所计划的测试所有执行，并且达成或超过指定的系统限制时没有出现任何软件故障。
内容：在客户机长时间内执行相同的、最坏的业务时候系统维持的时间。
重点：核算系统能否在连续或模拟了最多数量的客户机下正常运营。
3.3.8安全性和访问控制测试
目的：保证只有访问权限的用户才干访问系统，核算用户以不同身份登录有不同的访问权限。
内容：数据或业务功能访问的安全性，涉及系统登录或远程访问。
重点：保证治具有系统访问权限的用户才干访问应用程序，并且只能通过相应的网关来访问。。
3.3.9故障转移和恢复测试
目的：检测系统可否在意外数据损失、数据完整性破坏、各种硬件、软件、网络故障中恢复数据。
内容：
(1)客户机断电、服务器断电看事务可否发生回滚。
(2)网络服务器中断。
重点：看数据库的恢复情况，以及系统在经历意外时间时候是否会发生崩溃现象。
3.3.10配置测试
目的：核算是否可以在所需的硬件和软件配置中正常运营。
内容：核算该系统在不同系统、不同软件和硬件配置中的运营情况。。
重点：软硬件配置不同时候对系统的影响。
3.3.11安装测试
目的：此1.0版本重点在于检查系统初次安装可否正常运营。
内容：启动或执行安装，使用预先拟定的功能测试脚本子集来运营事务。
重点：异常情况解决：如磁盘空间局限性、缺少目录创建权限等；核算软件安装后可否正常运营。
3.3.12验收测试
目的：对整个系统，涉及软硬件，试运营，看一下是否所有功能可以实现。
内容：由软件测试工程师、用户等根据需求规格说明书对整个系统进行试运营，看是否能满足所有功能。
重点：在可移植环境中、并发访问环境中系统是否可以正常运营。
3.4测试用例范围
3.4.1 功能测试
测试的重点将重要放在功能测试上，按照三种角色：管理员、库存管理员、售货员，每种角色涉及如下模块：
1. 管理员
管理员的具体功能模块和测试项如下表4.1所示：
表4.1 管理员功能测试
模块
编号
测试项
登录
1
以管理员身份登录，登录成功则跳转电子商务管理主界面
2
用户账号被屏蔽，无法登录成功
3
输入非法标记符，提醒输入错误字符
4
输入用户名错误，提醒用户不存在
5
输入密码错误，提醒密码错误
用户管理
1
可设立每个用户的启动或屏蔽权限，进行启动用户或删除用户
2
单击角色修改按钮，进入角色修改页面，点选角色，修改成功，跳转登录界面
3
对用户信息进行修改，输入已注册用户新信息，提交后跳转到登录界面
4
被管理员屏蔽或删除的用户,无法进行设立，提醒重新激活账号
商品管理
1
单击商品管理按钮，进入商品列表页面
2
可以添加商品信息，对添加商品信息进行简朴输入信息验证，若输入非法标记符则指明错误；添加后跳转到商品列表界面
3
可以修改商品信息，对商品修改信息进行简朴输入信息验证，若输入非法标记符则指明错误；添加后跳转到商品列表界面
4
可以删除商品信息，提醒是否删除？确认删除后跳转到商品列表界面
2
若想修改邮箱，可以填写发件和收件地址、密码，提交后返回邮件管理界面
3
键入非法标记符，指明输入错误
2. 库存管理员
库存管理员的功能模块和测试项如下表4.2所示：
表4.2 库存管理员功能测试
模块
遍号
测试项
注册
1
用户单击登录入口的注册链接，输入相关注册信息，单击注册按钮，验证用户信息，核算无误则跳转登陆成功提醒页面
2
用户单击登录入口的注册链接，若输入非法标记符，则需要弹出指明错误的警示框
登录
1
以普通用户身份登录，登录成功则跳转电子商务管理主界面
2
用户账号被屏蔽，无法登录成功
3
输入非法标记符，提醒输入错误字符
4
输入用户名错误，提醒用户不存在
5
输入密码错误，提醒密码错误
商品入库
1
登录成功，单击浏览产品页，可以浏览产品
2
登录成功，单击查询商品浏览产品，可以查询特定商品
3
查询商品时假如合法输入且没有该商品，需弹出无商品的提醒框
4
查询商品时假如输入合法标记符，则弹出提醒框指明错误
3. 销售管理员
库存管理员的功能模块和测试项如下表4.3所示：
表4.3 销售管理员功能测试
模块
遍号
测试项
注册
1
用户单击登录入口的注册链接，输入相关注册信息，单击注册按钮，验证用户信息，核算无误则跳转登陆成功提醒页面
2
用户单击登录入口的注册链接，若输入非法标记符，则需要弹出指明错误的警示框
登录
1
以普通用户身份登录，登录成功则跳转电子商务管理主界面
2
用户账号被屏蔽，无法登录成功
3
输入非法标记符，提醒输入错误字符
4
输入用户名错误，提醒用户不存在
5
输入密码错误，提醒密码错误
商品销售
1
登录成功，单击浏览产品页，可以浏览产品
2
登录成功，单击查询商品浏览产品，可以查询特定商品
3
查询商品时假如合法输入且没有该商品，需弹出无商品的提醒框
4
查询商品时假如输入合法标记符，则弹出提醒框指明错误
5
商品成功搜索到后点击结账，自动弹出结账的相关信息
3.5评价
3.5.1范围
规定：
1.功能测试涵盖测试全过程。
2.界面测试涵盖测试全过程。
3.逻辑测试测试途径的涵盖率为85%以上。
3.5.2准则
①测试参数结果鉴定准则
(1)完全通过：
其相应测试用例通过率达成100％
(2)基本通过：
其相应的测试用例通过率达成70％及其以上，并且不存在非常严重和严重的缺陷
(3)不通过：
其相应的测试用例通过率未达成70%，或者存在非常严重和严重的缺陷
②测试入口出口准则
1）测试进入准则
以下条件为进入测试的基本条件：
(1)开发部/开发人员应提供软件说明书、具体需求或系统设计等必要文档；
(2)被测样品，己通过无病毒检测；
(3)被测样品，已通过单元测试(可选)；
(4)被测样品，已通过冒烟测试；
(5)测试环境（场地、网络、硬件、软件等）已所有准备完备。
2）测试暂停和再启动准则
测试暂停标准：
(1)测试环境发生变化（场地、网络、硬件、软件等），又处在不可使用状态；
(2)被测样品有大量错误或严重错误，以至于继续测试没有任何意义
(3)测试再启动标准：
(4)错误得到修改后，需要重新启动测试
(5)开发组提供错误修改后的安装程序以及再启动测试的相关说明
(6)测试组安装修改后的程序。如有必要，需要重新初始化测试数据，重新执行测试规程，恢复到发生错误前的状态。
3）测试退出的准则
测试结论达成完全通过、基本通过或不通过的标准时，测试可以退出
4超市收银系统覆盖率测试
4.1 逻辑覆盖测试
逻辑覆盖测试重要是针对程序的内部逻辑结构设计测试用例的技术，它通过运营测试用例达成逻辑覆盖的目的。
涉及以下3种类型的逻辑覆盖：
(1)语句覆盖
(2)鉴定覆盖
(3)条件覆盖

try
{
if (myread.HasRows)
{
if (myread.Read())
{
//MessageBox.Show("登录成功");
if (myread["UserID"].ToString() == tbxUsr.Text && myread["UserPassword"].ToString() == tbxPwr.Text && myread["UserRight"].ToString() == "管理员")
{
user = username;
Form8 f3;
f3 = new Form8();
f3.Show();
}
else if (myread["UserID"].ToString() == tbxUsr.Text && myread["UserPassword"].ToString() == tbxPwr.Text && myread["UserRight"].ToString() == "员工")
{
user = username;
Form2 f2;
f2 = new Form2();
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

语句块2

出口

图4.1 程序流程图

4.2 语句覆盖
语句覆盖就是设计若干个测试用例，运营被测试程序，使得每一条可执行的语句至少执行一次。根据概念，为了对上面的函数进行语句覆盖，只要设计一个测试用例就可以覆盖2个执行语句块中的语句。
针对程序的判断语句，可在入口处设计测试用例。
测试用例输入为：｛myread.HasRows！=null｝
假如程序只运营上面的测试用例，虽然可以执行模块中的所有语句，但并不能检查判断逻辑是否有问题。例如在第一个判断中错误地把==写成!=，则上面的测试用例仍可以覆盖所有的执行语句。可以说语句覆盖率是最弱的逻辑覆盖准则。
4.3 鉴定覆盖
鉴定覆盖（也称为分支覆盖），设计若干个测试用例，运营所测程序，使程序中每个判断的取真分支和取假分支至少各执行一次。
根据上面的定义，对于上面的程序，只要设计两个测试用例则可以满足条件覆盖的规定。
测试用例的输入为：｛myread.HasRows！=null｝
｛myread.Read()的内容是否与数据库中的数据匹配｝
上面的两个测试用例虽可以满足鉴定覆盖的规定，但是有时候也不能对鉴定条件进行检查。
4.4 条件覆盖
设计足够多的测试用例，运营所测程序，使程序中每个判断内的每个条件的各个也许取值至少执行一次。
为了清楚的设计测试用例，对例子中的所有条件取值加以标记。
例如：
对于第一个判断：条件myread.HasRows！=null，取真值为1，假值为0；
对于第二个判断： 条件myread.Read()是否匹配，取真值为1，假值为0；

5超市收银系统黑盒测试
5.1边界值测试
1.边界值测试用例如下表5.1所示：
表5.1 边界值测试
编制人
张润
审定人
严念慈
时间
2023-6-29
软件名称
超市收银系统
版本
Version1.0
测试目的
检查功能是否与需求相符
用例编号
CH
依赖关系
无
用例描述
输入用户名，其中字符长度在3到10之间【3，10】涉及汉字、字母
输入数据
输入错误用户名
盼望输出
输出提醒用户不存在的警示框
实际输出

2. 覆盖边界值测试用例如下表5.2所示：
表5.2 覆盖边界值测试用例
用例编号
输入数据
输出结果
CHL-01
张润
张润
CH-02
12740125
12740125
CH-03
张三
用户名非法
CH-04

编号不合法
CH-05
管理员
管理员
CH-06
普通人
用户权限不合法
5.2 等价类划分
1. 等价类划分如下表5.3所示：
表5.3 等价类划分测试
编制人
张润
审定人
严念慈
时间
2023-6-29
软件名称
超市收银系统
版本
Version1.0
测试目的
检查功能是否与需求相符
用例编号
CH
依赖关系
无
用例描述
输入注册用户名称，必填；
输入数据
12740125
盼望输出
12740125
实际输出
12740125
2. 覆盖等价类测试用例如下表5.4所示：
表5.4 覆盖等价类测试
用例编号
输入数据
输出结果
CHL-01
12740125
12740125
CH-02
空
用户编号不许为空
CH-03
张润
张润
CH-04
1274张三
用户编号非法

5.3 因果图法
从因果图生成的测试用例（局部，组合关系下的）涉及了所有输入数据的取TRUE与取FALSE的情况，构成的测试用例数目达成最少且测试用例数目随输入数据数目的增长而线性的增长。如下表5.5所示：
表5.5因果图测试用例
编制人
张润
审定人
严念慈
时间
2023-6-29
软件名称
超市收银系统
版本
Version1.0
测试目的
检查功能是否与需求相符
用例编号
CH
依赖关系
无
用例描述
输入注册日期；
输入数据
12740125
盼望输出
12740125
实际输出
12740125