黑盒测试举例

软件测试是一项复杂的系统工程，从不同的角度考虑可以有不同的划分方法，对测试进行分类是为了更好的明确测试的过程，了解测试究竟要完成哪些工作，尽量做到全面测试。

1,按是否需要执行被测软件的角度

按是否需要执行被测软件的角度，可分为静态测试和动态测试，前者不利用计算机运行待测程序而应用其他手段实现测试目的，如代码审核。（我认为主要是让测试人员对编译器发现不了的潜在错误进行分析，如无效的死循环，多余的变量等），而动态测试则通过运行被测试软件来达到目的。

2、按阶段划分：

1 单元测试

单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等等。它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。因为单元测试需要知道内部程序设计和编码的细节知识，一般应由程序员而非测试员来完成，往往需要开发测试驱动模块和桩模块来辅助完成单元测试。因此应用系统有一个设计很好的体系结构就显得尤为重要。

一个软件单元的正确性是相对于该单元的规约而言的。因此，单元测试以被测试单位的规约为基准。单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等等。

2 集成测试

集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。它根据集成测试计划，一边将模块或其他软件单位组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。集成测试的策略主要有自顶向下和自底向上两种。

3 系统测试

系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的“先知者问题”。因此，系统测试应该按照测试计划进行，其输入、输出和其他动态运行行为应该与软件规约进行对比。软件系统测试方法很多，主要有功能测试、性能测试、随机测试等等。

4 验收测试

验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集。所不同的是，验收测试常常有软件系统的购买者代表在现场，甚至是在软件安装使用的现场。这是软件在投入使用之前的最后测试。

5 回归测试

回归测试是在软件维护阶段，对软件进行修改之后进行的测试。其目的是检验对软件进行的修改是否正确。这里，修改的正确性有两重含义：一是所作的修改达到了预定目的，如错误得到改正，能够适应新的运行环境等等；二是不影响软件的其他功能的正确性。

6 Alpha 测试：在系统开发接近完成时对应用系统的测试；测试后，仍然会有少量的设计变更。这种测试一般由最终用户或其他人员员完成，不能由程序员或测试员完成。

7 Beta 测试：当开发和测试根本完成时所做的测试，而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员员完成，不能由程序员或测试员完成。

3、按测试方法划分：

1 白盒测试

白盒测试也称结构测试或逻辑驱动测试，是指基于一个应用代码的内部逻辑知识，即基于覆盖全部代码、分支、路径、条件的测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。

“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错。第三，穷举路径测试可能发现不了一些与数据相关的错误。

白盒测试可以借助一些工具来完成如Junit Framework，Jtest等。

2 黑盒测试

黑盒测试是指不基于内部设计和代码的任何知识，而基于需求和功能性的测试，黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等，主要用于软件确认测试。

“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。

黑盒测试也可以借助一些工具，如WinRunner，QuickTestPro，Rational Robot等。

3 ALAC(Act-like-a-customer)测试

ALAC测试是一种基于客户使用产品的知识开发出来的测试方法。ALAC测试是基于复杂的软件产品有许多错误的原则。最大的受益者是用户，缺陷查找和改正将针对哪些客户最容易遇到的错误。

软件测试举例：

ATM机操作用例：

一台 ATM 机器的主角和用例。

下表包含了上图中提款用例的基本流和某些备用流：

本用例的开端是 ATM 处于准备就绪状态。 准备提款 - 客户将银行卡插入 ATM 机的读卡机。 验证银行卡 - ATM 机从银行卡的磁条中读取帐户代码，并检查它是否属于可以接收的银行卡。 输入 PIN - ATM 要求客户输入 PIN 码（4 位） 验证帐户代码和 PIN - 验证帐户代码和 PIN 以确定该帐户是否有效以及所输入的 PIN 对该帐户来说是否正确。对于此事件流，帐户是有效的而且 PIN 对此帐户来说正确无误。 ATM 选项 - ATM 显示在本机上可用的各种选项。在此事件流中，银行客户通常选择“提款”。 输入金额 - 要从 ATM 中提取的金额。对于此事件流，客户需选择预设的金额（10 美元、20 美元、50 美元或 100 美元）。

授权 - ATM 通过将卡 ID、PIN、金额以及帐户信息作为一笔交易发送给银行系统来启动验证过程。对于此事件流，银行系统处于联机状态，而且对授权请求给予答复，批准完成提款过程，并且据此更新帐户余额。 出钞 - 提供现金。 返回银行卡 - 银行卡被返还。 收据 - 打印收据并提供给客户。ATM 还相应地更新内部记录。 用例结束时 ATM 又回到准备就绪状态。 备选流 1 - 银行在基本流步骤 2 中 - 验证银行卡，如果卡是无效的，则卡被退回，同卡无效 时会通知相关消息。 备选流 2 - ATM 在基本流步骤 5 中 - ATM 选项，如果 ATM 内没有现金，则“提款”内没有现金 选项将无法使用。 在基本流步骤 6 中- 输入金额，如果 ATM 机内金额少于请求提取的金备选流 3 - ATM 额，则将显示一则适当的消息，并且在步骤 6 - 输入金额处重新加入基内现金不足 本流。 在基本流步骤 4 中- 验证帐户和 PIN，客户有三次机会输入 PIN。 如果 PIN 输入有误，ATM 将显示适当的消息；如果还存在输入机备选流 4 - PIN 会，则此事件流在步骤 3 - 输入 PIN 处重新加入基本流。 有误 如果最后一次尝试输入的 PIN 码仍然错误，则该卡将被 ATM 机保留，同时 ATM 返回到准备就绪状态，本用例终止。 在基本流步骤 4 中 - 验证帐户和 PIN，如果银行系统返回的代码表明备选流 5 - 帐户找不到该帐户或禁止从该帐户中提款，则 ATM 显示适当的消息并且在不存在 步骤 9 - 返回银行卡处重新加入基本流。 在基本流步骤 7 - 授权中，银行系统返回代码表明帐户余额少于在基本备选流 6 - 帐面流步骤 6 - 输入金额内输入的金额，则 ATM 显示适当的消息并且在步金额不足 骤 6 - 输入金额处重新加入基本流。 备选流 7 - 达到在基本流步骤 7 - 授权中，银行系统返回的代码表明包括本提款请求在每日最大的提款内，客户已经或将超过在 24 小时内允许提取的最多金额，则 ATM 显金额 示适当的消息并在步骤 6 - 输入金额上重新加入基本流。 如果在基本流步骤 10 - 收据中，记录无法更新，则 ATM 进入“安全备选流 x - 记录模式”，在此模式下所有功能都将暂停使用。同时向银行系统发送一条错误 适当的警报信息表明 ATM 已经暂停工作。 备选流 y - 退出 客户可随时决定终止交易（退出）。交易终止，银行卡随之退出。 ATM 包含大量的传感器，用以监控各种功能，如电源检测器、不同的门备选流 z - “翘和出入口处的测压器以及动作检测器等。在任一时刻，如果某个传感器起” 被激活，则警报信号将发送给警方而且 ATM 进入“安全模式”，在此模式下所有功能都暂停使用，直到采取适当的重启/重新初始化的措施。 在第一次迭代中，根据迭代计划，我们需要核实提款用例已经正确地实施。此时尚未实施整个用例，只实施了下面的事件流： 基本流 - 提取预设金额（10 美元、20 美元、50 美元、100 美元） 备选流 2 - ATM 内没有现金 备选流 3 - ATM 内现金不足 备选流 4 - PIN 有误 备选流 5 - 帐户不存在/帐户类型有误 备选流 6 - 帐面金额不足

可以从这个用例生成下列场

景

场景 1 - 成功的提款 场景 2 - ATM 内没有现金 场景 3 - ATM 内现金不足 场景 4 - PIN 有误（还有输基本流 基本流 基本流 基本流 备选流 2 备选流 3 备选流 4 入机会） 场景 5 - PIN 有误（不再有基本流 输入机会） 场景 6 - 帐户不存在/帐户基本流 类型有误 场景 7 - 帐户余额不足 基本流 备选流 6 备选流 5 备选流 4 注：为方便起见，备选流 3 和 6（场景 3 和 7）内的循环以及循环组合未纳入上表。

对于这 7 个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表 测试用例的信息。本示例中，对于每个测试用例，存在一个测试用例 ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果。

通过从确定执行用例场景所需的数据元素入手构建矩阵。然后，对于每个场景，至少要确定包含执行场景所需的适当条件的测试用例。例如，在下面的矩阵中，V（有效）用于表明这个条件必须是 VALID（有效的）才可执行基本流，而 I（无效）用于表明这种条件下将激活所需备选流。下表中使用的“n/a”（不适用）表明这个条件不适用于测试用例。

测试场景/条件 用例 PIN 帐号 输入的金帐面金额 额 ATM 内预期结果 的金额 ID号 （或选择的金额） 场景 1 - 成功的CW1. 提款 V V V V V 成功的提款。 场景 2 - ATM 内CW2. V 没有现金 提款选项不可V V V I 用，用例结束 警告消息，返场景 3 - ATM 内CW3. V 现金不足 V V V I 回基本流步骤 6 - 输入金额 场景 4 - PIN 有CW4. 误（还有不止一次输入机会） 场景 4 - PIN 有CW5. 误（还有一次输入机会） 场景 4 - PIN 有CW6. 误（不再有输入机会） I V n/a V V I V n/a V V I V n/a V V 警告消息，返回基本流步骤 4，输入 PIN 警告消息，返回基本流步骤 4，输入 PIN 警告消息，卡予保留，用例结束 在上面的矩阵中，六个测试用例执行了四个场景。对于基本流，上述测试用例 CW1 称为正面测试用例。它一直沿着用例的基本流路径执行，未发生任何偏差。基本流的全面测试必须包括负面测试用例，以确保只有在符合条件的情况下才执行基本流。这些负

面测试用例由 CW2 至 6 表示（阴影单元格表明这种条件下需要执行备选流）。虽然 CW2 至 6 对于基本流而言都是负面测试用例，但它们相对于备选流 2 至 4 而言是正面测试用例。而且对于这些备选流中的每一个而言，至少存在一个负面测试用例（CW1 - 基本流）。

每个场景只具有一个正面测试用例和负面测试用例是不充分的，场景 4 正是这样的一个示例。要全面地测试场景 4 - PIN 有误，至少需要三个正面测试用例（以激活场景 4）：

* 输入了错误的 PIN，但仍存在输入机会，此备选流重新加入基本流中的步骤 3 - 输入 PIN。

* 输入了错误的 PIN，而且不再有输入机会，则此备选流将保留银行卡并终止用例。

* 最后一次输入时输入了“正确”的 PIN。备选流在步骤 5 - 输入金额处重新加入基本流。

注：在上面的矩阵中，无需为条件（数据）输入任何实际的值。以这种方式创建测试用例矩阵的一个优点在于容易看到测试的是什么条件。由于只需要查看 V 和 I（或此处采用的阴影单元格），这种方式还易于判断是否已经确定了充足的测试用例。从上表中可发现存在几个条件不具备阴影单元格，这表明测试用例还不完全，如场景 6 - 不存在的帐户/帐户类型有误和场景 7 - 帐户余额不足就缺少测试用例。

一旦确定了所有的测试用例，则应对这些用例进行复审和验证以确保其准确且适度，并取消多余或等效的测试用例。

测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定测试数据：

测试用例 场景/条件 ID 号 PIN 帐号 输入的金额 帐面金额 （或选择的金额） 成功的提款。场景 1 - 成功的809 - 4987 提款 498 新为 450.00 50.00 500.00 2,000 帐户余额被更的金额 ATM 内预期结果 CW1. 场景 2 - ATM 内809 - CW2. 4987 没有现金 498 提款选项不可100.00 500.00 0.00 用，用例结束 警告消息，返场景 3 - ATM 内809 - CW3. 4987 现金不足 498 100.00 500.00 70.00 回基本流步骤 6 - 输入金额 场景 4 - PIN 有809 - CW4. 误（还有不止一次4978 498 输入机会） CW5. 场景 4 - PIN 有4978 809 - n/a 500.00 n/a 500.00 警告消息，返2,000 回基本流步骤 4，输入 PIN 2,000 警告消息，返误（还有一次输入机会） 场景 4 - PIN 有498 回基本流步骤 4，输入 PIN 警告消息，卡809 - CW6. 误（不再有输入机4978 498 会） 结束 n/a 500.00 2,000 予保留，用例 以上测试用例只是在本次迭代中需要用来验证提款用例的一部分测试用例。需要的其他测试用例包括：

* 场景 6 - 帐户不存在/帐户类型有误：未找到帐户或帐户不可用

* 场景 6 - 帐户不存在/帐户类型有误：禁止从该帐户中提款

* 场景 7 - 帐户余额不足：请求的金额超出帐面金额

在将来的迭代中，当实施其他事件流时，在下列情况下将需要测试用例：

* 无效卡（所持卡为挂失卡、被盗卡、非承兑银行发卡、磁条损坏等）

* 无法读卡（读卡机堵塞、脱机或出现故障）

* 帐户已消户、冻结或由于其他方面原因而无法使用

* ATM 内的现金不足或不能提供所请求的金额（与 CW3 不同，在 CW3 中只是一种币值不足，而不是所有币值都不足）

* 无法联系银行系统以获得认可

* 银行网络离线或交易过程中断电

在确定功能性测试用例时，确保满足下列条件：

* 已经为每个用例场景确定了充足的正面和负面测试用例。

* 测试用例可以处理用例所实施的所有业务规则，确保对于业务规则，无论是在内部、外部还是在边界条件/值上都存在测试用例。

* 测试用例可以处理所有事件或动作排序（如在设计模型的序列图中确定的内容），还应能处理用户界面对象状态或条件。

* 测试用例可以处理为用例所指定的任何特殊需求，如最佳/最差性能，有时这些特殊需求会与用例执行过程中的最小/最大负载或数据容量组合在一起。

对于负载测试：

TC（测试用例）工作量 ID 号 1 PCW1. （单个 ATM） 2 全部交易（不依赖于主角的时间）PCW2. （1,000 个同时完成提款交易 在 30 秒之内完成 运行的 ATM） PCW3. 3 完成提款交易 全部交易（不依赖于主角的时间）完成提款交易 在 20 秒之内完成 全部交易（不依赖于主角的时间）条件 预期结果 （10.000 个同时运行的 ATM） 在 50 秒之内完成 对于强度测试：

TC（测试用例）工作量 ID 号 2 数据库锁定 - 2 个 ATM 请求同ATM 请求排成SCW1. （10.000 个同一帐户 时运行的 ATM） 2 交易排成队列或SCW2. （1,000 个同时无法实现银行系统的通信 超时 运行的 ATM） 2 在交易过程中，银行系统通信被终SCW3. （10.000 个同止 时运行的 ATM） 显示警告消息 队列 条件 预期结果

为安全性/访问控制测试生成测试用例，在 ATM 用例中，如果主角“银行客户”的卡和帐户有的属于拥有这个 ATM 机的银行，有的是竞争银行的银行卡（和帐户），或是企图使用该 ATM不支持的银行卡，则将对该主角“银行客户”执行不同的用例事件流。

对于功能性测试用例，请同样遵循上面列举的指南。

关于安全性和访问控制测试用例的示例：

卡 TC（测试用条件 例）ID 号 卡有效） ACW1. 在银行网络之内 V 机工作正常） V V 所有用例都可用 只有提款用例可ACW2. 银行网络之外 V V I 用 警告消息，卡被ACW3. 无法读卡 I V V 退出 因被盗，卡已挂ACW4. 失 I V V 保留 警告消息，卡予ACW5. 卡已过期 I V V 保留 警告消息，卡予 （V 表明 （V 表明读卡网络 读卡机 银行的预期结果 手机软件测试举例：

一、等价类分析法

等价类划分方法针对手机状态大致可以归几个大类：

1.按键类（等价法）：有效输入和无效输入（有效输入指UM和菜单指示；无效输入指

测试菜单功能此时没有定义的按键和用户动作）； 2. 外部中断类（等价法）：常用、不常用及无效

2.1. 常用：来电和来消息（短信、彩信、push消息）；掀合盖；侧键；耳机＆FM；情景模式；电量不足

2.2. 不常用：充电；闹钟＆记事本＆关机时间＆整点报时提示；Icon＆动画显示；Icon＆动画刷新；编辑界面＆pop显示框输入为空或满；编辑界面＆pop显示框状态输入法默认＆字符编码默认；失效SIM卡；大容量等SIM卡兼容；排序；号码识别； 2.3. 无效：“资料读取中…”；“复制中…”；“请稍后再试” 3. 存储器类

3.1. 等价法分类：读或写；不读或不写。

3.2. 因果法分类：先SIM卡后手机；先手机后SIM卡；提示用户选择存储器（对比Nokia）。

3.3. 操作分类：读；写；新增；删除；复制（先删除后新增；先新增后删除） 4. 状态类：正确；错误；变更；用户设定变更 测试如下

单个通话实例的拨打与挂断 测试用例标识 测试阶段：系统测试 测试项

单个通话实例的拨打与挂断 重要级别 高

测试原因

手机在待机状态下，确保手机能正常拨出电话 预置条件

1. 正常信号环境 2. IDLE状态

3. 默认原厂参数设定 输入

1. 电话号码（手机号码，固定电话，带分机的号码，字符串，特殊号码如：**21*021xxxxxxxx# ，+或00，超短号码，超长号码，拨打一位号码，拨打最大长度号码等）

2. 拨号过程中电池低电量提示、来短信、来彩信 3. 拨号过程中闹钟时间到、行事历时间到 4. 拨号过程中插上充电器 5. 拨号过程中突然断电 6.按键加锁 测试执行步骤 IDLE状态拨打号码 按Send键发送 按End键挂断 预期输出结果

1. 按Send键可以拨打并显示，按End键可挂断

2. 拨打号码过程电池低电量提示、来短信、来彩信拨打界面正常

3. 拨打号码过程闹钟时间到、行事历时间到拨打界面正常 4. 拨号过程中插上充电器，背光状态及拨打界面正常 5. 拨号过程中突然断电，插上充电器重新开机后能正常拨出 6. 按键加锁仅可拨打紧急电话号码112 测试用例标识 测试阶段：系统测试 测试项

单个通话实例的拨打与挂断 测试项属性 A 参照规范 重要级别 高 测试原因

手机在无信号或无网络情形下，手机无法正常拨打电话 预置条件

1. 正在搜索网络或正处于注册界面 2. IDLE状态

3. 默认原厂参数设定 输入 同上用例 测试执行步骤

IDLE状态拨打号码 按Send键拨号 预期输出结果

1. 重复以上操作，提示无法拨打成功的提示信息 2. 重复以上步骤，背光处理正常

诺基亚（英文）：Extended default 7-bit alphabet (over 140 Bytes)，智慧短信，可以携带黑白图片。 合法等价类： 0～140 非法等价类：：>140 动作

可以拨打电话 Y N

Y（除拨112外还可以拨打其它号码） 五、 流程分析方法

1-手动/自动选网模式；11-自动注册并显示已有网络服务

2-手动模式（选网模式的一种）；3-搜寻到HPLMN（归属网络）及FPLMN（禁止网络）；6-频段搜索；7-自动选择频段；8-手动选择频段900或1800；（新手机才有频段手动选择）4-选择FPLMN；5-注册FPLMN

图书馆管理系统测试用例：

1.1目的

测试用例的目的确定并传达一些条件，这些条件将在测试中执行，并且是核实实施软件需求是否成功和能否接受所必需的条件。测试用例反映了一种测试覆盖（基于需求的测试覆盖）评测方法。这是因为每个测试用例都可追踪到至少一个测试需求，而这些需求则反映出产品的需求。

1.2范围 功能测试 测试内容 功能用例 系统管理 功能分解 添加用户 浏览用户 图书管理 图书分类 浏览图书 读者管理 浏览身份 浏览读者 用户登录 修改密码 重新登录 测试环境

软件环境（相关软件、操作系统） 操作系统 应用软件 其它 WINDOWS XP ACCESS、WORD、图书管信息管理系统软件 WINRAR 硬件环境（网络、设备） 测试工作站 CPU 内存 硬盘 二、功能测试用例

2．1系统登录 用例编号 01 功能特性 系统登录 测试目的 测试是否可以正常登录 前置条件 系统正常启动，用户：admin 密码：admin 身份：管理员 己添加成功 用例分支 操作描述 01 启动系统： 数据 预期结果 实际结果 P/F 编制时间 admin（默进入主界达到预期 面 结果，进入到了主界面 (1) 输入正确图书证认) 号； (2) 输入正确密码； (3) 点击管理员选项； (4) 点击确定 02 重新登录： admin（默认) admin（默返回登录达到预期 界面 结果，同时提醒“没有选择角色” (1) 输入正确图书证认) 号； (2) 输入正确密码； (3) 点击确定 admin（默认) （未选择角色） 03 （1）输入正确图书证root 号； （2）输入正确密码； （3）点击管理员选项； （4）点击确定 root 登录读者达到预期 界面 结果 04 （1）输入错误图书证admin 号； 121 无法登录，达到预期 提示错误效果， 信息 （2）输入正确的密码； （3）点击管理员选项； （4）点击确定 05 （1）输入正确图书证admin 号； （2）输入空的密码； （3）点击管理员选项； （4）点击确定 06 （1）输入正确的图书admin 证号； （2）输入正确的密码 （3）点击管理选项 （4）点击取消 admin 无法登录，达到预期 提示错误效果，提信息，密码示密码不不能为空 能为空 退出系统 达到预期 效果， 2．2系统管理

2．2．1添加用户子功能 用例编号 02 编制时间 功能特性 测试其子功能添加用户和浏览用户功能是否可以正常运行 测试目的 验证数据的正确性 前置条件 用户以管理员身份正常登录成功 用例分支 操作描述 01 数据 预期结果 实际结果 P/F 添加成功 （1） 输入用户名称 yu(用户名添加成功 （2） 输入密码 （3） 确认密码 称) 123（密码） （4） 选择角色“管123（确认密理员” （5） 点击确定 02 (1)输入用户名称 (2)输入密码 (3)确认密码 xu(用户名添加成功 称) 123（密码） 添加成功 码） (4)选择角色“管理员” 123（确认密(5)点击确定 03 (1)输入用户名称 (2)输入密码 (3)确认密码 码） xu(用户名添加不成添加不成 称) 123（密码） 功 功 (4)选择角色“管理员” 128（确认密(5)点击确定 码） 04 (1)输入用户名称 (2)输入密码 (3)确认密码 空(用户名添加不成添加不成 称) 123（密码） 功 功 (4)选择角色“管理员” 123（确认密(5)点击确定

2．2．2浏览用户子功能 用例编号 03 编制时间 码） 功能特性 测试其子功能浏览用户功能是否可以正常运行 测试目的 验证数据的正确性 前置条件 用户以管理员身份正常登录成功 用例分支 操作描述 01 (1) 选中一条记录 (2) 点击删除 02 点击退出 无 退出浏览达到预期 用户界面

2．3图书管理

2．3．1图书分类子功能 用例编号 04 编制时间 结果 数据 无 预期结果 删除成功 实际结果 P/F 删除成功 功能特性 测试其子功能图书分类功能是否可以正常运行 测试目的 验证数据的正确性 前置条件 用户以管理员身份正常登录成功 用例分支 操作描述 01 (1) 点击添加 (2) 输入信息 (3) 点击确定 数据 预期结果 实际结果 P/F 添加成功 哲学（类型） 添加成功 小说之类（类型描述） 02 (1) 选中要删除的记无 录 (2) 点击删除 删除成功 删除成功 或提示“删除类型‘地理’失败，请先删掉该类型图书” 03 (1) 选中要修改的记选中“地修改成功 录 (2) 点击修改 理”，修改类型描述为修改成功 (3) 输入要修改的数“社会地据 (4) 点击确定 理” 04 点击退出 无 退出该子退出成功 界面

2．3．2浏览图书子功能 用例编号 05 编制时间 功能特性 测试其子功能浏览图书功能是否可以正常运行 测试目的 验证数据的正确性 前置条件 用户以管理员身份正常登录成功 用例分支 操作描述 01 (1)点击添加 (2)输入图书信息 (3)点击确定 02 (1)选中要删除的记选中要删除删除成功 录 (2)点击删除 03 的信息，点击“删除” 修改成功 修改成功 删除成功 数据 预期结果 实际结果 P/F 添加成功 输入图书信添加成功 息 (1)选中要修改的记选中录 (2)点击修改 “D2003”，修改类型描(3)输入要修改的数述为“社会地据 (4)点击确定 理” 04 点击退出 无 退出该子退出成功 界面

2．4读者管理

2．4．1浏览身份子功能 用例编号 06 编制时间 功能特性 测试其子功能浏览身份功能是否可以正常运行 测试目的 验证数据的正确性 前置条件 用户以管理员身份正常登录成功 用例分支 操作描述 01 (1) 点击添加 (2) 输入信息 (3) 点击确定 数据 预期结果 实际结果 P/F 添加成功 输入身份为添加成功 “专科生” 最长借阅时间为“1” 最大借阅数量为“3” 02 (1) 选中要删除的对无 象 (2) 点击删除 删除成功 删除成功 或显示“身份已被应用，无法删除” 03 (1) 选中身份信息 (2) 点击修改 选中身份“本科生”修改成功 修改成功 (3) 输入要修改的内改为“研究容 (4) 点击确定 04 点击退出 无 退出该子退出成功 界面

2．4．2浏览读者子功能 用例编号 07 编制时间 生” 功能特性 测试其子功能图书分类功能是否可以正常运行 测试目的 验证数据的正确性 前置条件 用户以管理员身份正常登录成功 用例分支 操作描述 01 (1) 点击添加 (2) 输入读者信息 (3) 点击确定 02 (1) 选中要删除的对无 象 (2) 点击删除 03 (1) 选中读者的信息 (2) 点击修改 将借书证编号为“1”的修改成功 修改成功 删除成功 删除成功 数据 预期结果 实际结果 P/F 添加成功 输入读者信添加成功 息 (3) 输入要修改的内容 (4) 点击确定 学生，将身份“本科生”改为“研究生” 04 点击退出 无 退出该子退出成功 界面 2．5用户登录 2．5．1修改密码 用例编号 08 编制时间 功能特性 测试其子功能修改密码功能是否可以正常运行 测试目的 验证数据的正确性 前置条件 用户以管理员身份正常登录成功 用例分支 操作描述 01 (1) 输入原密码 (2) 输入新密码 (3) 输入确认密码 (4) 点击确定 02 (1)输入原密码 (2)输入新密码 (3)输入确认密码 (4)点击确定 Admin 123 126 提示“两次达到预期 密码输入结果 不一致” 数据 Admin 123 123 预期结果 修改成功 实际结果 P/F 跟预期结 果一样 03 (1)输入原密码 (2)输入新密码 (3)点击确定 Admin 123 无 提示“填写达到预期 完整信息” 结果 04 点击退出 退出该子退出成功 界面 2．5．2重新登录 用例编号 09 编制时间 功能特性 测试其子功能重新登录功能是否可以正常运行 测试目的 验证数据的正确性 前置条件 用户以管理员身份正常登录成功 用例分支 操作描述 01 数据 预期结果 登录成功 实际结果 P/F 达到预期 结果 （1）输入正确图书证ddl 号； （2）输入正确密码； （3）点击管理员选项； （4）点击确定 ddl 02 （1）输入正确图书证ddl 号； （2）输入正确密码； （3）点击确定 （未选择角色） ddl 返回登录达到预期 界面 结果，同时提醒“没有选择角色” 03 点击取消 无 退出 达到预期 结果