软
件
测
试
计
划
书
修订历史记录
版本 | 日期 | AMD | 修订者 | 说明 |
1.0 | 2023年05月09日 | 杨子熙 | 2140129186 | |
(A-添加,M-修改,D-删除)
目录
1.简介
1.1目的
<智慧医疗系统>的这一“测试计划”文档有助于实现以下目标:
- 确定现有智慧医疗系统项目的信息和应测试的软件构件。
- 列出推荐的智慧医疗系统测试需求(高级需求)。
- 推荐可采用的测试策略,并对这些策略加以说明。
- 确定所需的资源,并对测试的工作量进行估计。
- 测试已实现的智慧医疗系统产品是否达到设计的要求,包括:各个功能点是否以实现,业务流程是否正确。
- 智慧医疗系统产品规定的操作和运行稳定。
- Bug数和缺陷率控制在可接收的范围之内。
- 列出测试智慧医疗系统项目的可交付元素。
1.2背景
1.3范围
本测试计划是针对<智慧医疗系统>项目中规定内容的测试计划,包括:
- 药品商城列表
- 购物车修改
- 医师信息列表
- 我的预约列表
- 个人主页
- 首页信息
- 登录页面
2.测试参考文档和测试提交文档
2.1测试参考文档
文档 (版本/日期) | 已创建或可用 | 已被接收或已经过复审 | 作者或来源 |
可行性分析报告 | 是√ 否□ | 是√ 否□ | 杨子熙 |
软件需求定义 | 是√ 否□ | 是√ 否□ | 杨子熙 |
软件系统分析 (STD,DFD,CFD,DD) | 是√ 否□ | 是√ 否□ | 杨子熙 |
软件概要设计 | 是√ 否□ | 是√ 否□ | 杨子熙 |
软件详细设计 | 是√ 否□ | 是√ 否□ | 杨子熙 |
软件测试需求 | 是√ 否□ | 是√ 否□ | 杨子熙 |
测试计划 | 是√ 否□ | 是√ 否□ | 杨子熙 |
测试方案 | 是√ 否□ | 是√ 否□ | 杨子熙 |
测试报告 | 是√ 否□ | 是√ 否□ | 杨子熙 |
测试分析报告 | 是√ 否□ | 是√ 否□ | 杨子熙 |
2.2测试提交文档
- 测试计划
- 测试用例
- 测试Bug单
- 测试小结
- 测试分析报告
3.测试进度
测试活动 | 计划开始日期 | 实际开始日期 | 结束日期 |
制定测试计划 | 2023.5.10 | 2023.5.11 | 2023.5.21 |
设计测试 | 2023.5.24 | 2023.5.24 | 2023.5.28 |
集成测试 | 2023.5.31 | 2023.5.31 | 2023.6.4 |
系统测试 | 2023.6.7 | 2023.6.8 | 2023.6.11 |
性能测试 | 2023.6.14 | 2023.6.15 | 2023.6.18 |
安装测试 | 2023.6.20 | 2023.6.20 | 2023.6.25 |
用户验收测试 | 2023.6.27 | 2023.6.28 | 2023.7.8 |
对测试进行评估 | 2023.7.8 | 2023.7.8 | 2023.7.9 |
产品发布 | 2023.7.12 | 2023.7.12 | 2023.7.16 |
4.测试资源
4.1人力资源
下表列出了在此项目的人员配备方面所作的各种假定。
[注:可适当地删除或添加角色项。]
角色 | 所推荐的最少资源(所分配的专职角色数量) | 具体职责或注释 |
开发人员 | 7 | 打包、编译 |
审核人员 | 2 | 审核并提交测试 |
接收测试人员 | 4 | 接收测试 |
测试人员 | 4 | 开始测试 |
4.2测试环境
软件环境(相关软件、操作系统等) |
Windows7以上操作系统 |
Bug管理工具为经过改进的Bug管理工具 |
硬件环境(网络、设备等) |
稳定的测试服务器,IP地址为:172.17.104.50 |
惠普暗影精灵游戏本 |
4.3测试工具
用途 | 工具 | 生产厂商/自产 | 版本 |
测试管理 | TestDirector | 未授权 | 最新 |
接口测试 | Jmeter | 未授权 | 最新 |
性能测试 | loadrunner | 未授权 | 最新 |
代码扫描 | findbugs | 未授权 | 最新 |
5.系统风险、优先级
本次测试过程中,可能出现的风险如下:
- bug的修复情况
- 模块功能的实现情况
- 系统整体功能的实现情况
- 代码的编写质量
- 人员经验以及对软件的熟悉度
- 开发人员、测试人员关于项目约定的执行情况
- 人员调整导致研发周期延迟
- 开发时间的缩短导致某些测试计划无法执行
6.测试策略
6.1功能测试
测试目标 | 系统能按照设计要求实现模块的各个功能,数据应完整、操作方便。 |
测试范围: | 产品质量要满足客户提出的功能性需求、改进性能、可用性、可重用性、 可行性等功能性需求;产品设计和实现应该使其能满足特定的功能性需求和规范。 |
技术: | 用户登录信息是否能够正确回显,并输入到系统中? 图形模式的数据项(如滑动条、按钮事件)是否正常工作? 是否能够识别非法数据? 增删改查功能是否实现? 数据输入消息是否可理解? 跨页面传参功能是否可实现? |
开始标准: | 硬件环境可用且软件正确安装完成。 |
完成标准: | 功能测试用例设计已经通过评审 ; 达到了测试计划中关于测试所规定的覆盖率的要求; 系统满足需求规格说明书的要求; 在系统测试中发现的错误已经得到修改,各级缺陷修复率达到标准。 |
测试重点和优先级: | 药品商城列表
购物车修改
医师信息列表
我的预约列表
个人主页
首页信息
登录页面
|
需考虑的特殊事项: | 涉及信息保存和跨页面传参功能的需要在登录状态下进行测试。 |
6.2用户界面测试
测试目标 | 界面美观,检查界面中功能、字段、操作按钮、链接等是测试中重要的一部分。 能够正确反映业务的功能和需求; 窗口与窗口之间、字段与字段之间的浏览直观大方; 各种访问方法(Tab键、鼠标移动、和快捷键)的使用正常便捷; 窗口的对象和特征都符合标准。 |
测试范围: | ① 按钮:个数、名称、布局是否合理; |
技术: | 为药品商城列表、购物车修改、医师信息列表、我的预约列表、个人主页、首页信息、登录页面每个窗口创建或修改测试,以核实各个应用程序窗口和对象都可正确地进行浏览,并处于正常的对象状态。 |
开始标准: | 硬件环境可用且界面功能正确部署完成。 |
完成标准: | 成功地核实出药品商城列表、购物车修改、医师信息列表、我的预约列表、个人主页、首页信息、登录页面窗口都与基准版本保持一致,并且符合可接受标准。 |
测试重点和优先级: | 1.界面控件标题是否正确 对于界面控件,其标题需要准确无误,不能给用户产生歧义,在不同的页面中,对于同一个意义的控件,需要保持一致。 2.界面控件必选项检测 对于必须输入的选项,需要用*标明,在界面提交后,需要进行检查该功能是否实现。 3.下拉框选择项检查 对于下拉框选项,需要与业务保持一致,要避免没有必要的选项,同事也需要保持选项没有遗漏。 4.文本输入框检查 文本输入框,如果有最大输入长度的限制,需要制定最大长度,可以减少输入错误的几率。 5.输入合法性检查 对于界面输入,需要进行合法性检查,如特殊字符需要限制不能输入,业务对输入的特殊限制。同事还需要进行边界值检查。 6.联动关系检查 对于需要实现联动的界面控件,需要检查联动是否实现,并且需要查看选项,查看是否正确。 7.按钮功能是否实现 对于重置按钮和取消按钮,查看是否实现重置、取消功能,对于提交按钮,需要检查是否实现提交功能,并转向指定的页面。 8.提交参数是否正确 对于通过界面控件提交参数,需要检查提交的参数是否争取也,尤其是一些通过特殊处理的参数,如金额转换的参数。 9.界面布局检查 对于一些复杂的界面,最好需要经过泰伦,以生成合适的布局。 10.界面提示信息准确性的检查 界面的提示信息有助于帮助用户理解界面控件的功能。准确的提示信息有助于提高用户界面操作的正确性。对于容易造成误解的操作,都需要提供提示信息。 11.警告信息和错误提示信息的检查 警告信息和错误提示信息帮助用户定位错误,应该简短明确。 12.新的需求和需求变更,是否实现 在系统开发过程中,新的需求和需求变更时难免的。对于这种情况,需要检查到吗是否做了及时的更新。 13.查询操作,需要检查返回结果是否符合条件 根据条件进行查询,是界面中的常用功能,在查询时,不仅要检查界面是否有返回结果,而且还需要检查返回的结果是否符合条件的记录。 |
需考虑的特殊事项: | 涉及信息保存和跨页面传参功能的需要在登录状态下进行测试。 |
7.问题严重度描述
问题严重度 | 描述 | 响应时间 |
高 | 系统崩溃 | 程序员在3小时改正此问题 |
中 | 系统报错 | 程序员在2小时改正此问题 |
低 | 系统缓慢 | 程序员在1小时改正此问题 |
8.附录:项目任务
以下是一些与测试有关的任务:
- 制定测试计划
- 确定测试需求
- 评估风险
- 制定测试策略
- 确定测试资源
- 创建时间表
- 生成测试计划
- 设计测试
- 准备工作量分析文档
- 确定并说明测试用例
- 确定测试过程,并建立测试过程的结构
- 复审和评估测试覆盖
- 实施测试
- 记录或通过编程创建测试脚本
- 确定设计与实施模型中的测试专用功能
- 建立外部数据集
- 执行测试
- 执行测试过程
- 评估测试的执行情况
- 恢复暂停的测试
- 核实结果
- 调查意外结果
- 记录缺陷
- 对测试进行评估
- 评估测试用例覆盖
- 评估代码覆盖
- 分析缺陷
- 确定是否达到了测试完成标准与成功标准
- 设计测试