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

看上面的目录，详细

文档说明

文档名称	创建人/修改人	版本	时间	备注
		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-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，1280*1024，1024*768，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模板要求内容编写
人力资源风险	软件测试时间，成本风险造成的不能对软件进行较全面的测试，导致测试不完善	保障主流程和重点功能的前提下，通过预设回归时间和交叉测试进行尽可能覆盖