网站首页 > 技术文章 正文
《系统测试方案》,整套标准化软件文档书写格式及实际案例分享。
1.引言
1.1.编写目的
本文档基于【XXX】信息化建设项目——“XXX”系统的需求说明书、实施进度计划编制,用于指导项目的测试工作有序进行,确定本轮测试的方法、环境、目标等内容。
读者 | 内容 |
张三 | 审核本文档,确定本测试方案符合本轮测试的要求 |
李四 | 阅读整篇文档,了解项目基本情况及测试目标、测试内容 |
1.2.项目背景
【填写项目背景】。
1.3.读者对象
项目经理、开发工程师、测试工程师及其他项目相关人员。
1.4.参考资料
编号 | 名称 | 版本号 | 描述 | 备注 |
1 | 用户需求说明书 | V1.0 | / | 无 |
2 | 概要设计说明书 | V1.0 | / | 无 |
3 | 详细设计说明书 | V1.0 | / | 无 |
1.5.术语与缩略语
(1) B/S架构:该模式为浏览器对服务器形式。
(2) 测试用例:测试工程师根据《用户需求说明书》编写出来模拟系统所有功能的正确操作、错误操作的一系列操作说明,确保系统在任何操作前提下都能得出预期的结果。
(3) 功能测试:测试工程师在不知道系统或组件内部结构的情况下,根据《测试用例》对系统进行全面的测试。
(4) 性能测试:测试工程师对项目经理确认出来的常用功能点进行性能测试用例的编制,模拟指定范围内的用户操作并发执行,确保系统能稳定运行。
(5) 安全测试:对系统的安全漏洞进行检查,主要涉及身份鉴别、安全审计、访问控制、剩余信息保护、保证通信完整性、通信保密性、应具有软件容错能力、具有抵抗性、实现资源控制、不存在SQL注入、跨站脚本编制等内容。
2.测试策略
2.1.测试完成标准
当依据测试用例执行测试结束后测试结果与预期结果一致,或者测试结果和预期结果虽然不一致,但是不可归咎于应用程序时为测试通过,反之则为测试失效。
2.2.测试类型
2.2.1.功能测试
测试范围 | 验证数据精确度、数据类型、业务功能等相关方面的正确性;导航、链接、cookie、页面结构包括菜单、背景、颜色、字体、按钮名称、TITLE、提示信息的一致性。同时需要对系统的友好性、可操作性、易用性进行测试。 |
测试目标 | 确保合适的测试对象(包括浏览、数据访问、处理和查询)的功能正确;核实各个窗口风格(包括颜色、字体、提示信息、图标、TITLE等)在整个系统中保持一致,保证用户界面的友好性、易操作性且符合用户的操作习惯。 |
技术 | 采用黑盒测试,使用边界值测试、等价类划分、数据驱动等测试方法。 |
工具与方法 | 手工测试。 |
开始标准 | 测试用例完成设计并通过审核,同时项目提交测试。 |
完成标准 | 所有计划的测试都已经执行,所有标识的缺陷都已经定位;UI符合可接受标准,能够保证用户界面的友好性、可操作性且符号用户操作习惯。 |
2.2.2.性能测试
测试范围 | 大流量数据或用户频繁使用模块的性能。 |
测试目标 | 确保系统满足用户的性能需求且长时间加压系统运行稳定,不会造成崩溃等现象。 |
工具与方法 | 使用Jmeter性能测试工具进行自动化测试。 |
开始标准 | 性能测试场景完成设计并通过评审,项目提交测试。 |
完成标准 | 系统满足用户需求中所要求的性能。 |
2.2.3.安全性与访问控制测试
测试范围 | 整个系统。 |
测试目标 | 系统不存在严重的安全问题,同时只有具备系统访问权限的用户才能访问系统且只能操作其拥有权限操作的功能。 |
工具与方法 | 手工测试或者安全测试工具如AWVS、Burp Suite、SQLMap。 |
开始标准 | 项目提交测试。 |
完成标准 | 系统不存在明显或者高危的漏洞且系统上使用正常。 |
2.3.测试工具
工具名称 | 用途 | 生产厂商/自产 |
禅道 | 缺陷管理 | 开源 |
Jmeter | 性能测试 | APACHE |
AWVS | 安全测试 | Acunetix |
Burp Suite | 安全测试 | PortSwigger |
SQLMap | 安全测试 | 开源 |
3.测试技术
(1) 功能测试(黑盒测试):就是对产品的各个功能进行验证,根据功能测试用例,逐项进行测试,检查产品是否达到用户要求的功能。
(2) 动态测试:是指通过运行被测程序,检查运行结果与预期结果的差异,并分析运行效率、正确性和健壮性等性能。
4.测试资源
4.1.人员安排
人员 | 角色 | 职责 |
XXX | 测试经理 | 提供管理监督 提供技术指导 获取合适的资源 |
XXX | 测试组长 | 标识、设计测试用例 编制测试计划 提交测试报告 执行测试 |
XXX | 项目经理 | 提供技术指导 跟踪测试进度 管理BUG对策修改 |
XXX | 测试工程师 | 执行测试 记录测试结果日志 错误重现 提交变更请求 |
XXX | 项目管理工程师 | 监督测试进度 协助协调相关资源 |
XXX | 质量管理员 | 评审和验证测试过程和测试的工作产品是否遵循公司规范 |
XXX | 开发工程师 | 修改BUG |
4.2.测试环境
4.2.1.硬件环境
(1) 应用服务器
CPU:4C
内存:32G
硬盘:550G
操作系统:CentOS Linux release 7.9.2009 (Core)
(2) 数据库服务器
CPU:4C
内存:8G
硬盘:150G
操作系统:CentOS Linux release 7.9.2009 (Core)
4.2.2.软件环境
(1) 服务器软件环境
软件说明 | 技术 | 软件版本 |
数据库软件 | Mysql | 8.0.30 |
中间件 | Tomcat | 9.0.58 |
开发环境 | Jdk | 1.8.0_202 |
代理服务器/负载均衡 | Nginx | 1.16.0 |
分布式缓存 | Redis | 6.2.7 |
(2) 客户端软件环境
操作系统:Windows XP及以上
浏览器:谷歌、360浏览器、IE6.0及以上(推荐使用IE6.0)
4.3.进度安排
测试活动 | 计划开始日期 | 计划结束日期 |
制定项目《测试进度计划》 | 2022/9/13 | 2022/9/13 |
项目经理评审项目《测试进度计划》 | 2022/9/14 | 2022/9/14 |
设计《测试用例》 | 2022/9/15 | 2022/10/14 |
项目组评审《测试用例》 | 2022/10/17 | 2022/10/17 |
制定《系统测试方案》 | 2022/10/18 | 2022/10/18 |
项目经理评审项目《系统测试方案》 | 2022/10/19 | 2022/10/19 |
准备系统测试环境 | 2022/10/20 | 2022/10/20 |
执行系统测试 | 2022/10/20 | 2022/11/14 |
编制《系统自测报告》 | 2022/11/15 | 2022/11/15 |
项目组评审《系统自测报告》 | 2022/11/16 | 2022/11/16 |
5.功能测试
5.1.服务集群
检查项目 | 功能说明 | 测试结果(符合要求) | ||
PC 端 服 务 | XXX管理 | XXX | □是 □否 | |
XXX | □是 □否 | |||
XXX | □是 □否 | |||
XXX | □是 □否 |
6.性能测试
6.1.负载测试
6.1.1.门户首页访问
场景说明 | 用户在门户首页模块进行信息访问。 | |
测试方法 | 依据连续递增的测试策略,不断增加并发线程数,观察测试过程中系统各项性能指标的变化情况,记录所测业务的最大TPS,与目标TPS比对,判断是否满足业务要求值。 | |
性能指标 | 业务场景TPS>200,能支持1000并发响应时间在5秒以内。 | |
目标TPS | 测试结果(符合要求) | |
200 | □是 □否 |
6.2.容量场景测试
6.2.1.门户访问
场景说明 | 依据业务模型组合接口模拟用户访问。 | |
测试方法 | 将门户首页访问、查看门户资讯、查询业务接口按比例进行组合,形成容量场景脚本,依据连续递增的测试策略,不断增加并发线程数,确认业务能否达到容量场景要求。 | |
性能指标 | 容量场景下各业务场景TPS>200,能支持1000并发响应时间在5秒以内。 | |
目标TPS | 测试结果(符合要求) | |
200 | □是 □否 |
7.安全性与访问控制测试
检查项目 | 检查点 | 测试结果(符合要求) |
主机安全 | 身份鉴别。 | □是 □否 |
访问控制。 | □是 □否 | |
安全审计。 | □是 □否 | |
入侵防范。 | □是 □否 | |
恶意代码防范。 | □是 □否 | |
可信验证。 | □是 □否 | |
数据完整性。 | □是 □否 | |
数据备份恢复。 | □是 □否 | |
剩余信息保护。 | □是 □否 | |
数据库安全 | 身份鉴别。 | □是 □否 |
访问控制。 | □是 □否 | |
安全审计。 | □是 □否 | |
入侵防范。 | □是 □否 | |
恶意代码防范。 | □是 □否 | |
可信验证。 | □是 □否 | |
数据完整性。 | □是 □否 | |
数据备份恢复。 | □是 □否 | |
剩余信息保护。 | □是 □否 | |
个人信息保护。 | □是 □否 | |
应用安全 | 身份鉴别。 | □是 □否 |
访问控制。 | □是 □否 | |
安全审计。 | □是 □否 | |
入侵防范。 | □是 □否 | |
恶意代码防范。 | □是 □否 | |
可信验证。 | □是 □否 | |
数据完整性。 | □是 □否 | |
数据备份恢复。 | □是 □否 | |
剩余信息保护。 | □是 □否 | |
个人信息保护。 | □是 □否 |
8.测试通过标准
对于本系统采用“基于测试用例”的准则:
功能性测试用例通过率达到100%;
致命、严重缺陷修复率达到100%;
一般缺陷修复率达到96%以上;
建议性问题修复率达到75%以上;
性能满足功能需求;
安全性达到对应的等级标准。
- 上一篇: 软件测试管理十讲——第三讲:你编写的测试用例真的有效吗?
- 下一篇: 浅谈测试用例设计
猜你喜欢
- 2025-01-11 信息系统项目管理师学习笔记-5.1.4软件实现
- 2025-01-11 软件测试职业生涯需要编写的全套文档模板,收藏这一篇就够了 ~
- 2025-01-11 教你做测试管理3-测试结论如何写
- 2025-01-11 一文读懂如何用Java编写单元测试用例
- 2025-01-11 测试报告怎么写?收藏版
- 2025-01-11 设计测试用例(万能思路 + 六种设计用例方法)(详细 + 图解 + 实例)
- 2025-01-11 破解测试难题,两步助你打造完美无缺的测试用例
- 2025-01-11 测试用例设计方法六脉神剑——第一剑:入门试招,等价边界初探
- 2025-01-11 测试人员为什么要编写测试用例?这个问题值的你好好去思考一下
- 2025-01-11 [测试新人必看] 测试报告如何编写? 掌握这五十个测试报告模板!
你 发表评论:
欢迎- 最近发表
- 标签列表
-
- oraclesql优化 (66)
- 类的加载机制 (75)
- feignclient (62)
- 一致性hash算法 (71)
- dockfile (66)
- 锁机制 (57)
- javaresponse (60)
- 查看hive版本 (59)
- phpworkerman (57)
- spark算子 (58)
- vue双向绑定的原理 (68)
- springbootget请求 (58)
- docker网络三种模式 (67)
- spring控制反转 (71)
- data:image/jpeg (69)
- base64 (69)
- java分页 (64)
- kibanadocker (60)
- qabstracttablemodel (62)
- java生成pdf文件 (69)
- deletelater (62)
- com.aspose.words (58)
- android.mk (62)
- qopengl (73)
- epoch_millis (61)
本文暂时没有评论,来添加一个吧(●'◡'●)