软件工程_医院挂号系统_软件测试文档

《医院挂号系统软件测试文档》 2012年6月1日 目  录 1  系统测试    25 1.1  测试环境    25 1.2  测试用例设计与执行记录    25 1.2.1  登陆模块    25 1.2.2  图书出借管理模块    26 1.3  测试可行性    54   系统测试 1.1  测试环境 1.  操作系统：Windows XP 2.  数 据 库：SQL Server 2005 3.  Visual Studio .NET 1.2  测试用例设计与执行记录 1.2.1  用户登陆模块 医院挂号系统登陆模块 用户登陆模块测试 项目/软件 医院挂号系统 程序版本 1.0.0       功能模块名 Login 编制人 　         用例编号- Pri_Login 编制时间 　 2012.05.17       相关的用例 无           功能特性 用户身份验证           测试目的 验证是否输入合法的信息，允许合法登陆，阻止非法登陆           预置条件 无 特殊规程说明 如数据库访问权限       参考信息 需求说明中关于“登陆”的说明           测试数据 用户名=00001 密码=00001 用户类型=挂号工作人员 操作步骤 操作描述 数 据 期望结果 实际结果 测试状态 1 输入用户名，密码，按“登陆”按钮。 用户名=00001，密码=00001，用户类型=挂号工作人员 跳转到挂号工作人员主界面 跳转到挂号工作人员主界面   2 输入用户名，密码，按“登陆”按钮。 用户名=00005，密码=00001，用户类型=挂号工作人员 显示警告信息“用户名或密码错误，您还有*次机会” 显示警告信息“用户名或密码错误，您还有*次机会”   3 输入用户名，密码，按“登陆”按钮。 用户名=00001，密码=00005，用户类型=挂号工作人员 显示警告信息“用户名或密码错误，您还有*次机会” 显示警告信息“用户名或密码错误，您还有*次机会”   4 按“登陆”按钮。 用户名=空，密码=空 显示警告信息“用户名或密码错误，您还有*次机会” 显示警告信息“用户名或密码错误，您还有*次机会”   5 输入用户名，按“登陆”按钮。 用户名=001,密码=空 显示警告信息“用户名或密码错误，您还有*次机会” 显示警告信息“用户名或密码错误，您还有*次机会”   测试人员 王奕胜 开发人员 王奕胜   项目负责人 王奕胜                   用户登陆模块测试 用户ID为a，用户密码 = 00001，下拉列表框为b 白盒测试： 测试案例1：a=00001，b=挂号工作人员 测试案例2：a=A0001，b=系统管理员 黑盒测试： 运用等价分类法划分等价类补充用例，然后用边值法和猜错法附加用例， 测试案例3：a=11111，b=挂号工作人员 测试案例4：a=@a ，b=挂号工作人员 测试案例5：a=空，b=系统管理员 测试案例6：a=空，b=系统管理员 测试案例7：a=001，b=系统管理员 登陆测试 序号 输入值 预期结果 实测结果 成功与否、失败原因 1 a=00001，b=挂号工作人员 能查询到00001的信息 能查询到00001的信息 成功 2 a=A0001，b=系统管理员 能查询到A0001的信息 能查询到A0001的信息 成功 3 a=11111，b=系统管理员 提示用户名或密码错误，还有2次机会 提示用户名或密码错误，还有2次机会 成功 4 a=@a ，b=挂号工作人员 提示用户名或密码错误，还有1次机会 提示用户名或密码错误，还有2次机会 成功 5 a=空，b=系统管理员 退出系统 退出系统 成功 6 a=空，b=空 提示用户名或密码错误，还有2次机会 提示用户名或密码错误，还有2次机会 成功 7 a=001，b=空 提示用户名或密码错误，还有1次机会 提示用户名或密码错误，还有1次机会 成功           1.2.2  修改工作人员信息模块 医院挂号系统修改工作人员信息模块 修改工作人员信息模块测试 项目/软件 医院挂号系统 程序版本 1.0.0       功能模块名 UpdateWorkerInfo 编制人 　 王奕胜       用例编号- Pub_UpdateWorkerInfo 编制时间 　 2012.05.17       相关的用例 无           功能特性 更新工作人员个人信息           测试目的 验证是否输入合法的信息，允许合法输入，阻止非法输入           预置条件 无 特殊规程说明 如数据库访问权限       参考信息 需求说明中关于“修改工作人员信息”的说明           测试数据 工作人员编号 = 00001 姓名=方忍 原始密码=00001 操作步骤 操作描述 数 据 期望结果 实际结果 测试状态 1 不输入任何信息或输入信息后直接点击“取消” 无 退出修改患者个人信息界面，回到医院挂号系统主界面 退出修改患者个人信息界面，回到医院挂号系统主界面   2 输入用户名，密码，按“登陆”按钮。 用户名=00005，密码=00001，用户类型=挂号工作人员 显示警告信息“用户名或密码错误，您还有*次机会” 显示警告信息“用户名或密码错误，您还有*次机会”   3 输入用户名，密码，按“登陆”按钮。 用户名=00001，密码=00005，用户类型=挂号工作人员 显示警告信息“用户名或密码错误，您还有*次机会” 显示警告信息“用户名或密码错误，您还有*次机会”   4 按“登陆”按钮。 用户名=空，密码=空 显示警告信息“用户名或密码错误，您还有*次机会” 显示警告信息“用户名或密码错误，您还有*次机会”   5 输入用户名，按“登陆”按钮。 用户名=001,密码=空 显示警告信息“用户名或密码错误，您还有*次机会” 显示警告信息“用户名或密码错误，您还有*次机会”   测试人员 王奕胜 开发人员 王奕胜   项目负责人 王奕胜                   用户登陆模块测试 用户ID为a，用户密码 = 00001，下拉列表框为b 白盒测试： 测试案例1：a=00001，b=挂号工作人员 测试案例2：a=A0001，b=系统管理员 黑盒测试： 运用等价分类法划分等价类补充用例，然后用边值法和猜错法附加用例， 测试案例3：a=11111，b=挂号工作人员 测试案例4：a=@a ，b=挂号工作人员 测试案例5：a=空，b=系统管理员 测试案例6：a=空，b=系统管理员 测试案例7：a=001，b=系统管理员 登陆测试 序号 输入值 预期结果 实测结果 成功与否、失败原因 1 a=00001，b=挂号工作人员 能查询到00001的信息 能查询到00001的信息 成功 2 a=A0001，b=系统管理员 能查询到A0001的信息 能查询到A0001的信息 成功 3 a=11111，b=系统管理员 提示用户名或密码错误，还有2次机会 提示用户名或密码错误，还有2次机会 成功 4 a=@a ，b=挂号工作人员 提示用户名或密码错误，还有1次机会 提示用户名或密码错误，还有2次机会 成功 5 a=空，b=系统管理员 退出系统 退出系统 成功 6 a=空，b=空 提示用户名或密码错误，还有2次机会 提示用户名或密码错误，还有2次机会 成功 7 a=001，b=空 提示用户名或密码错误，还有1次机会 提示用户名或密码错误，还有1次机会 成功           1.3  测试可行性分析 需求规格说明书评测  填表说明：Y—是，TBD—不确定，N—否，NA—不适用。 编号 评测项 评测结果 Y/TBD/N/NA 清晰性 1 系统的目标是否已定义 Y：应用于物业系统 2 是否对关键术语和缩略语进行定义和描述 N 3 所使用的术语是否和用户/客户使用的一致 Y 4 需求的描述是否清晰，不含糊 Y 5 是否有对整套系统进行功能描述 Y：系统功能分析 6 是否已详细说明了软件环境（共存的软件）和硬件环境（特定的配置） Y：开发工具的选择 7 如果有会影响实施的假设情况，是否已经声明 N 8 是否已经对每个业务逻辑进行输入、输出以及过程的详细说明 Y: 系统设计分析 完整性 9 是否列出了系统所必须的依赖、假设以及约束 TBD 10 是否对每个提交物或阶段实施都进行了需求说明 N 11 需求说明书是否已包含了主要的质量属性，例如有效性、高效性、灵活性、完整性、互操作性、可靠性、健壮性、可用性、可维护性、可移植性、可重用性和可测性（此范围比较广，包括性能指标、需求是否遗漏、重复或不一致的地方等） TBD 依从性 12 该文档是否遵守了公司规定的文档编写 Y 一致性 13 需求说明是否存在直接相互矛盾的条目 N 14 本需求说明书是否与相关需求素材一致 Y 可行性 15 所描述的所有功能是否必要并充分地满足客户/系统目标 Y 16 需求规格说明书描述的详细程度是否足以满足进行详细设计 Y 17 已知的限制（局限）是否已经详细说明 N 18 是否已确认每个需求的优先级别 N 可管理性 19 是否将需求分别陈述，因此它们是独立的并且是可检查的 N 20 是否所有需求都可以回溯到相应的需求素材，反之亦然 Y 21 是否已详细说明需求变更的过程 N       简单评价： 该系统的目标定义完整，其中所使用的术语与客户要求的基本保持一致，描述清晰，但是并没有声明影响实施的假设情况。没有提出系统必须的依赖，假设以及约束。该包含了主要的质量属性，并且进行了较详细的描述，遵从了公司文档的编写标准，需求说明没有存在直接相互矛盾的条目，但与相关需求素材保持了很好的一致性但是存在相互矛盾的条目，基本上满足了客户的需求。但是并没有对系统的局限性进行很好的说明，在可管理性方面没有将需求分别陈述，相对独立并可以检查，需求都能够回溯到相应的素材，但是没有详细说明需求变更的过程。 概要设计说明书评测规范 填表说明：Y—是，TBD—不确定，N—否，NA—不适用。 编号 评测项 评测结果 Y/TBD/N/NA 清晰性 1 是否所设计的架构，包括数据流、控制流和接口，被清楚的表达了 Y 2 是否所有的假设、约束、策略及依赖都被记录在本文档了 N 3 是否定义了总体设计目标 Y 完整性 4 是否所有的以前的TBD（待确定条目）都已经被解决了 Y 5 是否设计已经可以支持本文档中遗留的TBD有可能带来的变更 N 6 是否所有的TBD的影响都已经被评估了 Y 7 是否仍存在可能不可行的设计部分 N 8 是否已记录设计时的权衡考虑，该文件是否包括了权衡选择的标准和不选择其他方案的原因 N 依从性 9 该文档是否遵守了公司规定的文档编写标准 Y 一致性 10 数据元素、流程和对象的命名和使用在整套系统和外部接口之间是否一致 Y 11 该设计是否反映了实际操作环境（硬件、软件和支持软件） Y：开发与运行环境规定 可行性 12 从进度、预算和技术的角度上看该设计是否可行 Y：故障处理要求 13 是否存在错误的、缺少的或不完整的逻辑 N 数据使用 14 所有复合数据元素、参数以及对象的概念是否都已文档化 Y：系统设计目标概述 15 是否还有任何需要的，但还没有定义的数据结构，反之亦然 N 16 是否已描述最低级别的数据元素，是否已详细说明取值范围 TBD 功能性 17 是否对每一下级模块进行了概要算法说明 N 18 所选择的设计和算法能否满足所有需求 Y 接口 19 操作界面的设计是否有为用户考虑（例如：词汇、使用信息和进入的简易） Y 20 是否已描述界面的功能特性 Y：UI要求设计要求 21 界面将有利于问题的解决吗 Y：UI要求设计要求 22 是否所有界面都互相一致，与其他模块一致，以及和更高级别文档只中的需求一致 Y 23 是否所有的界面都提供了所要求的信息 Y 24 是否已说明内部各界面之间的关系 Y 25 界面的数量和复杂程度是否已减少到最小 TBD 可维护性 26 该设计是否是模块化的 Y 27 这些模块具有高内聚度和低耦合度吗 Y 28 是否已经对继承设计、代码或先前选择工具的使用进行了详细说明性能 Y：开发与运行环境规定 可靠性 29 该设计是否能够提供错误和恢复吗（例如：输入输出检查） Y：故障处理要求 30 是否已考虑非正常的情况 N 31 是否所有的错误情况都被完整并准确地说明 N 32 该设计是否满足该系统进行集成时所遵守的约定 Y 易测性 33 是否能够对该套系统进行测试、演示、分析或检查来说明它是满足需求的 TBD 34 该套系统是否能用增量型的方法来集成和测试 N 可追溯性 35 是否各部分的设计都能追溯到需求说明书的要求 Y 36 是否所有的设计决策都能追溯到原来确定的权衡因素 Y 37 所继承设计的已知风险是否已确定和分析 N       简单评价： 该系统的设计的架构，包括数据流、控制流和接口，被清楚的表达了，但是假设、约束、策略及依赖都被记录在本文档中，并定义了总体设计目标。以前的TBD（待确定条目）都已经被解决了，并且所有的TBD的影响都已经被评估。对是否仍存在可能不可行的设计部分没有说明。没有记录设计时的权衡考虑，该文件不包括权衡选择的标准和不选择其他方案的原因。该文档遵守了公司规定的文档编写标准。该设计反映了实际操作环境，数据元素、流程和对象的命名和使用在整套系统和外部接口之间是一致的。从进度、预算和技术的角度上看该设计是可行的，不存在错误的、缺少的或不完整的逻辑。所选择的设计和算法能满足所有需求，操作界面的设计为用户考虑，并已描述界面的功能特性。提供了错误检测和恢复，该设计满足了该系统进行集成时所遵守的约定。部分设计都能追溯到需求说明书的要求，所有的设计决策都能追溯到原来确定的权衡因素，但对所继承设计的已知风险没有确定和分析 详细设计说明书评测规范 填表说明：Y—是，TBD—不确定，N—否，NA—不适用。 编号 评测项 评测结果 Y/TBD/N/NA 清晰性 1 所有单元或过程的目的都已文档化 Y：系统结构 2 包括了数据流、控制流和接口的单元设计是否已清晰的说明 Y：系统结构 完整性 3 是否已定义和初始化所有的变量、指针和常量 Y 4 是否已描述单元的全部功能 Y 5 是否已详细说明用来实现该单元的关键算法（例如：用自然语言或PDL） Y 6 是否已列出该单元的调用 Y 依从性 7 该文档是否遵守了公司规定的文档编写标准 Y 8 是否采用了所要求的方法和工具来进行单元设计 Y 一致性 9 数据元素的命名和使用在整个单元和单元接口之间是否一致 Y 10 所有接口的设计是否相互一致并且和更高级别文档一致 Y 正确性 11 是否处理所有条件（>0、=0、<0、switch/case），是否存在处理“case not found”的条件 Y 12 是否正确的规定了分支（逻辑没有颠倒） Y 数据使用 13 是否所有声明的数据都被实际使用到 Y 14 是否所有该单元的数据结构都被详细说明 Y 15 是否所有修改共享数据（或文件）的程序都考虑到了其他程序对该共享数据（或文件）的存取权限 TBD 16 是否所有逻辑单元、时间标志和同步标志都被定义和初始化 TBD 接口 17 接口参数在数量、类型和顺序上是否匹配 Y 18 是否所有的输入和输出都被正确定义和检查 Y 19 是否传递参数序列都被清楚的描述 Y 20 是否所有参数和控制标志由已描述的单元传递或返回 Y 21 是否详细说明了参数的度量单位、取值范围、正确度和精度 TBD 22 共享数据区域及其存取规定的映射是否一致 Y 可维护性 23 单元是否具有高内聚度和低耦合度（例如：对该单元的更改不会在该单元有任何无法预料的影响并对其他单元的影响很小 Y 性能 24 是否该单元的所有约束（例如：过程时间和规模）都被详细说明 Y 可靠性 25 初始化是否使用到缺省值，缺省值是否正确 N 26 是否在内存访问的时候执行了边界检查（例如：数组、数据结构、指针等）来确保只是改变了目标存储位置 Y 27 是否执行输入、输出、接口和结果的检查 Y 28 是否对所有错误情况都发出有意义的信息 TBD 29 对特殊情况返回的代码是否和已规定的全局定义的返回代码相匹配 Y 30 是否考虑到意外事件 N 易测性 31 是否能够对每个单元进行测试、演示、分析或检查来说明它们是满足需求的 Y 32 该设计是否包含检查点来帮助测试（例如：有条件的编译代码和数据声明测试） N 33 是否所有的逻辑都能被测试 TBD 34 是否已描述测试程序、测试数据集和测试结果 Y 可追溯性 35 是否设计的每一部分都能追溯到其他项目文档的要求，也能追溯到更高级别文档的要求 Y 36 是否所有的设计决定都能追溯到权衡考虑 Y 37 单元需求是否都能上溯到更好级别的文档，更改级别文档的需求是否已经在单元中体现 Y       简单评价： 该系统的所有单元或过程的目的都已文档化，包括了数据流、控制流和接口的单元设计都已清晰的说明。已定义和初始化所有的变量、指针和常量，描述单元的全部功能，详细说明用来实现该单元的关键算法，并已列出该单元的调用。该文档遵守了公司规定的文档编写标准，采用了所要求的方法和工具来进行单元设计。所有接口的设计相互一致并且和更高级别文档一致，数据元素的命名和使用在整个单元和单元接口之间也一致。正确的规定了分支，所有声明的数据都被实际使用到，所有该单元的数据结构都被详细说明。所有的输入和输出都被正确定义和检查，传递参数序列都被清楚的描述，对所有错误情况都发出有意义的信息。能够对每个单元进行测试、演示、分析或检查来说明它们是满足需求的，已描述测试程序、测试数据集和测试结果。设计的每一部分都能追溯到其他项目文档的要求，也能追溯到更高级别文档的要求。单元需求都能上溯到更好级别的文档，更改级别文档的需求已经在单元中体现。