STLC - 测试基本原则

测试的共同目标是尽早发现错误。并且，一旦错误得到修复，确保它按预期工作并且不会破坏任何其他功能。

为了实现这些目标，软件测试有七个基本原则 −

测试显示了什么?

测试可以显示存在缺陷，但无法证明产品中没有缺陷。测试阶段确保被测应用程序根据给定的要求运行，并有助于降低应用程序中未发现缺陷的概率。但是，即使没有发现缺陷，也并不意味着它是绝对正确的。我们可以假设 AUT 符合我们的退出标准并根据 SRD 保持要求。

可以进行详尽测试吗?

除了简单情况外，不可能 100% 覆盖或测试所有输入组合和可能组合。除了详尽测试外，风险分析和优先级用于定义测试范围。在这里，大多数实时场景都可以考虑包括最可能的负面场景。这将有助于我们追踪失败。

早期测试

测试活动应尽快开始，并专注于测试策略中定义的目标和预期结果。测试的早期阶段有助于识别需求缺陷或设计级别差异。如果在初始阶段捕获这些类型的错误，它可以帮助我们节省时间并且也具有成本效益。为什么测试应该在早期开始，答案很简单——一旦收到 SRD，测试人员就可以从测试角度分析需求，并注意到需求差异。

缺陷聚类

根据之前的产品缺陷分析，可以说大多数缺陷都是从对应用至关重要的一小部分模块中识别出来的。这些模块可以根据复杂性、不同的系统交互或对不同其他模块的依赖性来识别。如果测试人员能够识别这些关键模块，他们就可以更加专注于这些模块，以识别所有可能的错误。一项研究发现，10 个缺陷中有 8 个是从 AUT 的 20% 功能中识别出来的。

农药悖论

什么是农药悖论——如果经常在农作物上使用农药，那么当昆虫产生某种抗药性时，喷洒的农药似乎对昆虫逐渐无效。

同样的概念也适用于测试。在这里，昆虫是虫子，而农药是用来反复运行的测试用例。如果一遍又一遍地执行相同的测试用例集，这些测试用例在一定时间范围后就会失效，测试人员将无法识别任何新的缺陷。

为了克服这些情况，应该不时修改和审查测试用例，并添加新的和不同的测试用例。这将有助于识别新的缺陷。

测试依赖于上下文

该原则指出，除非两种应用程序具有相同的性质，否则不能使用相同的方法测试两种不同类型的应用程序。例如，如果测试人员对基于 Web 的应用程序和移动应用程序使用相同的方法，那么这是完全错误的，并且产品发布的质量很差的风险很高。测试人员应该针对不同类型和性质的应用程序使用不同的方法、方法论、技术和覆盖范围。

没有错误 - 谬论

该原则指出，在应用程序或系统稳定之前查找缺陷并修复它们非常耗时，也会消耗资源。即使修复了 99% 的缺陷，应用程序仍然不稳定的风险很高。首先要验证应用程序的稳定性和环境的先决条件。如果满足这两个条件，我们才能开始详细测试。