一篇完整的测试方案怎么写网站首页 技术教程

一篇完整的测试方案怎么写

测试界的咸鱼仔 2024-07-14 06:01:02

简介一篇完整的测试方案怎么写

看上面的目录，详细

文档说明

文档名称	创建人/修改人	版本	时间	备注
		v1.0	2022-11-17	新建
		v1.1	2022-11-25
		v1.2	2022-12-05
		v2.0	2022-12-13
		v2.1	2022-12-14

一、文档目的

为软件开发项目管理者、软件工程师、系统维护工程师、测试工程师、项目经理提供关于项目系统整体功能和性能的测试指导，同时也是用户确定软件是否完整测试的重要依据

二、项目概述

xxx

三、测试目标

需求覆盖100%，功能错误修复率100%；
测试用例覆盖需求100%，用例执行率100%；
最后一轮回归覆盖率100%，发现问题为0；
bug关闭率100%；

四、测试参考文档

1、GBT 9386-2008 计算机软件测试文档编制规范

2、GBT 15532-2008 计算机软件测试规范

3、本项目原型材料

4、本项目设计图

五、测试范围

1、测试计划和设计：按照项目进度计划和功能清单、产品原型等材料编写测试计划、设计用例，完成测试工作安排；

2、黑盒测试：按照测试用例执行测试，通过输入输出验证系统功能是否满足需求说明书要求；

3、性能测试：根据性能指标进行场景设计和脚本开发，并执行性能测试，评估系统性能情况。

六、测试资源

测试人员、职位、工作职责：

成员角色	姓名	职责、任务
测试组长	xx	编写测试计划，缺陷管理，测试结果分析，开发脚本，性能测试执行，编写测试报告
测试工程师	xx	用例编写，执行测试，记录跟踪报告缺陷
测试工程师	xx	用例编写，执行测试，记录跟踪报告缺陷

需要配合的部门和人员：

成员角色	姓名	工作内容
产品经理	xxx	帮助解决测试人员对产品材料的疑问
技术负责人	xx	协助搭建压测环境，性能指标分析
业务负责人	xx	协助测试了解业务需求，获取第三方原始数据支持测试，提供业务帮助

七、测试规模

7.1 功能点清单

模块	子模块	测试人员	启动时间
			2022-12-19
			2022-12-18
			2022-12-15
			2022-12-15		2022-12-15
		2022-12-19
			2022-12-15
			2022-12-16
				2022-12-26

八、里程碑

8.1 进度进度及工作量

xxx项目测试人员数量为3人，测试时间为29个工作日。

任务名称	开始时间	结束时间	工作量（天）	人数（个）	阶段输出
编写测试计划	2022-11-14	2022-11-15	2	1	《xxx项目测试方案】
系统培训	2023-05-31	2023-05-31	1	1	培训内容记录
编写测试用例	2022-12-01	2022-12-07	5	2	各模板测试用例文件
用例评审	2022-12-08	2022-12-09	2	2	完善的用例文件
功能测试	2022-12-15	2023-01-04	15	2	BUG
性能测试	2023-01-05	2023-01-07	3	1	性能数据
内部验收测试	2023-01-04	2023-01-06	3	2	验收测试报告
编写测试报告	2023-01-08	2023-01-09	2	2	功能测试报告性能测试报告

8.2 测试轮次安排

根据项目实际情况，本次测试共分为4轮，具体安排如下：

测试活动	计划开始	计划结束	实际开始	实际结束
冒烟测试	2022-12-15	2022-12-15
第一轮测试	2022-12-18	2022-12-23
第二轮测试	2022-12-25	2022-12-30
第三轮测试	2023-07-19	2023-07-21

测试内容

1、冒烟：验证系统整体主流程是否已实现，达到提测标准

2、第一轮：功能测试

3、第二轮：缺陷验证，功能测试，用户界面测试，兼容测试

4、第三轮：回归所有功能

九、测试工具

测试管理工具为禅道，性能测试工具为jmeter和takin，用例维护是用例管理平台

工具	版本	用途
禅道	12.5.3	缺陷管理
jmeter	5.3	性能脚本开发
takin	-	性能测试
evolute studio	-	功能测试，用例管理

十、测试方法

10.1、黑盒测试

名称	描述	备注
冒烟测试	对主要功能流程进行验证而设计的案例	此案例针对冒烟测试，通常为每个流程设计一条用例，只需验证正常流程通过即可
UI测试	根据需求文档提供的规则设计用例，检测页面风格一致性，用户操作习惯，显示风格统一等	一个项目的总体规则是固定的，既要保证案例的执行覆盖度，又要避免案例的冗余，所以总体规则可由一个人完成设计，在各个模块下直接复用；测试执行时，可根据需要来进行执行情况的统计。
必填项、输入项验证	主要指在客户端所进行的各类输入数据项的合法性，页面中所必须录入/选择的项目，是否在为空的情况下仍然可以通过提交的检查。	输入验证主要是主要指在xx端和管理系统能够验证或限制的内容，如数据输入长度限制、是否含有非法字符等。必填项则是根据各个页面的必填项不同，要考虑必填项的显示方式，以及非必填项是否也被做了必输限制等。
基本功能测试	当前功能本身的操作及数据流程正确性的测试，包括正常流程和异常流程。	例如，执行报名操作，输入正确和错误密码是否得到了正确的正常和异常返回结果；以及显示的返回结果是否与实际结果一致等。
数据流转测试	主要指xx端与xx端之间的数据通讯是否准确，以及xx和xx流程的数据流转是否正确等。	例如：xxxx成功后，分配的xx是否准确，做的数据权限是否正确
后台线程测试	系统定时任务检查是否正确执行	当前xx结束后，账号是否清除，下次是否需可以重新注册，到xx节点，流程流程是否按时间更新流程数据状态

10.2、兼容测试

兼容性测试主要应针对客户端，并且根据客户的要求并结合实际，确定本次测试把B/S架构项目兼容性测试的重点，在于浏览器和操作系统的兼容测试

兼容对象	测试重点	备注
操作系统	不同的操作系统访问考试系统是否存在问题验证	主要包括Windows7,8,10,11，mac
浏览器	页面各功能的可用性，界面显示的美观、一致性	此为兼容性测试的重点。通常需要兼容谷歌浏览器，火狐浏览器，IE浏览器，360安全浏览器，Edge浏览器，搜狗浏览器，Safari浏览器，UC浏览器，360极速浏览器，QQ浏览器
主流软件	验证支付流程打开其他主流软件，是否会造成冲突	主要针对本次支付过程配置的不同渠道：支付宝，银联，微信等支付流程正常
网络兼容	对不同网络，系统功能是个有影响	wifi，接网线
pc端分辨率	验证主流分辨率下系统的正常性	次为兼容测试重点，包括：1920x1080，12801024，1024768，1400*1050主流分辨率下的页面展示正常

10.3、性能测试【需要确认流程考试阶段日常数据量】

根据客户要求和实际应用场景，性能测试将对以下场景和流程进行性能测试，详细策略如下：

10.3.1 性能测试场景

注册流程：

1、用户从输入信息到提交注册过程中，响应不超过5秒

登录流程：

1、登录接口并发100000用户，响应时间不超过3秒

2、用户从输入账号密码，到登录成功，跳转主页，全流程响应时间不超过10秒

查成绩流程

1、点击查询xx，数据请求到渲染响应不超过5秒

报名提交接口

1、50000用户，下载xx流程1小时内下载50000不报错，稳定运行

2、50000用户，点击上传xx，选择文件，到文件正确渲染流程响应时间不超过10秒

3、50000用户，填写信息后，点击确认提交xx过程响应时间不超过3秒

门户

1、xx开始入口跳转到登录页面，页面正确渲染，不超过5秒

10.3.2 性能测试策略

负载测试：不断增加压力，直到超出预期性能指标，或某种资源达到饱和状态。

（1）能找到系统所能承受的压力（在正常指标、资源范围内，如响应时间超过10秒，CPU大于70%）

（2）可以配合系统调优

并发测试：多用户并发访问同一个应用或模块

（1）主要关注并发访问时，是否内存泄露、死锁、其它资源争用的问题。

（2）“并发用户数”的估算，需要结合实际，并根据特定计算公式得出。

疲劳测试：较长时间的使系统处于一定压力下，看是否能够稳定运行。

（1）使CPU或其他资源处于较高的利用率下，持续运行一定时间，并关注整体运行状况。

（2）使CPU压力增大，可以等同于小压力情况下更长时间的运行效果，相当于是“压缩时间的测试”。

10.4 验收测试

内部验收测试是为了验证系统满足需求说明书要求，满足项目组规定的要实现的功能流程，通过内部验收测试标准

测试项	测试方法	预计结果	实际结果
xx	手工测试	和需求一致
x	手工测试	和需求一致
xx	手工测试	和需求一致
x	手工测试	和需求一致
x	手工测试	和需求一致
x	手工测试	和需求一致

十一、测试通过准则

11.1 验收标准

按照《xxx测试验收标准》当作本项目测试准出标准。即按照用例执行情况作为判断标准：

（1）功能性测试用例通过率达到100%

（2）非功能性测试用例通过率达到95%

（3）没有高于优先级3以上的问题

11.2 验收备选标准

根据实际情况由软件开发部门的经理，项目经理和测试负责人共同讨论确定本测试阶段是否结束。（实际按照每个阶段的准入准出规则）

十二、交付成果

文档	文档内容	文档类型	责任人
测试方案	项目信息、测试内容、测试人员	word	xx
测试用例	项目用例	word	x
功能测试报告	用例执行情况，bug修复情况，测试通过率，参建各方确认	word	x
性能测试报告	用例执行情况，bug修复情况，测试通过率，参建各方确认	word	x
测试规范	xx测试规范文档	word	x

十三、风险预估

风险分类	风险点	预设方案	备注
需求风险	移动端未确定是否要做，需求断续，不能一次确认，逻辑修改较频繁	实施跟进情况，预留了一定人力资源以备移动端的工作安排
开发阶段风险	提测质量不达标	xx月xx日进行冒烟测试，若不达标，返工直到通过方可正常进入测试工作
	研发并行开发其他项目	和研发协商进入测试阶段，中后期通过赶工期、加班，增加人员避免项目验收延期
	延期提测	分批提测，但是不得超过一周还未提测完所有东西	后台主流程还未完成研发，xx日只提测了基本的字段配置，测试有延期风险
文档风险	交付文档要求不确定	先按照word进行文档存档，测试后期排2天工期进行报告输出，测试前会跟进确定文档格式要求	已确定文档按xxx模板要求内容编写
人力资源风险	软件测试时间，成本风险造成的不能对软件进行较全面的测试，导致测试不完善	保障主流程和重点功能的前提下，通过预设回归时间和交叉测试进行尽可能覆盖