软件测试原理


软件测试原理

软件测试是实施软件或应用程序以识别缺陷或错误的过程。对于应用程序或软件的测试,我们需要遵循一些原则来使我们的产品没有缺陷,这也有助于测试工程师用他们的精力和时间来测试软件。在本节中,我们将学习软件测试的七个基本原则。

让我们一一看看七种不同的测试原则:

  • Testing shows the presence of defects
  • Exhaustive Testing is not possible
  • Early Testing
  • Defect Clustering
  • Pesticide Paradox
  • Testing is context-dependent
  • Absence of errors fallacy

软件测试原理

测试表明存在缺陷

测试工程师将测试应用程序以确保应用程序没有错误或缺陷。在进行测试时,我们只能识别应用程序或软件有任何错误。做测试的主要目的是借助各种方法和测试技术来识别未知错误的数量,因为整个测试应该可追溯至客户需求,这意味着找出任何可能导致产品无法满足要求的缺陷客户的需求。

通过对任何应用程序进行测试,我们可以减少错误的数量,这并不意味着应用程序没有缺陷,因为有时在对其执行多种类型的测试时,软件似乎没有错误。但是在生产服务器部署的时候,如果最终用户遇到了那些在测试过程中没有发现的bug。

详尽的测试是不可能的

有时,在整个实际测试过程中,使用输入数据的有效和无效组合来测试所有模块及其功能似乎非常困难。

因此,不要进行详尽的测试,因为它需要无限的决心,而且大部分努力工作都没有成功。所以我们可以根据模块的重要性来完成这种类型的变化,因为产品时间表不允许我们执行这种类型的测试场景。

早期测试

这里的早期测试是指所有的测试活动都应该在软件开发生命周期的需求分析阶段的早期阶段开始,以识别缺陷,因为如果我们在早期发现错误,它会在初始阶段自行修复,即与在测试过程的未来阶段确定的那些相比,我们可能花费更少。

为了进行测试,我们将需要需求规范文件;因此,如果需求定义不正确,那么它可以直接修复,而不是在另一个阶段修复它们,这可能是开发阶段。

Defect clustering

defect clustering定义了在整个测试过程中,我们可以检测到与少量模块相关的错误数量。我们对此有多种原因,例如模块可能很复杂;编码部分可能很复杂,等等。

这些类型的软件或应用程序将遵循Pareto Principle,该原则指出我们可以识别大约 80% 的复杂性存在于 20% 的模块中。借助这个,我们可以找到不确定的模块,但是如果定期执行相同的测试,这种方法有其困难,因此相同的测试将无法识别新的缺陷。

Pesticide paradox

这个原则定义了,如果我们在特定时间内反复执行同一组测试用例,那么这些类型的测试将无法发现软件或应用程序中的新错误。为了克服这些农药悖论,经常回顾所有的测试用例是非常重要的。并且需要为应用程序或软件的多个部分的实现编写新的和不同的测试,这有助于我们发现更多错误。

测试是依赖于上下文的

测试是一个上下文相关的原则,即我们有多个领域,如电子商务网站、商业网站等在市场上可用。有一种明确的方法可以测试商业网站和电子商务网站,因为每个应用程序都有自己的需求、特性和功能。为了检查这种类型的应用程序,我们将借助各种测试、不同的技术、方法和多种方法。因此,测试取决于应用程序的上下文。无错误谬误

一旦应用程序经过全面测试并且在发布之前没有发现任何错误,那么我们可以说该应用程序 99% 没有错误。但是,当应用程序在不正确的要求旁边进行测试时,有可能发现缺陷并在给定的时间内修复它们,因为测试是在错误的规范上进行的,这不适用于客户的要求。没有错误谬误意味着如果应用程序不切实际且无法满足客户的要求和需求,则识别和修复错误将无济于事。