完整版自动化测试计划文档格式.docx
《完整版自动化测试计划文档格式.docx》由会员分享，可在线阅读，更多相关《完整版自动化测试计划文档格式.docx（16页珍藏版）》请在冰豆网上搜索。
设.........................................................
...........
角色和职
责.........................................................
安全性测
...................
5.3界面测
易用性测
.....................
..................
性能测
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.功能性测试
方法和标准
使用UFT或许selenium自动化任务模块，而且在脚本中使用框架。
A.新闻模块
新建新闻
正确输入各项内容点
页面新增新闻成功，
击新建按钮
数据库表中成功导入
改数据
不知足输入条件的输
弹犯错误信息
入项
删除新闻
选择一个新闻，点击
该新闻被成功删除，
删除按钮
数据库表中该数据被
成功删除
编写新闻
选择一个新闻，进入
页面中新闻内容被更
编写页面，更新数据
新，数据库中数据也
点击保留
被更新
搜寻新闻
输入新闻的标题等信
显示切合检索条件
息点击搜寻
的新闻信息
B.通告模块
新建通告
页面新增通成功功，
删除通告
选择一个通告，点击
该通告被成功删除，
编写通告
选择一个通告，进入
页面中通告内容被更
搜寻通告
输入通告的标题等信
的通告信息
C.人脉模块
新建人脉
页面新增人脉成功，
管理人脉
选择联系人，点击删
该联系人被成功删
除按钮
除，数据库表中该数
据被成功删除
选择一个人脉种类，
页面弹出excl
信息
选择一个或许多个
联系人，能够导出联
系人信息到excl中
点击组按钮
讲联系人挪动到
不
同组别中
时间和安排
自动化测试周期估计为两天。
角色和职责
详细工作量安排以下表：
序号
任务
负责人
工作量
1
登录模块
3人2天
新闻模块
2
通告模块
2人2天
3
人脉模块
登出模块
安全性测试
方法和标准
内容
明确划分系统中不一样用户权限
系统中会不会出现用户矛盾
用户登岸密码是不是可见、可复制
4
模拟非受权攻击，看防备系统能否牢固
5
采纳各样木马检查工具检查系统木马状况
6
系统数据能否机密
7
系统数据的完好性
8
系统数据可管理性
9
系统数据的独立性
10
系统数据可备份和恢复能力
5.3界面测试
长宽靠近黄金点比率，切忌长宽比率失
调、或宽度超出长度。
布局要合理，不宜过于密集，也不可以过
于空阔，合理的利用空间。
按钮大小基本邻近，忌用太长的名称，
省得占用过多的界面地点。
按钮的大小要与界面的大小和空间要
协调。
远景与背风景搭配合理协调，反差不宜
太大，最好少用深色，如大红、大绿等。
假如菜单项选择项许多，应当采纳加长菜单
的长度而减少深度的原则摆列。
安装界面上应有单位介绍或产品介绍，
并有自己的图标。
主界面，最好是大部分界面上要有公司
图标。
5.4易用性测试
性能测试
用户界面能否干净、不冒昧、不拥堵？
UI的组织和布局合理吗？
有剩余功能吗？
帮助系统有效吗？
软件使用起来应当舒坦，不可以给用户工作制造阻碍和困难。
切合标准和规范
确立系统最大蒙受量，比如系统最大用户数，最大储存量，最多办理的数据流量等。
测试硬件系统能否达到需求文档设计的性能目标
比较新的或未知测试对象与已知参照
标准（如现有软件或评测标准）的性能。
核实在保持配置不变的状况下，测试对
象在不一样操作条件（如不一样用户数、
事务数等）下性能行为的可接受性。
核实测试用户同时使用软件程序的最
大数目。
6.组织形式
角色
姓名
职责
组员
李雪琴
人脉模块，登出模块的功能性测试，界面测
试
刘欢
李晋华
通告模块的功能性测试，安全性测试
朱志贵
登录模块，新闻模块的功能性测试，性能测试
组员苏航通告模块的功能性测试，安全性测试
邓鹏
人脉模块，登出模块的功能性测试，性能测
李力
组长牟亚飞测试计划书编写，登录模块，新闻模块的功能性测
试，易用性测试
7.测试进度
测试阶段
开始时间
结束时间
资源
能否里程碑
测试用例编写
19
日
20
测试用例评审
√
测试计划编写
21
功能测试
界面测试
性能需求
易用性测试
8.质量目标
编写
测试质量目标
确认人以及特别说明
测试已实现的产品能否达到设计的要求，包含：
各个功能点能否
2个人交错负责
以实现，业务流程能否正确
全部的测试用例已经履行过
一个人检查
全部的自动测试脚本已经履行经过
不一样意存严重程度为高和中的功能缺点
缺点的发现速率正在降落并靠近0
在最后的三天内没有发现严重程度为高和中的缺点
升级会员 