软件检查指导原则

2023-06-16 16:23:03 78

测试表明存在缺陷

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

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

假设电子商务应用程序经历了几个测试阶段，并以优异的成绩通过了所有测试。尽管该应用程序在生产环境中取得了成功，但真正的最终用户尚未使用它。也许客户会使用测试可能忽略的罕见功能，认为没有人使用它。

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

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

为了成功进行早期测试，组织可以指定一个单独的团队来处理需求过程。为每个测试阶段选择一个代表会好得多。然后测试人员查看每个需求并在需要时进行修改。组织必须聘请经验丰富的测试人员，他们可以定义标准、明确意图并以绝对准确的方式准备测试用例。

该原则指出，不可能使用有效和无效的组合来测试所有功能。不仅繁重的测试需要无限的努力，而且它也不会给您预期的结果。因此，测试人员建议使用各种技术（如边界值分析和等价划分）仅使用少数组合。

创建系统所有可能的执行环境是不可能的，尤其是对于依赖于温度、天气、风速、压力等现实世界因素的软件。

用隐含的设计和假设开发的软件对于测试来说非常复杂。

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

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

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

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

开发的软件携带相同代码的可能性太小了。这意味着，测试人员无法按照银行应用程序的测试流程来测试电子商务应用程序。一切，包括方法、方法和测试类型，都因应用程序而异。

缺陷聚类是当大多数缺陷或错误集中在少数模块上时发生的现象。它可能由于模块的复杂性而发生。

缺陷聚类的原则遵循帕累托原则，即20%的模块可能包含80%的问题。这在大型系统中最为明显，其中特定模块由于某些因素而受到影响，例如：

系统尺寸

编码复杂度

修改

开发商的失误

缺陷聚类现象在测试设计人员中广泛流行。测试人员主要在风险评估和测试计划期间使用此信息。测试人员通常会专注于这些棘手的领域以发现更多缺陷，从而减少了发现缺陷的时间和成本。

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

没有比举例更好的方式来解释农药悖论了。假设您正在一个模块上运行一个测试周期。您发现了一些错误并将它们报告给开发团队。然后，他们修复了它并用新代码更新了你。

现在您使用相同的一组测试用例执行了另一个测试。这次您发现的错误比上次少。您再次将报告发送给相关团队进行修复。现在，在运行相同的测试用例时，您遗漏了一些东西。您如此沉迷于修复当前的缺陷，以至于您完全忘记了一些新的错误可能与最近的更改一起进入系统。

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

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

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