单元测试针对详细设计，如何执行基于需求的测试ISO 29119？对单元需求的可跟踪性？

Question

根据ISO 29119和ASPICE等标准，V模型的左侧包含需求、体系结构设计和详细设计。在测试方面，有单元/组件测试、集成测试、资格测试。而ISO 29119提到的测试应该根据对测试项目的期望和测试基础中所描述的内容来执行。对于单元/组件测试，测试项是隔离的原子SW组件，测试基础是原子SW组件的详细设计文件。

那么，我的问题是:原子SW组件应该做什么？-->这不是SW组件的要求吗？如果是，这是否意味着在详细的设计文档中，原子的SW组件需求会被记录下来，并在单元测试中进行测试。当标准要求执行基于需求的测试时，这就是他们的意思吗？

如果我们不在详细设计文档中编写原子的SW组件需求，那么为什么在单元测试规范和详细设计之间存在可追溯性，而在单元测试和需求之间没有可追溯性。

标准太混乱了，我迷路了。请帮帮忙。

Answer 1

你的问题真让人困惑！

简单的想法是，您应该能够将测试追溯到需求。否则，你为什么要测试不需要的行为！

显然，在实践中，没有人会像他们的单元测试那样详细地编写需求。即

“加法类将有一个函数Add()，它将两个int相加并返回结果，这应该是这些int的总和。”

他们只会写

“当我在篮子里添加一个项目时，总价格应该相应地更新”

现在我说“没有人”写的要求在这个层次的细节，但这是一个谎言。如果你正在向太空发射火箭，你可能会去做，你可能也想要一个测试，你会给这个测试一个数字，并检查需求是否有测试等等。

这会使你符合标准。

或者，您也可以忽略所有没有需求的单元测试，只记录符合标准的测试。

Answer 2

为了更好地理解，一个人需要熟悉自己

1. 整个V模型是如何工作的，术语是什么，以及
2. 根据这些标准进行的测试是如何工作的。

为此，我建议检查ASPICE手册(3.1版)，特别是检查附件D(至少在3.1版中)是很有说明性的。另外，使用ASPICE进行专业开发通常意味着有一个可以供工程师咨询的人(通常这应该是质量经理的角色)。

V模型背后的理念是自上而下的设计，首先收集和分析需求，然后创建体系结构，然后通过详细的设计来描述最小的建筑元素。通常，所有这些都不需要编码(比如编写将要执行的实际代码，无论是以编译或解释的方式)。只有V的左边的最后一步，详细的设计是用特定的编程语言实现的，最后的“二进制”被创建了(引号是有意的，因为历史上有一种对编译语言的偏见，但是如果你愿意的话，你可以想把所有必要的源文件用一种解释语言拼凑成“创建二进制图像”)。

作为这个过程的一部分，每个软件元素最终将被链接到某些需求。代码中的多个独立部分可能涵盖了一些需求，有些代码可能涵盖多个需求。

现在对于测试:重要的是要测试的对象和测试规范之间的区别(用你的话说是什么)。

对象总是二进制的。根据所讨论的测试级别，它可能更小(单元测试)、更大(集成测试)或所有正在开发的软件的完整二进制(资格测试)。

测试规范是从测试运行的每个特定级别上的软件描述派生出来的：

• 单元测试验证二进制(单元)按照详细设计的行为。因此，这意味着测试低级别的算法。对于编译语言(假设C)，最基本的测试(甚至更好的先决条件)是“源文件编译成对象文件吗？”当然，这只是第一步，但这是单元测试工作的复杂性水平。
• 集成测试验证二进制(几个集成在一起的单元)根据体系结构(顾名思义，这里重要的是组件之间的通信以及它们是否正确地组装在一起)的行为。通常需要测试的一件事是API的正确性，各个单元通过API进行通信。先决条件：“所有对象文件是否都正确链接到库中？”体系结构通常还包括动态视图(定时等)，因此有许多不同类型的测试。
• 资格测试验证整个软件是否符合要求。只有在这里，您实际上是在测试需求，因为这些需求是针对整个软件的。

这就是说，我认为您问题的核心可以这样回答:软件单元可以追溯到需求，但是单元测试和集成测试不需要测试需求。这甚至是不可能的--在需求和单元之间很少有1:1的对应。其背后的原因是，实际单元不仅不依赖于需求，也不直接依赖于需求--它们受到体系结构和其他约束的影响，这可能是由于许多原因(几种备选方案之间的架构/设计决定、附加标准、硬件/系统限制)。

顺便提一句:对于新的程序员来说，这一整个过程的想法似乎常常是危险的，而且经常被认为是太多的开销，但不知怎么的，它已经在实践中得到了证明。这是某些行业(航空航天、铁路、汽车、医疗)需求的原因。一旦人们的生命危在旦夕，游戏规则就不同于“更平常”的编程(商业个人软件、游戏、网络应用程序)。