748 lines
30 KiB
Plaintext
748 lines
30 KiB
Plaintext
Q/SY KLD
|
||
昆仑数智科技有限责任公司企业标准
|
||
Q/SY KLD
|
||
软件测试设计编制规范
|
||
Specificationforsoftwaretestdesigndocumentation
|
||
(草案)
|
||
20XX-XX-XX发布
|
||
20XX-XX-XX实施
|
||
昆仑数智科技有限责任公司
|
||
发布
|
||
目
|
||
蒋次
|
||
前言
|
||
1范围..
|
||
2规范性引用文件
|
||
1
|
||
3术语和定义..
|
||
1
|
||
3.1基准测试BenchmarkTesting
|
||
1
|
||
3.2MCDC测试ModifiedCondition/DecisionCoverage.
|
||
1
|
||
3.3通过准则passcriteria...
|
||
1
|
||
3.4软件特征softwarefeature...
|
||
1
|
||
3.5测试覆盖testcoverage..
|
||
1
|
||
3.6测试设计testdesign.
|
||
2
|
||
3.7测试项testitem..
|
||
2
|
||
3.8测试目标testobjective.
|
||
2
|
||
3.9WCAG标准WebContentAccessibilityGuidelines.
|
||
2
|
||
4测试设计的结构..
|
||
.2
|
||
5测试设计要求.
|
||
2
|
||
5.1测试设计说明标识符
|
||
2
|
||
5.2识别测试项.
|
||
.2
|
||
5.3测试技术选择.
|
||
3
|
||
5.4测试覆盖要求.
|
||
.5
|
||
5.5测试项标识...
|
||
7
|
||
5.6测试通过准则
|
||
.8
|
||
6风险评估..
|
||
.8
|
||
6.1风险识别..
|
||
.8
|
||
6.2风险缓解策略
|
||
6
|
||
附录A（资料性）
|
||
测试技术分类
|
||
附录B（资料性）
|
||
常见测试工具
|
||
.13
|
||
附录C（资料性）软件测试设计示例
|
||
.14
|
||
C.1测试设计规格标识符
|
||
..14
|
||
C.2测试设计方法细化
|
||
.14
|
||
C.3测试项标识...
|
||
.17
|
||
C.4测试通过准则.
|
||
17
|
||
参考文献..
|
||
.18
|
||
前
|
||
蓝言
|
||
本文件按照GB/T1.1—2020《标准化工作导则第1部分：标准化文件的结构和起草规则》的规定
|
||
起草。
|
||
本文件是Q/SYXXXXX《XXXXXXXX》的第1部分。Q/SYXXXXX已经发布了以下部分：
|
||
第1部分：XXXXXXXXXXXXXXXX；
|
||
第2部分：XXXXXXXXXXXXX。
|
||
（分部分标准应有此段描述，只写出已经发布的，没有发布的可在引言中描述。）
|
||
本文件由数字和信息化管理部提出。
|
||
（信息标准提出单位只可以是”数字和信息化管理部”或中国石油天然气集团有限公司标准化委
|
||
员会信息技术专业标准化技术委员会”）
|
||
本文件由中国石油天然气集团有限公司标准化委员会信息技术专业标准化技术委员会归口。
|
||
本文件起草单位：数字和信息化管理部、共享运营公司、勘探开发研究院、昆仑数智。
|
||
（起草单位写到局级单位且为简称【在每年标准制修订计划中有简称，可查询】，应与编制说明中
|
||
的单位对应一致，集团公司企业标准至少应由3个局级单位共同起草）
|
||
本文件主要起草人：XXX、XXX
|
||
（专家审查会之前，起草人应确定，排名顺序应按照编写标准的责献程度排名。）
|
||
本文件主要审查人：XXX、XXX。
|
||
1范围
|
||
本文件规定了基本的软件测试设计文档的格式和内容要求，
|
||
本文件适用于软件测试过程中软件设计的编写工作。
|
||
2规范性引用文件
|
||
下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，
|
||
仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本
|
||
文件。
|
||
GB/T15532-2008计算机软件测试规范
|
||
GB/T9386-2008计算机软件测试文档编制规范
|
||
GB/T38634.4-2020系统与软件工程软件测试第4部分：测试技术
|
||
马品
|
||
3术语和定义
|
||
GB/T11457中确立的以及下列术语和定义适用本标准。
|
||
3.1
|
||
基准测试BenchmarkTesting
|
||
通过运行标准化测试程序或场景，评估系统、组件或软件的性能、效率及稳定性，为后续优化或比
|
||
较提供数据依据。
|
||
3.2
|
||
MCDC测试ModifiedCondition/DecisionCoverage
|
||
MCDC测试ModifiedCondition/DecisionCoverage（修改条件/决策覆盖测试）是一种基于结构的
|
||
白盒测试技术，旨在验证代码中每个逻辑条件对整体决策结果的独立影响能力。
|
||
3.3
|
||
通过准则passcriteria
|
||
判断一个软件项或软件特征的测试是否通过的判别依据。
|
||
3.4
|
||
软件特征softwarefeature
|
||
软件项的显著特性（如功能、性能或可移植性）。
|
||
3.5
|
||
测试覆盖testcoverage
|
||
给定的测试或测试集，对于给定的系统和部件实现所有规定的需求的程度。
|
||
3.6
|
||
测试设计testdesign
|
||
一种文档，它规定对软件特性或软件特性与标识相关测试的组合的详细测试方法。解决测什么、怎
|
||
么测的问题。
|
||
3.7
|
||
测试项testitem
|
||
测试点
|
||
是测试目标的软件项。
|
||
3.8
|
||
测试目标testobjective
|
||
在规定的条件下要量度的软件特性的标识集，它由把时间行为与在软件文档中描述的所要求的行为
|
||
进行比较来量度。
|
||
3.9
|
||
WCAG标准WebContentAccessibilityGuidelines
|
||
WCAG（WebContentAccessibilityGuidelines，Web内容无障碍指南）是由方维网联盟（W3C）制
|
||
定的国际标准，旨在确保残障人士能够平等访问和使用网络内容。其核心目标是消除数字环境中的障碍，
|
||
帮助视觉、听觉、运动或认知障碍用户通过辅助技术（如屏幕阅读器）与网页交互。
|
||
4测试设计的结构
|
||
测试设计应有如下内容和结构：
|
||
a）测试设计说明标识符；
|
||
b）识别测试项；
|
||
c）测试设计方法细化（技术选择、覆盖要求）；
|
||
d）测试项标识；
|
||
e）软件特征测试通过准则。
|
||
5测试设计要求
|
||
5.1测试设计说明标识符
|
||
为该测试设计说明规定唯一的标识符。如果在相关的测试计划中有规定，则应引用。
|
||
5.2识别测试项
|
||
5.2.1测试项来源与范围定义
|
||
测试项是测试目标的软件项。测试项需基于需求文档、设计文档及风险分析报告等文件进行提取和
|
||
识别。具体包括：功能需求、性能指标、安全约束、兼容性要求、可靠性要求、易用性要求、可维护性
|
||
要求、可移植性要求等。
|
||
在测试过程中，应明确测试项的层级与类型：层级分为模块级、系统级和接口级；类型包括功能测
|
||
试、性能测试、安全性测试及兼容性测试等。同时，应明确定义排除项并说明排除理由，以确保测试范
|
||
围的透明性。
|
||
5.2.2测试项识别方法
|
||
测试项的识别需结合系统需求、设计文档及风险分析，提取软件特性中可测试属性。以下是具体方
|
||
法：
|
||
a）基于需求的分解法
|
||
1）功能特征识别：通过逐条分析需求文档（如用户故事、需求规格说明书），提取功能点并
|
||
分解成测试项；
|
||
示例：通过需求描述”系统应支持用户密码修改”→提取特征”密码修改功能”，包括输
|
||
入校验、加密存储等子特征，最终形成测试项。
|
||
2）非功能特征识别：从性能、安全性等非功能性需求中提取可量化指标。
|
||
示例：响应时间≤2秒、并发用户数≥1000人。
|
||
b）基于设计的结构分解法
|
||
1）架构与模块分解：根据系统设计文档（如架构图、模块说明书），识别各组件接口、数据
|
||
流及依赖关系，确定需测试的测试项；
|
||
示例1：根据系统的功能特性，将其拆分为不同的功能模块，如登录模块、搜索模块、购物车
|
||
模块等，每个功能模块可独立进行测试；
|
||
示例2：版本拆分：根据项目规划的版本进行拆分，同一个版本的功能可独立进行测试。
|
||
2）代码分析：通过代码走查或工具识别关键逻辑分支、异常处理路径等结构测试项；
|
||
3）对于图形用户界面系统，可以将界面元素拆分为不同的组件，如按钮、文本框、下拉框等。
|
||
每个界面元素可单独进行测试：
|
||
4）根据数据在系统中的流动路径进行拆分，从输入到处理再到输出。可以针对数据的输入、
|
||
处理和输出进行测试
|
||
c）用户场景分解法
|
||
1）流程图：通过活动图或业务流程图，识别端到端场景中的关键测试项。
|
||
示例：按照业务流程的顺序将系统拆分为一系列步骤或阶段，如订单处理流程、客户注册流
|
||
程等，每个业务流程可以独立进行测试。
|
||
2）角色-功能矩阵：按不同用户角色（如管理员、普通用户）划分权限，根据权限进行测试。
|
||
d）基于风险的优先级划分
|
||
1）风险矩阵评估：结合历史缺陷数据、用户场景重要性，对软件特征进行风险评级，优先识
|
||
别高风险的软件特征进行测试；
|
||
2）失效模式分析：针对关键模块，分析潜在失效点（如数据库连接失败），转化为需验证的
|
||
测试项。
|
||
e）行业标准与法规符合性检查
|
||
1）根据国家法规或行业标准识别强制测试项。
|
||
全等级保护基本要求》，识别强制测试项：”用户个人敏感信息数据应加密存储”。
|
||
5.3测试技术选择
|
||
测试技术选择应基于被测对象的特性、需求明确性、测试阶段目标、资源约束及风险等级等因素综
|
||
合评估，主要测试技术见附录A。
|
||
5.3.1技术选择原则
|
||
a)需求明确性
|
||
1）需求清晰时应优先使用基于规格说明的技术，如：等价划分、决策表；
|
||
2)）需求模糊时宜使用基于经验的技术和探索性测试。
|
||
b）系统复杂度
|
||
1）逻辑复杂或条件组合多时，采用组合测试或因果图法；
|
||
2）状态依赖型系统优先选择状态转换测试。
|
||
c）资源与风险
|
||
1）资源充足时，采用组合测试或MC/DC提高覆盖率；
|
||
2）高风险模块需综合多种技术，如：边界值+错误猜测+决策表的测试组合。
|
||
5.3.2测试技术分类及核心自标
|
||
a）基于规格说明的测试技术（黑盒测试）
|
||
目标：验证系统行为是否符合需求规格说明，关注输入与输出的正确性。
|
||
适用场景：需求文档明确、功能逻辑复杂或需覆盖用户场景的测试阶段。
|
||
典型技术：
|
||
1）等价划分：输入域存在明确分组规则时（如合法/非法值）；
|
||
2）边界值分析：输入输出存在数值范围或边界条件时；
|
||
3）决策表测试：多条件组合触发不同业务规则时；
|
||
4）状态转换测试：系统行为依赖状态迁移；
|
||
5）场景测试：模拟用户端到端业务流程。
|
||
b）基于结构的测试技术（白盒测试）
|
||
目标：验证代码逻辑的完整性和健壮性，提升代码覆盖率。
|
||
适用场景：单元测试、集成测试或需深度验证代码逻辑的场景。
|
||
典型技术：亮
|
||
1）语句/分支测试：需覆盖代码基本执行路径时；
|
||
2）MC/DC测试：高安全性系统需满足严格覆盖准则时；
|
||
3）数据流测试：检测变量定义与使用异常时。
|
||
c）基于经验的测试技术
|
||
目标：利用测试人员经验补充系统化设计的盲区。
|
||
适用场景：需求模糊、时间紧迫或需探索潜在缺陷的场景。
|
||
典型技术：
|
||
1）错误猜测：依赖历史缺陷模式或领域知识推测易错点；
|
||
2）检查表：使用预定义的检查项指导测试设计，确保覆盖关键点。
|
||
5.3.3技术组合策略
|
||
a）分层覆盖：在单元测试中采用白盒技术确保代码质量，在系统测试中通过黑盒技术验证功能完
|
||
整性。
|
||
b）互补增强
|
||
1）针对关键功能应使用边界值分析和错误猜测的组合测试；
|
||
2）针对多条件交互功能应使用决策表和分支条件组合等进行组合测试。
|
||
c）选代优化：根据测试结果动态调整技术，当发现分支覆盖不足时应补充分支条件组合测试。
|
||
5.4测试覆盖要求
|
||
测试覆盖要求的制定应与软件质量特性紧密结合，并明确覆盖的度量方法与实施要求。
|
||
5.4.1结合质量特性的覆盖要求
|
||
测试覆盖邀请需结合测试技术分类（基于规格说明、结构、经验）进行设计，具体覆盖类型如下：
|
||
5.4.1.1功能测试覆盖要求
|
||
a）需求覆盖
|
||
1）应建立需求道踪矩阵（RTM），确保每个需求对应的功能至少被一个测试用例覆盖，测试
|
||
用例应涵盖所有预期功能和边界条件；
|
||
2）应标识需求的优先级，高优先级需求对应的功能应实现100%覆盖。
|
||
b）业务流程覆盖要求
|
||
1）应覆盖所有主流程和分支流程；
|
||
2）应测试覆盖异常流程的处理；
|
||
3）应验证端到端的业务流程。
|
||
c）UI交互覆盖
|
||
1）应覆盖所有页面元素（按钮、表单、弹窗、导航）的交互行为；
|
||
2）应测试覆盖响应式设计的适配性，包括屏幕尺寸、分辨率、横竖屏方向等。
|
||
d）接口覆盖要求：应覆盖验证系统内外接口（API、协议、数据格式）的输入/输出及异常处理。
|
||
e）权限覆盖要求
|
||
1）覆盖所有用户角色的功能权限（如管理员增删改查，普通用户仅查询）；
|
||
2）应验证权限变更的实时性。
|
||
）基于结构的测试覆盖
|
||
1）语句/分支测试：应覆盖代码基本执行路径；
|
||
2）MC/DC测试：高安全性系统应满足严格覆盖准则；
|
||
3）数据流测试：应检测变量定义与使用异常。
|
||
9）基于规格说明的测试技术覆盖要求
|
||
此类覆盖关注需求或功能规格说明的覆盖程度，适用于黑盒测试：
|
||
1）等价划分：测试用例需覆盖所有有效和无效等价类，确保每个类至少有一个用例；
|
||
2)边界值分析：应覆盖输入域的边界值，如：最小值、最大值、略超出边界的值：
|
||
3）决策表测试：应覆盖决策表中所有条件组合对应的动作；
|
||
4）状态转换测试：应覆盖所有状态转移路径，包括合法转移和非法触发；
|
||
5）场景测试：应覆盖用户场景中的所有关键路径和异常分支。
|
||
5.4.1.2性能测试覆盖要求
|
||
a）负载范围覆盖
|
||
1）宜根据基准测试结果，设计50%、80%、100%、120%四种不同级别的负载测试；
|
||
2）宜对每种负载级别持续运行足够时间以观察系统稳定性；
|
||
3）宜模拟突发流量场景，测试系统对流量突增的应对能力。
|
||
b）网络环境覆盖
|
||
1）宜覆盖3G/4G/5G/Wi-Fi等多种网络环境，保证高延迟下功能正常；
|
||
2）应测试网络切换时的系统表现。
|
||
5.4.1.3安全测试覆盖要求
|
||
a）漏洞扫描覆盖
|
||
1）所有代码应进行静态安全扫描；
|
||
2）系统上线前，宜对系统进行动态安全扫描；
|
||
3）系统上线前，宜对系统执行渗透测试，覆盖所有对外暴露的接口。
|
||
b）数据安全覆盖
|
||
1）应验证敏感数据（如密码、身份证号）加密存储和传输的情况。
|
||
c)权限覆盖
|
||
1）应测试覆盖所有角色的权限分配情况；
|
||
2）应测试权限变更后的即时生效情况。
|
||
d）合规覆盖
|
||
1）应审计所有安全日志的记录和存储情况；
|
||
2）应验证系统是否符合相关法律、法规的要求。
|
||
5.4.1.4兼容性测试覆盖要求
|
||
a）浏览器覆盖
|
||
1）应选择Chrome/Firefox/Safari/Edge中至少2个最新版本进行覆盖测试；
|
||
2）宜测试浏览器插件和扩展的影响。
|
||
b）移动端覆盖：应选择主流移动设备厂商的不同型号进行覆盖测试；
|
||
c）分辨率覆盖
|
||
1）应覆盖720p/1080p/2K/4K及全面屏；
|
||
2）应测试不同DPI设置下的显示效果；
|
||
3）宜测试覆盖全面屏、刘海屏等特殊屏幕形态。
|
||
d）操作系统覆盖：宜对操作系统的不同版本进行覆盖。
|
||
e）安装卸载测试
|
||
1）应验证模拟常见的安装错误，如空间不足、权限不足、网络中断等。
|
||
2）应检查软件卸载是否彻底；
|
||
3）应确认软件安装后是否正常。
|
||
5.4.1.5可靠性测试覆盖要求
|
||
a）压力边界覆盖
|
||
1）应测试超过设计容量50%的负载情况；
|
||
2）应测试资源耗尽情况下的系统行为。
|
||
b）容错覆盖
|
||
1）应模拟测试网络中断、服务崩溃、磁盘满等异常场景；
|
||
2）应验证降级策略的有效性。
|
||
c）恢复覆盖
|
||
1）应测试数据库崩溃后的恢复流程；
|
||
2）应验证备份数据的完整性和可用性。
|
||
5.4.1.6易用性测试覆盖要求
|
||
a）核心路径覆盖
|
||
1）应测试新手用户的首次使用体验情况；
|
||
2）宜验证操作步骤的最简化程度。
|
||
b）多语言覆盖
|
||
1）应测试日期、时间、货币等本地化内容；
|
||
2）应测试系统所有支持语言的显示效果。
|
||
5.4.1.7可维护性测试覆盖要求
|
||
a）日志覆盖
|
||
1）应确保所有关键操作都有日志记录；
|
||
2）应验证日志信息的完整性和可读性。
|
||
b）文档覆盖
|
||
1）应验证系统API文档的完备性；
|
||
2）应验证系统部署手册的完备性；
|
||
3）应验证系统故障处理指南的完备性。
|
||
5.4.1.8可移植性测试覆盖要求
|
||
a）宜确保系统能在不同环境（云、容器、物理机）中部署和运行；
|
||
b）宜覆盖依赖项、配置、数据迁移的兼容性。
|
||
5.4.2覆盖的实施要求
|
||
a)分层覆盖管理：
|
||
1）单元测试：代码结构覆盖为主，语句覆盖率≥90%，分支覆盖率>80%；
|
||
2）集成测试：接口测试验证所有输入/输出接口及交互协议，应覆盖正常与异常场景；
|
||
3）系统测试：需求功能覆盖应达到100%，场景覆盖核心业务流程。
|
||
b）高风险模块增强覆盖：对高优先级需求或复杂模块，应采用多技术组合测试，提高覆盖率。
|
||
c）自动化支持：宜使用自动化工具实现覆盖率动态监控，如：代码覆盖率工具、需求跟踪工具。
|
||
对未覆盖项生成告警并触发测试用例补充机制。
|
||
5.4.3覆盖的合规性要求
|
||
测试覆盖的合规性应满足以下要求：
|
||
a）可道溯性：测试用例与需求、代码或风险的关联关系应通过需求跟踪矩阵（RTM）记录；
|
||
b）可重复性：覆盖率度量方法应标准化，确保不同测试周期或团队的结果一致性；
|
||
c）透明度：测试报告中应明确说明覆盖目标、实际结果及未覆盖项的潜在影响；
|
||
d）适应性：覆盖标准应根据项目变更动态调整。
|
||
5.5测试项标识
|
||
列出与该设计有关的每一个测试项的标识并简要描述。测试项列表示例见表1。
|
||
表1测试项示例表
|
||
序号
|
||
测试项描述
|
||
测试项代码
|
||
1.
|
||
有效的小数点，含4个小数位的前导点
|
||
NNE.TC.040
|
||
2.
|
||
有效的小数点，含1个小数位的嵌人式点
|
||
NNE.TC.041
|
||
3.
|
||
有效的小数点，含0个整数的尾部点
|
||
NNE.TC.042
|
||
4.
|
||
无效的小数点，5个小数位
|
||
NNE.TC.050
|
||
5.
|
||
无效的小数点，2个点
|
||
NNE.TC.051
|
||
6.
|
||
无效的小数点，没有数字的点
|
||
NNE.TC.052
|
||
5.6测试通过准则
|
||
给出用于判定软件特征或软件特征组合是否通过或失败的准则。
|
||
a）明确判定依据，定义通过或失败的具体条件，包括但不限于：
|
||
1）功能正确性：功能模块的输入与输出必须与需求文档定义的预期结果一致；
|
||
2）性能指标：响应时间、吞吐量、资源占用率等需满足预设阈值；
|
||
3）兼容性要求：功能需在指定的操作系统、浏览器、设备或版本范围内正常运行；
|
||
4）容错能力：对异常输入、非法操作或极端场景需具备合理处理机制。
|
||
b）量化或定性标准
|
||
1）量化标准：提供可测量的指标，例如数值阈值（响应时间≤1秒）；
|
||
2）定性标准：描述可观察的行为或状态，例如界面交互流畅无卡顿、业务流程完整无中断。
|
||
c）覆盖范围定义
|
||
1）覆盖率要求：在软件测试阶段，应执行全部设计的测试用例，并提供执行记录；
|
||
2通过率要求：关键功能（如核心业务流程、安全模块）的测试用例应100%通过；非关键
|
||
功能的测试用例通过率不低于95%，未通过用例应评估影响范围并在测试报告中明确标注。
|
||
d通过准则豁免
|
||
1）任何偏离上述准则的情况需经上级审批，并在发布说明中明确标注。
|
||
6风险评估
|
||
6.1风险识别
|
||
风险识别是系统化发现可能影响测试目标实现的内外部因素的过程，需覆盖技术、管理、资源及环
|
||
境等多维度风险。
|
||
在软件测试过程中，风险评估是识别潜在威胁、分析其影响并制定应对策略的核心环节，旨在降低
|
||
测试活动的不确定性，确保测试目标的达成。应覆盖技术、管理、资源及环境等多维度进行风险识别。
|
||
风险来源分类见表1。
|
||
表2风险来源分类表
|
||
风险类型
|
||
典型风险示例
|
||
需求风险
|
||
需求不清晰或频繁变更
|
||
风险类型
|
||
典型风险示例
|
||
关键需求遗漏或优先级误判
|
||
技术风险
|
||
复杂算法实现缺陷
|
||
第三方组件兼容性问题
|
||
代码质量风险
|
||
数据风险
|
||
性能瓶颈或安全漏洞
|
||
资源风险
|
||
测试环境不足（如硬件、工具缺失）
|
||
成本风险
|
||
人力短缺
|
||
人员能力风险
|
||
人员技能不足
|
||
测试人员对业务不熟悉造成的风险
|
||
测试人员可能对产品的功能不熟悉，导致测试不充分
|
||
进度风险
|
||
开发延期导致测试时间压缩
|
||
缺陷修复周期不可控
|
||
环境风险
|
||
依赖外部系统接口不稳定
|
||
生产环境与测试环境配置差异
|
||
流程风险
|
||
测试用例设计遗漏关键场景
|
||
缺陷管理流程不规范
|
||
风险应通过风险登记册进行记录，包含以下信息：
|
||
风险ID、描述、类别、概率（高/中/低）、影响（高/中/低）、优先级、责任人、状态（开放/
|
||
关闭）。
|
||
示例：
|
||
ID
|
||
风险描述
|
||
类别
|
||
概率
|
||
影响
|
||
优先级
|
||
责任人
|
||
状态
|
||
R01
|
||
第三方支付
|
||
技术风险
|
||
中
|
||
高
|
||
高
|
||
张某某
|
||
开放
|
||
接口响应超
|
||
时
|
||
6.2风险缓解策略
|
||
针对已识别的风险，应制定优先级排序的应对措施，确保风险可控或影响最小化。宜采用风险矩阵
|
||
对风险进行量化评估。风险评估方法见表2。
|
||
表3风险评估矩阵表
|
||
影响/概率
|
||
高
|
||
中
|
||
低
|
||
高
|
||
紧急处理（PO)
|
||
高优先级（P1）
|
||
中优先级(P2）
|
||
中
|
||
高优先级(P1)
|
||
中优先级（P2)
|
||
低优先级(P4)
|
||
影响/概率
|
||
高
|
||
中
|
||
低
|
||
低
|
||
中优先级(P2)
|
||
低优先级（P3）
|
||
观察（P4)
|
||
根据风险评估结果使用风险应对策略对风险进行处理，风险应对措施见表3。
|
||
表4风险应对措施表
|
||
策略类型
|
||
定义与实施方法
|
||
适用场景
|
||
风险规避
|
||
通过调整计划或方案避免风险发生。
|
||
替换不稳定的第三方组件。
|
||
风险减轻
|
||
采取措施降低风险发生概率或影响。
|
||
增加性能测试覆盖关键接口。
|
||
风险转移
|
||
将风险转移至第三方（如外包、保险）。
|
||
外包高复杂度模块的开发与测试。
|
||
风险接受
|
||
明确接受风险后果，并制定应急计划。
|
||
低影响且处理成本过高的风险。
|
||
附录A
|
||
（资料性）
|
||
测试技术分类
|
||
测试技术分类见表A.1。
|
||
表A.1测试技术分类表
|
||
测试技术分类
|
||
测试技术名称
|
||
简要说明
|
||
基于规格说明的
|
||
等价划分
|
||
将输入数据划分为等价类，每个类选取代表性值进行测试，减少
|
||
测试设计技术
|
||
冗余用例。
|
||
（黑盒测试)
|
||
边界值分析
|
||
针对输入或输出的边界值设计测试用例，验证系统在边界条件下
|
||
的行为。
|
||
分类树法
|
||
通过树状结构对输入条件进行分类组合，生成系统化的测试用例。
|
||
决策表测试
|
||
基于条件与动作的组合关系，覆盖所有逻辑组合的测试用例。
|
||
场景测试
|
||
模拟用户实际业务流程，验证系统在端到端流程中的表现。
|
||
状态转换测试
|
||
测试系统在不同状态间的转换逻辑，覆盖状态迁移路径和触发条
|
||
件。
|
||
因果图法
|
||
分析输入条件与输出结果的因果关系，生成覆盖因果逻辑的测试
|
||
用例。
|
||
随机测试
|
||
随机选择输入数据进行测试，常用于探索性测试或大规模数据验
|
||
证。
|
||
需求基测试
|
||
根据需求文档直接设计测试用例，确保需求与实现的一致性。
|
||
变异测试
|
||
通过人为注入代码缺陷验证测试用例能否发现这些缺陷。
|
||
基于结构的测试
|
||
语句测试
|
||
确保代码中每条语句至少执行一次。
|
||
设计技术(白盒
|
||
分支测试
|
||
覆盖代码中所有分支的真假路径。
|
||
测试)
|
||
决策测试
|
||
覆盖代码中所有决策条件的真假组合。
|
||
路径测试
|
||
覆盖代码中所有可能的执行路径。
|
||
数据流测试
|
||
通过追踪程序中变量的定义、使用和销毁过程，验证数据在程序
|
||
执行路径中的传递逻辑，并检测未初始化使用、冗余定义或资源
|
||
泄漏等数据流异常。
|
||
分支条件组合测
|
||
覆盖分支中所有条件的可能组合。
|
||
试
|
||
修改条件/决策
|
||
确保每个条件能独立影响决策结果，满足高安全性系统的覆盖要
|
||
覆盖（MCDC)
|
||
求。
|
||
错误猜测
|
||
依赖测试人员的经验，猜测系统中可能存在的缺陷并针对性设计
|
||
经验导向的测试
|
||
用例。
|
||
测试技术分类
|
||
测试技术名称
|
||
简要说明
|
||
检查表
|
||
使用预定义的检查项（如常见错误列表）指导测试设计，确保覆
|
||
盖关键点。
|
||
设计技术
|
||
历史数据分析
|
||
基于历史缺陷数据或用户反馈，识别高风险模块并针对性设计测
|
||
试。
|
||
附录B
|
||
(资料性）
|
||
常见测试工具
|
||
常见测试工具及用途见表B.1。
|
||
表B.1
|
||
测试工具
|
||
测试工具
|
||
途径分类
|
||
备注
|
||
编写测试大纲编写需
|
||
Excel
|
||
求对比编写测试用例
|
||
使用Excel本地编写，使用SVN进行测试设计保存
|
||
Xmind
|
||
编写脑图
|
||
使用Xmind本地编写，使用SVN进行测试设计保存
|
||
昆仑智联
|
||
编写测试用例及管理
|
||
使用统一开发平台编写用例及管理
|
||
Selenium、Appium
|
||
功能测试工具
|
||
这些工具用于验证系统或应用程序的功能是否正确实现。可以模拟
|
||
用户操作来测试Web应用程序和移动应用程序的功能
|
||
Selenium、Appium
|
||
自动化测试工具
|
||
这些工具可以自动执行测试用例，模拟用户操作来验证软件的功能，
|
||
可以用于自动化Web应用程序和移动应用程序的测试
|
||
JMeter、LoadRunner
|
||
性能测试工具
|
||
这些工具用于评估软件的性能，如响应时间、吞吐量、资源利用率
|
||
等。可以用于执行负载测试和压力测试
|
||
这些工具用于检测软件中的安全漏洞和风险。可以用于执行漏洞扫
|
||
OWASP ZAP、Nessus
|
||
安全测试工具
|
||
描和渗透测试
|
||
SonarQube、FindBugs
|
||
这些工具通过分析代码来检测潜在的错误、漏洞和质量问题。可以
|
||
静态代码分析工具
|
||
用于检测代码中的缺陷和违反编码规范的问题
|
||
JIRA、TestRail
|
||
测试管理工具
|
||
这些工具用于管理测试活动，包括测试计划、测试用例、测试执行
|
||
和缺陷跟踪等。可以用于管理测试过程和团队协作
|
||
Cobertura、Jacoco
|
||
这些工具用于测量代码的测试覆盖率，帮助确定哪些部分的代码没
|
||
覆盖率分析工具
|
||
有被测试覆盖到。可以用于生成代码覆盖率报告
|
||
Mockito、WireMock和
|
||
环境模拟工具
|
||
适用于接口测试、依赖隔离、数据驱动测试。模拟外部依赖（如Mo
|
||
Faker
|
||
ckito、WireMock）或生成测试数据（如Faker）。
|
||
附录C
|
||
（资料性）
|
||
软件测试设计示例
|
||
下面的示例来自于软件测试设计的一种文档形式。这个示例并不意味着本文件对其他种类的软件适
|
||
用性有任何的限制。
|
||
C.1测试设计规格标识符
|
||
XSGW.TD.001
|
||
20XX年4月14日
|
||
C.2测试设计方法细化
|
||
借助思维导图可以进行启发式测试设计并可视化承载设计过程。思维导图的编写不是只在测试设计
|
||
阶段完成的，而是一个逐级细分的过程，思维导图的设计从测试的特性入手，一层一层地分解，直至最
|
||
终输出测试用例，这体现了从整体到局部逐渐细化、具体的思维方式。
|
||
C.2.1填写说明
|
||
a）思维导图绘制说明
|
||
1）定义：思维导图是一种以图形化的方式展示信息和思维结构的工具；
|
||
2）目的：帮助用户整理、理解和记忆信息，促进创造性思维和问题解决；
|
||
3）内容：思维导图通常包含一个中心主题，以及与之相关的子主题和分支；
|
||
4）结构：以中心主题为起点，子主题通过线条和连接词与中心主题相连，形成一个树状或网
|
||
状结构。
|
||
5）绘制步骤：
|
||
确定中心主题：选择一个核心概念或问题作为思维导图的中心；
|
||
·
|
||
添加分支：从中心主题开始，添加与之相关的子主题和分支；
|
||
●细化内容：在每个分支下添加更具体的细节和相关信息；
|
||
·使用关键词：使用简短的关键词来描述每个子主题和分支，避免过长的句子；
|
||
·利用颜色和图像：使用不同的颜色和图像来区分不同的主题和分支，增强视觉效果和
|
||
记忆；
|
||
·连接关联：通过连接词或箭头来表示主题之间的关系和逻辑。
|
||
b）思维导图绘制要求：
|
||
1）简洁明了：保持思维导图的简洁性和清晰度，避免过多的细节和文字；
|
||
2）结构合理：确保分支和子主题的层次结构合理，便于理解和阅读；
|
||
3）突出重点：使用颜色、字体大小或符号来突出重要的子主题和关键信息；
|
||
4）逻辑连贯：保持主题之间的逻辑连贯性，确保分支之间的关系清晰；
|
||
5）个性化：根据个人的思维方式和需求进行绘制，体现个人风格和特色。
|
||
C.2.2思维导图模板
|
||
思维导图模板见图C.1。
|
||
功能测试
|
||
业务场景
|
||
分支场景
|
||
功能点
|
||
测试点1
|
||
测试点2
|
||
性能测试
|
||
测试点
|
||
安全测试
|
||
测试点
|
||
易用性测试
|
||
测试点1
|
||
测试设计思维导图模板
|
||
测试点2
|
||
兼容性测试
|
||
测试点
|
||
可靠性测试
|
||
测试点
|
||
可移植性测试
|
||
测试点
|
||
可维护性测试
|
||
测试点
|
||
图C.1
|
||
测试设计思维导图
|
||
C.2.3大纲笔记模板
|
||
思维导图模板见图C.2。
|
||
测试设计大纲笔记模板
|
||
功能测试
|
||
·业务场景
|
||
·分支场景
|
||
·功能点
|
||
·测试点1
|
||
·测试点2
|
||
性能测试
|
||
测试点
|
||
安全测试
|
||
测试点
|
||
易用性测试
|
||
测试点1
|
||
测试点2
|
||
兼容性测试
|
||
·测试点
|
||
可靠性测试
|
||
·测试点
|
||
可移植性测试
|
||
测试点
|
||
可维护性测试
|
||
测试点
|
||
图C.2测试设计大纲笔记图
|
||
测试设计大纲笔记分级填写说明见表C.1。
|
||
表C.1
|
||
测试设计分级填写说明表
|
||
层级
|
||
填写说明
|
||
要求
|
||
中心主
|
||
填写测试对象，应填写项目名称、模块名称或版本名称，以明确
|
||
明确脑图的主题和中心思想
|
||
题
|
||
测试的具体范围。
|
||
测试类
|
||
选择适当的测试类型，如功能测试、性能测试、安全测试、兼容
|
||
根据主题和中心思想，划分出主要的分支
|
||
型（第-
|
||
性测试、可靠性测试、用户体验测试等。
|
||
和子分支，形成清晰的层次结构。
|
||
层级
|
||
填写说明
|
||
要求
|
||
级）
|
||
业务场
|
||
来自于产品设计报告，主要设计的是功能测试类型的业务场景
|
||
按照产品设计报告的业务场景设计
|
||
景（第二
|
||
级）
|
||
分支场
|
||
来自于产品设计报告，主要设计的是功能测试类型的分支场景
|
||
按照产品设计报告的分支场景设计，测试
|
||
景（第三
|
||
人员要充分考虑分支场景，如产品设计报
|
||
级）
|
||
告的分支场景考虑不全面需要与产品人
|
||
员讨论决定
|
||
功能点
|
||
来自于研发需求
|
||
功能点要覆盖所有研发需求
|
||
（第四
|
||
级）
|
||
测试点
|
||
测试人员应考虑用户需求、系统规格和行业标准。测试点应明确、
|
||
测试点要覆盖所有的需求
|
||
（第五
|
||
可重复和可度量，以便进行有效的测试和结果评估。通过识别测
|
||
级）
|
||
试点，测试人员可以创建一个全面的测试计划，确保系统的质量
|
||
满足预期的要求。
|
||
C.3
|
||
测试项标识
|
||
分支场发]
|
||
8100件商
|
||
上角址
|
||
C.4测试通过准则
|
||
为了通过这种测试，每种测试项（测试点）必须通过所有的测试用例。
|