软件测试文档-测试计划模版(功能与性能)
测试计划概念:就在软件测试工作实施之前明确测试对象,并且通过资源、时间、风险、测试范围和预算等方面的综合分析和规划,保证有效的实施软件测试。
需求挖掘的6个方面:
1、输入方面
2、处理方面
3、结果输出方面
4、性能需求方面
5、用户接口方面
6、硬件接口方面
软件测试人员需要写的测试文档:
1、测试大纲
2、测试方案
3、测试计划(也有的分功能和性能)
4、测试用例(功能用例、性能用例等)
5、缺陷报告
6、测试总结报告(功能测试报告、性能测试报告等)
测试方案的内容:
1、概述【测试项目简介、设计题目、设计目的、设计背景简介】
2、需求分析【系统概述、系统主要功能设计、性能需求、兼容性需求】
3、测试计划【测试进度、测试环境、系统风险与优先级、测试项目确认、测试方法、参考资料】
测试计划的内容:
1、测试目的 《阐明软件实现什么样的功能、功能测试中达到多少的覆盖率;各项非性能测试中,软件达到怎样的指标等》
2、测试目标《测试项目的简介》
3、测试参考文档
4、测试提交文档
5、术语和定义
6、测试范围 《软件产品哪些部分进行测试或者哪些部分不用进行测试;指明某些部分不在现有的测试范围之内;指明所处的测试阶段是单元测试、集成测试、系统测试、验收测试;指明该测试包含的功能测试和非功能测试的类型》
7、测试方法《该测试活动所使用的黑盒、白盒、灰盒方法,或者多者兼有,指出测试方法的名称和在哪些情况下使用该方法》
8、测试思路 针对具体的功能点或性能指标。
9、测试资源/预算《包括人力资源和设备资源等,包含测试小组可能接触的人和测试小组直接参与测试活动的人,将以上人员列成一张表,有姓名、职务、联系方式和职责范围等;设备资源管理包括文档归档、软件工具归档和其他硬件设备分配,将用到的文档和软件工具制成一张表,在表中报考文档或软件工具的名称、版本、用途和下载地址等》
10、测试进度 《设计文档的完成作为开发测试用例阶段的起始点,在此基础上加上时间期限;测试设备进行预定和调试安装这部分内容考虑进去,并且责任到人》
11、测试策略 《测试策略是配合测试阶段来做的,指明测试活动中用到什么测试手段,白盒、黑盒或是灰盒,或是多者兼有,描述为什么使用测试手段,有了测试手段就可以确定测试方法,描述各种测试方法在测试中的适用范围和为什么要使用该方法;若需要进行自动化测试,要分析自动化测试和手动测试的分配情况,阐明为什么如此安排;测试工具的选择,如测试用例管理工具、缺陷管理工具、自动化测试工具以及性能测试工具等,都要一一分析并阐明理由》
12、风险和问题
测试计划设计工具:Word、Excel、Project。
现在很多公司一般有多个软件测试人员,每个人负责的模块不一样,形成分工,那么就容易出现一些因任务分解而带来的风险。
测试总结报告的内容:
1、简介
2、测试背景
3、测试计划进度执行情况
4、测试执行阶段情况报告
5、缺陷统计与分析
6、测试结论与建议
测试完成准则:
1 所有测试案例已经运行
2 所有软件缺陷已经解决和终结
3 对软件缺陷的所有修改都已经进行了回归测试
4 软件缺陷后,所有相关软件文档版本均已经更新
5 测试报告已经通过评审并获得批准
功能测试计划模板截图:
性能测试计划模板截图:
软件测试计划模版(总括型)
序号 | 时间 | 修改人 | 主要变化 |
1 | 2021-09-20 | 齐哈 | 创建 |
2 | 2021-12-14 | 建哈 | 修改“测试人员安排” |
... | ... | ... | ... |
一、测试工作任务
1. 系统组成
陈述系统组成情况,例如总体功能,有哪些子系统,可以附一张系统结构图。
如:
为提高xx的市场占有率,方便用户,所以开发项目。
xx项目的主要功能包括:
(1)登录;
(2)社区;
(3)生活;
(4)管家;
(5)我的。
同时,在性能上要满足10万人同时在线的需要。
2. 各子系统的需求概要
简单陈述各子系统的需求,让人看过之后对系统有一个大致的了解。
如:
(1)登录:xxxxx。
(2)社区:xxxxx。
(3)生活:xxxxx。
(4)管家:xxxxx。
(5)我的:xxxxx。
3. 开发进度
测试离不开开发,而且在现实中测试对开发工作有相当大的依存度。这里介绍开发进度,是为后面介绍测试工作安排做铺垫。
如:
里程碑 | 立项与调查 | M1(第一阶段) | M2(第二阶段) | Beta | RC(选择版本) | RTM(发布) |
时间 | 2021/01/02-01/15 | 2021/01/16-02/28 | 2021/03/01-04/30 | 2021/03/01-04/30 | 2021/03/01-04/30 | 2021/03/01-04/30 |
目标 | 做一些技术调研,尝试发现xx技术难题 |
(1)登录 (2)社区 (3)生活 |
(1)管家 (2)我的 |
(1)提高性能 (2)修正以前发现而没有来得及修改的bug |
(1)修改所有需要修改的bug (2)选择一个稳定的版本,准备发布 (3)整理Beta用户的反馈 |
(1)对选定的版本最最后的验证测试 (2)发布 |
4. 开发人员安排
让测试员知道模块都是由谁负责,方便测试进行中的交互。
如:
开发人员 | 模块 |
xx | (1)登录 |
xx |
(1)社区 (2)生活 |
二、测试工作安排
1. 测试人员安排
人员安排,包括测试工作分配。
如:
测试人员 | 模块 | 其他工作 |
xx | (1)登录 |
测试管理工作 性能测试 |
xx |
(1)社区 (2)生活 |
搭建测试环境、配置管理 |
2. 测试进度
时间安排。
如:
里程碑 | 立项与调查 | M1(第一阶段) | M2(第二阶段) | Bata | RC(选择版本) | RTM(发布) |
时间 | 2021/01/02-01/15 | 2021/01/02-01/15 | 2021/01/02-01/15 | 2021/01/02-01/15 | 2021/01/02-01/15 | 2021/01/02-01/15 |
目标 |
(1)人员到位 (2)准备测试用的计算机和相关软件 |
(1)制定和评审测试计划 (2)编写测试用例并作评审 (3)搭建测试环境 (4)作M1功能测试 |
(1)作M2的功能测试 (2)作性能测试 |
(1)用户测试 (2)做所有功能的测试 (3)作性能测试 |
(1)及时验证开发人员所做的修改 (2)做所有功能的测试 (3)做性能测试 |
(1)对选定的版本最最后的验证测试 |
3. 测试环境的要求和搭建
测试环境是测试的基础,非常重要,所以单独列出来。最好能过去㓵需要的所有软硬件资源和具体负责人。
如:
项目 | 操作系统 | 浏览器 | 其他 |
具体要求 |
WindowsXP Windows10 Mac |
IE9 Firefox 10 Sofari Google 9 |
各种弹窗阻止程序 Google工具条 |
4. 联合测试的安排
测试工作以模块为单位分解到人以后,跨模块的功能比较容易被忽视,模块之间的联合测试需要有人来协调。这里确定具体的时间和负责人。
如:
负责人 | 模块 | 时间 |
xx | xx | xx |
xx | xx | xx |
5. 现场测试的安排
这一点是可选的,有些行业应用软件需要现场安装调试,确定现场测试的时间、地点、负责人和通过标准。
如:
负责人 | 地点 | 时间 | 通过标准 |
xx | xx | xx |
(1)运行所有优先级为0和1的测试用例 (2)作为期3天的性能测试,模拟10万用户同时在线 |
6. 如何选定发布版本及其测试
这里确定测试退出(测试结束)的标准,测试什么时候结束,达到什么样的标准后软件可以发布出去?
如:
(1)运行所有优先级为0和1的测试用例;
(2)保证5万人连续7天同时在线;
(3)优先级为2的测试用例通过率为90%以上。
7. 工作接口制度
在测试组内部,有什么事情应该去找谁?如果要和开发组交互,应当通过谁?或者有什么流程?
如:
(1)测试组只接受通过了BVT测试(冒烟测试)的版本做测试;
(2)测试人员有任何疑问,可以直接找相应的开发人员;
(3)测试人员和开发人员有不同意见的问题,可以提交给测试组长或开发组长;
(4)需求问题可以提交给需求组长。
8. 版本控制
使用什么来做版本控制,有什么重要规定?如果还有单独的配置管理计划,这里可以见到写一下。如果没有可以把版本控制的具体规定写下来。
如:配置管理工作由XX负责,具体安排请参阅《XX项目配置管理计划》。
9. 其他提示
其他未尽事项。
如:空。
三、测试风险
普通测试员不会考虑整体层面上的测试工作风险,所以测试组长和测试经理需要分析测试工作可能存在的风险以及应对办法。例如:
(1)某些测试环境难以搭建
(2)测试时间少
(3)测试人员的水平可能达不到工作要求
(4)需求变更带来的风险
(5)测试员没有本行业软件的开发经验或者测试经验
(6)测试团队的建立需要时间
(7)各子系统之间的开发进度不一造成测试进度不能统一
(8)程序界面设计没有一个标准,造成这方面的测试没有标准
(9)整个开发小组不适应或者违反配置管理的规定
如:
(1)各阶段留给测试的时间比较少。应对办法:开发人员要按时完成开发任务,不占用测试时间。
(2)不同浏览器对脚本语言会有一些不同的解释,这既是开发风险,也是测试风险。应对办法:在调研阶段对这一方面多做调查。
(3)要支持Windows平台和非Windows平台,增加测试自动化的难度。应对办法:测试自动化优先只考虑Windows平台。
(4)需求小组、开发小组和测试小组的磨合需要一段时间。应对办法:这只能通过实际工作或组织活动增进了解。
(5)各种阻止窗口的程序都是变化之中。应对办法:测试环境及时更新阻止弹出窗口的程序,发现问题,及时让开发人员知道。
(6)各浏览器也在升级之中。应对办法:在xxx项目不再支持xxx浏览器版本。
四、参考文档
罗列出相关的需求文档、开发文档和测试文档。
如:
《XX产品需求规格说明书》
《xx产品界面设计需求规格说明书》
《xx产品性能需求规格说明书》
《XX产品概要设计》
《XX产品配置管理计划》
《xx产品市场调研》
《xx产品接口文档》
五、未解决的问题
测试不可能一次就大功告成,把悬而未解决的问题列在这里,方便以后提高和改进。
如:(1)测试计算机还缺10台;
(2)需要购买xxxx;
(3)《XX性能需求规格说明书》中有些指标没有明确。
软件测试计划模版(具体型),适合一个模块或者子系统的测试计划。
序号 | 时间 | 修改人 | 主要变化 |
1 | 2021-01-12 | 齐哈 | 创建 |
2 | 2021-02-14 | 建哈 | 修改“功能测试” |
... | ... | ... | ... |
一、系统概述
1. 系统概述
系统的概括性陈述。
2.系统需求概述
系统需求的概括性陈述,比上一节应详细一些。
3.系统设计概述
开发人员对本系统的设计的概括性陈述。
4.系统的目标客户和运行环境
本系统预期的客户是哪些人群?他们有什么特点和操作习惯?系统将会运行在什么样的软硬件环境之中?
二、测试方案与策略
1.测试方案与策略
准备如何做功能测试、性能测试、压力测试、安全性测试?有无自动化测试的安排?手动测试和自动化测试的大致比例是多少?
2.测试内容说明
本模块或子系统有哪些方面需要测试?
3.测试准备工作
测试准备工作都有哪些?例如测试环境的准备、测试工具的准备。
4.条件与限制
对这个模块或者子系统的测试有哪些依赖性,或者有哪些地方因为条件限制无法进行测试?
三、功能测试
功能测试的具体安排,可以根据功能列表逐一进行讨论,要详细。
四、性能测试
性能测试的具体安排。做性能测试之前,一定要有一个预期的性能指标的定义,例如系统在什么硬件条件下可以允许多少人登录?性能测试需要什么测试工具也要列在这里。
1.性能指标
2.测试工具
3.性能测试安排
五、压力测试
压力测试的安排。压力测试是极端情况下的性能测试,需要建立在性能测试的基础上来做。
六、安全性测试
测试产品在安全性方面的考虑,例如是否会被他人攻击,用户密码是否会被盗取,用户数据是否能恶意删除,程序是否会执行恶意代码,传输的内容是否会被截取和解密,等等。
七、测试进度安排
在整个项目的时间框架下,本模块的测试时间和进度安排。
八、测试退出标准
模块达到什么标准后测试就可以退出。
九、软件质量风险分析
从测试技术的角度出发,去分析本模块是否存在一些质量风险(也就是容易出现问题的地方或者不容易发现问题的地方)。
十、参考文档
相关的需求、开发和测试文档。