SWEBOK软件工程知识体系 - 4.软件测试

最新推荐文章于 2022-10-29 10:39:26 发布

啊哼哼

最新推荐文章于 2022-10-29 10:39:26 发布

阅读量1.4k

点赞数

分类专栏： # SWEBOK V3.0 软件工程知识体系指南

本文链接：https://blog.csdn.net/imlichao/article/details/111907628

版权

在这里插入图片描述

软件测试（SOFTWARE TESTING）

软件测试包括动态验证一个程序在一组有限的测试用例上提供了预期的行为，这些测试用例是从通常无限的执行域中选择的。
在上述定义中，粗体字对应于描述软件测试知识领域（KA）的关键问题：

动态：这一术语意味着测试总是对选定的输入执行程序。因为一个复杂的系统，仅仅用一个不确定的输入值来指定一个不确定的行为是不够的。然而，在本KA中，术语“输入”将被保留，其隐含的约定是，其含义在其重要的情况下也包括指定的输入状态。静态技术不同于动态测试，是动态测试的补充。静态技术包含在软件质量KA中。值得注意的是，不同社区的术语并不统一，有些社区使用术语“测试”也指静态技术。
有限：即使是在简单的程序中，理论上也有很多测试用例，因此穷举测试可能需要数月或数年才能执行。这就是为什么在实践中，一套完整的测试通常被认为是无限的，测试是在所有可能的测试的子集上进行的，这是由风险和优先级标准决定的。测试总是意味着一方面有限的资源和时间表，另一方面固有的无限测试需求之间的权衡。
选择：许多提议的测试技术在如何选择测试集上有本质的不同，软件工程师必须意识到，不同的选择标准可能产生不同程度的有效性。如何在给定的条件下确定最合适的选择标准是一个复杂的问题，在实践中，风险分析技术和软件工程的专业知识被应用。
预期：必须有可能（尽管并非总是容易）决定所观察到的程序测试结果是否可接受；否则，测试工作是无用的。可以对照用户需求（通常称为验证测试）、规范（验证测试）或潜在需求或期望的预期行为检查观察到的行为（见软件需求KA中的验收测试）。

近年来，软件测试的观点逐渐成熟为一种建设性的观点。测试不再被视为一种只在编码阶段完成后才开始的活动，而检测失败的目的有限。在整个开发和维护生命周期中，软件测试是或应该是无处不在的。实际上，软件测试的规划应该从软件需求过程的早期阶段开始，测试计划和程序应该系统地、持续地开发，并且可能随着软件开发的进行而细化。这些测试计划和测试设计活动为软件设计者提供了有用的输入，并有助于突出潜在的弱点，例如文档中的设计疏忽/矛盾或遗漏/含糊不清。

对于许多组织来说，提高软件质量的方法是预防：预防问题显然比纠正问题要好得多。因此，可以将测试视为提供有关软件功能和质量属性的信息的一种手段，也可以在错误预防无效的情况下识别故障。这也许是显而易见的，但值得承认的是，即使在完成了广泛的测试活动之后，软件仍然可能包含错误。交付后遇到的软件故障通过纠正性维护解决。软件维护主题包含在软件维护KA中。

在软件质量KA（参见软件质量管理技术）中，软件质量管理技术主要分为静态技术（无代码执行）和动态技术（代码执行）。这两个类别都很有用。本文主要研究动态技术。

软件测试也与软件构建相关（参见软件构造KA中的构建测试）。尤其是，单元测试和集成测试与软件构建密切相关。

软件测试KA的主题分解：
在这里插入图片描述

1.软件测试基础

1.1.测试相关术语

1.1.1.测试术语及相关定义

引用的参考文献中提供了测试和测试相关术语的定义，总结如下。

1.1.2. 故障与错误

软件工程文献中使用了许多术语来描述故障：fault, failure 和 error等等。对于系统很重要必须查明原因的故障（使用fault）和以交付系统中不期望的结果（使用failure）。事实上，软件中很可能存在从不以失败的形式表现出来的错误（参见第1.2节“关键问题”中测试的理论和实践限制）。因此，测试可以揭示故障，而且必须排除故障。当区别不重要时，更通用的术语“缺陷”可以用来指故障或失败。

然而，应该认识到失败的原因不能总是明确地确定。一般来说，没有理论标准可以确定导致观测到的故障的原因。可能会说，这是必须修改的错误，以消除失败，但其他修改可能也可以工作得很好。为了避免歧义，可以使用导致失败的输入，而不是错误，即导致出现失败的输入集。

1.2.关键问题

1.2.1.测试选择标准/测试充分性标准（停止规则）

测试选择标准是一种选择测试用例或确定一组测试用例足以满足特定目的的方法。测试充分性标准可用于决定何时完成或已完成足够的测试[4]（见第5.1节“实际考虑”中的终止）。

1.2.2.测试有效性/测试目标

测试有效性是通过分析一组程序执行来确定的。要执行的测试的选择可以由不同的目标来指导：只有根据所追求的目标才能评估测试集的有效性。

1.2.3. 缺陷发现测试

在缺陷发现测试中，成功的测试是导致系统失败的测试。这与证明软件满足其规范或其他期望属性的测试有很大不同，在这种情况下，如果在实际的测试用例和测试环境中没有观察到任何失败，那么测试就是成功的。

1.2.4. 预言问题

预言是任何人或机械代理，它决定一个程序在给定的测试中的行为是否正确，并相应地得出“通过”或“失败”的结论。存在许多不同类型的预言；例如，明确的需求规范、行为模型和代码注释。自动化的机械化预言可能是困难和昂贵的。

1.2.5.测试的理论和实践局限性

测试理论警告不要将不合理的信心归因于一系列成功的测试。不幸的是，测试理论的大多数既定结果都是否定的，因为它们指出了测试永远无法实现的东西，而不是实际实现的东西。在这方面最著名的引用是Dijkstra的格言，“程序测试可以用来显示bug的存在，但决不能显示它们的不存在”[5]。明显的原因是，在现实的软件中，完整的测试是不可行的。因此，测试必须基于风险[6，第1部分]来驱动，并且可以看作是一种风险管理策略。