软件检查指导原则

测试表明缺陷的存在

每个应用程序在发布到生产环境之前，都必须经过一系列测试阶段，例如系统集成测试、用户验收测试和 Beta 测试等。无论进行多少测试，总会发现某种形式的缺陷。

测试团队的核心目标应集中在查找应用程序中的缺陷。检查团队必须使用不同的方法来发现尽可能多的错误。这有助于减少软件应用程序中未发现的错误数量。即使测试团队没有发现任何缺陷，也并不意味着软件是 100% 完美的。

假设一个电子商务应用程序经过多个测试阶段，并顺利通过所有测试。尽管该应用程序在生产环境中成功运行，但最终用户尚未使用它。也许客户会使用测试团队可能忽略的罕见功能，因为他们认为没有人会使用它。

尽早测试

在 SDLC 的早期阶段进行测试使测试人员能够在需求分析阶段或文档阶段发现缺陷。测试人员需要做的是在需求确定后立即进行测试过程。在早期阶段修复缺陷的成本几乎比在后期修复错误的成本低十倍。

测试团队必须在将新代码添加到现有代码结构之前测试代码集成。此外，测试人员必须运行进一步的测试，以确保修改后的代码正确集成。这是引入 1:10:100 规则的地方。该规则指出，在用户验收测试期间修复缺陷的成本是开发阶段修复缺陷成本的十倍。如果缺陷在发布后未被发现，则成本将增加 100 倍。

为了成功进行早期测试，组织可以指定一个单独的团队来处理需求过程。最好为每个测试阶段选择一名代表。然后，测试人员检查每个需求并在必要时进行修改。组织必须聘用经验丰富的测试人员，他们能够定义标准、指定意图并以极高的准确性准备他们的测试用例。

详尽测试是不可能的

该原则指出，使用有效和无效组合测试所有功能是不可能的。详尽的测试不仅需要无限的努力，而且也不能提供预期的结果。因此，测试人员建议仅使用边界值分析和等价划分等各种技术的一些组合。

为什么详尽测试在大多数测试用例中都会失败？

• 创建系统的全部可能的执行环境是不可能的，特别是对于依赖于现实世界因素（如温度、天气、风速、压力等）的软件。

• 使用隐含设计和假设开发的软件对于测试来说极其复杂。

• 测试有效输入和无效输入可能太大而无法用于测试系统。

• 具有大型输入域以及输入时间约束的程序可能导致测试失败。

详尽测试将需要无限的努力，并且大部分努力都是无效的。此外，项目时间表不允许测试如此多的组合。因此，建议使用等价划分和边界值分析等各种方法来测试输入数据。

测试依赖于上下文

市场包含多个领域，例如医疗保健、银行、旅游、广告等。每个领域的应用程序都具有独特的功能。因此，它需要不同的需求、测试过程、风险分析和技术。这种领域的多样性使测试成为一个依赖于上下文的流程。

开发的软件携带相同代码的可能性非常小。这意味着测试人员不能遵循银行应用程序的测试过程来测试电子商务应用程序。从方法、方法到测试类型，一切都因应用程序而异。

缺陷聚集

缺陷聚集是一种现象，当大多数缺陷或错误集中在少数模块上时发生。这可能是由于模块的复杂性造成的。

缺陷聚集原则遵循帕累托法则，该法则指出 20% 的模块可能包含 80% 的问题。在大型系统中，由于某些因素（例如）导致特定模块受到影响，这一点最为明显。

• 系统规模
• 编码复杂度
• 修改
• 开发人员的错误

缺陷聚集现象在测试设计人员中普遍存在。测试人员大多在风险评估和测试计划中使用此信息。测试人员通常专注于这些棘手区域以查找更多缺陷，从而减少查找缺陷的时间和成本。

杀虫剂悖论

这种现象杀虫剂悖论指出，反复测试软件会使其对缺陷免疫，就像昆虫对杀虫剂产生抗药性一样。

没有什么比用例子来解释杀虫剂悖论更好的了。假设您正在对某个模块运行测试周期。您发现了一些错误并将其报告给开发团队。然后，他们修复了它并向您提供了新的代码。

现在您使用相同的测试用例执行了另一个测试。这次您发现的错误比上次少。您再次将报告发送给相关团队进行修复。现在，在运行相同的测试用例时，您错过了某些内容。您过于专注于修复当前的缺陷，完全忘记了随着最近的更改，一些新的错误可能已进入系统。

因此，建议测试人员使用一组新的测试用例，重点关注多个热点或模块。将新的测试用例与现有测试用例一起添加也有助于避免杀虫剂悖论。

无错误谬误

该原则指出，没有哪个软件是 100% 没有缺陷的。仅仅因为软件经过测试证明 99% 没有缺陷，并不意味着剩下的 1% 不值得关注。可能测试人员根据错误的要求对其进行了测试。

例如，一个测试团队使银行软件 99% 没有缺陷，并将其提交给管理层。尽管软件没有缺陷，但管理层并不满意，因为它希望软件具有简单的 UI 和高用户负载容量。在这种情况下，测试团队无法满足最终需求，因为他们过于专注于产品的质量。

Vineet Nanda

更新于：2021 年 3 月 6 日

220 次查看

启动您的职业生涯

通过完成课程获得认证

开始