📜  STLC-测试基本原理

📅  最后修改于: 2020-12-04 04:44:25             🧑  作者: Mango


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

为了实现这些目标,软件测试给出了七个基本原则-

测试显示什么?

测试可以表明存在缺陷,但是无法证明产品中没有缺陷。测试阶段确保被测应用程序可以根据给定的要求运行,并且有助于减少应用程序中未被发现的缺陷的可能性。但是,即使未发现缺陷,也不表示它绝对正确。我们可以假设AUT符合我们的退出标准,并根据SRD保持了要求。

是否可以进行详尽的测试?

除琐碎的情况外,不可能对所有输入组合以及可能的组合进行100%的覆盖率或测试。代替详尽的测试,使用风险分析和优先级来定义测试范围。在这里,大多数实时方案都可以考虑包括最可能的负面方案。这将帮助我们跟踪故障。

早期测试

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

缺陷聚类

根据以前的产品缺陷分析,可以说,大多数缺陷是从对应用至关重要的少量模块中识别出来的。可以基于复杂性,不同的系统交互或对其他模块的依赖性来识别这些模块。如果测试人员可以识别这些关键模块,则他们可以将更多精力放在这些模块上,以识别所有可能的错误。在一项研究中,发现从20%的AUT功能中可以识别出十分之八的缺陷。

农药悖论

什么是农药悖论–如果农药经常在农作物上使用,那么当昆虫产生某种抗药性时,就会逐渐出现,这样喷洒的农药似乎对昆虫无效。

相同的概念也适用于测试。在这里,昆虫是虫子,而农药是用于一次又一次地运行的测试用例。如果一次又一次地执行相同的测试用例集,则这些测试用例将在一定时间范围内失效,并且测试人员将无法识别任何新的缺陷。

为了克服这些条件,应该对测试用例进行修订并不时进行审查,并可以添加新的和不同的测试用例。这将有助于识别新缺陷。

测试取决于上下文

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

没有错误–谬误

该原理指出了发现缺陷并加以修复,直到应用程序或系统稳定,既费时又消耗资源。即使修复了99%的缺陷,也存在很高的不稳定应用风险。首先,必须验证应用程序的稳定性和环境的先决条件。如果这两个条件都满足,则只有我们可以进行详细的测试。