求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
要资料
 
追随技术信仰

随时听讲座
每天看新闻
 
 
目录
软件测试
1.教程
2. 软件测试原则
3. 软件开发生命周期(SDLC)
4. 软件测试命周期(STLC)
5. 软件测试的类型
6. 测试成熟度模型
7. 测试级别
SDLC 模型
1.瀑布模型
2.螺旋模型
3.混合模型
4.原型模型
5. V模型/V和V模型/验证和验证模型
测试的类型
1.手动测试
2.自动化测试
手册的类型
1.白盒测试
2.黑盒测试
3.灰盒测试
白盒技术
1.数据流测试
2.控制流测试
3.分支覆盖测试
4.语句覆盖率测试
5.决策覆盖率测试
黑盒技术
1.决策表
2.全对测试
3.黑盒测试中的因果图
4.状态转换技术
5.用例技术
黑盒的类型
1.功能测试
2.非功能性测试
功能类型
1.单元测试
2.集成测试
3.系统测试
非功能性的类型
1.性能测试
2.易用性测试
3.兼容性测试
测试用例开发
1.测试文档
2.测试场景
3.测试用例
测试技术
1.错误猜测技术
2.等效分区技术
3.边界值分析
测试管理
1.测试计划
2.测试用例审查过程
3.需求可追溯性矩阵
缺陷跟踪
1.软件测试中的错误
2.Bug生命周期
3.测试中bug的严重性和优先级
4.测试环境
5.缺陷管理过程
其他类型的测试
1.回归测试
2.冒烟测试
3.健全性测试
4.静态测试
5.动态测试
6.负载测试
7.压力测试
8.恢复测试
9.探索性测试
10.可视化测试
11.验收测试
12.Alpha 测试
13.Beta 测试
14.数据库测试
15.主机测试
16.Adhoc测试
17.全球化测试
18.变异测试
19.安全测试
20.可访问性测试
21.结构测试
22.批量测试
23.可伸缩性测试
24.稳定性测试
25.峰值测试
26.负面测试
27.正面测试
28.耐久性测试
29.可靠性测试
30.Monkey测试
31.敏捷测试
32.组件测试
33.GUI测试
34.测试策略
软件测试工具
1.软件测试工具
2.测试管理工具
3.缺陷/Bug跟踪工具
4.自动化测试工具
5.性能测试工具
6.跨浏览器测试工具
7.集成测试工具
8.单元测试工具
9.移动测试工具
10.GUI测试工具
11.安全测试工具
12.渗透测试工具
差异
1.自动化测试与手动测试
2.负载测试与压力测试
3.冒烟测试和健全性测试之间的差异
4.系统测试和验收测试之间的差异
5.质量保证与质量控制
6.静态测试与动态测试
7.验证和确认测试
8.Alpha 测试和 Beta 测试
9.黑盒测试与白盒测试与灰盒测试
10.全球化测试和本地化测试之间的区别
11.测试用例与测试场景
12.测试计划 VS.测试策略
13.边界值分析和等价划分之间的差异
14.SDLC VS.STLC
15.Bug, Defect, Error, Fault 和 Failure之间的区别
16.测试和调试之间的区别
17.前端测试 VS.后端测试
18.HLD和LLD的区别
19.BRS vs SRS
20.正面测试和负面测试之间的区别
21.自上而下和自下而上的集成测试之间的区别
22.用例和测试用例之间的区别
23.Monkey 测试 VS Gorilla 测试
24.Stubs和Drivers之间的区别
25.组件测试和单元测试之间的区别
26.软件测试和嵌入式测试之间的区别
27.GUI 测试和可用性测试之间的差异
28.SDET和Tester的区别
29.桌面应用程序测试、客户端-服务器应用程序测试和 Web 应用程序测试之间的区别
30.主动测试
31.什么是API
32.自动化测试
 
 
目录
需求可追溯性矩阵
来源:Javatpoint     翻译:Linda (火龙果软件)
1390 次浏览
1次  

1. 可追溯性矩阵

可追溯性矩阵是一种表型文档,用于开发软件应用程序以跟踪需求。它可用于向前(从需求到设计或编码)和向后(从编码到需求)跟踪。它也被称为需求可追溯性矩阵 (RTM) 或交叉参考矩阵 (CRM)。

它是在测试执行过程之前准备的,以确保每个需求都以测试用例的形式涵盖,这样我们就不会错过任何测试。在 RTM 文档中,我们映射了所有需求和相应的测试用例,以确保我们已经为每个条件编写了所有测试用例。

测试工程师将为各自的分配模块准备RTM,然后将其发送给测试主管。测试主管将进入存储库以检查测试用例是否存在,最后测试主管合并并准备一个必要的 RTM 文档。

本文档旨在确保每个需求都有一个测试用例,并且测试用例是根据客户端提供的业务需求编写的。如果缺少任何需求,它将在测试用例的帮助下执行,这意味着测试用例不是为特定需求编写的,并且该特定需求不会进行测试,因为它可能存在一些错误。编写可追溯性是为了确保涵盖整个要求。

我们可以在下图中观察到,没有提到需求编号 2 和 4 测试用例名称,这就是我们突出显示它们的原因,以便我们可以轻松理解我们必须为它们编写测试用例。

通常,这类似于包含表格的工作表文档,但也有许多用于可追溯性矩阵的用户定义模板。可追溯性矩阵中的每个需求都与其各自的测试用例相关联,以便可以根据特定要求按顺序执行测试。

注意:

我们在批准后和执行之前进行RTM,这样我们就不会错过任何要求的测试用例。

我们在编写测试时不编写 RTM,因为它可能不完整,并且在编写测试用例后,我们不会去这里,因为测试用例可能会被拒绝。

RTM 文档确保每个需求中至少编写一个测试用例,而它并不讨论为特定需求编写的所有可能的测试用例。

2. RTM 模板

以下是需求可追溯性矩阵 (RTM) 的示例模板:

2.1 RTM 模板示例

让我们提供一个 RTM 模板示例,以便更好地理解:

3. 可追溯性矩阵的目标

  • 它有助于跟踪在SDLC的各个阶段开发的文档。
  • 它确保软件完全满足客户的要求。
  • 它有助于检测任何错误的根本原因。

4. 可追溯性测试矩阵的类型

可追溯性矩阵可分为三种不同的类型,如下所示:

  • 前向可追溯性
  • 向后或反向可追溯性
  • 双向可追溯性

4.1 前向可追溯性

前向可追溯性测试矩阵用于确保每个企业的需求或要求在应用程序中正确执行,并经过严格测试。这样做的主要目的是验证产品开发是否朝着正确的方向发展。在这种情况下,需求被映射到测试用例的前进方向。

4.2 向后或反向可追溯性

反向或向后可追溯性用于检查我们是否通过增强设计元素、代码、测试业务需求中未提及的其他内容来增加产品空间。其主要目标是现有项目保持在正确的方向上。在这种情况下,需求被映射到测试用例的向后方向。

4.3 双向可追溯性

它是转发和后向可追溯性矩阵的组合,用于确保在测试用例中执行所有业务需求。它还评估由于应用程序中的错误而发生的需求的修改。

5. RTM 的优势

以下是需求可追溯性矩阵的好处:

  • 借助 RTM 文档,我们可以根据需要显示完整的测试执行和错误状态。
  • 它用于显示文档中缺少的要求或冲突。
  • 在这种情况下,我们可以确保完整的测试覆盖率,这意味着所有模块都经过测试。
  • 它还将考虑测试团队为重新设计或重新考虑测试用例所做的努力。

 

 


您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码: 验证码,看不清楚?请点击刷新验证码 必填



1390 次浏览
1次