一篇完整的测试方案怎么写
一个完整的项目测试方案
看上面的目录，详细
文档说明
|
文档名称 |
创建人/修改人 |
版本 |
时间 |
备注 |
|
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模板要求内容编写 |
|
人力资源风险 |
软件测试时间，成本风险造成的不能对软件进行较全面的测试，导致测试不完善 |
保障主流程和重点功能的前提下，通过预设回归时间和交叉测试进行尽可能覆盖 |
魔乐社区（Modelers.cn) 是一个中立、公益的人工智能社区，提供人工智能工具、模型、数据的托管、展示与应用协同服务，为人工智能开发及爱好者搭建开放的学习交流平台。社区通过理事会方式运作，由全产业链共同建设、共同运营、共同享有，推动国产AI生态繁荣发展。
更多推荐
8
0- 0
已为社区贡献5条内容
所有评论(0)