自动化测试计划Word格式.docx
- 文档编号:18247589
- 上传时间:2022-12-14
- 格式:DOCX
- 页数:11
- 大小:94.63KB
自动化测试计划Word格式.docx
《自动化测试计划Word格式.docx》由会员分享,可在线阅读,更多相关《自动化测试计划Word格式.docx(11页珍藏版)》请在冰豆网上搜索。
5.5.1方法和标准.........................................................................
6.组织形式.............................................................................
7.测试进度................................................................................
8.质量目标................................................................................
1.目标
本次自动化测试需要完成的目标如下:
A.根据自动化测试小组讨论结果,对可自动化的模块及其手工测试用例进行自动化测试。
B.本次自动化测试由8名自动化测试人员在5天之内完成自动化测试脚本的编写及运行分析。
2.测试对象
根据小组讨论,我自动化测试小组将对“小薇企业信息化”网站的登录模块,公告模块,新闻模块,人脉模块及其登出模块进行自动化设计,这些模块相对比较适合自动化测试,如下图所示:
3.自动化测试通过标准
通过标准:
1、基本流程能够通畅的完成,核心功能可以体现;
2、对具备分支的流程,确保有一种分支可以持续使用,另外几种要求可以体现设置方法和直接效果,否则就应暂时屏蔽分支功能;
3、基本界面符合术语规范,不存在错误或明显歧义;
所有可使用的流程中的界面设计工作必须完成;
4、按照标准流程没有出现各种非正常提示;
5、关键流程和流程中的基本数据备份恢复没有问题;
6、所有报表能够在基本数据的基础上正确生成。
4.自动化测试挂起和恢复条件
A.挂起条件:
1.主业务流上某些问题导致工作流不通顺;
2.某些功能模块的问题导致依赖其实现的功能不能测试;
3.出现大量的BUG,测试继续执行没有意义。
4.资源的短缺,如测试过程中需要抽调人员到其他任务中;
5.测试中发现程序结构(或业务)不合理,这些是由于项目前期工作不充分造成,如没有完善的需求调研,没有概要、详细设计等;
6.用例的通过度。
这需要建立在用例通过评审,达到既定覆盖率,且有效性合格。
B.恢复条件:
测试恢复的条件是接收软件时先进行冒烟测试,引起挂起的测试用例重新测试通过之后,可以恢复测试。
5.功能性测试
5.1.1方法和标准
使用UFT或者selenium自动化任务模块,并且在脚本中使用框架。
A.新闻模块
新建新闻
正确输入各项内容点击新建按钮
页面新增新闻成功,数据库表中成功导入改数据
不满足输入条件的输入项
弹出错误信息
删除新闻
选择一个新闻,点击删除按钮
该新闻被成功删除,数据库表中该数据被成功删除
编辑新闻
选择一个新闻,进入编辑页面,更新数据点击保存
页面中新闻内容被更新,数据库中数据也被更新
搜索新闻
输入新闻的标题等信息点击搜索
显示符合检索条件的新闻信息
B.公告模块
新建公告
页面新增公告成功,数据库表中成功导入改数据
删除公告
选择一个公告,点击删除按钮
该公告被成功删除,数据库表中该数据被成功删除
编辑公告
选择一个公告,进入编辑页面,更新数据点击保存
页面中公告内容被更新,数据库中数据也被更新
搜索公告
输入公告的标题等信息点击搜索
显示符合检索条件的公告信息
C.人脉模块
新建人脉
页面新增人脉成功,数据库表中成功导入改数据
管理人脉
选择联系人,点击删除按钮
该联系人被成功删除,数据库表中该数据被成功删除
选择一个人脉类型,选择一个或者多个联系人,可以导出联系人信息到excl中
页面弹出excl信息
点击组按钮
讲联系人移动到不同组别中
5.1.2时间和安排
自动化测试周期预计为两天。
5.1.3角色和职责
具体工作量安排如下表:
序号
任务
负责人
工作量
1
登录模块
3人2天
新闻模块
2
公告模块
2人2天
3
人脉模块
登出模块
5.2安全性测试
5.2.1方法和标准
内容
明确区分系统中不同用户权限
系统中会不会出现用户冲突
用户登陆密码是否是可见、可复制
4
模拟非授权攻击,看防护系统是否坚固
5
采用各种木马检查工具检查系统木马情况
6
系统数据是否机密
7
系统数据的完整性
8
系统数据可管理性
9
系统数据的独立性
10
系统数据可备份和恢复能力
5.3界面测试
5.3.1方法和标准
长宽接近黄金点比例,切忌长宽比例失调、或宽度超过长度。
布局要合理,不宜过于密集,也不能过于空旷,合理的利用空间。
按钮大小基本相近,忌用太长的名称,免得占用过多的界面位置。
按钮的大小要与界面的大小和空间要协调。
前景与背景色搭配合理协调,反差不宜太大,最好少用深色,如大红、大绿等。
如果菜单选项较多,应该采用加长菜单的长度而减少深度的原则排列。
安装界面上应有单位介绍或产品介绍,并有自己的图标。
主界面,最好是大多数界面上要有公司图标。
5.4易用性测试
5.4.1方法和标准
用户界面是否洁净、不唐突、不拥挤?
UI的组织和布局合理吗?
有多余功能吗?
帮助系统有效吗?
软件使用起来应该舒适,不能给用户工作制造障碍和困难。
符合标准和规范
5.5性能测试
5.5.1方法和标准
确定系统最大承受量,譬如系统最大用户数,最大存储量,最多处理的数据流量等。
测试硬件系统是否达到需求文档设计的性能目标
比较新的或未知测试对象与已知参照标准(如现有软件或评测标准)的性能。
核实在保持配置不变的情况下,测试对象在不同操作条件(如不同用户数、事务数等)下性能行为的可接受性。
核实测试用户同时使用软件程序的最大数量。
6.组织形式
角色
姓名
职责
组员
李雪琴
人脉模块,登出模块的功能性测试,界面测试
刘欢
李晋华
公告模块的功能性测试,安全性测试
朱志贵
登录模块,新闻模块的功能性测试,性能测试
苏航
邓鹏
人脉模块,登出模块的功能性测试,性能测试
李力
组长
牟亚飞
测试计划书编写,登录模块,新闻模块的功能性测试,易用性测试
7.测试进度
测试阶段
开始时间
结束时间
资源
是否里程碑
测试用例编写
19日
20日
测试用例评审
√
测试计划编写
21日
功能测试
安全性测试
界面测试
性能需求
易用性测试
8.质量目标
编写
测试质量目标
确认人以及特殊说明
测试已实现的产品是否达到设计的要求,包括:
各个功能点是否以实现,业务流程是否正确
2个人交叉负责
所有的测试用例已经执行过
一个人检查
所有的自动测试脚本已经执行通过
不允许存严重程度为高和中的功能缺陷
缺陷的发现速率正在下降并接近0
在最后的三天内没有发现严重程度为高和中的缺陷
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 自动化 测试 计划